Windows 10 In-place Notes

So I have started experimenting with in place upgrades in ConfigMgr. The stock Task Sequences dont have any error catching in them so I am starting down that road. My first attempt was the use something Johan Arwidmark posted. Do a scan, then upgrade if the scan came back clean. Great idea. Addresses many catches. 

So setting that up I do my first run. Using a VM with a few apps on it. Should run fine. Watched it until it started downloading the Install Media and coming back from lunch I have a systray bug saying Software was installed and to click here. Something was not right so I clicked it.

Something didnt feel right. Sure, Microsoft backpeddled a little on the Start Menu between Windows 7 and 10 but I would expect it to look different then the same... Sarcasm aside, it did give me a chuckle when I saw this. Now to resolve.

So first off to smsts.log under %WINDIR%\CCM\Logs. It shows it exited cleanly. Johans post has a continue on error for the scan step I'm not a super big fan of this option but it is useful. Digging firther we find an error on the scan step.

Process completed with exit code 3247440392
Saving exit code 0xC1900208 of Windows upgrade to Task sequence environment variable '_SMSTSOSUpgradeActionReturnCode'

Decoder ring time... This has key

• Compatibility issues found (hard block):  0xC1900208

ok. makes sense. I have not put in any error control for non successful exits from the scan. Still have to find the cause of this particular issue. Head on over to setupact.log under %WINDIR%\Panther. Not here, this is from the initial deployment. Searching.. Theres one in %WINDIR%. 

Determining whether we should run ConX or legacy setup

Will launch ConX setup experience

Launching ConX setup experience

Inspecting ConX Setup Cmdline

Launching C:\_SMSTaskSequence\Packages\CH200AC0\Sources\SetupPrep.exe /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable /compat ScanOnly

Not useful, shows us starting the scan but no scan results. %WINDIR%\SMSTSPostUpgrade has some interesting BAT files. Still searching for relevant setupact/err logs. I am guessing that ConfigMgr cleaned those up when it wacked the %SYSTEMDRIVE%\_SMSTaskSequence folder. 

Lets run the scan again manually to see where things go. Grab the execution from SMSTS.LOG (above). I did strip the two post switches.

SETUP.EXE /ImageIndex 1 /auto Upgrade /quiet /noreboot  /DynamicUpdate Disable /compat ScanOnly

Setup created the directory %SYSTEMDRIVE%\$WINDOWS.~BT\Sources\Panther where the two setup logs are located. It was not present earlier. Looking in SETUPACT.LOG it did not have anything useful, just the 0xC1900208 error. Same for SETUPERR.LOG.

Looking around this dir there are some CompatData*.XML files. All but one have this in it

BlockingType="None"

The last log file however, had what we were looking for:

OSMajorVersion="6" OSMinorVersion="1"/>

<Devices>

<Device Class="display" ClassGuid="{4d36e968-e325-11ce-bfc1-08002be10318}" DeviceInstanceId="pci/ven_15ad&amp;dev_0405&amp;subsys_040515ad&amp;rev_00/3&amp;2acf1e9&amp;0&amp;78" Manufacturer="VMware, Inc." Model="VMware SVGA 3D">

<CompatibilityInfo BlockingType="Hard" StatusDetail="WarnUpgrade" Message="You'll have problems with your display in Windows 10."/>

<Action Name="Dismiss" Link="wsc:wica:_pci/ven_15ad&amp;dev_0405&amp;subsys_040515ad&amp;rev_00/3&amp;2acf1e9&amp;0&amp;78" DisplayStyle="Link" ResolveState="NotRun"/>

</Device>

</Devices>

<DriverPackages>

<DriverPackage Inf="oem0.inf" BlockMigration="True" HasSignedBinaries="False"/>

<DriverPackage Inf="oem1.inf" BlockMigration="True" HasSignedBinaries="False"/>

<DriverPackage Inf="oem10.inf" BlockMigration="True" HasSignedBinaries="True"/>

<DriverPackage Inf="c:\windows\system32\driverstore\filerepository\vmci.inf_amd64_neutral_faff95b55e0fdc1f\vmci.inf" BlockMigration="False" HasSignedBinaries="True"/>

<DriverPackage Inf="oem5.inf" BlockMigration="False" HasSignedBinaries="True"/>

<DriverPackage Inf="oem8.inf" BlockMigration="False" HasSignedBinaries="True"/>

</DriverPackages><Programs/></CompatReport>

Again, I knew I had to put in some error control and probably some HTAs for end user prompts. This error though, the SVGA driver is incompatible. Hmm.. Using the latest tools 10.0.10 in the VM. Surprised to see this. Lets run setup.exe by itself to see how the GUI takes an upgrade. Do have snapshots afterall. Same error, so if I'm in a hurry, just run the GUI to see if it complains as well.

The GUI let me continue so lets revisit our Task Sequence and enable 'Ignore any dismisible compatibility messages' on the Upgrade Operating System step for the Assessment.  It works now as the ScanOnly is returning 0xC1900210 (3247440400).

-Kevin

MDT Windows 10 1607 and WSUS

While we use ConfigMgr for deployments we do use MDT for Build and Capture. Just works better for some reason. Many others recommend it as well. So right down that path for 1607 I went. Something wasn't right though. It would not download updates from the MDT WSUS instance...

The first patch to download is 'Microsoft Silverlight (KB3162593) so I was thinking originally it was an issue with Silverlight so I remove that. It just stops on the next one. Then I thought WSUS so I make sure its all current and KB3159706 is still latest so I'm good there. Since doing our last few B&Cs I did dedup the drive WSUS content is on so I remove that. Still no love. Now I am circling back to 1607 itself since there were no other changes made for MDT.

So on the B&C box I'm looking at WUA logs. Not really seeing anything in there other then update GUIDs and it trying to set auto detect proxy. Hmm. Why is it trying to get out when I have WSUS in the customsettings. Digging around the web I find that Johan Arwidmark mentions that KB3176495 needs to be injected for this issue. makes sense. We do that for some of the rollups to save some WSUS time and of installing some low level patches for NVMe and TPM 2.0 support in Windows 7.

Johan's suggestion doesn't work for me. Same result, stuck at downloading the first update. During August, MS released several cumulatives for 1607 since the Aug 9th one Johan mentions so I try those as well. Maybe its in one of those?

• KB3176934 (8.23.2016)
• KB3176938 (8.31.2016)

Nope. Also just because I tried the earlier ones from July which also failed. Also messed with Delivery Optimization that Michael Niehaus was discussing.

Finally I stumble on this post, KB3176936, called 'Servicing stack update for Windows 10 Version 1607: August 23, 2016' It works. The name says it all: "Servicing stack update". I get a patched 1607 system now! So I go back through my above trials with each cumulative. It works with the 8/9/2016 and higher through the 8.31.2016 release. but fails with the 8.2 and July ones.

I add the two into Patches to get injected. Since I use MDT for Windows 7, 8, and now 10, I have sub folders for each OS and arch as well as specific Selection Profiles. Therefore under the Task Sequence under the 'Apply Patches' step it points to the Windows 10 64-Bit folder containing these two KBs.

As the Sept Patch Tuesday is fast approaching, I would assume we will see another Cumulative that may include this Servicing stack update as well. If not then I bet the next one will.

UPDATE: 09.13.2016 - Yes, the Sept Cumulative KB3189866 (14393.187.1.2).has this fix build in as I suspected.

-Kevin

Updated AD Cleanup Script supporting ConfigMgr

Previously I wrote about how we manage to keep Active Directory clean, which in turn helps keep ConfigMgr clean by deprecating old machine objects. Instead of rehashing, you can just read the original post to understand its full purpose.

A major change in this new version is that it adds support for SCCM. If you do not use SCCM then do not move to this one as there is no SCCM=True switch to enable/disable that functionality.

By pulling from ConfigMgr the emails are more useful.

 Disabled computer account ABC12345. Last SCCM Inventory:9/5/2016 9:35 PM. Primary User:kfason. Account was moved on 8/8/2016 1:44:43 PM. Description: ::Account Automatically Moved - [8/8/2016 1:44:43 PM]  
      ABC12345 was moved to ou=Disabled,ou=ADCleanup,DC=mydomain,DC=local.  
      Updated the description for account ABC12345.  

The flow was changed to be more streamlined as well with this order:

• Delete machine objects that are at that date
• Disable any Active machine objects (that were already moved) that are past its date
• Move any machine objects into ADCleanup that have not touched the domain since its date
• Move any machine objects (out of ADCleanup) that have touched the domain back to where the script found them
• Move any enabled machine objects out of the Disabled OU back to where it found them 

Additionally if there are any formatting errors it will put those in the email so you can deal with them manually if it could not figure it out. Can be useful if you have staff making changes to these objects. Im sure these could be adapted to the older version if you wanted to try.

 Disabled computer account ABC12345 does not have correct disabled time stamp.  

 Cleaned up description field for CBA54321.  

Download

The time frames and paths can be modified so review lines 1 through 34 and 740. Line 19 lets you choose specific OS versions to work with to include Servers for example. There are two optional support files available. One for Excluded Computers and one for Excluded OU's. They are used to exclude objects manually created for non Windows devices such as SAN or Linux systems as well as special purpose OUs that need excluding.

This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script.  Always test, test, test before rolling anything into a production environment.


You can get the updated script here.


-Kevin