ConfigMgr 2007: The Self Signed Certificate Can Not Be Created Successfully

I’ve been scratching my head for the last hour or so at a customer site having issues with installing the PXE Service Point role onto some new Secondary Site Servers – getting an error “The Self Signed Certificate Can Not Be Created Successfully”.  This problem also affected the ability to extend the expiration time on the self signed certificate on existing PXE enabled site systems.

I spent considerable time tracing logs, file/object access and repeated uninstall/re-install of the PXE service point role.  Some Google searches for this error only returned results for people experiencing problems when re-installing the PXE service point role where it had once existed.

When I was down to my last few strands of hair, in a moment of inspired clarity, I remembered a little popup balloon when I was logged into the server stating that I was being logged on with a temporary profile (this organisation does not allow roaming profiles on their servers.)  I quickly created a local administrative user, gave it some permissions within ConfigMgr and ran a new Console window under those credentials and was able to add the PXE service point role no problem.

So I can only assume that during the generation of the self-signed certificate it is a requirement that a locally cached profile/folder must exist for the user, perhaps for only temporary reasons.


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.