How to Avoid 5 Common Windows 10 Deployment Pitfalls

This year at the Midwest Management Summit (MMS), I co-presented a session with Johan Arwidmark covering the top ten issues we have seen in OS deployment over the last year. There are many issues outside of the ones we presented that could qualify as a top issue for many IT professionals. We decided to narrow our list to the top ten issues that we most frequently see on Twitter and in email. In this blog, I explain how to identify and resolve five that I feel you absolutely need to know. Read on to see if your issue made our list.

Issue #1

Category: ConfigMgr
Subject: ConfigMgr client is stuck in provisioning mode

The ConfigMgr client stuck in provisioning mode issue isn’t new, however it has been a while since we have seen it. With this issue, an affected endpoint does not see new deployments in Software Center. Understandably, this makes life extremely frustrating for the admin. There were two sets of advice floating around Twitter for how to properly fix the problem. The first (and incorrect) solution is to delete keys from the registry. This, my friends, is merely a band aid because what is set in the registry in this case is controlled by WMI.

The correct way to get a client out of provisioning mode is to run the following PowerShell script from an elevated prompt:
Powershell.exe Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false
If you would like more information about the issue, you can read the following TechNet article: Fix new deployments are unavailable in software center on configuration manager clients

Issue #2

Category: Windows 10 ADK
Subject: ADK 1607/1703 issues

ADK 1607
The two most recent ADKs are certainly not problem free. You could argue that all of them have problems. The most common issue I am questioned about is how to apply Windows 7 drivers during a sequence when using ADK 1607. To recap, the problem is an issue within the Windows 7 stack that Microsoft has no plan to resolve. Therefore, this will always be an issue in any ADK going forward until Windows 7 goes away. Since DISM doesn’t like applying Windows 7 drivers to fast disks (SSDs, etc.), you need to make an alternate plan.

Microsoft has issued a statement about the issue as well as several workarounds which you can read here.

Of all the listed workarounds, we believe that the “download driver package” workaround is the best option. Package creation is super quick and it allows for dynamic model selection if you apply an optional script. To get started quickly, do the following:

1. 1. Disable auto apply drivers step
   2. Add a download package content step
      1. Point to the driver package you created for the Windows 7 drivers for the model you want to deploy
      2. Specify the following custom path for the drivers: %_SMSTSMDataPath%\Drivers

The correct syntax to run the conversion tool within a Windows session

1. 1. Set a condition on each package such as a WMI query, Model Alias, or Model equals variable

Validate the disk

1. 1. Repeat steps 2 and 3 for each model you want the sequence to handle
   2. Add a “dummy drivers” package such as one that contains printer drivers
      1. Specify the following custom path for the drivers: %_SMSTSMDataPath%

Add a Run Command Line

1. Add a run command line step with the following:
   1. Name: Run DISM Install Drivers
   2. Command: DISM.exe /Image:%OSDTargetSystemDrive%\ /Add-Driver /Driver:%_SMSTSMDataPath%\Drivers\ /Recurse /forceunsigned /logpath:%_SMSTSLogPath%\dism.log

If you are interested in using Model Alias, this post that I wrote on using Model Alias with ConfigMgr will be helpful: https://deploymentresearch.com/Research/Post/587/Using-ModelAlias-for-ConfigMgr-Driver-Management. Just remember to change the action to download package content when it comes time to add the steps to the sequence.

If you are interested in using a script that makes model selection dynamic and bypasses the need to import the drivers to the database, then check out the post we have on the Deployment Research blog written by Matthew Teegarden: https://deploymentresearch.com/Research/Post/611/ConfigMgr-Driver-Management-in-just-four-steps-By-Matthew-Teegarden.

Kim Oppalfens has also written a blog on the topic as well as presented a session on it at MMS: The holy grail of ConfigMgr diver management, or whatever you want to call it.

ADK 1703
When ADK 1703 came out, admins everywhere were caught off guard when the installation failed. The error was caused by an unsigned driver that would cause the install to break if Secure Boot was enabled.

To get around the issue, Secure Boot needs to be disabled. This is only suitable in lab scenarios as it is not recommended to disable Secure Boot on a production machine.

To get the fix for the ADK issue, use this link.

Issue #3

Category: Drivers
Subject: Managing drivers in your boot image

The bottom line with this issue is that you need to be aware of what drivers belong in a boot image. The rule of thumb is you create a driver, and then boot into WinPE to run a test. If you open a command prompt and get an IP Address, then you don’t need a network driver. If you don’t get an IP Address, then you do need a network driver.

The next step is to determine if you need a storage driver. To test whether the disk is usable in WinPE, open a command prompt and run diskpart. If you can successfully format the disk then you do not need a storage driver. Sometimes you can see the disk whether there is a driver issue or not, so always make sure that you can also format the disk if this is the first time you’re testing for any given model.

There are drivers that aren’t recommended for use in WinPE as well and adding unnecessary drivers will bloat your boot image. Generally speaking, you need the drivers that match the version of WinPE that you’re using. If you are using WinPE 10, then use Windows 10 drivers, even if the target deployment is Windows 7. Do not add Bluetooth or wireless drivers as they have no use in WinPE. Finally, don’t mix architecture. A 32-bit boot image needs 32-bit drivers. A 64-bit boot image needs 64-bit drivers. If you are creating a new boot image, the wizard will stop you from mixing architecture. However, if you are adding drivers to an existing boot image then there is no safety net, so proceed with caution. Drivers Should Match.

Issue #4

Category: Drivers
Subject: Driver (mis)management

This issue is actually two in one. Any technician needs to know not only where to get the drivers from, but also how to manage and deploy them.
Obtaining Drivers
Each of the three major PC vendors have ways to obtain their enterprise-class drivers. Here are the methods I recommend:

Dell: https://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment

HP: https://ftp.hp.com/pub/caps-softpaq/cmit/HP_Driverpack_Matrix_x64.html

Lenovo: https://support.lenovo.com/us/en/solutions/ht074984

Sometimes you need to reach out to the vendor’s vendor to get a specific version of a driver because of a requirement from a software vendor. For example, your 3D rendering software may require a specific version of a graphics driver for the software to function correctly and not just the latest driver. In that case, you need to know that freedrivers.com isn’t where you should go (ever) to get specific drivers.

A better way to get individual drivers is to use the Hardware ID of the device. You can get it from the details tab of the device properties in Device Manager. With the Hardware ID, you can search the Microsoft update catalog for drivers too. I recommend copying the last entry in the list as it requires less clean up before it can be used in the update catalog.

To search the update catalog, you only need the vendor and dev codes, anything after the “&” after the dev code can be dropped in the search. As depicted below, I have properly formatted the Hardware ID for the search and I have returned quite a list from the catalog. Finally, if you are deploying a PC from a retail shelf, as long as it is Windows 8.1 or above, you can use PowerShell to create a driver repository. Then, create a directory (I always use C:\MyDrivers) and open a PowerShell window as Administrator. Use the following command to extract the drivers to the directory you created:
Export-WindowsDriver -online -destination C:\MyDrivers\

After a few minutes, you will see activity in the window as the drivers are exported. When the export completes, navigate to the directory you created and remove anything with “prn” in the title. Prn drivers are printer drivers and they aren’t needed for OS deployment. This folder should then be renamed and saved to your ConfigMgr site server where you will import the drivers and create a package as normal.

Managing Drivers
Managing drivers is a complex task but when you understand the theory, it becomes simple. A while ago, Johan Arwidmark and I published a post on DeploymentResearch.com on how to manage drivers in an MDT scenario which you can read about here: https://deploymentresearch.com/Research/Post/325/MDT-2013-Lite-Touch-Driver-Management
To translate the post into ConfigMgr terms, you should know that “Auto Apply Drivers” is the same as the total chaos scenario because it is relying on Plug and Play (PnP). Applying drivers by category is similar to the added predictability method of using Selection Profiles. It is a bit more granular than auto apply, but it is still letting PnP make decisions on what it thinks is the best driver for the system. If you’re up for a headache, go study up on driver ranking to understand why plug and play could be a disastrous scenario. Creating a driver package, or using the “holy grail” method is still the best option because you, as a technician, have complete control over the driver injection process. While it is up to you what method you choose, just remember that if you need advanced filtering because you have multiple models and operating systems, you’re not going to get it using a method that involves PnP.

Issue #5

Category: MDT
Subject: Ref images breaking during build and capture

The unfortunate news about this scenario is that it is not a repeatable 100% of the time, but it does happen often enough to make the list. In this scenario, if your Windows 10 reference image has an Internet connection during creation and the store apps are able to reach out to the Microsoft CDN, sysprep will break and the capture will fail.

How do you fix it? Isolate the VM. There are quite a few ways to do it, and here’s what I recommend: Use local WSUS.

Have a local WSUS that the reference VM can reach out to in order to grab updates. It’s straightforward with the only gotcha being that you need to remove the local WSUS entry from the registry of the reference image so that when it is deployed to production it doesn’t try to look for that isolated WSUS server. That will be bad for one of two reasons. The first reason is that the WSUS server isn’t reachable. If it is reachable, it probably has every single update approved and that would be bad in a production scenario if a PC is applying updates outside of your maintenance windows of test, approval, and deployment. Think: unwanted reboots, and untested patches = time to update your resume!

There are other ways to manage this if you can’t use local WSUS. We have a detailed post to help you understand both the potential causes of the failure as well as an additional option to fixing it: https://deploymentresearch.com/Research/Post/615/Fixing-why-Sysprep-fails-in-Windows-10-due-to-Windows-Store-updates

Conclusion

Those are the first five issues we decided to tackle when it comes to Windows 10 deployments. We hope you found the tips useful.