Tag: System Center Configuration Manager

This problem is interesting as it is not easily discoverable if you do not stare at the screen during the entire upgrade process, and hey, who does that? However, this is a very interesting finding when it comes to Windows as a Service that I am certain will affect many more enterprise customers (see cause section below).

Problem

Initiate an upgrade of Windows 10 to another version of Windows 10 using an inplace-upgrade task sequence via System Center Configuration Manager. The upgrade runs smooth until it reaches 75% (of the Upgrade step) where setup reboots the machine and then continue the last step of the upgrade, which is the migration phase. However, at 76% the user is presented with the login screen and the user thinks “well, the upgrade is done, let’s login!” after which the user login only to see a reboot a few minutes later, and also a rollback to the previous version of Windows.

The upgrade process is still running although the logon screen is presented, and when the user login, the migration engine of Windows setup shows a bunch of MIG errors due to files becoming locked. At the same time a rollback to the previous version of Windows 10 is initiated. The rollback by the way works very well! 

Cause

The cause of this issue is the software Net iD, which is a very common smart card application/credential provider for governments and others, providing smart card logon capabilities for all types of smart cards. When that piece of software is installed it somehow (still not determined exactly what is going on) interfere with the upgrade and the consequence is that the login screen is displayed although the upgrade continue in the background.

Workaround

Uninstall the Net iD client before doing inplace-upgrade to another Windows 10 version, and then install it as one of the last steps during the upgrade.

Encountered an interesting issue doing Windows 8.1 Deployment using ConfigMgr 2012 R2. A specific model was constantly failing at the very last step in the task sequence. The smsts.log revealed a few errors with the codes 80070002 and 80072ee2, failing at random files every time from the MDT Toolkit Package.

A few examples:

DownloadFiles() failed. 80072ee2.
DownloadContentAndVerifyHash() failed. 80070002.

It seems Microsoft is aware of the issue and the current workaround is to set the following variables first in the task sequence to address the problem until it hopefully will be fixed in a coming hotfix.

SMSTSDownloadRetryCount = 5
SMSTSDownloadRetryDelay = 15

After settings these variables the deployment finish as expected.

So to end the pain of handling duplicate drivers in System Center Configuration Manager there has been a hotfix released that resolves the issue with “The selected driver has already been imported at this site”, at least partly, depening on what method your are using to apply drivers. Read more about the affected scenarios at the Mike Niehaus blog and download the hotfix from Microsoft.