[SOLVED] Domain Join Assistance: Account Already Exists

All Replies

• Wednesday, March 31, 2010 4:20 PM

   

   
  

  0

  Add-Computer Cmdlet creates a computer account in AD and joins the machine to domain. In your case the computer accounts are already created, thats why you are getting errors.

  You have to remove the computer accounts from AD, if you want to proceed with this cmdlet, else try using "Netdom Join" command to join the machine to domain.

   

  Regards

  Jas

  ---

  Jaswinder Singh

  • Proposed As Answer by Mohamed Garrana Wednesday, March 31, 2010 5:27 PM
  •  
  • Reply
  • Quote

   
• Friday, May 28, 2010 11:37 AM

   

   
  

  1

  Thanks for the response.

  I understood that the cmdlet was trying to create an account.  What I didn't understand was why there were no options for Add-Computer or a simple one-liner to either remove the existing AD object, replace the existing AD object, or skip the creation of an AD object and just join.

  We couldn't use netdom because that's part of RSAT or another suite of tools and we can't get netdom onto the machine without installing those tools.  (Our users don't need them so why bundle it in the image?)  If I'm remembering things correctly, I tried copying the netdom executable to a machine but that didn't work; from a post I believe I recall reading, we had to copy the netdom executable, the netdom.exe.mui and perhaps another file and place them in specific locations.  I didn't [want to] bother with all that.

  We found two solutions

  1. Search for and remove the old object as part of the domain join process
  2. Use VBScript.

  The problem with the former solution was that although we could successfully remove the object from the domain controller in the Seattle office, we can't control which domain controller the machine will use to join the domain which meant that sometimes, it would join using a domain controller in another office.  Yes, I could try to be slick and create an array of site domain controllers

  Function Get-SiteDC ($office) {
   $site_lookup = @{
   "S1"		= "Site1";
   "S2"		= "Site2";
   "S3"		= "Site3";
   }
  
   $site = $site_lookup.$office
   $siteDCArray = @(nslookup -type=srv _kerberos._tcp.$site._sites.fqdn.domain.tld | where {$_ -like "*hostname*"})
   $siteDCArray[0].substring(20)
  }

   

  Then search for that object in each of the domain controllers, but I (a) hadn't considered that at the time until we fully understood why it was failing and (b) wanted something that would work without the need to wait for replication.

  The problem with the latter was that I had already created a bunch of other powershell scripts and our domain join script was PowerShell.  I just wanted to be uniform.  Besides, 'anything VB can do PowerShell can do better!'

   

  So I used the JoinDomainOrWorkGroup method of Win32_ComputerSystem and incorporated that into our PoSH script.

  Function JoinDOMAIN ($OU) {
   $domain = “fqdn.domain.tld”
   $domainAcc = “domain\user”
   $domainPw = “password”
   $DomainJoin = 1
   $CreateAccount = 2
   $AllowJoinIfAlreadyJoined = 32
  
   $computer = get-wmiobject Win32_ComputerSystem
   $ret = $computer.JoinDomainOrWorkGroup($domain,$domainPw,$domainAcc,$OU,$DomainJoin+$CreateAccount+$AllowJoinIfAlreadyJoined)
   $ret = $ret.ReturnValue
  
   Switch ($ret) {
   2224 {
    $ret = $computer.JoinDomainOrWorkGroup($domain,$domainPw,$domainAcc,$OU,33)
    $ret = $ret.ReturnValue
    }
   }
   
   return $ret
  }

  There were some issues with this as well.  For instance it worked for a handful of machines but fails when the account is already in AD.  So, we were back to square one almost.  However, unlike the Add-Computer cmdlet, this method allows us to choose/control what we'll be doing in AD when we attempt to join.  That's why I use Switch().  (FYI - If you don't know what that error code is run `net helpmsg 2224` or whatever the error code is)

   

  • Marked As Answer by JuliusPIV Friday, May 28, 2010 11:52 AM
  •  
  • Reply
  • Quote