SCCM 2012 - Some clients showing INACTIVE and Client Cert : None

[matt_isda_bomb]

Hi All,

 

Hopefully someone can help me with this.

 

We have a few hundred clients all deployed through SCCM 2012 successfully, however we currently have a problem on 50% of PC's where they are showing in the Configmgr console as inactive.

 

On further investigation loading the Configmgr control panel app shows that the client certificate is set to none.

 

This is NOT happening on ALL PC's, we can have two PC's sat next to each other on the same subnet and one will have Client Cert :self signed and the other will say Client Cert : None.

 

We only use HTTP currently hence the self signed cert.

 

I have checked and none of these PC's show as Obselete.

 

I have tried reinstalling the client to no avail and i have also renewed the certificate in the Management Point.

 

Any Help on this greatly appreciated.

 

Thanks

Matt

[Mackan]

Check if the failed clients are in Provisioning Mode. For some reason working clients sometimes is set back to provisioning mode the night after they have been deployed (and that may be caused by a scheduled task).

 

Check the values “ProvisioningMode” and “SystemTaskExcludes” under the registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec]

 

 

Change the value“ProvisioningMode” to "False" and delete the data in value

“SystemTaskExcludes” so it is blank. Then restart the SMS Client service. Wait a minute and then check in the ConfigMgr control panel if PKI is enabled again and that all Actions are there.

 

We have seen this problem and we think it is caused by one or several applications in the Task Sequence that is stuck in a installation loop. The MSI product code detection method was not enough so we added other detection methods, eg a registry value or a file existence, fore those applications.

 

Beware of that a client you fix can be set to Provisioning Mode again the night after you have fixed it.

 

 

Regards

 

M

[matt_isda_bomb]

Mackan, that WORKED!

 

Weirdly enough we don't actually use Applications, still using packages in the task sequence. SO i'm not really sure what could be causing this in our environment.

 

I will check the PC I have fixed in the morning and see if it has reverted back to "Provisioning Mode".

 

Thanks so much for your help!!

 

Matt

[Mackan]

Hi again!

 

Have you installed Powershell 3.0 on your clients? If so, it could be the trigger to cause the problems.

 

What we think we know for now is...

 

When we install Powershell 3.0 it breaks something (eg. WMI). When the nightly scheduled task runs ccmeval.exe it tries to repair the client. When this happens the last thing it does is to set the client in Provisioning Mode because it is instructed to do so in "C:\Windows\ccmsetup\MobileClient.TCF" and "C:\Windows\ccmsetup\MobileClientUnicode.tcf".

 

A quick fix is to open MobileClient.TCF and MobileClientUnicode.tcf in C:\Windows\ccmsetup\ in Notepad (as Admin) and change "SMSPROVISIONINGMODE=1" to "SMSPROVISIONINGMODE=0". Then run C:\Windows\CCM\ccmeval.exe to repair and set the client to none provisioning mode.

 

It is the installation of Powershell 3.0 that triggers Ccmeval to repair and set the client in provisioning mode but we think it could be triggered by other software too. The real issue seems to be that the tcf-files has the SMSPROVISIONINGMODE=1 setting. So even though we choose to NOT install Powershell 3.0 we believe it could be a time ticking bomb because suddenly another software may cause the ccmeval to repair and set all clients in provisioning mode.

 

We have opened a support case at Microsoft Support for this issue.

[Yanze]

Did you ever get a response from Microsoft Support?

 

We have exactly the same issue on about 65% of our clients. Yes, I can manually remedy the inactive clients but the day after they will be inactive again?

[marwes]

Hi!

 

We still use a quick fix: A GPO Preference that copies a correct C:\Windows\ccmsetup\MobileClient.TCF" and "C:\Windows\ccmsetup\MobileClientUnicode.tcf from a server share.

 

Microsoft told us that it should be fixed in SP1. We have installed SP1 but still have the problem. Maybe the tcf-files is wrong in our core image but I haven't verified if it thats the case. If so it should be fixed when we build and capture a new core image.

 

Regards

 

Marcus

[Davooo]

Hey,

 

Just letting you know that this fix resolved an issue for me. I have yet to try it on other machines that seem to be getting the problem but fingers crossed it works.

 

The problem appears to happen randomly some clients are fine and some are not. All our clients are installed during OSD so there should be no real difference here.

 

All our clients will be using the same client source so the MobileClient.TCF are the same on clients that have had no issues and my client that failed.

 

We are about to undergo a major migration to SCCM 2012 sp1 and if we see these issues on any percentage of machines it is definitely going to cause me a major headache, firstly identifying them and then resolving. We will no doubt be upgrading to SCCM 2012 R2 soon so it may or may not resolve the issue,

 

Would love to know if you have any more info.

 

cheers

 

Davo

 

[anyweb]

if the task sequence is failing for whatever reason then the client WILL be stuck in provisioning mode, this is NORMAL and a symptom of the failed installation. what you need to find out is why the installations are faliing, and fix that problem

 

cheers

niall

[cnc077]

What may be other causes as to what causes clients to enter the inactive status? We too are experiencing a large volume of our clients that have moved into the inactive state. I looked into the above referenced possible causes and fixes and they did not apply within our environment.

 

Thanks!

 

Jerry

[chthomas]

What may be other causes as to what causes clients to enter the inactive status? We too are experiencing a large volume of our clients that have moved into the inactive state. I looked into the above referenced possible causes and fixes and they did not apply within our environment.

 

Thanks!

 

Jerry

 

Jerry,

 

I just cleared this issue up in one of my elementary labs and plan on making some changes that should prevent this in the future. Hopefully it's not too late to help you or others.

 

It looks like this could be caused if your OSD TS has a Restart step with a small timer. If the client doesn't have enough time after "Setup Windows and ConfigMgr" step it will get stuck in Provisioning Mode. In addition is looks like some people were saying 2012 (pre-SP1 and def. pre-R2) would sometimes just get clients stuck in Provisioning Mode.

 

My intention is to check each TS and change the Restart step to 60 seconds. I'm pretty sure I lowered it to 5 seconds after our guys were complaining the multiple restarts I had were taking too long. I also intend on putting two Run Command steps after "Setup Windows and ConfigMgr" with the following in each one:

 

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec /v ProvisioningMode /t REG_SZ /d false /f

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec /v SystemTaskExcludes /t REG_SZ /d "" /f

As a manual workaround, and tested today, I created a bat file for our guys to run. The command window will stay open for the duration of the ccmsetup.exe process and I left it that way as a visual indication of when it was finished so people wouldn't have to check Task Manager. Also be aware that my reading this weekend seems to show that manually doing a Machine Policy Retrieval & Evaluation Cycle action right after installing a client does NOT help at all. All it does is place a request in the queue BEHIND the client installations initial policy request. You just have to sit it out and wait patiently.It DOES work to force a policy retrieval if the initial policy has already come down, just not right after installation. This is the content of the bat for the technicians:

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec /v ProvisioningMode /t REG_SZ /d false /f

REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec /v SystemTaskExcludes /t REG_SZ /d "" /f

net use s: \\sccm\sms_XXX\client

s:\ccmsetup.exe

net use s: /delete

 

 

I ran that bat file on each desktop, waited 5-10 minutes and was able to shutdown all machines through SCCM.

 

NOTE: If I'm incorrect on the Machine Policy Retrieval thing please let me know.

 

-Chris