1 of 1 people found this helpful
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.
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.
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...
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.
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.
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.
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.
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.
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
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)
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.
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.
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.
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
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