Everything can be done automatically, as long as you configure it manually :-)
Short and sweet. My Windows 10 Toast Notification Script have received a minor update. Now being at version 1.2. The changes mentioned in details below.
This is not exactly an A-Z guide on the topic, but rather a story of my experiences with upgrading Windows 10 over the Internet with In-Place Upgrade (IPU) Task Sequence using ConfigMgr and how it works in my environment.
I’m using a Cloud Management Gateway (CMG) with enhanced HTTP as well as initially being connected to the on-premises infrastructure with Always On VPN. The VPN in this scenario is a user-initiated tunnel and thus obviously disconnects once the upgrade restarts the computer. It’s not completely without challenges and I will try to cover those during this post.
Curious? Read on 🙂
Oh yeah, seeing I now allow IPU to happen over the Internet, I also created something in Powershell App Deployment Toolkit which extraordinarily warns the user if the upgrade is being initiated from outside the office network. A preview of that in the end of the post 🙂
When installing Office 365 ProPlus today, the recommended and default architecture is 64-bit. It has been so for some time, but it’s not until lately (at time of writing) that the Office Deployment Tool (in short ODT), is able to migrate from 32-bit to 64-bit in a single operation.
I have tested the migration, both using Microsoft Intune and System Center Configuration Manager and the outcome is what made this blog post.
Note: Migrating Office 365 ProPlus like this, from 32-bit to 64-bit in production, probably has more to it in terms of considering third party add-ins. You will have to test and make sure those add-ins are compatible with the relevant 64-bit Office application. I expect there will be some migration paths for those as well, where you will need to remove the 32-bit add-in prior to migrating Office 365 ProPlus to 64-bit.
Similar to when Windows 10 v1809 was released back in October 2018 and RSAT debuted as “Features on Demand”, the way of installing RSAT continues with the v1903 release.
Back then I did a Powershell script which is able to install and uninstall the RSAT features. I have now rewritten the script to also include Windows 10 v1903.
Find my 1809 post here: https://www.imab.dk/deploy-rsat-remote-server-administration-tools-for-windows-10-v1809-using-sccm-system-center-configuration-manager/
First off, bear with me here during the intro. I know introductions usually are boring, but I do have a few words to share with you first.
The following is by no means any substitution for any other Modern Driver Management solution out there. This is purely me exploring, learning and sharing that experience with anyone who’s interested. When I find something useful, I usually try to do my own thing for various reasons, but mainly to learn and also for being less dependent on others work and future maintenance plans.
Now, this post is primarily about a Powershell script and how that Powershell script is designed to run on a given device and export the device drivers into your ConfigMgr source file library or locally. In the process, the script is able to create a regular package in ConfigMgr containing those drivers. The post is also about how to use the regular packages for applying drivers, but the script is what took the most of my time 🙂
The idea here is, that you fire up a given device with a given version of Windows (preferably Windows 10) and install ALL the drivers (preferably the latest drivers) and verify that everything works in that combination of Windows, drivers and hardware model.
Note: Most vendors provide a tool which checks online for latest drivers and gives you option to install those. This is pretty handy when building new drivers for a given computer model.
Now knowing that everything works, this is the drivers you want to apply to future deployments of this computer model, so you run the script and everything is automatically exported and a package in ConfigMgr is created.
In lack of a better name, this is what I call ‘Almost Modern Driver Management‘. 😀
PS. If you’re looking for a truly nifty and ‘modern’ approach, I suggest you head over to SCConfigMgr.com and take a peek at their solutions for both BIOS and drivers.
Installing the OneDrive for Business client on a per machine basis is an often requested feature and for good reasons. OneDrive in it’s current state in the production ring, is installing into the users profile in %localappdata%, and for equally good reasons that is often not desired by enterprises.
Now, Microsoft has finally given us an option, allowing us to install OneDrive for the device into %programfiles(x86)%. The option is currently in preview and all the juicy details are found here: https://docs.microsoft.com/en-us/onedrive/per-machine-installation
PS. Credit where due: I was inspired by Per Larsen’s post on doing the same with Microsoft Intune and like many times before, this brought me to doing something on my own for the sharing and learning experience. Enjoy. 🙂
Since my previous WaaS posts, I have received a few inquiries about how to do drivers when precaching the content prior to running the actual In-Place upgrade. As of such, I figured it would make a great blog post covering the approach I’m currently using.
So this is me doing just that, as a small addition to what I have previously covered with my PreCache and In-Place Upgrade Task Sequences.
Note: I’m brewing on a complete WaaS section on here, sharing all and everything I do in details in regards to Windows Servicing. This will be available from this link once I get there: https://www.imab.dk/windows-as-a-service/
UPDATE: The script used here has been severely updated: https://www.imab.dk/windows-10-toast-notification-script/. The scenario described here is still relevant though, so I recommend that you still read through this 🙂
This will be a small but exciting contribution to my ‘Windows as a Service’ series!
The usual story here is, that everyone wants to add more user-friendliness to the whole experience around Windows Servicing.
End-users generally doesn’t care about new versions of Windows and they also, generally speaking, find interruptions in their work annoying, especially if those interruptions come unexpected.
So we come up with clever solutions to solve those problems and this will be an addition to that; remind the user with a big nice Windows toast notification when a Windows upgrade is pending. This is for the obvious reminder, but also to lure the end-user into a voluntary participation.
Find some of my previous WaaS posts here:
Part 1: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-1/
Part 2: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-2/
This is an extremely hot topic and I do know that we have some awesome OSD experts out there sharing their content already (Gary Blok, Mike Terrill etc.). Now, their content is way superior to mine and probably suit a lot of needs already, but I think that content around WaaS in particular is interesting and especially when sharing how one does Windows Servicing in details.
So, this is me doing just that – sharing my precaching and in-place upgrade task sequences – in details. This will be a lengthy post, so grab a good cup of coffee ?
Also, this is based on a mid-size company in Denmark and we don’t manage thousands and thousands of devices. WaaS is a small part of my daily job and I’m the only one doing it, so the time and effort put into this is reflecting the size of the company and the resources available, but is still done with an eye on the detail. With that being said, some of the stuff I do here is done with inspiration from how some of the mentioned people does it (credit where due during the posts). If you find yourself in similar position or just need some more inspiration – then this will be for you 🙂
Update! The content in this post, has been updated: Windows as a Service: Sharing my PreCache and In-Place Upgrade Task Sequences – 20H2 edition, part 1
This is an extremely hot topic and I do know that we have some awesome OSD experts out there sharing their content already (Gary Blok, Mike Terrill etc.). Now, their content is way superior to mine and probably satisfy a lot of needs already, but I think that content around WaaS in particular is interesting and especially when sharing how one does Windows Servicing in details.
So, this is me doing just that – sharing my precaching and in-place upgrade task sequences – in details. This will be a lengthy post, so grab a good cup of coffee 🙂
Also, this is based on a mid-size company in Denmark and we don’t manage thousands and thousands of devices. WaaS is a small part of my daily job and I’m the only one doing it, so the time and effort put into this is reflecting the size of the company and the resources available, but is still done with an eye on the detail. With that being said, some of the stuff I do here is done with inspiration from how some of the mentioned people does it (credit where due during the posts). If you find yourself in similar position or just need some more inspiration – then this will be for you 🙂
