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:
Properties=SMS_Unique_Identifier0
5. Add the following section to the end of the Rules:
[GetSMSGUID]
SQLServer=SMS DB Server
Instance= SMS DB Instance, if used
Database=SMS DB name
Netlib=Netlib type
SQLShare=Share on SMS DB Server
Table=System_DISC
Parameters=OSDNewMachinename
Order=Creation_Date0 DESC, Active0
OSDNewMachinename=Netbios_Name0
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
Anonymous
January 01, 2003
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. BenAnonymous
January 01, 2003
Hi Jacob, You should have no problems. I have done this myself sucessfully before. Thanks, BenAnonymous
January 01, 2003
Hi Conny, If you remove the "GUID:" from your CustomSettings.ini then this should work. Thanks, BenAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi, You do not need to use this script with ConfigMgr. It will look after the GUID issue for you when you rebuild a machine. Thanks, BenAnonymous
January 01, 2003
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:
- The site is in native mode and the new machine is given the same certificate (e.g. using AD)
- 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) Thanks, Ben
Anonymous
January 01, 2003
Johans method should work. Also the wizard should cause no issues. Thanks, BenAnonymous
January 01, 2003
Thanks for that information Troy.Anonymous
January 01, 2003
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: http://blogs.technet.com/benhunter/archive/2007/03/17/understanding-bdd-rule-processing.aspx Thanks, BenAnonymous
January 01, 2003
The priority doesn't really matter.Anonymous
January 01, 2003
I depends on what you are trying to do, but it is there to make things simpler.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi Ryan, Did the SMSCFG.INI file actually get updated as the log says? Thanks, BenAnonymous
January 01, 2003
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 ? Or.Anonymous
July 24, 2007
Tried this,and Z-CONFIG-REUSE-SMSGUID.log says it successfully updated the smscfg.ini file, but the workstation still received a new GUID.Anonymous
July 31, 2007
The comment has been removedAnonymous
August 17, 2007
[GetSMSGUID] . . OSDNewMachinename=Netbios_Name0 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 BenAnonymous
August 17, 2007
The comment has been removedAnonymous
August 17, 2007
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?Anonymous
October 04, 2007
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.iniAnonymous
October 04, 2007
The comment has been removedAnonymous
November 19, 2007
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?Anonymous
December 17, 2007
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.
- Uninstall SMS Client
- run ccmdelcert.exe
- 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? regards Conny
Anonymous
December 18, 2007
The comment has been removedAnonymous
January 22, 2008
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.Anonymous
February 02, 2008
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.Anonymous
March 04, 2008
Try this in Microsoft Deployment using the litetouch wizard and it pulls the WinPE computername rather then the one I assign, any ideasAnonymous
March 11, 2008
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??