Get-QADComputer fails workflow if launched in PowerShell script through Orchestrator

[Matt_B1]

I am using the cmdlet "Get-QADComputer" in my .ps1 script that is scheduled to execute via Orchestrator.  I have several PowerShell scripts launched by Orchestrator and executed on a windows host without any issues.  For this one script, I have these 2 commands and it always errors out.  The script does not error when run locally.

Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue

$Computer = Get-QADComputer -Identity "server01" | where {$_.name -eq "server01"}

In troubleshooting, I have ran Get-PSSnapin and can see the Snapin for AD is successfully loaded.  I have tried Connect-QADService and that also gives the same error even though it works fine locally.

I am using the vCO 5.1.1. appliance.   On the Windows hosts where the PowerShell scripts are, the AD Snapin is version 1.6.0.2683.

Here is the error in the Orchestrator logs...

PowerShellInvocationError: Errors found while executing script

System.Runtime.InteropServices.COMException (0x8007054B): The specified domain either does not exist or could not be contacted.

   at Interop.ActiveDs.IADsOpenDSObject.OpenDSObject(String lpszDNName, String lpszUserName, String lpszPassword, Int32 lnReserved)

   at Quest.ActiveRoles.ArsPowerShellSnapIn.DirectoryAccess.AdsiDirectory.NativeBind(String adsPath, AuthenticationTypes bindFlags)

   at Quest.ActiveRoles.ArsPowerShellSnapIn.DirectoryAccess.AdsiDirectory.BindToObject(String dn)

   at Quest.ActiveRoles.ArsPowerShellSnapIn.DirectoryAccess.ConnectorFactory.Create(String serverName, String user, SecureString password, ConnectorType type)

   at Quest.ActiveRoles.ArsPowerShellSnapIn.Powershell.Cmdlets.ConnectionAwareCmdlet.EstablishConnection(ConnectionProperties connectionProperties)

   at Quest.ActiveRoles.ArsPowerShellSnapIn.Powershell.Cmdlets.ConnectionAwareCmdlet.GetContainer()

   at Quest.ActiveRoles.ArsPowerShellSnapIn.Powershell.Cmdlets.GetUserCmdlet.BeginProcessing()

   at System.Management.Automation.Cmdlet.DoBeginProcessing()

   at System.Management.Automation.CommandProcessorBase.DoBegin()

(Dynamic Script Module name : invokeScript#14)

[tschoergez]

Can you try to play around with the authentication and credentials that are used to call the Powershell script?

It might be a comparable issue to the one state at the end of this article: http://www.vcoportal.de/2013/04/vco-and-veeam-backupreplication-a-powerful-combination/

Also make sure that there are no erros in escaping the commandline parameters.  Depending on how you call the powershell script, you might have to do some weird "backslash-wars" to generate the command line properly....

Cheers,

Joerg

[Matt_B1 · Accepted solution]

Thanks for the info.  I use the "Invoke an external script" workflow to run several PowerShell scripts from my admin host.  It is easier for me to maintain all the .ps1 files in one location and not import them into Orchestrator.  The article prompted me to switch my Powershell host connection from Basic to Kerberos.  In order to do that, I had to update /etc/krb5.conf on the vCO appliance.  I referenced VMware KB2036986 to get around the "Cannot get kdc for realm" issue.  This issue was primarily because we did not need to have krb5 configured earlier.

I now got a different error when running the workflow after bouncing vCO.

System.NullReferenceException: Object reference not set to an instance of an object.

This pointed me back to the need to make the AD connection first.  It did not work previously without Kerberos authentication.  Once I add these lines of code, Get-QADComputer finally worked without error!   Thanks for the help.

$pass = ConvertTo-SecureString -AsPlainText -Force -String "password"

Connect-QADService -ConnectionAccount "example.com\serviceaccount" -ConnectionPassword $pass

$Computer = Get-QADComputer -Identity "server01" | where {$_.name -eq "server01"}

Disconnect-QADService