SCCM Client Not Updating the server - Part 2

Following on from this post the fix I decided to use is again, not ideal but it will get the machines talking back to the SCCM server.

The solution was to create a task sequence in Group Policy Preferences.
"Computer Configuration" > "Preferences" > "Control Panel Settings" > "Scheduled Tasks".

Create a new task with the following settings. The most important one is "Run with highest priviledges". Enter the details of an admin account that can run this on the PC's you want it to as well.

Create a new trigger, I went for "At log on", and delayed this by an hour. So after the user has been logged in for an hour, run this task. I also add a limit to how long this can run, just incase.

Create a new action, "Start a program". You want to run:

C:\Windows\System32\ccm\ccmrepair.exe

I have also added a condition that a network connection must be available. There is no point trying to reconnect to the server if it cannot be reached.

The rest of the settings dont really matter, but the above is what I went for. As long as a machine gets Group Policy, the SCCM client will repair.

Still best to resolve the issue with the build as outlined in this post, but this will fix the ones that slipped through the deployment.

Re-install SCCM Client

There comes time when reinstalling the SCCM client on the users PC is needed. I tend to delete the client from the SCCM server before doing this so that a new account is created.

Click > "Start" and type "CMD"
Right click on "cmd.exe" and click "Run as Administrator"

Click Yes or authenticate to run the CMD window as Admin.
NOTE: "Run as administrator" is NOT the same as runing as an administrator account!!

In the command window, type the following:

cd / <enter>
cd \Windows\System32\ccmsetup\ <tab><tab>
 

Where <enter> and <tab> are the enter and tab keys on your keyboard.

This should now show the path including the GUID of the folder and press enter. This is different for every computer.

Type:

msiexec /x client.msi <enter>

The SCCM client will now uninstall. Once removed, run "ccmsetup.exe" again. You cannot install from the MSI. This can be found on the SCCM server, or from the folder:

"C:\Windows\System32\ccmsetup"

Since this silently installs the SCCM client, watch to see when the process "ccmsetup" stops running.

Windows KMS Keys

The Windows KMS keys are generic and basically tell Windows to go and look for your KMS server get get licensed.

Below is Microsofts list of keys to use.

http://technet.microsoft.com/en-us/library/jj612867.aspx

CryptoCard - Outer Window Authentication

Not really deployment related but something I have been scratching my head over today. For a 2nd factor of authentication we run CryptoCard.

CryptoCard is wonderful, the way it works is that it knows what the next X number of possible codes that the shiny dongle of fun will generate (My guess is 3,600 of them).
In the “Policy Admin” screen there are some options for “Syncronization” the important ones are the top 2.

From the Crypto Hand-Book modified to make sense:
INNER EVENT BASED OTP WINDOW SIZE
This represents the number of passwords the server will “Look-ahead” from the last successful logon by the user.
Using an Example, if the user presses the button and does not use that number. The server will be expecting token number 1. But when the user authenticates they use token number 2. The server will look through token codes, 1 through to 10 (the default) and if a match is found they will be authenticated.

OUTER EVENT BASED OTP WINDOW SIZE
When the entered token code is not found in the Inner Event Based OTP Window the server will check the next set of codes up to the limit in the Outer Event Based setting (default 100). If a token code match is found the user will need to resync their token, in admin the web interface this can be seen with the “Result”: “Outer Window Authentication"



Junos Pulse doesnt handle the "Enter Next Token" bit properly and just comes up saying "BAD Passcode" and asks for a response. I tried everything I could think of, same code with and without pin, next code with and without pin and the same for the next 2 screens that come up. No luck.

This leaves us with no real way to resync a token that is in this state. The options are to increase the OTP Window Sizes, or find some way to resync.

I have gone with both... 10 is a bit too few. Especially if the Crytpo box has a problem and users keep trying to login over a weekend.

The 2nd part was to have a way to actually do a resync when it is needed, since the proposed method on a crypto card requires the user to enter challenge codes on a token with 1 button... not ideal. The alternative isnt pretty but will do the job and get them logged in.

On the Crypto Server add the user as an Operator with the lowest privileges (Reporting). They give you the PIN and Token number which you use to login. The login page will prompt again for the login details telling you to enter the NEXT OTP (One Time Passcode).
Enter the username, PIN + Token number. You should see the reporting page. Log out, remove the Operator roles from the user and they can login as them selves from home.

Not ideal to add them to the server as an Operator, but they never attempt the logins (an admin does) and the roles should be removed straight away. Its got us out of a jam in a week that should have been quiet.

SCCM OS Targeting by Collection

In cases like updates and such you may want to target machines based on what OS they are running.
Create a new collection, and select a Query based rule

Give the rule a name, limit it to a collection if you wish. Click "Edit Query Statement..."

On the Query Statement Properties, click "Show Query Language". This will allow you to enter a statement rather than selecting fields manually.

Paste in the the query below, and change the <OSVERSION> with the version number below that.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like "%<OSVERSION>%"

Windows XP: Workstation 5.1
Windows 7: Workstation 6.1
Windows Server 2003: Server 5.2
Windows Server 2008: Server 6.0
Windows Server 2008 R2: Server 6.1

Save the query and the collection. Update and the collection will now contain all machines that have reported to be running that OS Version.

SCCM Client Not Updating the server

PART 2, the more reliable solution

Post deployment clients are not talking to the SCCM server and updating it with their information.

The blog post here has some great information on how to solve the issue. What it doesnt cover is how to get the PC's you have rolled out already.

What J.C. Hornbeck does mention is where to correct it, the registry key:
HKLM\SOFTWARE\Microsoft\CCM\CcmExec\ProvisioningMode="true"

I have created a Group Policy Preference to change the "true" to a "false". Follow this up with the script from Microsoft here. If you are deploying this out there, comment all the "Echo" commands out so it gives no prompts and is 100% silent.

This is NOT a fix for the root issue, but gets the clients already deployed to comunicate back to the mothership

Remove Domain Group Policy from PC in a Workgroup

Scenario:
You build a PC using you favourite deployment method which adds it to a domain. The PC gets Group Policy but is then removed from the domain.

The computer policies are NOT removed... By design or a design flaw who knows.

Solution:
To remove the policies launch "regedit" and browse to:
"HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy"
Remove any keys starting with "S-".

Open the key "GroupMembership" and delete the entries starting with "S-" that you removed above.

 

Reboot and you are now policy free.