Monday, January 29, 2018

Old School BitLocker Enable Script

A friend of mine has a small client with a few hundred systems. Recently they identified a business need to encrypt all their devices so he asked me for some assistance. As they were on Windows 10 this would be an easy exorcise but one I would have to do differently due to their maturity and lack of something like MBAM licensed or third party options so we elected to use native Bitlocker with AD DS integration. Instead of using Powershell we chose to do it oldshool so it was easier to follow.

We chose to do this in three steps:
  1. Enable TPM
  2. Configure Bitlocker
  3. Encrypt with Bitlocker
Luckily they were over 95% Dell OptiPlex systems so it was pretty easy. For the TPM we used the Dell Command | Configure (CCTK) to create SCE files. These were pushed out via GPO as a DOS script. The script does these tasks

  • Checks for a dropper file and exits out if ran. If not creates dropper file
  • Detects 32-Bit or 64-Bit so it runs the right SCE
  • Initiates a restart for the TPM to be actually setup

Per Dell requirements you have to set a firmware (BIOS) password if there is none, then turn on and enable the TPM, and then finally reset the password. You can follow the process in this White Paper by Dell instead of me rehashing. This script is attached at the bottom.

Next we had to configure Bitlocker and this was done via GPO. Choosing things such as 128-bit vs 256-bit and XTS vs CBC for Windows 10. We went with 128 bit XTS as well as configure it to escrow the key in AD.

Finally we had to start encryption. Some people think you just set the GPO policy and the system starts encryption. This is not true, GPO just sets all the settings or preferences. You still need to trigger encryption. We did this also via a GPO startup script a week after using GPO to enable TPM. It created a scheduled task to run the script.

While their %SYSTEMDRIVE% is on C: some of these systems have additional volumes on secondary drives that they needed to encrypt as well. I started with a for loop like this one but it was not that eloquent.

 ::look for drives  
 for %%a in (a b c d e f g h i j k l m n o p q r s t u v w x y z) do if exist %%a:\nul (   
 Call :ENCRYPT %%a  
 Goto EXIT  

However these being OptiPlex units they had optical drives so that meant the OS was on C: and D: or maybe E: was the optical so I went a different path. Additionally they had network shares setup via GPO. While manage-bde would error out in these two situations it was not that pretty so I went with a different for loop that used diskpart. I modified one used previously for other tasks. I found it online and unfortunately I do not recall where to give credit.

   for /f "delims=" %%i in ('^  
     echo list volume ^|^  
     diskpart ^|^  
     findstr Volume ^|^  
     findstr /v ^  
     /c:"Volume ### Ltr Label    Fs   Type    Size   Status   Info"^  
     ') do (  
     set "line=%%i"  
     set letter=!line:~15,1!  
     set fs=!line:~32,7!  
     if not "    "=="!fs!" (  
       if not " "=="!letter!" (  
         call :Encrypt !letter!  

This spits out any physical volume simply as 'C' or 'E' which then calls the function :Encrypt. It will put the key into both AD and TPM, and then encrypt it. At the end it will prompt the user to restart as a restart is needed for the system drive to start encrypting.


This simply sets up shop. The loop passes C for example, but manage-bde wants the volume as C: so this addresses that but also changes to a more friendly variable used throughout the rest of the script. You could technically pass this via the loop by using:

      call :Encrypt !letter:!  

above. Since this is running via GPO we have a check to exit out if any volumes are already encrypted.

 ::Detecting if Bitlocker is already on  
 %WINDIR%\System32\manage-bde.exe -status %1 | FIND "Protection On" > nul2  

In addition I put in some friendliness in case it is ran outside of the GPO so there are ECHO statements throughout as well as the initial header.

 ECHO Encrypting Volume %DRIVELETTER% your PC, be patient . . .  
 ECHO There is no Need to write down the numerical password below  
 TITLE Encrypting your PC, be patient . . .  

The actual meat of it is to create the protectors and encrypt it. First it creates the password protector which then gets put into ActiveDirectory per GPO. then enables the TPM protector, and finally starts the encryption.

 ::Create Recovery Key  
 ECHO Create Recovery Key  
 %WINDIR%\System32\manage-bde.exe -protectors -add %DRIVELETTER% -recoverypassword  
 ::Create TPM Key  
 ECHO Create TPM Key  
 %WINDIR%\System32\manage-bde.exe -protectors -add %DRIVELETTER% -tpm  
 ::Enable Bitlocker on Windows Drive  
 ECHO Enable Bitlocker on Windows Drive  
 %WINDIR%\System32\manage-bde.exe -on %DRIVELETTER%  

Finally we need to exit out. If a volume was encrypted it will set a variable and exit the loop. Once all volumes are parsed it will initiate a restart which is when the Windows volume actually encrypts.

 Set BLEnabled=YES  
 EXIT /B  
 IF %BLENABLED%==YES %WINDIR%\System32\shutdown.exe /r /t 300 /c "IT Department made a change and your workstation will restart in 5 Mins. Questions? Please open a ticket with IT Support."  

Thats it. They were able to encrypt several hundred systems quickly to meet their business need and I did not have to spend a great deal of time helping my friend out and this was real easy for them to follow and understand how it worked. I would say it took you longer to read this then for me to write it.

On the lab system you can see the key is escrowed in AD and it matches if you manually print the key to PDF. AD also holds all the previous keys for that machine object. My friend ran it many times to validate it worked.


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 find these two scripts here.


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.


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.


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.