December 21 2012

SCCM 2012 client goes into Provisioning Mode

Problem Summary

SCCM 2012 client goes into provisioning mode after running the ‘Configuration Manager Health Evaluation’ scheduled task and it is deemed necessary to try and reinstall the client.
Problem Details

In SCCM 2012, after running the ‘Configuration Manager Health Evaluation’ scheduled task and trying to reinstall the client, the SCCM client enters provisioning mode – this means that the SCCM client stops functioning and the Configuration Manager Control Panel applet actions tab only shows the ‘Machine Policy Retrieval & Evaluation Cycle’ and the ‘User Policy Retrieval & Evaluation Cycle’ actions and nothing else. In addition, the registry values on the client shows:

HKLMSOFTWAREMicrosoftCCMCcmExecProvisioningMode = True
HKLMSOFTWAREMicrosoftCCMCcmExecSystemTaskExclude = SchedulerStartup;SchedulerShutdown;SchedulerLogon;SchedulerLogoff;ClientRegistrationStartup

On a healthy machine that has finished a task sequence, these registry values should be:

HKLMSOFTWAREMicrosoftCCMCcmExecProvisioningMode = False
HKLMSOFTWAREMicrosoftCCMCcmExecSystemTaskExclude = (no value, should be blank)

Even after fixing the registry value to look like a healthy machine, once the ‘Configuration Manager Health Evaluation’ scheduled task runs again, the client will once again be broken and the
registry values set back to provisioning mode.

Also, checking the Mobileclient.tcf file in the ccmsetup directory of a fully built machine shows SMSPROVISIONINGMODE=1 in the client install section – on a healthy client this should be

The SMSPROVISIONINGMODE value in Mobileclient.tcf is incorrectly set to the value of 1 after the task sequence instead of 0.
According to Microsoft Premier Support, this is scheduled to be fixed in Service Pack 1 of SCCM 2012 that is due for release in early 2013.

Create a VB script to run at the end of the task sequence to remove the SMSPROVISIONINGMODE value from Mobileclient.tcf:


Const ForReading = 1
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:windowsccmsetupMobileClient.TCF”, ForReading)

strText = objFile.ReadAll
strNewText = Replace(strText, “SMSPROVISIONINGMODE=1 “, “”)

Set objFile = objFSO.OpenTextFile(“C:windowsccmsetupMobileClient.TCF”, ForWriting)
objFile.WriteLine strNewText
Related information


I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.


December 18 2012

KB2506143 (WMF 3.0) breaks SCCM 2012

I’m currently working with a client that has installed Microsoft Update KB2506143 (Windows Management Framework 3.0) that was released by Microsoft on 12/12/2012 on their SCCM 2012 clients. Microsoft have confirmed that this KB has a known issue that breaks WMI and subsequently SCCM 2012 clients and management points.

I would suggest removing the update from SCCM until a fix is found.  See

Update 21.12.2012 – KB released

December 18 2012

Decline / exclude an update in SCCM 2012

Recently I needed to decline an update in SCCM 2012 so it wouldn’t install or get approved again via an Automated Deployment Rule.

Remove / Decline Update

  1. Go to All Software Updates
  2. Find the Update you want to decline
  3. Highlight and right-click, then select Edit Membership
  4. Uptick all of the Software Update Groups and click OK

Stop automatic approval via Automated Deployment Rule

  1. Set the Custom Severity for the update you want to exclude to Low
  2. In the ADR(s),  add the Custom Severity field and set it to None. This will exclude any update(s) that are set to Low.




December 10 2012

Enabling verbose logging on SCCM server

I’ve needed to do this a number of times in the past for SCCM 2007, the process is similar for SCCM 2012. Note that this is verbose logging for server components – it’s nothing to do with the SCCM client side.  In the registry of the server, navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSCOMPONENTS and then find the component that you want to need to enable verbose logging for. Select that key and then find the DWORD “Verbose Logging” as shown below:

Update the DWORD “Verbose Logging” to one of the following values:

Default is value 0.

Value 0: Errors and key messages;
Value 1: Everything in value 0 and Warnings and more general information;
Value 2: Verbose (everything)

Then restart the ‘SMS Executive’ service on the server.

Give it a few minutes to start writing to the logs, then check the logs of the component you are interested in, for example:

offermgr.log – SMS_OFFER_MANAGER
policypv.log – SMS_POLICY_PROVIDER
statesys.log – SMS_STATE_SYSTEM
wsyncmgr.log – SMS_WSUS_SYNC_MANAGER

The log should now hold a lot more information.

As I was writing this article, I came across another similar article that has a lot more detail in it, some it may be worth a look too –


September 25 2012

Defining multifactor authentication

I was recently having a discussion about the definition of multifactor authentication and what actually constitutes one, two or three factor authentication.  There seems to be confusion around these definitions, so I am posting some industry accepted definitions for all to see or reference.  Authentication methodologies involve three basic “factors”:

  1. Something the user knows (eg. password, personal identification number, personally identifiable information)
  2. Something the user has (eg. smartcard, security token, telephone, signed digital certificate)
  3. Something the user is (eg. fingerprint, voice, retinal pattern, DNA)


According to the Federal Financial Institutions Examination Council’s Authentication in an Internet Banking Environment, August 15, 2006, two-factor authentication (aka multifactor authentication) is described as:


“By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category would not constitute multifactor authentication.”


Therefore, two factor (aka multifactor) authentication is a combination of any two of these factors. For example – a fingerprint scan and a password is two factor authentication; a password and a signed computer digital certificate is two factor authentication.  However if you use a password, a signed computer digital certificate, a PIN and a number generated from your RSA SecurID token then you are still using two factor authentication as the identifiers only come from two of the three categories listed above.

There is a great article here ( which discusses this in detail, and it is also worth checking out the PCI Security Standard Council Quick Reference Guide, especially section 8.3 (, FFIEC’s Authenitcation Guidance whitepaper ( and Australia’s DSD security advice article (