BDD 2007 – Reusing the SMS GUID in a New Computer deployment

When performing a refresh based deployment using Zero Touch BDD will retain the computers current SMS GUID. This is very handy if you want to rebuild a computer but not lose any information associated with the computer SMS. (i.e. Assigned applications or configuration). This also has the effect of reducing the number of duplicate records in SMS.

Unfortunately when rebuilding a computer using a New Computer scenario (from PXE or CD/DVD) the SMS GUID value will not be retained. To get around this issue I query the SMS database to see whether an SMS 2003 GUID already exists for the computer. If one does exist, the SMSCFG.ini file on the computer is updated to include the SMS 2003 GUID.

The process is used to perform this "magic" involves two main processes:

    1. Use rules to perform an SMS database lookup.

    2. During the Post Install phase the SMSCFG.ini file is updated with the correct SMS GUID.

The rest of the post details how these two processes are implemented.

Update the Rules on the ZTI Deployment Point

The next thing you need to do is update the rules on your ZTI deployment point. These rule updates perform a lookup on the SMS database. If it finds a record with its NetBios_Name0 value equal to the current computer name then it will populate the SMS_Unique_Identifier0 variable with the value from that record.

To update the rules on the deployment point, complete the following steps:

    1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

    2. Open the ZTI deployment point, select the Rules tab.

    3. Add the GetSMSGUID value to the priority line of the rules:

Priority= Default, GetSMSGUID

Note - The GetSMSGUID section must be added after the section that determines the computer name.

    4. Add the SMS_Unique_Identifier0 value to the Properties line of the Rules:


    5. Add the following section to the end of the Rules:


SQLServer=SMS DB Server

Instance= SMS DB Instance, if used

Database=SMS DB name

Netlib=Netlib type

SQLShare=Share on SMS DB Server



Order=Creation_Date0 DESC, Active0


Note - For more information on how database lookups are performed using rules please refer to my rule processing blog here.

Copy the Script to the Deployment Point

The attached script will update the SMSCFG.ini file with the SMS GUID if one was identified by the rules.

    1. Copy the script Z-CONFIG-Reuse-smsguid.wsf to the .\Distribution\scripts folder.

Note - Any script in the Distribution\scripts folder that starts with a "Z" will be automatically replicated to the ZTI deployment point.

Create an Application

I am a strong believer in an application for every task you perform within BDD wether they update a file or install an application. These applications can then be added to the task sequence as required.

To create an application, complete the following steps:

    1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

    2. Click Distribution Share, right-click Applications, and then click New.

    4. Select Application without source files or elsewhere on the network, and then click Next.

    5. Set Application Name to CONFIG-REUSE-SMSGUID.

Note - When creating an application you should use a naming convention that clearly identifies the purpose of the application.

    6. Set the Command Line to cscript "%SCRIPTROOT%\Z-CONFIG-REUSE-SMSGUID.wsf".

    7. Set the Working Directory to %SCRIPTROOT%.

Add the Application to the Task Sequence

Now that you have created the application you must now add it to the builds task sequence.

To add an application to the build task sequence, complete the following steps:

    1. Click Start, then point to All Programs. Point to BDD 2007, and then click Deployment Workbench.

    2. Click Builds, right-click BuildID (where BuildID is the name of the build to edit—for example, DEP-VISTA-ENTERPRISE), and then click Properties.

    3. Click the Task Sequence tab.

    4. Navigate to the Postinstall group.

    5. Select the Inject Drivers task.

    6. Click Add, and then select Application\CONFIG-REUSE-SMSGUID.

Note - This will add the CONFIG-REUSE-SMSGUID after the Inject Drivers task.

Update the BDD Deployment Point

Once the changes have been made to the rules and the applications you must update the deployment point to commit the changes and copy the new script to the deployment point.

Update the SMS Package

Now you must update the SMS package and the distribution points with the new script (Z-CONFIG-REUSE-SMSGUID.wsf) and rules.

To update the task sequence, complete the following steps:

    1. In the SMS Administrator console, locate Site Database, and then expand Image Packages.

    2. Double-click the image package you are updating, and then click the Programs subfolder.

    3. Right-click the program (for example, Install), and then click Properties.

    4. Click the Advanced tab.

    5. In the Phase selection field, ensure that Validation is selected, and then select Zero Touch Install - Validation.

    6. Click Settings.

    7. In the Custom Action dialog box, click Add.

    8. Browse to \\ServerName\ZTI$\BuildName (where BuildName is the name given to the build select all the files, and click Open.

Note - Ensure that All Files (*.*) is selected in the Files of Type dialog box.

    9. In the Custom Action dialog box, click OK.

    10. In the Install Properties dialog box, click OK.

    11. Right-click the image package, point to All Tasks, and then click Update Distribution Points.

Note - Be sure to determine the network implications of updating distribution points before performing the update.

    12. In the Confirm Update Distribution Points dialog box, click Yes.   

So that's how it done. Hopefully you will find this process useful, I certainly do. 

UPDATE - 31/12/207

This script will not work for Configuration Manager. This is because it uses certificates to identify clients rather than the GUID.

However if you are using the built-in media and PXE support provided in ConfigMgr then it will automatically look up the previous identity and try to use it.  But it will only succeed if:

       1. The site is in native mode and the new machine is given the same certificate (e.g. using AD)

       2. The site is in mixed mode and configured to manually resolve conflicting records and the admin resolves the conflict using the “Merge” action (See the “Conflicting Records” help topic 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Comments (29)

  1. Ben Hunter says:

    Built in media support refers to the option within ConfigMgr to create media. For example a DVD deployment image. This is similar to the way that BDD creates a ISO image for DVD based deployment.

    PXE support refers to the PXE service point role within ConfigMgr.

    You are quite correct about changing the smscfg.ini file. This is because it no longer uses the GUID value to identify clients.

    Thanks for your feedback, keep it coming.


  2. Ben Hunter says:

    Hi Jacob,

    You should have no problems. I have done this myself sucessfully before.



  3. Ben Hunter says:

    Hi Conny,

    If you remove the "GUID:" from your CustomSettings.ini then this should work.



  4. Ben Hunter says:

    Hi John,

    Try replacing the following line in the script:

    strCOMPUTERNAME = oUtility.Computername


    strCOMPUTERNAME = oEnvironment.Item("ComputerName")



  5. Anonymous says:

    I am often asked how I install and configure BDD 2007. So I thought now was a good time detail at a high

  6. Ben Hunter says:


    You do not need to use this script with ConfigMgr. It will look after the GUID issue for you when you rebuild a machine.



  7. Ben Hunter says:

    This script will not work for Configuration Manager. This is because it uses certificates to identify clients rather than the GUID.

    However if you are using the built-in media and PXE support provided in ConfigMgr then it will automatically look up the previous identity and try to use it.  But it will only succeed if:

    1. The site is in native mode and the new machine is given the same certificate (e.g. using AD)

    2. The site is in mixed mode and configured to manually resolve conflicting records and the admin resolves the conflict using the “Merge” action (See the “Conflicting Records” help topic)



  8. Ben Hunter says:

    Johans method should work. Also the wizard should cause no issues.



  9. Ben Hunter says:

    Thanks for that information Troy.

  10. Ben Hunter says:

    Hi Troy,

    This is not setting the OSDNewMachineName to be Netbios_Name0. This command simply translates the value so that when BDD performs a DB lookup it looks for a column with the name Netbios_Name0 then it uses the value from the OSDNewMachineName property to determine what record to return.

    Have a look at my post on understanding rule processing for more information:



  11. Ben Hunter says:

    The priority doesn’t really matter.

  12. Ben Hunter says:

    I depends on what you are trying to do, but it is there to make things simpler.

  13. Ben Hunter says:

    If you are using any type of instance then you must specify it, otherwise you do not need this line at all.



  14. Ben Hunter says:

    Hi Ryan,

    Did the SMSCFG.INI file actually get updated as the log says?



  15. Anonymous says:

    Hi Ben,

    On WinPE 2005, this script’s log report an Object Required (424) error.  i’ve used johan’s method of implementing ADSI Support and tested it but the script remains the same

    I also you the method of displaying the LTI Computer name wizard for name selection, can this be the problem ?


  16. ryan says:

    Tried this,and Z-CONFIG-REUSE-SMSGUID.log says it successfully updated the smscfg.ini file, but the workstation still received a new GUID.

  17. Scott says:

    If I’m using the default instance on my SQL box, I can leave the, Instance =, line blank.

  18. Troy L. Martin ( says:





    In the code/section above, I understand that OSDNewMachineName property is being initialized by the value represented in the Netbios_Name0 field, but why is it being done there?  By the time GetSMSGUID section runs, OSDNewMachineName property will have already been set, and can no longer be modified…Correct?

    I use the computer naming script during NewComputer installs, via the OS Install CD, which actually sets the value of the OSDNewMachineName property.

    Great tip…I’ll be implementing this very soon!!

    Thanks Ben

  19. Troy L. Martin ( says:

    Blog example: Priority= Default, GetSMSGUID

    Line 29 in .wsf file: Priority=GetSMSGUID, Default

    Which Priority line above is correct?  I assume the one in the .wsf file in the .zip that’s available to download.

    Thanks Ben

  20. Troy L. Martin ( says:

    Aahh…very cool!!…didn’t know you could do that and I don’t think documented in any of the BDD Guides.

    So would that take the place of say – a custom stored procedure -, which would be doing the same thing (e.g. returning a record if found)…thereby making the stored-proc irrelevant/not necessary?

  21. Troy L. Martin (troym[at]Intellinet[dot]com (donotspam)) says:

    When "Object Required (424)" error is received when GetSMSGUID section is processed, you need to make sure your SMS Network Connection Account(s) has 1) been given/created a SQL login to the SQL server hosting the SMS database, 2) create a User account for the SMS Network Connection Accounts(s) on your SMS database and 3) grant the User account(s) SELECT permissions on the System_DISC table so that it can be read when the GetSMSGUID section is processed in CustomSettings.ini and BootStrap.ini

  22. Troy L. Martin (troym[at]Intellinet[dot]com (donotspam)) says:

    The following line in Z-Config-Reuse-smsguid.wsf is incorrect:

    objSMSCFG.WriteLine "SMS Unique Identifier=GUID:" & strSMSGUID

    …it should be modifed to…

    objSMSCFG.WriteLine "SMS Unique Identifier=" & strSMSGUID

    The change that was made was to remove "GUID:"…it’s not needed.

  23. ScriptedIT says:

    We never got this to work so we wrote a script to pull the guid from SMS using VBscript and then generating the same smscfg.ini (using parts of the script here).  We install the SCCM client (note we are using SCCM and BDD 2007 lite touch) during the build and clean the cert (using the old SMS reskit tool)ccmdelcert.exe (does sysprep do this for Vista it looks like it may) then disable the client (process to disable).  At the end of the build we log in and start the SMS client.  It then initially writes more detail to smscfg.ini but after a minute it re-writes the whole file with a different GUID.  So we can pull the GUID and we can create the smscfg file the question I guess is with SCCM running on Vista how to you tell the SMS client to retain the same guid if you have the old GUID and the client has been cleaned and is currently disabled?

  24. Conny L says:

    Hi, I have the same issue as ScriptedIT regarding duplicate SMS objects when we reinstall a computer via PXE boot or boot media (new computer scenario). When I initiate the reinstallation from the Operating System (refresh scenario) the SMSGUID is retained.

    I have tried to create the SMSCFG.ini with the old GUID the after apply drivers action and before the Setup Windows and ConfigMgr action without success.

    I’ve also failed to reuse the sms guid on a running computer by doing the following.

    1. Uninstall SMS Client

    2. run ccmdelcert.exe

    3. Leave the smscfg.ini untouched or just the two lines:

    [Configuration – Client Properties]

    SMS Unique Identifier=GUID:"oldguid"

    4.Install SMS Client

    So my question is if there is any way to reuse the SMSGUID when doing a reinstallation initiated via PXE or other deploy media(bare metal) and how the reinstallation initiated from within the operating system is able to do so?



  25. Conny L says:

    Hi again,

    I might add that where running SCCM 2007 and Vista deployment with MDT in the environment.

    I removed the GUID: from smscfg.ini, after that everything looks fine but the logfile ClientIDManagerStartup.log says:

    Client Settings prohibit local GUID generation, no smsid will be (re)generated

    Smsid is invalid but (re)generation is disabled.

    And in SCCM a duplicate record is created, but with the same GUID as before.

    How does the SCCM OS Installation Refresh scenario avoid duplicate records, because in that scenario I have no problem?



  26. ScriptingIT says:

    Built in media and PXE support?  That just means using the PE image that comes with the SCCM built in OS deployment?

    I can confirm that no amount of making changes to smscfg.ini made any difference for us.  In fact there is still no way to get SCCM to retain or get back to its guid (verses using its OS deployment or perhaps the manual method mentioned here).

    If the native method however acheives this in a PE session at some point though we will find it at some point.

  27. ScriptingIT says:

    I guess there are a few people in here who’s real interest is how to link back to a GUID in SCCM using one of the other MS deployment methods (like RIS, Lite Touch BDD, ADS, a manual unattended build etc).  For me there is not so much a need to have the old record more of a want not to have duplicates records.  It might even be the go for me to script deleting the old record in the build and then let it get a new one (AD groups will link back the apps anyway).  I’d love to see a proper solution though that does what this process should do for SMS in SCCM.

  28. JohnStawicki says:

    Try this in Microsoft Deployment using the litetouch wizard and it pulls the WinPE computername rather then the one I assign, any ideas

  29. Jacob Hodges says:

    Hi Ben,

    We use a userexit to prompt for a computer name in LTI and ZTI. This means OSDNewMachinename is never set. Can you see anything wrong with using Computername instead??

Skip to main content