Monday, January 8, 2018

Windows 10 In-Place Upgrade Assessment Error Handling



As I progress to making Windows 10 available to end users I needed to polish out the error handling. While I am using the Upgrade Readiness tool that Microsoft provides to target successful systems, I am still performing one final check in the Task Sequence by having the Task Sequence do an assessment before continuing and capturing those results.

You just insert the Upgrade Operating System step and select the box 'Perform Windows Setup compatibility scan without starting upgrade' at minimum. I have also selected the other chekboxes below it such as 'Ignore any dismissible compatibility messages' checkbox. If unchecked, this will for example, trigger a failure for an incompatible driver that gets removed anyway. Useful if you have some weird driver for a microscope type device (I do!) but not useful if you accept the removal that the upgrade does. For those types of endpoints the Readiness tool has identified them.



I also enabled the last two check boxes. These will cause the eval step to pull the latest eval info from Microsoft instead of using what data shipped on the ISO. There may be some proxy concerns here.

Here is what that part of the Task Sequence looks like:



For initial roll out to IT, I am using Niall C. Brady's dialog Powershell Script so I wont cover that part here. I am working on a template script to pull HTML edited file to be more polished for an end user when I get to that point but Niall's script works great.

The 'Upgrade Assessment' step outputs to the read-only variable _SMSTSOSUpgradeActionReturnCode. SETUP.EXE actually outputs in hex whereas the variable is in decimal. Looking at Microsofts blog post these are the major exit codes. I converted the hex to decimal with a converter so I work in the same format ConfigMgr is.


  • No issues found:  0xC1900210 (3247440400)
  • Compatibility issues found (hard block):  0xC1900208 (3247440392)
  • Migration choice (auto upgrade) not available (probably the wrong SKU or architecture)· 0xC1900204 (3247440388)
  • Does not meet system requirements for Windows 10: 0xC1900200  (3247440384)
  • Insufficient free disk space: 0xC190020E (3247440398)


The 'Assessment Errors Detected' group has a condition of _SMSTSOSUpgradeActionReturnCode ≠ 3247440400 whereas the 'Upgrade the Operating System' group has _SMSTSOSUpgradeActionReturnCode = 3247440400.

Under the 'Assessment Errors Detected' Group, each of the 4 sub groups matches a code in _SMSTSOSUpgradeActionReturnCode. For example, the 'Compatibility Issues found (hard block)' group has a condition for _SMSTSOSUpgradeActionReturnCode = 3247440392.

Then each error code displays a custom message and errors the Task Sequence out. For the  'Compatibility Issues found (hard block)' error it shows

The Upgrade Assessment detected an error which is preventing a successful upgrade and it must be mitigated first. There is an application or driver that must be removed first. This is generally due to an old version of Sophos Safeguard present. Please contact the IT Service Desk for assistance.

Again, these groups are just a final sanity check, While the Readiness tool identifies bullet 2 impacted systems, ConfigMgr collections are identifying the last two bullets for example.

Download

This TaskSequence 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 TaskSequence.  Always test, test, test before rolling anything into a production environment.

Per request I have made a sample Task Sequence available here so you can see it in action.



Friday, January 5, 2018

Move the System Reserved Partition

One of my techs came to me with a Windows 7 system that they cloned the drive to a bigger one using something like this from StarTech. The problem was the System Reserved Partition was at the back of the drive instead of the front so after cloning it was now in the middle which prevented the Windows partition from being expanded via Disk Manager.


This system in particular was an older system that was deployed originally without the System Reserved Partition due to us using a 3rd party FDE when it was deployed however later was transitioned to BitLocker. That and SCCM/MDT didn't initially create one back then.

These cloners work well vs a Software Refresh when new space is all thats needed. Also works well to transition older system to SSD from HDD, assuming the SSD is bigger. Just make sure you use SSDTweak or TweakSSD or whatever else is out there on Windows 7. 7 only adjusts for SSDs at install whereas Windows 10 will generally adjust itself after detecting an SSD is present. We will clone when theres still life left in the device but a Hardware Refresh is in its near future.

There are a few options to address in the Windows world that use more labor such as using BCD to move the Boot Manager to the Windows partition and decrypting etc, however I like to do the simplest thing. I like and use gparted so I thought I would just throw up how I've done it in the past in hopes to maybe help a few others that visit.

To prep, you need to download the gparted LiveCD ISO and convert to USB with LiveLinuxUSB. Boots faster and many systems no longer have optical drives.

Suspend Bitlocker if present, then boot up gparted. During bootup you are prompted for keyboard and language etc. In most cases you can just accept the defaults.

Once gparted has started up it should select the first disk and show layout in two formats. Note the System Reserved partition in red. The goal is to migrate the System Reserved partition in red) to the back end of the drive.  This is done so using the following procedure..


In my case this is done by selecting /dev/sda2 and then selecting the Resize/Move button. 


In the popup, simply drag the partition to the right side of the bar. While your here you can first resize to 500MB that Windows 10 sets this partition to by default. Then select Resize/Move and OK to the warning.



Just to note, we are not actually performing any moves or resizes at this point, we are simply just creating a chain of commands that gparted will follow once it is applied.  You can either apply at the end of each step, or wait till the bitter end and do it, its up to you.  Either way when you are done, you should see your drive laid out the way you want.

Once its laid out the way you want and the actions at the bottom are correct, just click Apply and away it goes. Since the Reserved partition is so small it only takes a moment or two to move it.


Once done, remove the gparted media and restart into Windows. It will run a CHKDSK. Then after startup you can go to Disk Manager and see your handy work.


Then its a simple matter of extending the volume for your end results.


After extending, Bitlocker, if present, will start encrypting the larger volume and this can take a while since it  encrypts the entire volume in Windows 7 while newer can be configured for used space only. Once this is done you can resume Bitlocker and go about your day. Additionally, depending how you are managing recovery keys, be sure that is updated if its not something like MBAM or a 3rd party manager.

-Kevin


Wednesday, January 3, 2018

Unable to install KB3159706 (aka ESD support)


I was helping a friend with a ~800 endpoint ConfigMgr 1706 instance on Windows Server 2012 R2. Windows 10 1709 was made available via SUP to start testing the process. In initial testing by IT they were reporting it erroring out.


That was real helpful (not) so we went looking in WUAHandler.log It didn't really say much either.


Since it was reported by a few IT staff I suspected it was most likely back-end related so lets start at the top. Sure enough, WSUS was not at a supported version. 


Its should be 6.3.9600.18324 or higher. It appeared that KB3159706 was not applied and the post tasks not done per its KB. Simple enough, lets go get it from the Update Catalog and apply it and cleanup. We ended up getting an error it does not apply.


So after much investigation, it appears that KB2919355 is at fault. There were several installed KBs that stated '(Not including KB2919355)' in their title. This system being the sole SCCM system it was being patched by itself so this was odd as it should be completely patched. It had KB4054519 (December 2017 Cumulative Rollup) on it which does update WSUS version to 6.3.9600.18838. Only if KB2919355 is present however.

If you are unaware, KB2919355 is also known as 'Update' or 'Update 1'. Think legacy Service Pack here. We therefore have to back out enough to get KB2919355 installed then we can install KB3159706 to get WSUS up to date and bring it back to current patch condition.

Before continuing I would highly push that you take a snapshot of the VM or backup if physical. We did have one of the restarts lock up during shutdown and had to power cycle it. If I do it again I would probably restart after each uninstall instead at the end.
  • Uninstall KB2883200
  • Uninstall KB2894029
  • Uninstall KB2894179
  • uninstall KB2919355 (if present, was not in my case)
  • Restart
Install KB2919355. When you download this there are several files and it needs to be done in a specific order shown under 'Install Instructions'. Before doing that however, it also states you need to install KB2919442 as a prerequisite. This KB has been superseded by several updates but you can validate you have a newer Servicing Stack installed with the latest being KB3173424.
  1. clearcompressionflag.exe
  2. KB2919355
  3. KB2932046
  4. KB2959977
  5. KB2937592
  6. KB2938439
  7. KB2934018
Once you installed all the components of KB2919355 above you can finally install KB3159706 and perform the post install tasks needed to support in-place. This KB will take WSUS to 6.3.9600.18324 so it will support in-place ESD files. You can also run msinfo32 and check the HAL which should be 6.3.9600.17031 for KB2919355.

I have always had to manually add the ESD extension to IIS so that WSUS will transfer those files. Not needed for SCCM installs but should be done. Open IIS Manager and navigate to SERVERNAME | Sites | WSUS Administration | MIME Types. Add esd with MIME type 'application/octect-stream'.

Finally we applied the latest cumulative, KB4054519, as of this writing.

Now that we are current, we get to cleanup WSUS as it is a dirty state. Before KB3159706 it didn't know how to handle the Upgrades category. You need to rip all that out of the database and let it resync. Luckily there is a great article by MS on what to do to get WSUS clean. Note that step 3 and 4 can take a while. This WSUS instance had all the languages for Windows 10 upgrades in it which was weird when only English was selected.

Once this was all done and cleaned up, upgrades were going to the test systems again. WSUS was at version 6.3.9600.18838 and the HAL was at a good version. I also disabled all the ConfigMgr services during this work since there were may restarts.

-Kevin