Manually update Forefront Endpoint Protection and Client Security

Sometimes in FEP 2010 and FCS you need to force a signature update. There are two ways of doing this. Firstly, Microsoft supply a download of the latest signatures at this link

http://support.microsoft.com/kb/935934

The package you download can update both FCS and FEP 2010.

To manually start the signature update from the client software run

MpCmdRun.exe -SignatureUpdate

In FCS you should therefore run

C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\MpCmdRun.exe -SignatureUpdate

In FEP 2010 you should run

C:\Program Files\Microsoft Security Client\Antimalware\MpCmdRun.exe -SignatureUpdate

On Windows 7 you should run MpCmdRun.exe with elevated privileges or from an elevated command prompt.

Don't forget that because the path to the executable contains spaces you'll need to use quotes if run in a Run Command Line step in a Task Sequence.

Why does this MSI keep reinstalling?

Packaging up applications is one of the key tasks for anyone working with OSD. Creating software packages can be pretty easy, especially if the app is supplied as an MSI. Most of the time it's as simple as running something like

msiexec /i Setup.msi /qb ALLUSERS=1

Occasionally though, you'll run into problems. We had an app that seemed to install successfully. However, each time the app was run, the MSI ran through some checks and appeared to try to repair the app.



After a bit of digging it turned out that the problem was being caused by an advertised shortcut. Each time the app was run, the advertised shortcut kicked off an auto-repair, even though the app was installed successfully. The quick (and probably nasty solution) was to install the app without the advertised shortcut

msiexec /i Setup.msi /qb ALLUSERS=1 DISABLEADVTSHORTCUTS=1

In situations like this it's probably better to return to the vendor and ask for a working MSI, or to use a tool like Orca to discover what is causing the auto-repair to kick in.

XP Mass Storage Drivers on Toshiba Laptops

A common way of installing Mass Storage Drivers for XP is to add a condition in your Task Sequence to query the Model of the machine and apply the relevant driver. The Deployment Guys have a great post on how to do this here.

The basic idea is that you have a step in your task sequence to apply (for example) the Intel(R) PCHM SATA AHCI Controller 4 Port driver.



On the options tab you would have a number of WMI queries which identify the machines that need that driver. In this example you'd probably see things like-

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Satellite Pro L500%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Satellite Pro U500%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude E5410%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude E4310%"




Unfortunately this type of driver application assumes that there is one chipset per model (in the above example, the Intel HM55 Chipset). This is not always the case. Take the Toshiba Tecra A11.

Some Tecra A11 models have the Intel HM55 chipset. Some have the Intel QM57 chipset. On both models, running the following code would return TRUE-

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Tecra A11%"

So, how do you identify the revision of the Tecra and therefore the chipset, in your task sequence? You need to query for the partnumber instead of the model. Toshiba store the partnumber of the laptop in Win32_ComputerSystemProduct. In this case the following code would return true for the Tecra A11 with an HM55 chipset-

SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE0E%"




Here are the SELECT statements to use for some of the other Toshiba laptops in the current range.

Toshiba Tecra A11 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE0E%"

Toshiba Tecra A11 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE1E%"

Toshiba Tecra M11 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTME0E%"

Toshiba Tecra M11 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTME1E%"

Toshiba Portege R700 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PT310E%"

Toshiba Portege R700 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PT311E%"

So, adding the Toshiba HM55 models to the above example would give us this

Using DISM to fix a broken Windows 7 image

The best way to create your gold image is by running a build and capture in a virtual machine. The reason for this is that you don't get extra drivers hanging about in your image.

One of our team accidentally created a fresh image on real hardware. This image worked fine on most models, but failed on a Toshiba Tecra A11. After a long investigation it turned out that the image contained an old Intel network driver that would not work on the Tecra. Even though we had the new driver in our driver store, the Tecra would always choose the driver in the image. Not having a working network driver during OSD is a bit of a problem!

The solution is to use DISM to remove the drivers from the image*.

First of all, make a copy of your image and work on this copy. Once you've done this you need to mount the image. From an administrative command prompt run the following commands-

mkdir C:\mountfolder

dism /mount-wim /wimfile:yourwimfile.wim /index:1 /mountdir:C:\mountfolder 

Once the image has been mounted, run the following

dism /image:C:\mountfolder /get-drivers 

This should show you all the extra drivers that have been added to your image. The drivers will be listed as oem1.inf, oem2.inf and so on. Here's the sample output from an image I recently had to edit-

Deployment Image Servicing and Management tool

Version: 6.1.7600.16385

Image Version: 6.1.7600.16385

Obtaining list of 3rd party drivers from the driver store...

Driver packages listing:

Published Name : oem0.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7600.16385

Published Name : oem1.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7601.17514

Published Name : oem2.inf
Original File Name : sthda.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem3.inf
Original File Name : sthda64.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem4.inf
Original File Name : b57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

Published Name : oem5.inf
Original File Name : k57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

The operation completed successfully.

To remove, for example, the Broadcom k57nd60a.inf driver, just run the command

dism /image:C:\mountfolder /remove-driver /driver:oem5.inf 

You should see dism reporting success

Found 1 driver package(s) to remove.
Removing 1 of 1 - oem5.inf: The driver package was successfully removed.
The operation completed successfully.

Once you've removed the drivers you want, unmount the image and commit the changes

dism /unmount-wim /mountdir:C:\mountfolder /commit

And that should be that. Create a new OS install package and test your image. Once you're happy you can use that image instead of the original.

*Of course, the real solution is to recreate the image in a VM, but that's not always practical!

Set the default domain in XP

One of the problems with using OSD to deploy XP is that the default logon domain after a build is always the local computer. If you refresh your clients on a regular basis this can confuse your users. This hack will allow you to set the default logon domain to be your Active Directory domain instead.

The key trick with this hack is to import this registry file before you join the domain.

Copy and paste the following code into a text file called setdomain.reg


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultDomainName"="YOURDOMAIN"
"CachePrimaryDomain"="YOURDOMAIN"
"AltDefaultDomainName"="YOURDOMAIN"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DomainCache]
"YOURDOMAIN"="yourdomain.com"


In a Run Command Line step use the following command-


regedit /s setdomain.reg


Force BitLocker key backup to Active Directory

If a Windows 7 machine is not in a domain when the drive is encrypted with BitLocker, then the key backup will not automatically occur. I've modified some code from this TechNet article to force this backup to occur for the C: drive. The script could be modified to backup keys from all drives pretty easily, but this had to be rolled out very quickly!

The script:

strDriveLetter = "c:"

Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate," _
& "authenticationLevel=pktPrivacy}!\\." _
& "\root\cimv2\security\microsoftvolumeencryption")

If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
Else
WScript.Echo "Successfully connected to BitLocker interface."
End If

Set colTargetVolumes = objWMIService.ExecQuery _
("Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'")


If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on this computer "
WScript.Quit -1

End If

For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
strEncDriveLetter = objVolume.DriveLetter
WScript.Echo "Encryptable Volume found :" & strEncDriveLetter
intRC = objVolume.GetProtectionStatus(nPStatus)

If nPStatus = 1 Then
WScript.Echo "Drive is encrypted"
Else
WScript.Echo "Drive Not Encrypted"
End If
Next

nKeyProtectorType = 3 'Numerical Password

insKey = objVolume.GetKeyProtectors(nKeyProtectorType,vProtectors)

For each vFoundKeyProtectorID in vProtectors
vKeyProtectorID = vFoundKeyProtectorID
' WScript.Echo "Key Protector: ", vKeyProtectorID
Next

insKey = objVolume.GetKeyProtectorNumericalPassword(vKeyProtectorID,numPWD)

If insKey <> 0 Then

WScript.Echo "Password Get Failed"

WScript.Quit -1

End If

WScript.Echo "Numerical PW: " & numPWD

WScript.Echo "For key Protector: ", vKeyProtectorID

iBackupSuccessful = objVolume.BackupRecoveryInformationToActiveDirectory(vKeyProtectorID)

If iBackupSuccessful <> 0 Then
WScript.Echo "Password Storage to ADS failed."
WScript.Quit -1
Else
WScript.Echo "Successfully stored password in ADS."
End If


RunAs in SCCM 2007 R2

When deploying an OS using a Task Sequence, you might need to run a step as a particular user. By default OSD runs all application installs under the localsystem account, but some applications don't behave as expected under this context. For example, the package SPSS requires the use of a program called spssactivator.exe to license the product and this only seems to work if run as Administrator.

In the example of SPSS, the following command line needs to be run from C:\Program Files\SPSS as the local administrator-

spssactivator productkey

This is where SCCM 2007 R2 comes in handy. The Run Command Line step has a new option Run this step as the following account. Clicking the Set button allows the credentials of the account to be set. But there is a problem. Credentials can be set in either of these two formats-

domain\user

or

%variable%

-but annoyingly, this format is not supported-

%OSDComputername%\user

So how can the Task Sequence be told to run the command as the local administrator? Well, it's quite simple - just set the %OSDComputername%\Administrator up as a variable in a separate step before the Run Command Line step.

So, add another step to the Task Sequence of Set Task Sequence Variable. Set the variable name to something memorable, such as RUNASACCOUNTFORSPSS, and set the variable value to %OSDComputername%\Administrator.



In the Run Command Line step, enter %RUNASACCOUNTFORSPSS% as the account to use, and supply the password.



You can then deploy the task sequence to any number of machines and the command line will use the correct credentials. Obviously you need to ensure the local account exists, is enabled, and you have supplied the correct password.