PXE-MOF : Exiting Intel boot agent

Recieved the following symptom after bouncing a distribution point which is also the WDS server for a site. Clients trying to PXE boot recieved:

TFTP.

PXE-MOF : Exiting Intel boot agent

This issue was caused by the permissions on C:\Windows\Temp being reset and locked out for everyone.
The result is clients trying to boot from WDS cannot access the files they require.
These are stored in C:\Windows\Temp\PXEBootFiles\Windows\Boot\PXE\

Restarting the WDS service can sometimes resolve it.

However, if this is the permissions issue there is a bit more work involved.

1. Remove the PXE Service Point role from SCCM
2. Remove the WDS role from the server, this will reboot the server.
3. Take ownership of the Temp folder, and reset permissions (include all sub folders and files)
4. Delete the Temp folder
5. Create a new Temp folder
6. Add the WDS role to the server
7. Reboot
8. Add the PXE Service Point role in SCCM
9. Re-add the boot images

Obviously wait on each step to make sure roles are removed especially in SCCM.

Information thanks to: http://grahamhosking.blogspot.co.uk/2011/08/problems-with-pxe-boot.html

SCCM - Enable BitLocker with TPM and PIN

In our environment we are using BitLocker with the TPM and a PIN. SCCM has the option to enable BitLocker as part of a Task Sequence.

However, you cannot set a PIN. Now if you have the settings in Group Policy to force a PIN this wont add the registry settings until AFTER the TS has completed. Not very useful.

The solution:
Use the built in SCCM Task for Enable BitLocker. Choose TPM only and save the recovery info into AD:

This will enable BitLocker and start encrypting the disk. I have not tested it yet, but I cant see why you couldnt have this straight after the step "Setup windows and ConfigMgr". In theory this would leave you much further in the encryption process by the time the TS ends.

From an encrypted PC you want to export the registry with your settings. Remember to re-do this if you change your BitLocker policy. The registry you want is located here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]

With this all at the end of the TS, I add a reboot after the above step. I have had some odd results with the first login without doing this reboot. However if this is at the begining, you will most likely have a reboot somewhere.

Apply the registry you exported above, using a "Command Line", or create a package.

regedit /s <filename.reg>

Ok, so we have encryption enabled, and our registry added. Now we can set a PIN. Add another "Command Line"

manage-bde.exe -protectors -add c: -tp %EnPass%

%EnPass% is a task sequence variable. How you set this is up to you, you can set this manually here if you want. I have an HTA with some options, one of which asks for this password and sets this variable.

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.