I hope you managed to join our recent webinar on avoiding creaking infrastructure, stressed IT staff and cranky users during your Windows 10 migration. We covered a number of steps you can start taking now to prepare for a smooth migration to Windows 10 and talked about ways to automate the process. We had a few questions during the Q&A session that I’ve written up in this blog for your reference.
Q: Can I upgrade from SCCM 2012 R2 SP1 to CM Current Branch 1602?
A: You will need to upgrade to Current Branch 1511 first. 1511 is considered a ‘baseline’ version, so you can upgrade SCCM 2012 sites or install new sites using the 1511 version. The 1602 release is only available as an ‘in-console’ update, so you’ll need to install 1511 first. 1511 will add the new Service Connection Point necessary to install the later ‘in-console’ updates. If you’re building a new site from scratch – in some scenarios, you might want to build a parallel environment and migrate your existing clients and objects across – you can start with 1511 then download and install the 1602 update. 1602 also allows you to do an in-place upgrade of the OS (from Server 2008 R2 SP1 to Server 2012 R2), but you have to go through the ConfigMgr upgrade to 1602 before you go on to upgrade the OS.
Q: Our ConfigMgr Site Server doesn’t have access to the internet. How do we get the Current Branch in-console updates?
A: The Service Connection Point site system replaces the Microsoft Intune connector and provides the additional functionality of uploading CM usage data and downloading relevant CM in-console updates. You can install this site system on a server that does have internet access. Alternatively, as long as you’re not integrating Intune with CM, you can use the Service Connection Point in offline mode and run the Service Connection Tool from another device that does have an Internet connection and download the updates from that device. You do have to get some telemetry data from the site server too – this process is documented in TechNet.
Q: Can I use ConfigMgr Hardware Inventory to determine if a PC is using UEFI?
A: Yes – you can do this by collecting the UEFISecureBootEnabled registry value from HKLMSystemCurrentControlSetControlSecureBootState through a custom data class. If the registry value does not exist, the reported value will be NULL and the PC is using or emulating BIOS. If it has a numeric value, the PC is running native UEFI. Check out Mike Terrill’s blog, or the online help for the 1E Windows 10 Readiness Dashboard for details on how to do this.
Q: Does the 1E Windows 10 readiness dashboard require the ConfigMgr hardware inventory to be extended?
A: Most likely. Some of the tiles in the dashboard can be generated using default inventory properties, but some will require properties that are available but not collected by default. Some, like the UEFI status will most likely require extending the hardware inventory.
Q: With the Microsoft peer-to-peer solutions, how well are you able to monitor to ensure content is there in advance?
A: The only one you can really do that with is the Windows PE Peer Cache. You can create a Task Sequence that has all the reference packages in it and you use the Download Package Content task in the Task Sequence. You’ll need to add logic to prevent the content from being installed if you just want to prestage the content and set the SMSTSPreserveContent variable in the Task Sequence. You can then deploy the Task Sequence to the devices you want to prestage the content on and use Status Reporting to monitor which machines it succeeded on.
Q: Do I need Shopping and AppClarity to do intelligent application mapping?
A: It’s possible to engineer a form of application mapping using the Microsoft Deployment Toolkit. If you’re doing that, you’re at the mercy of mapping the application display names as they appear in Programs and Features to specific Package/Program combinations in Configuration Manager. You may have lots of different versions of an application – even just minor version differences – that would each need to be mapped to the Package/Program that will install the desired application. AppClarity does all the inventory normalization for you, so you can just identify an installation as WinZip 16 for example, which will include all minor versions of the WinZip 16 release. When you add applications in Shopping, you define the ConfigMgr Application or Package and Program that will install the application, so that bit is already done. You then simply make the association between the ‘normalized’ product release from AppClarity with the existing application in Shopping that will install the desired replacement.
Don’t forget to check out the other Windows 10 Migration and ConfigMgr content referenced in the session:
Don’t forget to register for our next Windows 10 Migration webinar on Wednesday 13th April – “When is your Windows 10 migration complete? Never!” where we’ll be looking at managing the Windows 10 servicing model.
