ConfigMGr MPControl.log: Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden

I was working in my Hyper-V lab this morning trying to PXE boot a client VM into a ConfigMgr Task Sequence but somehow things had just stopped working, overnight.  SMSPXE.log was showing me this;

sending with winhttp failed; 80072f8f
Failed to get information for MP: https://CON-CM1.contoso.local. 80072f8f.
PXE::DB_InitializeTransport failed; 0x80004005
Unspecified error (Error: 80004005; Source: Windows)

My MPControl.log had also, within minutes, gone from this (working);

>>> Selected Certificate [Thumbprint 37d4c9502df29c6780a456597b5088d569ceca6b] issued to 'CON-CM1.contoso.local' for HTTPS Client Authentication
Call to HttpSendRequestSync succeeded for port 443 with status code 200, text: OK

to this (broken);

>>> Selected Certificate [Thumbprint 37d4c9502df29c6780a456597b5088d569ceca6b] issued to 'CON-CM1.contoso.local' for HTTPS Client Authentication
Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden

So what happened here?

First things, I wanted to isolate if this was a problem with the Management Point component or the PKI setup – so I simply set the Management Point role to run as HTTP only.  Within minutes I was seeing a working management point in the MPControl.log – so it was certificate related.

I looked on my Windows Server 2008 R2 Certificate Authority and there were no certificate revocations.  Maybe the client certificate is a bit screwed up I thought – so I deleted the Client Authentication Certificate from the Personal Store on the Management Point and tried to request a new one from the CA but received a failure that the Certificate Revocation Server was unavailable.  Weird.  A quick visit back to the CA and I stopped and restarted the CA service and tried the request again from the MP and it went through fine.

I changed the Management Point back to HTTPS and again within a few minutes I was seeing a working Management Point again in the MPControl.log.

Just goes to show that it isn’t always (actually, it isn’t USUALLY) Configuration Manager that is to blame when things aren’t working correctly.



Patch your ConfigMgr Boot Image for Advanced Format / 512e Drives

Advanced Format (AF or 512e) drives are out there, often fitted randomly from one model to the next.  I won’t go into the technicalities of what they are all about as Google will tell you this, but what I will tell you is that their presence can slow down the deployment rate on an affected system.

Firstly, if you are not sure whether your system is equipped with an AF drive (DELL include bright orange note with the system, HP just seem to sneak them in) then you can download and run the following tool in the OS or in WindowsPE;

The tool will tell you if an AF drive is fitted and also if the partitions are ‘aligned’.

When we use ConfigMgr and WindowsPE boot images to deploy systems with AF drives you may notice quite a slow down, especially in the “Apply Operating System Image” Task Sequence step.  There is a patch to be downloaded from Microsoft that should be installed within a fully patched Windows 7 SP1 OS image AND we must also incorporate this patch into our ConfigMgr boot images;

Once you have obtained the x86 and amd64 versions you can follow my guide below on how to update BOTH of your ConfigMgr boot images.  We will do the x86 boot image first and you just need to repeat the process for the amd64 image.

You should have installed the Windows Automated Deployment Toolkit (WAIK).  You can undertake this task on the ConfigMgr server as it will have the WAIK installed.  From your Start Menu, find the Microsoft Windows AIK\Deployment Tools Command Prompt and run as Administrator.

Create the following structure on a drive of your choice with a good few GB free (where X = YourDriveLetter)


Copy both of the downloaded Windows6.1-KB982018-v3-x64.msu and Windows6.1-KB982018-v3-x86.msu to X:\WinPE\patches.  It does not matter that they are together as the patch injection process is clever enough to pick the right one.

Copy the boot.wim file (ignore the boot.xxx12345.wim) from <ConfigMgrInstallDir>\OSD\boot\i386 to X:\WinPE

From the Deployment Tools Command Prompt, run the following commands (replacing X:\ as appropriate);

DISM /Mount-Wim /WimFile:X:\WinPE\boot.wim /MountDir:X:\WinPE\mount /Index:1
DISM /Image:X:\WinPE\mount /Add-Package:X:\WinPE\patches
DISM /Unmount-Wim /MountDir:X:\WinPE\mount /Commit

Rename the existing <ConfigMgrInstallDir>\OSD\boot\i386 .wim file to .old and copy up your replacement boot.wim from X:\WinPE.

From the ConfigMgr Console, Right click the x86 Boot Image and choose to Update Distribution Points.  This will take our new boot.wim and re-integrate the ConfigMgr components, your modifications and drivers and re-send out to the DP’s.

You should also click the “Reload” button on the Images tab of the boot image properties, so that the size changes will be reflected.

The size increases on the boot.wim files you should be looking for, if all went successfully, should be;
i386 boot.wim should increase by approx 10MB
x64 boot.wim should increase by approx 12MB

With a patched WindowsPE boot image, the “Apply Operating System Image” Task Sequence step when ran on an AF drive should speed up considerably.  The speed increases I have observed on an HP Touchsmart system were as follows;

BEFORE: AF Drive non-patched took 28 minutes for the “Apply Operating System Image” step to complete (inc. download)
AFTER: AF Drive patched took 13 minutes for the “Apply Operating System Image” step to complete (inc. download)

So you can see, there are significant time savings to be made with a properly patched WindowsPE boot image on an AF drive equipped system.

Oddly, when an AF equipped drive is partitioned and formatted using the boot images generated by ConfigMgr 2012 the Dell Alignment Tool states that the partitions are aligned correctly – however without the patch the disk performance is still poor.

Improving Availability of your remote Branch Distribution Points

Whilst I remember, this is a quick post to share a couple of tips which might help you improve the availability of Windows 7 Branch Distribution Points that you may have operating within your ConfigMgr infrastructure.

  • BIOS Power On Timer – If the BIOS supports it, enable the Power On events each working day to power up the system every morning, ready for business.
  • BIOS Power On after AC Loss – Again, if the BIOS supports it, ensure that in the event of a power failure the system will power up again and boot to the OS (not network!)
  • Windows 7 Recovery Options – If Windows 7 is not shut down correctly, it will default to boot into Recovery mode.  To negate this and always attempt to boot into the OS, run the following command line from an Administrative command prompt;
    bcdedit /set {current} bootstatuspolicy ignoreallfailures

This should help to make your Branch Distribution Point systems a little more resilient to everyday life at remote offices.


ConfigMgr 101: Detecting and Disabling Bitlocker during OSD Task Sequence

There are quite a few blog posts and articles that provide guidance on how to enable Bitlocker during an OSD Task Sequence, however most (if not all) of them omit critical information as to how to correctly handle the detection and disabling of Bitlocker during the REFRESH scenario.  So here goes…

Out of the box, the standard Client Task Sequence MDT Template has a disabled step for ‘Enable Bitlocker’ and as long as you have either manually or scripted the enable and activation of the TPM chip and completed the Active Directory work required this will do the job of encrypting your OS drive.  You probably already got this far, which is no doubt why you are reading this article.

You then arrive at testing your Task Sequence in the REFRESH scenario (initiating the Task Sequence from within the running OS) and find that if Bitlocker is enabled then your standard Task Sequence fails – as it cannot stage the boot image to your OS drive.  You then add the ‘Disable Bitlocker’ task to the Refresh section of your Task Sequence and this works nicely.  However, your Task Sequence will now fail if you attempt to refresh a system that does not have Bitlocker enabled to be disabled – a poor show by the ‘Disable Bitlocker’ step really.  You could enable the ‘Continue on error’ option on this step, however if the step genuinely fails to disable the Bitlocker protectors then it will still proceed to attempt to stage the boot image, which is far from ideal.

The solution then, is that we need ‘something’ to first check to see if Bitlocker is enabled and use this to govern whether the ‘Disable Bitlocker’ step runs.  I used to use a script I found out on the web but I had to amend it a little so that it worked on both x86 and x64 platforms, by using references to SYSNATIVE rather than the hardcoded paths to managebde.exe – as x86 and x64 require the correct version to be ran.  It worked, eventually, after experimenting with the command line and disabling/enabling 64bit redirection – quite exactly what I did I don’t recall.  Many months later, I needed to do the same again for another customer but I wasn’t happy implementing this again – there had to be something better?

Enter – UDI Preflight Checks!  The MDT User Driven Installation (UDI) Client Task Sequence template includes the ‘Disable Bitlocker’ step by default, but on the condition that a the variable ‘OSDBitlockerStatus’ equals ‘Protected’ – so how does it determine this?  The UDI Task Sequence runs a series of pre-flight checks which, amongst other things, checks to see if Bitlocker is enabled.  The Script responsible for this is called ‘OSDBitlockerState.vbs’ and can be found in the ‘<MDT Toolkit Files Package>\Tools\<platform>\preflight’ folder which gets downloaded locally during build as part of the ‘Use Toolkit Package’ step.  You just need to create a step which runs and passes the script the drive letter (ie: ‘C:’) of the partition to be checked and if Bitlocker is enabled on that partition it will set the ‘OSDBitlockerStatus’ variable to ‘Protected’.  I have a step in my Task Sequence before the ‘Disable Bitlocker’ step which runs the following command;

cscript.exe "%TOOLROOT%\preflight\OSDBitlockerState.vbs" C:

The %TOOLROOT% variable resolves to the correct MDT Tools platform folder for the currently running OS – although the script does appear to be the same in both folders.  You would then add a condition to your ‘Disable Bitlocker’ step to check for this condition prior to restarting into Windows PE.

You now have a Standard Client Task Sequence that performs to the same specification as the UDI Task Sequence template with regard to Checking for and Disabling Bitlocker, and we DO like standardisation!

ConfigMgr 101: Configuring and Utilising Branch Distribution Points

It’s easy to get into a mess with Branch Distribution Points (BDP’s) and often I hear that things are not happening they way they anticipated – which is not surprising given that it can often be difficult for the newcomer to get their head around protected site systems and the way that Distribution Point selection works and how we must control the client behaviour in the advertisement properties.

There is an excellent Technet Library article which covers exactly how clients within branch sites with a branch DP are (and should be) influenced by the protection of site systems to ensure that when possible they always use their local Branch DP.  This is an essential read.

In a nutshell, a BDP, like any client system must be located within the boundaries of a regular DP at the site in order to pull content from it.  The BDP itself MUST be protected and configured to service only the boundaries where your clients reside.  You then need to review ALL of your advertisements to control whether or not client systems can ‘fall back’ to the regular DP (probably the very same one that services the BDP) if the package is not available on the BDP.

Note: If the BDP is OFFLINE and clients cannot obtain packages that were on it, then the ‘fall back’ behaviour does not occur here.  The ‘fall back’ behaviour applies ONLY for packages that have not been added to the BDP.


BITS in Pieces

I like BITS, however the bandwidth control and resiliency comes at a cost.

There is a tiny processing overhead for each file downloaded by BITS which is OK when you are dealing with only double digit numbers of files to download, however this overhead soon mounts up and can become a real problem when you have complex package content that contains hundreds or thousands of files – the client will take a very long time to download the entire package.  You should of course resolve the root cause, which is to simply create installation packages that contain a single msi for example, but sometimes this is not an available option and you need a workaround.

Regular non-HTTP/BITS download via SMB can be utilised in these scenarios.

Create a share on your server (giving SYSTEM and Administrators full control, whilst allowing EVERYONE else Read-Only of course) and add this as a server share to your ConfigMgr site.  You could give this share an appropriate name such as SMSSMB$.  Assign this new server share the role of a Standard Distribution Point but do not enable the HTTP/HTTPS transfer options.

Create a Distribution Point Group and add the SMB shares that you have created in your environment to this group, then for any troublesome package that isn’t suited to BITS transfer distribute these only to your SMB Distribution Points.

Do be aware that this is really a workaround and not a permanent fix – you are sacrificing the resiliency of BITS and the ability to control the bandwidth usage between the client and the DP.

ConfigMgr 101: Control your Distribution Points

On almost every consultation visit to healthcheck a ConfigMgr impementation it seems some solution providers are forgetting about the basics, such as when provisioning a new Distribution Point there thought should be given to controlling exactly which drives ConfigMgr content can occupy.

Firstly, we need to consider compressed package content (.PCK files) that arrive at the site, which by default get stored in an “SMSPKG” folder on the root of the same drive as the site installation files.  To control the drive used for compressed content, simply set your desired drive letter in the “Software Distribution” component within the “Component Configuration” node of your site.  Give that time to apply and then when you send content to that site it will be stored where you want it to be.

Secondly, we need to control where compressed content can be decompressed to. If you have ever taken the time to watch the distmgr.log on a site you will see entries which show ConfigMgr figuring out which drive is best to decompress to, mainly based on available freespace.  Freespace changes, thus content may sprawl across any and all drives it sees.  Decompressed content resides in “SMSPKGX$” folders (where X represents the host drive letter) on the root of utilised drives.  We need to reign in this behaviour, and this is accomplished by creating a small file called “no_sms_on_drive.sms” on the root of whichever drives you DO NOT want ConfigMgr to consider as a possible destination for decompressed content.

Get this set right from the outset and you will save a lot of trouble later on trying to relocate and re-pushing content to DP’s to fix everything to where it needs to be.