Earlier this afternoon I was watching the Deploying Windows 10: Automating Deployment by Using System Center Configuration Manager live event from Microsoft Virtual Academy (MVA). The three sessions were presented by Aaron Czechowski and Wally Mead, both well known profiles within the ConfigMgr space. Here follows a summary of the live event:
Event Summary
The event was divided in three sessions:
- Preparing Your Environment for System Center Configuration Manager
- Configuration Manager Operating System Deployment Concepts
- Deploying and Supporting Windows 10
So let's break it down per session:
Preparing Your Environment for System Center Configuration Manager
In addition to the speaker introductions, they started by announcing the availability of a free Windows 10 deployment book written by Andre Della Monica, Russ Rimmerman, Alessandro Cesarini, and Victor Silveira. The book is titled Deploying Windows 10 and can be downloaded from http://mva.microsoft.com/ebooks, together with many others. This book has indeed some valuable info on deploying Windows 10. Good stuff.
Then Wally took the lead and talked about Windows 10 support in ConfigMgr, and to summarize that part: If you want to both deploy and service Windows 10, you should be on ConfigMgr Current Branch. And continuing on ConfigMgr Current Branch, Aaron took over and talked about how that version supports the faster pace of updates for Windows 10 and Microsoft Intune, he talked about using it to simplify the inplace-upgrade scenarios and the product actively listens to customer feedback and are adding more features faster than ever before.
Then the upgrade and migration paths to ConfigMgr Current Branch were explained, and basically, of you are on ConfigMgr 2012 SP1 or higher you can do an inplace upgrade, if you are on older versions, even counting ConfigMgr 2007, you have to migrate to the new platform. A nice little feature that was introduced with ConfigMgr v1602 was also mentioned: The ability to do an inplace upgrade of the underlying operating system. For example going from Windows Server 2008 R2 to Windows Server 2012 R2. Then Wally took over and walked through all needed steps for an upgrade.
Configuration Manager Operating System Deployment Concepts
The next module was the OSD basics, covering Windows ADK versions, boot and OS images, upgrade packages, drivers, and task sequences. The initial takeaway was to basically stay away from Windows ADK 10 v1507 (build 10240), because of issues with PowerShell, MDAC and static IP addresses, and instead use Windows ADK 10 v1511 (build 10586) with KB3143760 installed. You really need the KB3143760 or WinPE will fail to stage on the hard drive in for example computer refresh scenarios. You can read more about this in the Issue with the Windows ADK for Windows 10, version 1511 ConfigMgr team blog.
Another thing that was mentioned was the need for ICD to be installed if you want to use the bulk enrollment features for Windows 10 in ConfigMgr. The ConfigMgr setup prereq checker will not tell you it's needed, but it is if you want to use that feature.
Next up was performing Windows 10 inplace-upgrades with ConfigMgr Current Branch, and they also pointed out a bug when pre-provisioning of BitLocker didn't work for Windows versions older than Windows 10 v1511. The workaround is found on a blog with a record long title 🙂 Windows versions prior Windows 10 build 1511 fail to start after "Setup Windows and Configuration Manager" step when Pre-Provision BitLocker is used with Windows PE 10.0.586.0 (1511).
Another thing that was demoed, was a new safety mechanism in regards to drivers. This was added already in ConfigMgr 2012 R2 SP1 but prevents you from accidentally inject a x86 driver into a x64 boot image or the other way around.
Deploying and Supporting Windows 10
In the final module they went into more details on Windows 10 readiness assessment, Windows 10 deployments (bare metal and inplace-upgrade), monitoring , Windows 10 dashboard and Windows 10 servicing.
One really nice thing about the Windows 10 setup is the compatibility scan, and the built-in option in the ConfigMgr task sequence that uses it. This option is obviously there to make sure that applications and hardware is compatible with Windows 10, and in the demo Aaron added an extra upgrade action to the task sequence, to have the task sequence figure out if the setup would work or not, and only try to actually run it, of the compatibility scan gave a green light.
The compatibility scan will always spit out a non-zero return code, for example 0xC1900210 which is the no issues found return code. The return code is set in a new read-only task sequence variable, the _SMSTSOSUpgradeActionReturnCode variable, and the reason for having a variable that, is so you can use it further down the line in the task sequence. The important thing is that even though Windows setup spits back a hexadecimal value, ConfigMgr reads it as a decimal value, so you need to do some conversion. For example 0xC1900210 in hex is 3247440400 in decimal.
Converting 0xC1900210 to decimal (3247440400).
So below are some screenshots from my lab, showing the same setup that Aaron did in the demo. I've added in an extra Upgrade Operating System action, configured it to continue on error, and renamed it to Upgrade Assessment. then I added a condition to the Upgrade the Operating System group, to only run if the return code from the assessment is success, e.g. 3247440400 in decimal. Pretty nice. Aaron also hinted that there is work in progress to enhance the setup assessments, something to arrive later this year 🙂
The extra Upgrade Operating System action added, renamed to Upgrade Assessment, and configured to run the setup assessment.
The extra Upgrade Operating System action, also configured for continue on error.
The condition added to the Upgrade the Operating System group, only to run if the assessment showed no issues.
Next up was Wally demonstrated how to deploy a task sequence, showing the updated deployment verifications that shows up when deploying a task sequence to collections containing more than the configured threshold of machines for a high risk deployment. Wally showed the Deployment Verification dialog box where you actually have to select the "I want to create this high risk deployment" check box, with the "This will generate an audit status message" text next to it.
Aaron then added in that Microsoft IT used to offer inplace-upgrade task sequences as available, but recently switched into required. They way they do this is to make the task sequence available on a specific date, but set the deadline later, allowing the users to start it when they want to (within those dates). They also communicated out of course that this change were coming 🙂
After the deployment where started the focus was shifted into monitoring of OS deployments, and they talked about In-console monitoring and reports being the two primary monitoring methods. That's where I disagree with Wally and Aaron, there are many more options available, for example with the MDT integration, but I'll be a nice citizen for now 🙂
'
Smile of the day
Biggest laugh in the session was when Aaron mentioned that even in the TV studio they had a system that was having some problems, and at time Wally chimed in and said "I didn't say that, Aaron did", and then the TV studio team yelled and said that Aaron made that up and they never had any problems what so ever in the studio. If I was sitting in my hotel room with a big stupid grin all over my face? Oh Yes! 🙂
Anyway, Aaron also did mention, that in great conditions an inplace upgrade can be done in 30 minutes, but it often takes longer than that. In my own experience up to two hours.
Back on track
Anyway back to monitoring, Wally explained that to use in-console monitoring, you simply do the following:
Click the monitoring workspace, then select deployments
Find the task sequence to monitor
Summarize the results (will take a few Microsoft seconds)
View the status
, and select the status tab of interest (such as "In Progress" or "Error")
Select an asset in that state and click more details.
After that Wally continued explaining how to monitor OS Deployments with reports:
Click the monitoring workspace, expand Reporting, expand Reports, and the select the node of interest.
There are for nodes for monitoring OS deployment:
– Task Sequence – Deployment Status (11 reports)
– Task Sequence – Deployments (11 reports)
– Task Sequence – Progress (5 reports)
– Task Sequence – References (1 report)
Wally also mentioned that the SRS Reports website is great when you need others to monitor the status, but don't want to give them access to the ConfigMgr console.
After the monitoring piece, Aaron switched over the to the ability of seeing the status of your Windows 10 environment. For example what builds of Windows 10 that are deployed, how many clients running each build, how many clients having builds that are nearing end of life, and how many clients having builds that are already expired.
After that they switched to the Windows 10 servicing plan feature, which allows you to create servicing plans to upgrade Windows 10 builds. Pretty much a copy of the Automatic Deployment Rules (ADR) for software updates. To summarize that part, don't use it 🙂 It's not really ready for production deployments yet (sorry Aaron/Wally). It simply doesn't yet support adding drivers, adding language packs, and doing compatibility pre-assessments. This is planned for the future, so in the meantime, if you are doing inplace-upgrades, use task sequences for now.