A History of TechEd Europe in Conference Bags Part 1

I'm off to MMS 2011 next month so I thought it would be fun to look back over the Microsoft conferences I've attended in the past. I've dug out the old conference bags from on top of the wardrobe - excuse the dust!

TechEd Europe 2004
29 June - 2 July, Amsterdam

Held in the Amsterdam RAI, this was the first major conference I attended. Some of the key topics covered were the additional security features of XP SP2, Windows ACS (which ended up in SCOM) and running Server 2003 on 64-bit hardware.

Sadly, the conference bag was possibly the worst ever conference bag in the history of conference bags. A bright orange courier bag with a special hook to hold your drum(!). I'm assuming the orange was to help you remember you were in the Netherlands, and the drum... believe it or not, the drum was handed out as part of the keynote. It was fun coming back through customs with this.



TechEd Europe 2005
5 - 8 July, Amsterdam

Again held in the Amsterdam RAI, the big topics in 2005 (for me) were WSUS, LTI and ZTI with BDD and security.

Looking at the bag, it would appear that SQL Server 2005 was a big deal this year. The bag seems a bit conservative compared to 2004!



TechEd: IT Forum 2006
14-17 November, Barcelona

The IT Forum and TechEd events merged in 2006 and TechEd: IT Forum was born. The conference center in Barcelona was excellent, but not quite as good as the RAI in Amsterdam.

I went to a lot of talks about Vista. This was sadly a waste of time thanks to the pain that was/is Volume Licensing 2.0. The original Reduced Functionality Mode in Vista made it impossible for us deploy Vista - we weren't prepared to take the risk that someone's workstation may end up a glorified web browser. Security talks were high on my list again this year - they were not only useful, but helped with the CISSP CPE credits!

A simple check to see if the TPM is enabled

The Deployment Guys have an interesting post on how to check if the TPM chip is enabled and activated as part of a task sequence (see here).

When we deployed Windows 7 we ran into the same problem. Our solution was a bit simpler!

Connecting to root\cimv2\Security\MicrosoftTPM and executing

select * from win32_tpm

will only return a value if the TPM is enabled. This can be added as a condition in your Task Sequence so that your Bitlocker steps only run if the TPM is on.



A note of caution though - this query does not check whether the TPM is activated. It only checks that the TPM is enabled.

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