13 Replies Latest reply on May 22, 2012 1:18 PM by JeremyG

    Question about unattend.xml

    Benjamin THIEN Specialist



      I have a question about unattend.xml and provisioning action...

      If i use a unattend.xml file, do i have to add action in provisioning to join domain (already in the unattend file..)


      And in the provisioning windows, when i add a script for unattend.xml file, i have to give a name for the target file, i don't what is it...

      Please help....


        • 1. Re: Question about unattend.xml
          tdavenport Specialist



          The nice thing about using provisioning to join the domain is that it happens late enough in the process for all of the NIC drivers to be properly loaded. We use HII and we noticed that some models would not join the domain with unattend.xml - whiled others would. We now join the domain late in the "System Configuration" phase of provisioning - and have removed the Join Domain action from the unattend.xml file entirely. If you need to use unattend to join, be sure you're putting in the right "pass". There are 7 passes in an unattend script and putting it in the wrong one will prevent it from executing your actions properly. Use the Windows AIK to edit and build your unattend.xml - its a good tool. Finally, you need to name the the unattend script because provisioning can store multiple scripts for different prov. tasks. You need a way to identify unique scripts. I find it helpful when I'm testing different unattends with the same prov. task. Ex: Set up a couple of unattend scripts with your Join Domain statement in different passes. See which one works.


          I hope this helps.

          1 of 1 people found this helpful
          • 2. Re: Question about unattend.xml

            I think travis is right for an essential reason : In unattend.xml your domain administrators account and password should be written in it. Ok the password is cripted but we thinks that it s a security issue. More, if you change your domain account password tou should need to modify all your templates. By using Landesk action to join domain you could use variables. It's easyer to change the value as you need to change it just in Landesk OSD.


            • 3. Re: Question about unattend.xml
              Frank Wils ITSMMVPGroup

              All true, but there is unfortunately one big BUT... The LANDesk Provisioning Join Domain action wont let you add to a custom OU... If you want/need this, you do have to use the Unattend, or a custom vbscript later in the process...



              • 4. Re: Question about unattend.xml
                Benjamin THIEN Specialist



                Thx for your answer, ok i will go in this way then.

                I don't need to add to custom OU... but thx for the information.


                • 5. Re: Question about unattend.xml

                  Yes I know but the domain administrator will move it to the choosen OU. Its not convenient but more secure than writing domain administrative accounts information in a text file. One thing I have learn on security training, is to rename built in administrator's login, to keep it secret, and to use it only for internal administrative network actions.


                  • 6. Re: Question about unattend.xml
                    JeremyG Apprentice

                    As a landesk partner I try to implement the best-of-both-worlds for customers.


                    It is often a need to add machines to the proper OU...sometimes there are many different possibilities of what OU a machine should be joined to, that require logic to figure out.  Other times a deployment is just too large for it to be practical to manually move machines into different OUs.


                    What I generally set up is to create an unattend file with various variables in it thatget replaced during provisioning.


                    For example the account used to add a machine to the domain is not actually in the unattend file.  Instead, the unattend specifies "LANDeskJoinAccount", "LANDeskJoinPassword" "and LANDeskJoinOU".   Provisioning then copies down the Unattend and replaces those values with variables from the provisioning template.


                    In this way, the sensitive information *IS* written out to a plain text files, but it only lives for the life of the deployment job (since unattend is removed at the end), and it is never stored on a network share or an OS image. 

                    • 7. Re: Question about unattend.xml

                      I uses this kind of sollution to re-inject old computer name in a sysprep.inf file (windows XP sysprep) and in an unattend.xml file too.

                      It is working find. But we had a very simple AD tree so we didn't need it for moving computers in a specific OU.

                      But you are right, it could be usefull for others peoples.



                      • 8. Re: Question about unattend.xml

                        I'd be very interested in how others are handling advanced domain joining.  Right now I'm copying netdom.exe and the associated netdom.exe.mui to their corresponding locations, then executing the file to do a netdom remove, then a netdom join.  The remove attempts to remove the account if it already exists.  So far this remove command isn't the most reliable (currently troubleshooting this, seems to be OU related).  The join command puts it into the OU I need it in, which currently the LANDesk join domain function doesn't do.

                        • 9. Re: Question about unattend.xml

                          Why did you need to remove the account? For my part, with an domain administrator account, if you join the domain with a computer which is already existing, it will get back his old AD settings. And for me it is a good thing, because most of time, in this case, it s the computer which have been rebuilt, because of a system failure for example.


                          And in the other ase, the account don't exist.


                          As I explained in my previous posts, I think the best way to use the procurement system is to create a highly customizable. To do this, the ideal is to create a blank image of Windows, ready for running sysprep. Then when you first start, run sysprep it, via the method you want, then install Landesk. At this point everything becomes easily distributable, integration in the field, to software distribution, through the parameterization of the OS.

                          That's how I created my provisioning, which makes them flexible, evolutionary, and virtually universal for all type of computers we have, with a very limited number of ghosts.


                          Hope it can help you

                          • 10. Re: Question about unattend.xml
                            JeremyG Apprentice



                            The way I have removed computer accounts from the domain is by adding ADSI functionality to the WindowsPE boot disk...and then executing a script to remove the account from the domain (once you know what the computer name will be in the template)

                            • 11. Re: Question about unattend.xml

                              If the account already exists in the domain and I use netdom.exe to join a machine to the domain, the join will fail if the computer already exists.  This functionality is different if you go through the steps of joining the domain using the point and click method.  Additionally, when a machine is re-imaged, we want it to be created in the correct OU afterwards.  If you "re-join" a machine, the computer object doesn't move, which may not be the location we need it in if the computer is being repurposed.

                              • 12. Re: Question about unattend.xml

                                Can you copy/paste that here?  I'm unfamiliar with scripting so far (but slowly learning).  How did you enable functionality on the WinPE boot disk?  It looks like LANDesk restricts access to it.

                                • 13. Re: Question about unattend.xml
                                  JeremyG Apprentice

                                  You'll need to get this plugin.    http://www.deployvista.com/Repository/WindowsPE20/tabid/73/EntryId/31/DMXModule/399/ctl/EntryDetails/mid/399/language/en-US/Default.aspx


                                  There's a manul way to do it, but this guy created ADSI as a "driver" so that it's easy to inject into Windows PE with DISM.   If you dont already know how to use DISM andor ImageX, you'll need to download the Windows AIK and get aquinted a bit.  not too hard.


                                  Then You have to mount your provisioning WIM file to C:\Mount an then run this command  (BACK UP YOUR OLD .WIM FILE FIRST!)

                                  Dism /image:c:\mount /add-driver /driver:c:\plugins\adsi\adsi.inf   (or where you extract that ZIP file to)


                                  This just puts ADSI functionality into your provisioning boot disc  


                                  Then you'll have to make a VBScript to run during your provisioning template to delete the computer from AD.  Obviously you'll have to provide the computer name at the start of provisioning in order for any of this to work!!!


                                  I cant provide the exact script you would need, but here's an example.   It will delete the computername specified from AD.   It first checks if the object exists...otherwise the script will error when it tried to delete.



                                  'Setup Variables
                                  Const ADS_SCOPE_SUBTREE = 2
                                  strComputer = "YourComputerName"
                                  strDomain = "YourDomain"
                                  strADUser = "YourUserAccountThatHasPermissionsToDeleteObjects"
                                  strADPass = "YourPassword"

                                  Set objShell = CreateObject("wscript.shell")

                                  'Setup ADO connection so that AD can be queried
                                  Set objConnection = CreateObject("ADODB.Connection")
                                  objConnection.Provider = "ADsDSOObject"
                                  objConnection.Properties("User ID") = strADUser
                                  objConnection.Properties("Password") = strADPass
                                  objConnection.Properties("Encrypt Password") = True

                                  'Open ADO Connection
                                  objConnection.Open "Active Directory Provider"

                                  'Setup ADO Command
                                  Set objCommand =   CreateObject("ADODB.Command")
                                  Set objCommand.ActiveConnection = objConnection
                                  objCommand.Properties("Page Size") = 100
                                  objCommand.Properties("Cache Results") = False
                                  objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

                                  'Set Query
                                  objCommand.CommandText = "SELECT ADsPath FROM 'LDAP://" & strDomain & "' WHERE objectCategory='computer' AND Name='" & strComputer & "'"

                                  'Execute Query and return LDAP Path
                                  Set objRecordSet = objCommand.Execute

                                  'Make sure the LDAP query returns any results.  If not, then the object does not exist in AD and no action required
                                  If objRecordSet.recordcount > 0 Then
                                  strADsPath = ""
                                  'Get the LDAP Path
                                  While Not objRecordSet.EOF
                                       strADsPath = objRecordSet.Fields("ADsPath").Value
                                  'Retrieve LDAP object, and delete
                                  If strADsPath <> "" Then
                                    Set openDS = GetObject("LDAP:")
                                    Set objComputer = openDS.OpenDSObject(strADsPath, strADUser, strADPass, ADS_SECURE_AUTHENTICATION + ADS_SERVER_BIND)
                                    msgbox "Got: " & strADsPath
                                    objComputer.deleteobject (0)
                                  End If
                                  End If