Job Details Error Responses

Below is a list of possible errors reported in the Job Details page.

Click the error response message or code below to skip down to its section where further explanation and possible resolutions are located.

If your specific error is not found or the resolutions are still not working as expected, please contact our Support Team for further assistance.


Job Error Responses:

Response error: 401

The 401 error response is usually associated to an Unauthorized response from the remote host. The following reasons may be the root cause for this error:


  1. The User or Password associated to the record (or shadow account) is either incorrect or does not have the permissions to connect to the remote host. To troubleshoot, attempt to establish a Secure Connection using this record to the remote host. If that fails, then Edit the record, modify the User or Password and then try again. For Windows tasks, try using the format DOMAIN\user or for the User parameter in the record.
  2. The user or shadow account used for this Task does not have the Windows permission to execute a remote PowerShell command. To troubleshoot, ensure this user or shadow account is a member of the local Windows group “Remote Management Users” on your remote host and then try again. Some scripts may require additional permissions, so adding this account to the “Administrators” group may also help to resolve the error.
  3. Remote Windows tasks are sometimes executed using the Windows Remote Management protocol and this needs to be enabled on the host. To do so, run the following command on this Windows host: Winrm quickconfig . WinRM, by default, uses the ports 5985/5986 so these must be open between the XTAM host server and your endpoint.


To troubleshoot a 401 response error, consider trying the following:

  1. From the XTAM host server itself, open a PowerShell session (run as administrator) and execute the following command. Replace the bolded values with those from your XTAM record.
  2. Copy
    Invoke-Command -ComputerName remote-host -Credential domain\user -ScriptBlock {dir \}


    If the above command executes successfully, meaning PowerShell does not return any error messages, then it will display a list of directories in the root drive of the remote host.


    If the above command does not execute successfully, then that may indicate an issue with the network’s Windows Remote Management (WinRM) configuration. Try to understand and troubleshoot the error message that PowerShell returns. If you are stuck, consider trying the following:


  3. From the XTAM host server itself, open a PowerShell session (run as administrator) and execute the following command. Replace the bolded values with those from your XTAM record.
    Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value 'remote-host'


    This command will add your remote-host computer to the trusted hosts list in the server’s WinRM configuration. After this command is executed successfully, try executing your record’s Task in XTAM again.

Response error: Cannot perform this operation at this time

When attempting to reset the password on an AS400 host, this message may appear if the Password policy does not allow for the password to be updated at this time.

To troubleshoot, either wait until the policy on the AS400 host allows for the password to be updated or modify the policy to allow more frequent updates and then try again.

Response error: The user or administrator has not consented to use the application with ID

When attempting to reset the password on an Azure or Office 365 Administrative account, the operation fails because permissions have not been fully granted to the Application.

To troubleshoot, login to your Azure Portal (as an Administrator), open our XTAM App you created earlier, click All Settings > Required Permissions > Grant Permissions and then Yes to confirm. Once complete, try the password reset again.

Response error: Verification Error: Exception calling “ChangePassword”

This can commonly be the error response when attempting to a change password in a Windows domain where the new password does not meet the requirements of your Local or Domain Security policy.

For example, this could be the password age (resetting too frequently) or complexity (formula not strict enough).

To troubleshoot, log in to this Remote host and attempt to manually change the password.

If it fails to update manually, check the Password Policy on this Local computer or the Domain Controller to ensure the new password meets its minimum requirements.


Of particular importance, if your Password Policy has the policy Password must meet complexity requirements set to Enabled, then you must configure your XTAM formula to comply with this policy. This means that your formula must meet at least 3 out of the following 4 requirements:

  • Minimum Number of Upper Case Characters: 1 or greater
  • Minimum Number of Lower Case Characters: 1 or greater
  • Minimum Number of Numeric Characters: 1 or greater
  • Minimum Number of Special Characters: 1 or greater

You also want to be aware that most password policies do not allow a password to be changed often (minimum password age), this may mean that you are only allowed to change the password once a day or less often.

While this is an important policy for production account security, it can prove to be problematic during testing where you may need to or want to change an account’s password with more frequency.

Exception calling “SetPassword” … “Access is denied.”

This can commonly be the error response when attempting to set a password (script: Password Set Remote Windows with Service Dependencies) using a non-domain, local account as the PAM Shadow Account.

Due to native Windows permissions, the local account used as the Shadow Account needs additional privileges beyond the usual WinRM requirements. To progress beyond this error, you can use the following options:

Task: Password Reset LDAP, State: error, Message: StrategyDirectory: Error resetting password. PamException: Failure to update AD certificate

This can commonly be the error response when attempting to a reset an Active Directory password when XTAM was integrated with AD not using LDAPS.


If you are using the Password Reset LDAP script, as shown in the above error message, then in order to reset an AD domain password through a native LDAP connection in XTAM, your AD integration must be configured using LDAPS.

Microsoft requires any such AD passwords to be updated only through a secure port using your AD’s SSL certificate.

With this in mind, the first thing to check is that your XTAM AD integration (Administration > Settings > AD) should be using LDAPS and a secure port which is usually either 636 or 3269.

For example, in your Server parameter your connection should begin with ldaps:// and end with the required port 636 or 3269.


If you are not configured with LDAPS, then you will need to change it as required and once the integration is successful, you will need to then restart the XTAM service (PamManagement or pammanager).

During this restart, XTAM will attempt to import your AD’s SSL certificate so that the connection is secured over the defined port which then allows for the password change.


As an alternative approach, you can try using the Windows Host record type to rotate your password. When created, this record type will connect to the Host machine defined in the record and attempt to reset the AD account’s password through this host itself.

This method does not use a direct LDAP connection, so LDAPS is not required in this case.

Task: Password Reset LDAP, State: error, Message: StrategyDirectory: Error resetting password. PamException: Cannot find user domain\user or cannot connect to AD ldaps://yourADServer:3269.

This can commonly be the error response for a few possible reasons.

  • The most obvious reason is that either the displayed user account was not found in this AD or the connection to this AD failed. Confirm that the user does exist with this exact account name, take note that if you are logging into XTAM using UPN accounts, then the User in this record should be in the same format ( Also ensure that XTAM can still connect to your Active Directory using the displayed server and port.
  • If your AD integration limits the scope of user logins based on OU configuration or AD Group membership, then the account in this record should be included in this OU or the defined AD Group. Make the necessary adjustments and retry your password reset task.
    • However, if you do not want to modify your AD integration parameters, consider using additional options in XTAM to manage Active Directory accounts not relying on your integration. For more information, please read this article.

(Partial) Message: StrategyDirectory: Error resetting password. PamException: The WS-Management service cannot process the request. The maximum number of concurrent shells for this user has been exceeded.

Microsoft Server limits the maximum number of concurrent users connected to the WinRM session to five and the maximum number of shells per user to five also. This could present issues when multiple connections, using WinRM, are connected to the host.

If you wish to resolve this issue by increasing the maximum number of allowed user or shells per user, you can use this procedure on the host:

  1. On the host, open command prompt using the Run as Administrator option
  2. Execute the following command to retrieve the host’s current configuration
    winrm get winrm/config/winrs
  3. To increase limits, the following commands may be used if needed (note these changes are permanent unless changed later)

    winrm set winrm/config/winrs @{MaxConcurrentUsers="20"}
    winrm set winrm/config/winrs @{MaxShellsPerUser="20"}
  4. Copy
    winrm set winrm/config/winrs @{MaxMemoryPerShellMB="512"}

For additional information about these limits, please review: