Using Active Roles Management Shell in WinPE

We are using Acitve Roles 7.0.  I maintain the Windows Imaging task sequences.  During the task sequence the tech is prompted for the computer name and the domain to join.  

I have copied the "C:\Program Files\Dell\Active Roles\7.0\Shell" folder and I am copying it to WinPE during the task sequence and importing the modules using the same commands found in "ManagementShell.ps1".  It works for the most part... I can get-QADComputer, and some other tasks, but I'm having trouble getting the New-QADComputer command to create the computer account in some cases.

For example the code below works for DOMAIN1.  But not for DOMAIN2.  When I use DOMAIN2, it will successfully run the "Connect-QADService", but it throws an error when it runs the "New-QADComputer" command saying "New-QADComputer : Logon failure: unknown user name or bad password."

I'm not sure what what I'm missing or maybe is there an easier way?  I've been searching for the best way to do this, but I haven't come up with much.  Any advice is welcome.

Here's the code I'm using:

$DCFQDN = (Get-ADDomainController -Discover -DomainName "DOMAIN1.COM").Hostname[0].tostring()

 $JoinAccount = "DOMAIN1\JoinAccount"

 $creds = get-credential -UserName "$JoinAccount" -Message "Enter Creds"

Connect-QADService -Service $DCFQDN -Credential $creds

 New-QADComputer -name 'TestClient1' -SamAccountName 'TestClient1$' -ParentContainer ‘OU=Win10,OU=Clients,DC=domain1,DC=com' -ObjectAttributes @{edsaJoinComputerToDomain=$JoinAccount} -Credential $creds -Connection $QADConnection



  • Hello, Michael.

    Your question is a bit old now, so you may have already come up with a solution. Your question, though, is a bit confusing.

    Your sample code is showing that you're connecting to a Domain Controller (instead of an Active Roles server), and the call to Connect-QADService is missing the "-Proxy" switch - which means that you're trying to make a change natively in AD, not through Active Roles. In the call to New-QADComputer, though, you populate the edsaJoinComputerToDomain attribute, which of course is an Active Roles-specific virtual attribute that would not be available in native AD. In fact, that this works at all is surprising to me.

    I expect that what you're actually looking for would be more something like this:

    $ARServer = ""
    $JoinAccount = "DOMAIN1\JoinAccount"
    $creds = get-credential -UserName "$JoinAccount" -Message "Enter Creds"
    $QADConnection = Connect-QADService -Service $ARServer -Credential $creds -Proxy
    New-QADComputer -name 'TestClient1' -SamAccountName 'TestClient1$' -ParentContainer ‘OU=Win10,OU=Clients,DC=domain1,DC=com' -ObjectAttributes @{edsaJoinComputerToDomain=$JoinAccount} -Credential $creds -Connection $QADConnection
    Disconnect-QADService -Connection $QADConnection

  • Thanks for the reply Shawn. 
    I found a solution to the problem.  During the task of joining the computer to the domain, I realized that I was actually doing it after the OS was installed to the disk and it rebooted, so I had found the ARS installer in the temp folder on the SCCM server (only 66Mb), and I was able to add a task that runs that install and have it only install the “Tools” components on the client machines during the task sequence.  And then uninstalling it after it is done. It works great now.

    Before that, I had tried the -Proxy switch (without doing the installation of the ARS tools), but it gave me an error about the syntax of the command.  Once I installed the tools, it worked perfectly