Monthly Archives: June 2010

Windows Server

Windows Deployment Service Pre-Staging and GUIDs

Leave a comment
Windows Deployment Services (WDS) has the ability to search Active Directory for pre-staged computer accounts to use when deploying images. There are several benefits to this, e.g. you can choose to service only known clients that you have created and ignore others, and you don’t have to provide or generate computer names since the image is deployed with the name of the pre-staged account. The information used to match a pre-staged computer account with a PXE-booting client is one of three things; the MAC address of the NIC executing the PXE boot, the GUID of the system or the GUID of the NIC executing the PXE boot. The latter is most widely used and recommended by Microsoft, since it virtually guaranteed to be unique. The WDS server performs an LDAP query to find the account that matches the booting computer:
(&(objectCategory=<DN of Computer Schema object>)(|(netbootGUID=<GUID>)(netbootGUID=MAC)))
This filter ensures that a device will be found if it is pre-staged using either a computer GUID or a MAC address. The netbootGUID attribute on a pre-staged client is used to store the value of the physical computer’s GUID or the MAC address.
You enter the GUID in two ways; using the GUI and Active Directory Users and Computers (ADUC) or using the CLI and WDSUTIL.EXE. Regardless you need to pay attention to how you format the GUID, because GUIDs can be byte-swapped according to the endianism of the system that handles them. The GUI in ADUC hints at this if you enter an invalid value:
—————————
GUID Not Valid
—————————
The globally unique identifier (GUID) query you entered is not valid. Use one of the following formats to enter a GUID:

0123456789ABCDEFABCDEFABCDEFABCD or

{67452301-AB89-EFCD-ABCD-EFABCDEFABCD}    (Note byte reordering)
—————————
OK
—————————

In this message the first GUID is presented in what is known as binary octet string, the second representation is called just GUID string.
From the message you can work out how to convert between the two.
From Binary Octet string to GUID string (using the octet string in the message above):
  1. Each pair or characters is called an octet. Work with the GUID from left to right.
  2. Take the first 4 octets and reverse their order: 01234567 –> 67452301.
  3. Take the next 2 octets and reverse their order: 89AB –> AB89.
  4. Repeat for the next 2 octets: CDEF –> EFCD
  5. The rest of the octet string is identical for both formats so just add a hyphen: ABCDEFABCDEFABCD –> ABCD-EFABCDEFABCD
Reverse the process to convert from GUID string to binary octet string.
So how do you know which type you have? Sometimes the system will tell you; like ADUC’s Attribute Editor does:
Now, to confuse you completely, take a look at this from the ADUC Attribute Editor:
You have a value that is stored as an Octet String, but displayed in the list as GUID string! You have to double-click the value to see the REAL Octet String! Nice going!
Anyway, back to figuring out which way your GUID is displayed. If the system does not explicitly tell you which type its using I can give you this rule of thumb: GUID strings are usually displayed in braces (squiggly/sexy brackets) and with hyphens, or just with hyphens, while Binary octet string GUIDs are not. Keep in mind though; this might not always be the case. A perfect example of this is PXE boots, where the GUID that is displayed has hyphens, but is still an octet string GUID. All physical machines that I have observed have had octet string GUIDs in their PXE boot screens (see exception below for Hyper-V VMs).
If you want to pre-stage a computer account in Active Directory using this GUID you have to enter it without braces and hyphens:
This will cause ADUC to convert it to a GUID string, which is what the GUI always displays:
A very interesting exception to this is for Hyper-V VM PXE boots. For some strange reason, Microsoft decided that the GUID displayed during PXE boots in a Hyper-V VM is in GUID string format!
If you want to pre-stage a Hyper-V VM in Active Directory using this GUID you have to enter it with braces and with hyphens. This prevents ADUC from converting it, which it would do with a normal (octet string) GUID. So the braces probably mean ‘literal’ string or something.
Way to go Microsoft! 🙁
So to summarize:
  • PXE boot screens always display octet string GUIDs (except Hyper-V VMs)
  • Active Directory Users and Computers always displays the GUID in GUID string format.
  • Active Directory Users and Computers accepts both octet string GUIDs and GUID string GUIDs, but will always convert to GUID string when displaying.
More info:
Active Directory, Group Policy, Windows Server

Microsoft Security Essentials, Sysprep and Group Policy

3 Comments

In smaller deployments Microsoft Security Essentials (MSE) is a good, free alternative for anti-malware. If you decide to use MSE in your images, you will discover that sysprep resets the Out Of Box Experience (OOBE) settings for MSE. In other words; every user that logs on to a machine deployed from your image will see the MSE OOBE Wizard (Figure 1-2), until someone with Administrator privileges completes the wizard. Sometimes you might not want to expose your users to that. Fortunately for us, we can use Group Policy Preferences to bypass the OOBE wizard.

Steps to disable MSE OOBE with Group Policy Preferences:

  1. Create a new Group Policy Object (GPO) or use an existing one.
  2. Create a new Registry preference for computers (Figure 3).
  3. Update the key HKLMSOFTWAREMicrosoftMicrosoft Security EssentialsOOBE DWORD to 0.
  4. Update policy on the client.

The OOBE value has two (known) values:

  • 1: Yes, run OOBE please
  • 0: No thanks, OOBE has already run for this computer

Having shown you how to do this I would like to call attention to the following excerpt from the Microsoft Security Essentials EULA:

  1. INSTALLATION AND USE RIGHTS.
    1. Home Use. If you are a home user, then you may install and use any number of copies of the software on your personal devices for use by people who reside in your household. As a home user, you may not use the software in any commercial, non-profit, or revenue generating business activities.
    2. Small Business. If you operate a small business, then you may install and use the software on up to ten (10) devices in your business.
    3. Restrictions.
      1. The software may not be used on a device running an enterprise version of a Microsoft Windows operating system.
      2. The software may not be used on devices owned by government or academic institutions.
    4. Separation of Components. The components of the software are licensed as a single unit. You may not separate the components and install them on different devices.
    5. Included Microsoft Programs. The software may contain other Microsoft programs. The license terms with those programs apply to your use of them.
Windows

Identifying unknown devices in Device Manager

Leave a comment

Windows and Microsoft do a great job of providing drivers for hardware devices. A lot of drivers ship in the box with Windows and hundreds of thousands more are available online on the Windows Update site. Still you quite often end up with one or two unknown devices in Device Manager. When Windows Update or the Windows DVD cannot help you, you have to turn to the manufacturer of the computer or device. If the machine is a specific model you will probably find the drivers on the drivers page of that model. But if it’s a custom system or a system where hardware has been added or replaced you will have no help.

I recently discovered a website that was incredibly useful in discovering who made a particular device and which device it is. The site is PCIDatabase.com:

PCIDatabase.com offers a very simple and very useful search engine. You can use either vendor or device search:

So just find your unknown device in Device Manager and lookup its Hardware Ids. You find these on the Details tab of the device:

Highlight the value and press Control+C (right-clicking does not work here). Past the value into Notepad or some other text editor and copy just the numbers following VEN_. Past these numbers into PCIDatabase.com’s Vendor Search box. You will see a result like this:

So now you know who made your device. Repeat the process but this time select the numbers following DEV_:

So now you have identified you device and can start looking for a driver. I recommend going directly to the source, that is, the manufacturer of the device. Drives hosted by computer manufacturers are often hopelessly outdated. As you no doubt have noticed it is sufficient to search for the device ID, because that will return the vendor ID as well.

PS: Sometimes the manufacturer of a particular device will not let you download drivers for it from their site. You are instead forwarded to the manufacturer of you machine. This is done because sometimes computer manufacturers modify the hardware device to work a particular way. Using a generic driver in these cases can be problematic. That said I have yet to encounter a device that has been modified in such a way and have used generic drivers directly from the hardware manufacturers for all my devices.

Sometimes the device manufacturers even block you from installing their drives for devices that have been used by the machine manufacturers. The most common examples of this are GPU manufacturers. Both nVidia and ATI (AMD) will check to see if your GPU is one that has been OEMed by a computer manufacturer and prevent the generic nVidia and ATI drivers from installing for such a device. That is quite annoying, especially since the drivers work perfectly with the GPUs. To work around this you can use a custom inf file or a drives modder. The site LaptopVideo2Go provides custom inf files for nVidia drivers, for ATI you can use the MobilityModder application. I am sure there are mode sites and apps that do this, but these are the ones I have used.