ZTIMoveStateStore.wsf does not move the StateStore folder during Refresh

When ConfigMgr 2012 is integrated with MDT 2012, the Client Task Sequence template includes a step that uses ZTIMoveStateStore.wsf to move the StateStore folder to WINDOWS\TEMP in the event of success or failure, however this script has not been updated to cater for the new location of the StateStore and when it runs it will simply not find the StateStore in the expected location and exit without any error.  This isn’t too much of a problem until you attempt a second refresh of a system -which will result in the Task Sequence failing to store the user state.

To rectify this, create a backup copy of the ZTIMoveStateStore.wsf script within the MDT Toolkit Files package and then open the original for editing.  You will be looking for any references to “oUtility.LocalRootPath” and replace these with “oUtility.StatePath” and remove the additional path.  There are 6 (SIX) lines to which this amendment needs to be made;

– 1 –

If oFSO.FolderExists(oUtility.LocalRootPath & "\StateStore") Then


If oFSO.FolderExists(oUtility.StatePath) Then

– 2 –

oLogging.CreateEntry "Moving " & oUtility.LocalRootPath & "\StateStore" & " to " & sArchiveDir & "\StateStore", LogTypeInfo


oLogging.CreateEntry "Moving " & oUtility.StatePath & " to " & sArchiveDir & "\StateStore", LogTypeInfo

– 3 –

oFSO.MoveFolder oUtility.LocalRootPath & "\StateStore", sArchiveDir & "\StateStore"


oFSO.MoveFolder oUtility.StatePath, sArchiveDir & "\StateStore"

– 4 –

oLogging.CreateEntry "Error moving " & oUtility.LocalRootPath & "\StateStore" & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning


oLogging.CreateEntry "Error moving " & oUtility.StatePath & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning

– 5 –

OFSO.CopyFolder oUtility.LocalRootPath & "\StateStore", sArchiveDir & "\StateStore"


OFSO.CopyFolder oUtility.StatePath, sArchiveDir & "\StateStore"

– 6 –

oLogging.CreateEntry "Error Copying " & oUtility.LocalRootPath & "\StateStore" & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning


oLogging.CreateEntry "Error Copying " & oUtility.StatePath & " to " & sArchiveDir & "\StateStore: " & Err.Description & " (" & Err.Number & ").  Trying to copy", LogTypeWarning


This has worked great for me.

ConfigMgr 101: Patience dear boy… SMS_SERVER_BOOTSTRAP

In ConfigMgr world, one must learn patience – in particular when installing hotfixes, service packs and cumulative updates.  It is quite common for the installer GUI to complete and leave you under the false pretense that your environment is ready to go again, but what you will find is that the installer has triggered additional tasks which the SMS/ConfigMgr component manager needs to handle.

I would certainly recommend using trace32/cmtrace to watch the sitecomp.log when you are performings updates to your environment as this will give you an idea as to whether the component manager is initiating a re-installation of certain site components following an update.   You may see a flurry of activity which mentions the re-installation of components and the SMS_SERVER_BOOTSTRAP service.  When this log has settled back down to normal then you can think about returning your environment to normal usage.

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.


ConfigMgr 2012: Cumulative Update 1 for System Center 2012 Configuration Manager

Somehow, I missed the release of this completely!


This Cumulative Update contains several fixes – but primarily I needed it to fix an Asset Intelligence Point which wouldn’t synchronise due to an expired certificate.

PITA – ATI Catalyst Drivers Installation

I love manufacturers who stubbornly refuse to conform to Industry standards for Driver and software Deployment.  ATI and NVidia are two such culprits who make the installation of drivers for their products using widely used deployment tools a royal pain in the arse.  The driver .inf files can be easily extracted from the vendor supplied software, however when installed using Driver Injection and Plug and Play during Windows Setup they are not ‘completely’ installed and if the first user of the system is not an administrator they will receive a prompt for elevation to complete the install.  This is unacceptable guys!

So, we have to work with the vendor supplied drivers in the format they were provided and using whatever silent/unattended methods they provide.  ATI do not make this particularly easy with their Catalyst drivers as they use an installer technology called ‘Monet’ – nope, I never heard of it either.  There seems to be multiple ways to start the installation routine too; Setup.exe, ATISetup.exe and InstallManagerApp.exe – so what do we use?

After several hours of mucking around trying to get one of these to install the drivers during a task sequence, I can proudly put my name to a command line that actually works!  If you create a standard package that contains the extracted files from the vendor supplied install files and create an ‘install.cmd’ file that contains the following;


Create a program that runs the ‘install.cmd’ file (Run Hidden, Whether or not a user is logged on, Allow TS Deployment) and add this as an ‘Install Package’ Step to your Task Sequence.  You should enable the ‘Continue On Error’ option on this step, as the ATI installer will exit with a non-zero exitcode even if the drivers install successfully.

In the command line above, I am choosing to only install the drivers and not the associated ‘crap’ that comes with them – but if you want more than just the drivers then just amend the /UNATTENDED_INSTALL option and take off the ‘\Drivers’ at the end of the path.


ConfigMgr 2012: 64bit file system redirection bites again…

Even though the ConfigMgr 2012 client is supposedly 64bit now, the issue with 64bit file system redirection is still very much a problem during Task Sequence and even regular package/program deployments when we want to copy things to the ‘Native’ “%Program Files%” or “%WinDir%\System32”.  File System redirection kicks in and we are magically transported to the 32bit “Program Files (x86)” or “Windows\SysWOW64”. Boo hiss.  I even found a log entry in the client-side execmgr.log which clearly states;

Running "C:\Windows\ccmcache\3\CopyFiles-Temp.cmd" with 32bitLauncher

Why? Why? Why?

In the Task Sequence we can easily get around this problem by choosing to run a “Run Command Line” step instead of an Install Package step; we reference our package and command line and ensure we tick the box to “Disable 64bit file system redirection.”  This is all well and good but what about deployments outside of the Task Sequence?  There simply isn’t the same option, so we need to build this into our script/batch file that we are trying to run.  My borderline Obsessive Compulsiveness dictates that the single solution must ‘just work’ for both 32bit and 64bit operating systems.

The most elegant way I have found for doing this that doesn’t involve re-writing sections of your batch file to cater for the various operating environments, involves taking advantage of being able to invoke the ‘Native’ 64bit command processor (system32\cmd.exe) from within any 32bit command processor running within a 64bit OS if needed.  Here’s a snippet of code you simply add to the very top of your existing batch files…

  ECHO "Re-launching Script in Native Command Processor..."
  %SystemRoot%\Sysnative\cmd.exe /c %0 %*
ECHO "Running Script in Native Command Processor..."
REM Your script starts here

What this will do for you, is first detect if the batch file is being ran from within a 32bit command interpreter on a 64bit OS – if it isn’t then the code jumps to the “:native” label and continues your script as usual.  If we are in a 32bit command interpreter on a 64bit OS, then the script invokes the ‘Native’ 64bit command processor to run this very same batch file and then exit.  The %PROCESSOR_ARCHITEW6432% condition near the top will simply be evaluated again by the Native command processor and ignored (as we are running 64bit cmd.exe in 64bit OS, or a 32bit cmd in a 32bit OS) and your script will happily continue without being subject to redirection.  Neat!


ConfigMgr 2012 SP1: The Lord Giveth…

..but he’s taken away the ability to add collection variables to the default “Unknown Computers” collection.  Why God, why.

I like the convenience of using this collection to attach the “OSDComputerName” blank variable so that the deployment process for new ‘Unknown’ systems prompts for this information.  I now have to create another collection of my own for this variable, essentially containing the same two resources.