none
WDS Client COMPUTERNAME with duplicated GUIDs in Active Directory

    Question

  • My Setup:

    Windows Server 2003 R2 SP2 – WDS Server

    Windows 7 Images created with Sysprep

    2003 Functional Domain Level

     

    The Problem:

    WDS client is obtaining pre-existing computer names from our Active Directory database, and applying the names to our systems being imaged. This causes the pre-existing computer account to fail, having to be dis-joined and the re-joined to our domain.

     

    The Cause:

    We have been using RIS to deploy Windows XP images to our network for years. I have two boxes that I use to build these hard drives in and then deploy out to the network. This has been in place for 7 + years, and each box build on our network has been RIS’ed though these two boxes.

    RIS has duplicated the GUID of these two boxes to each computer account that we have.  So now I have all my Active Directory computer account with duplicate GUID’s.

    When the WDS client performs the installation, it seems to check for ‘prestaged’ computer accounts by checking for a matching GUID from Active Directory.  If it finds a prestaged account then it will ignore the COMPUTERNAME field in the Unattend.xml file that I have created.  Instead it utilizes the prestaged account name found by querying Active Directory.

     

    What I want to do:

    The problem here is im not trying to ‘prestaging’ my computer accounts. Rather the WDS client found a matching GUID because I’ve used this box in the past to build Windows XP hard drives.  It then applies the hostname of the matching GUID to the local box being built with WDS.  This caused two problems.

    1. I now have a broken box in AD that I have to dis/re-join to the domain to repair.
    2. I now have a Windows 7 image on a hard drive with an incorrect ComputerName value

     

    What do I need to do, in order to use these same two boxes to deploy Windows 7 WDS images to hard drives, and not have problems with duplicate GUID’s?

    Tuesday, April 10, 2012 1:06 PM

Answers

  • I have a solution...

    .

    I have manually deleted all the duplicate GUID's from my active directory. At that point the <Computername>*</Computername> works like its expected to, and generates a random host name.

    .

    Problem is, im still planning on using the same two boxes to build my hard drives - then deploy to the network. Its just good for business at my site. So the duplicate GUIDs will re-appear after 2 or 3 WDS builds, and then i'll be back in the same boat as before..

    .

    So what ive done to prevent Active Directory from getting duplicated GUIDs - i made a power shell script that goes into AD and deletes ALL GUIDs from all objects. Dosnt seem to harm anything so im just blowing them all out. I run this script every 5 min via a scheduled task (maybe thats overkill?) ..

    .

    Now when i build a Win7 WDS image - i can be sure there are no duplicate GUIDs in AD, AND it will generate a random hostname as ive defiend in the WDS server properties page.

    .

    Then i use FirstLogonCommands to execute another .VBS script to change the hostname to my desired name. This script actually changes the hostname in AD and does not break the trust relationship.

    .

    .

    What a NIGHTMARE... Thank you M.$. for making my life harder with you 'newer and better' WDS... I liked my RIS just fine....

    .

    Thanks for all your help guys!


    me

    • Marked as answer by drumgod Friday, April 13, 2012 12:30 PM
    Friday, April 13, 2012 12:30 PM
  • For other guys find attatched a powershell cmd for deleting the GUID from AD computer objects that are older than 5 day:

    Get-ADComputer -Filter {NetbootGUID -like "*"} -Properties Created | ? {$_.Created -le ((get-date).addDays(-5))} | Set-ADComputer -clear NetbootGUID

    ......

    Regards,

    Tim


    http://directoryadmin.blogspot.com



    Please note - the above PS script Requires Windows 2008 / Windows 7 with the installed Active-Directory PS module.

    me

    Monday, April 16, 2012 1:01 PM

All replies

  • Hi,

    This article may useful.

    Duplicate GUIDs? – Fix it with Scripts!

    http://blogs.technet.com/b/smsandmom/archive/2007/11/07/duplicate-guids-fix-it-with-scripts.aspx

    Wednesday, April 11, 2012 10:25 AM
  • Good atricle, but im not running SMS..

    me

    Wednesday, April 11, 2012 3:58 PM
  • Hi

    for Windows 7 you can user the value %machinename% to find prestaged computer in Active Directory. For random names use a asterisk *.

    ...

    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>%Machinename%</ComputerName> </component>

    ...

    Regards,

    Tim


    • Edited by butim Thursday, April 12, 2012 9:55 AM
    Thursday, April 12, 2012 9:54 AM
  • Thats the problem. WDS THINKS i have prestaged my computer in AD, because is find the GUID in AD when running the WDS client install. But in fact i have not prestaged anything...

    Since i have duplicate GUIDs in AD its doing this all on its own, and I do not want it to.

    I want it to use a randomly generated hostname ("*" in my Computername field).

    What would happen if i just deleted ALL the GUIDs in AD? What effect would that have on my network?


    me

    Thursday, April 12, 2012 12:16 PM
  • It wouldn´t affect your network if you delete the guid.

    But if you image a workstation it will generate a random name and not use the object in AD.

    If I use a asterisk or nothing in my answer file Windows 7 will generate a random name.

    ...

    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
               
    <ComputerName>*</ComputerName>
    </component>

    Regards,

    Tim

    Thursday, April 12, 2012 1:15 PM
  • <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
               
    <ComputerName>*</ComputerName>
    </component>

    My unattend.xml has an asterisk in the <Computername> field. Just like yours above. Ive even tried to hard code it with a dummy name. But WDS still ignores this. Seems that if it finds a matching GUID in AD, then it will use it. No matter what you place in the unattend.xml.

    BTW, im applying the <Computername> section in pass 4 specialize, under x86_Microsoft-Windows-Shell-Setup_Neutral

    I do have another question on this unattend.xml file configuration. Im using the Windows System Manager to build my unattend.xml In the bottom left corner i have my windows catalog. I have TWO selections for Windows-Shell-Setup_Netural. It looks like this:

    +Catalog\Componets\x86_Microsoft-Windows-Shell-Setup_6.1.7600.16385_Neutral

    +Catalog\Componets\x86_Microsoft-Windows-Shell-Setup_6.1.7601.17514_Neutral

    Seems as if i have one for Win7 GOLD and Win7 SP1.. Is there any difference between the two? They seem to provide the same info in the unattend.xml. I have tried both with ComputerName=* with the same result as above. Ive decided to stick with 6.1.7601.17514 as thats the newer version... Any advice on this ??


    me

    Thursday, April 12, 2012 1:33 PM
  • Only between x64,ia64 and x86 is a difference in the answerfile.

    Regards,

    Tim


    • Edited by butim Thursday, April 12, 2012 1:58 PM
    Thursday, April 12, 2012 1:50 PM
  • Ok. I deleted the entire Pass 4 Specialize Microsoft-Windows-Shell-Setup, and then re-added it back to Pass 4 specialize. The COMPUTERNAME field is left blank..

    .

    I'd expect that WDS would either prompt me for a computername, or use the random naming convention ive defined under the WDS Server\Properties\Directory Settings\New client naming policy field. (Value = %09%#Username)

    .

    I will deploy an image right now, and report back the results... I do not have high hopes for this to work though....


    me

    Thursday, April 12, 2012 1:59 PM
  • Ok, so after doing the step above - it is STILL pulling an exiting hostname from my AD. There is no change...

    me

    Thursday, April 12, 2012 2:39 PM
  • Hi,

    you can try this XML for the install image, if you want.

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <settings pass="offlineServicing">
            <component name="Microsoft-Windows-LUA-Settings" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <EnableLUA>false</EnableLUA>
            </component>
        </settings>
        <settings pass="specialize">
            <component name="Microsoft-Windows-Deployment" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <RunSynchronous>
                    <RunSynchronousCommand wcm:action="add">
                        <Order>1</Order>
                        <Description>Activate Administrator</Description>
                        <Path>net user Administrator /active:yes</Path>
                    </RunSynchronousCommand>
                </RunSynchronous>
            </component>
            <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <Identification>
                    <Credentials>
                        <Domain>123a.com/</Domain>
                        <Username>domainjoin</Username>
                        <Password>xxx</Password>
                    </Credentials>
                    <JoinDomain>123a.com/</JoinDomain>
                </Identification>
            </component>
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <ComputerName>*</ComputerName>
                <AutoLogon>
                    <Username>Administrator</Username>
                    <Enabled>false</Enabled>
                </AutoLogon>
            </component>
            <component name="Microsoft-Windows-International-Core" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <InputLocale>en-US</InputLocale>
                <SystemLocale>en-US</SystemLocale>
                <UserLocale>en-US</UserLocale>
            </component>
        </settings>
        <settings pass="oobeSystem">
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <OOBE>
                    <HideEULAPage>true</HideEULAPage>
                    <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                    <NetworkLocation>Work</NetworkLocation>
                    <SkipMachineOOBE>true</SkipMachineOOBE>
                    <SkipUserOOBE>false</SkipUserOOBE>
                </OOBE>
                <OEMInformation>
                    <SupportPhone>5555</SupportPhone>
                    <SupportURL>http://directoryadmin.blogspot.com/</SupportURL>
                </OEMInformation>
                <TimeZone>W. Europe Standard Time</TimeZone>
                <UserAccounts>
                    <AdministratorPassword>
                        <Value>xxxxx</Value>
                        <PlainText>true</PlainText>
                    </AdministratorPassword>
                </UserAccounts>
            </component>
        </settings>
        <cpi:offlineImage cpi:source="catalog:c:/win7sysprep/install_windows 7 enterprise.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
    </unattend>

    Regards,

    butim

    Friday, April 13, 2012 6:54 AM
  • Hi,

    using a prestaged computer.

    I used this answer file with <ComputerName>%Machinename%</ComputerName> he is catching the AD name.

    If I used this answer file with <ComputerName>*</ComputerName> it will generate a random name.

    Regards,

    Tim

    Friday, April 13, 2012 8:12 AM
  • I have a solution...

    .

    I have manually deleted all the duplicate GUID's from my active directory. At that point the <Computername>*</Computername> works like its expected to, and generates a random host name.

    .

    Problem is, im still planning on using the same two boxes to build my hard drives - then deploy to the network. Its just good for business at my site. So the duplicate GUIDs will re-appear after 2 or 3 WDS builds, and then i'll be back in the same boat as before..

    .

    So what ive done to prevent Active Directory from getting duplicated GUIDs - i made a power shell script that goes into AD and deletes ALL GUIDs from all objects. Dosnt seem to harm anything so im just blowing them all out. I run this script every 5 min via a scheduled task (maybe thats overkill?) ..

    .

    Now when i build a Win7 WDS image - i can be sure there are no duplicate GUIDs in AD, AND it will generate a random hostname as ive defiend in the WDS server properties page.

    .

    Then i use FirstLogonCommands to execute another .VBS script to change the hostname to my desired name. This script actually changes the hostname in AD and does not break the trust relationship.

    .

    .

    What a NIGHTMARE... Thank you M.$. for making my life harder with you 'newer and better' WDS... I liked my RIS just fine....

    .

    Thanks for all your help guys!


    me

    • Marked as answer by drumgod Friday, April 13, 2012 12:30 PM
    Friday, April 13, 2012 12:30 PM
  • For other guys find attatched a powershell cmd for deleting the GUID from AD computer objects that are older than 5 day:

    Get-ADComputer -Filter {NetbootGUID -like "*"} -Properties Created | ? {$_.Created -le ((get-date).addDays(-5))} | Set-ADComputer -clear NetbootGUID

    ......

    Regards,

    Tim


    http://directoryadmin.blogspot.com


    • Edited by butim Monday, April 16, 2012 11:54 AM
    Monday, April 16, 2012 11:54 AM
  • For other guys find attatched a powershell cmd for deleting the GUID from AD computer objects that are older than 5 day:

    Get-ADComputer -Filter {NetbootGUID -like "*"} -Properties Created | ? {$_.Created -le ((get-date).addDays(-5))} | Set-ADComputer -clear NetbootGUID

    ......

    Regards,

    Tim


    http://directoryadmin.blogspot.com



    Please note - the above PS script Requires Windows 2008 / Windows 7 with the installed Active-Directory PS module.

    me

    Monday, April 16, 2012 1:01 PM
  • Hello, I have more information that may help. We got a pile of used Gateway computers and they are duplicating machine names just as described here. Up until now we've primarily used Dell computers and never had any problem.

    If you switch your Active Directory Users and Computers (ADUC) MMC to Advanced mode (View menu -> Advanced Features) and examine the netbootGUID of the machines that keep reduplicating each other's machine name, you may see a repeated pattern like this:

    03000200-0400-0500-0006-000700080009

    ,

    Searching the Internet for this number turns up some interesting results, like this article:

    http://howtowriteaprogram.blogspot.com/2012/06/smbios-uuid-fail.html

    Partial quote:

    In the SMBIOS System Information table (Type 1) there is a field called UUID which is described as "Universal Unique ID number. If the value is all FFh, the ID is not currently present in the system, but is settable. If the value is all 00h, the ID is not present in the system."

    So let's assume your program reads this value (either directly or via WMI Win32_ComputerSystemProduct, for example) and the value is not all FFh or all 00h; what two properties would you expect of this universally unique identifier? I suggest you'd want it to be (a) a unique value, and (b) an unchanging value.

    Oh dear.

    I've probably seen more SMBIOS UUIDs than you've had hot dinners, and I can tell you that the UUID is not always unique and not always constant.

    Sometimes the UUID has some kind of "obviously" non-unique place-holder, such as a repeated pattern. For example, it might be 58585858585858585858585858585858 (58 hex = ASCII 'X') or it might be 00020003000400050006000700080009. (And don't forget that, although it looks like a pretty obvious pattern, when read in little-endian byte order, as the SMBIOS UUID field should be, the UUID you will get is {03000200-0400-0500-0006-000700080009}.) You might write some code that could detect some of the more obvious patterns and discard the UUID as probably non-unique when you find them. By the way, both of these examples are from real computers.

    Sometimes there is no discernable pattern in the UUID - it looks random. That is good. Except when you find that somehow every computer at that customer site has exactly the same "random" UUID.

    Again, sometimes the UUID looks truly random, and no two computers appear to have the same UUID. And then you restart the computer and now you have a new UUID, completely different to the one the computer had last time you looked! This is pretty rare, but I've seen it happen. A more common problem is that, for some reason, someone in the organisation changed the UUID, maybe deliberately, maybe unintentionally.

    I think that for the majority of computers the UUID is a unique constant. But because some computers have bad UUIDs, and because you cannot always tell the good from the bad just by looking at the UUID, the only safe thing to do is assume that all computers have bad UUIDs. And that's a shame. I guess a few people spoiled it for everyone.

    Perhaps I misunderstood the SMBIOS documentation. To be fair, it doesn't actually say "if present, this value will be unique to this system board and will never change." It's rather terse on the subject. But it does say, "Universal Unique ID number." So, you know, I assumed the ID would be unique. Perhaps they meant to say, "Potentially Universal Unique ID number. Look, we are just providing somewhere to put a 128-bit number, and if someone sets it to a unique value, and they don't change it, then it will be unique and constant."

    (snip)

    ,

    ,

    So basically the computer manufacturer screwed up and failed to make the SMBIOS UUID unique on each machine. This is why WDS is getting confused, and why the problem only affects certain machine types.

    For me, the affected machines are "Gateway ClientPro E - 4620N".


    Thursday, August 23, 2012 11:57 AM
  • Oh, and take a look at this other thread. WDS already has a way of handling bad / duplicate GUIDs due to manufacturers not setting this attribute correctly in the machine's BIOS:

    Getting SCCM to ignore the UUID?

    http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/76198d2e-5957-4518-afd2-fe5ebee88dc0/

    ,

    No need to hack the directory, apparently. Just put your bad GUIDs in the WDS server's registry key mentioned and WDS will only use the MAC address of machines that have duplicated GUIDs.


    • Edited by Dale Mahalko Thursday, August 23, 2012 12:10 PM
    • Proposed as answer by Dale Mahalko Thursday, August 23, 2012 12:11 PM
    Thursday, August 23, 2012 12:10 PM