VSatellite Worker is Unavailable When Testing MSCA Credentials


When adding a Microsoft Certificate Authority in Venafi as a Service and testing the credentials, you receive an error message stating something similar to:

"VSatellite Worker is unavailable: Microsoft ADCS is unavailable. This error is often caused due to invalid credentials or connection information. Microsoft ADCS responded with error: CCertAdmin:GetCAProperty: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE), Error Code -2147023174"



When adding a Microsoft Certificate Authority in Venafi as a Service, after deploying and successfully connecting a VSatellite host and VSatellite Worker, you are prompted for 4 pieces of information:

  • FQDN or IP address of MSCA host
  • Microsoft CA common name
  • Username
  • Password

After entering the information you receive an error similar to the one noted above indicating the VSatellite Worker is unavailable.


There are various reasons for the message to appear. 

  • The VSatellite Worker Service is installed on the Microsoft CA instead of a separate system.
  • The VSatellite host, VSatellite Worker, or MSCA has just gone offline.
  • An FQDN was Supplied for the AD CS Administrative Address Rather Than A Host Name or IP Address.

  • An incorrect name for the common name (CN) of the target MSCA service was provided.
  • The username is incorrect or the account is disabled.
  • The password for the username is incorrect.
  • Proper permissions were not assigned to the target service account.


Depending on the cause, there will be different resolutions. Following is the corrective actions to take or validate.

The VSatellite Worker Service is Installed on the Microsoft CA Instead of a Separate System

The VSatellite Worker service is unable to communicate properly to the local RPC host. It must be deployed on a system that is not also functioning as the target certificate authority. To resolve this problem:

  1. Cancel the current install/configuration of the MSCA.
  2. Uninstall the vsatellite worker. This can be done with Programs and Features in Control Panel or by running .\vsatworkerctl.exe uninstall in an administrative PowerShell session.
  3. Start the Microsoft CA deployment again and obtain a new pairing code.
  4. Perform the installation on a new Server 2019 or later host that is not functioning as the target certificate authority.

The VSatellite Host, VSatellite Worker, or MSCA Has Just Gone Offline

Sometimes an error will occur that will disable a system that was just being managed. Verify connectivity to all systems and that required services are still running.

  • On the Microsoft CA host, ensure the Active Directory Certificate Services service is running. If this CA was just restored from a VM snapshot or came out of suspend/hibernation. This service may just need a restart.
  • On the Microsoft CA, ensure your firewalls allow inbound TCP access to port 135 and the ephemeral ports from the VSatellite Worker.
  • On the VSatellite Worker, ensure it can connect to the Microsoft CA on port 135 and the ephemeral ports. An easy test is to use the RSAT tools to connect to the Microsoft CA service or use WMI from a PowerShell prompt with the following command: 

New-CimSession -ComputerName REMOTEMACHINE -SessionOption (New-CimSessionOption -Protocol Dcom) -Credential "MYDOMAIN\MYUSER"

  • On the VSatellite Worker, ensure your firewalls allow inbound TCP connectivity to port 8085 from the VSatellite host.
  • On the VSatellite host, ensure it is online and communicating with Venafi as a Service at:
  • On the VSatellite host, ensure you can connect to your VSatellite worker on port 8085 (or an alternate port if so configured) using utilities like OpenSSL, nmap or telnet.
  • In Venafi as a Service, go to Settings | VSatellites and check the status of your VSatellite is Active and the Last VaaS Check-In happened within the last 30 minutes or less. If the the status is not active or the Last VaaS Check-In is not within those parameters, a restart of the host can often fix these problems.

An FQDN was Supplied for the AD CS Administrative Address Rather Than A Host Name or IP Address

When adding the Active Directory Certificate Services information a host name or IP address must be supplied. Fully Qualified Domain Names (FQDNs) cannot be used. Change the AD CS administrative address field to contain either a host name or IP address.

An Incorrect Name for the Common Name (CN) of the Target MSCA Service was Provided

The common name of the certificate authority is best had by examining the certificate issued to the CA by its root. There are several ways to obtain this information, two of which are:

  • From any Windows system joined to the domain, open a command or PowerShell prompt and run: certutil.exe. The output will contain a list of certificate authority services. Copy the name, without quotes from here.
  • From the issuing certificate authority in the Certificate Authority snap-in. Normally the service name  at the top of the tree in the MMC should match the certificate service name. To be sure, go to the properties of the CA within the snap-in. From the General tab, select View Certificate. Note the Issued to: value. This is the expected name.


The Username is Incorrect

The name entered should simply be a username without qualification. So using a domain name of and a username of vaas-svc-acct, the user's name should simply be entered as vaas-svc-acct and all domain components should be omitted.

The Password for the Username is Incorrect or the Account is Disabled

Validate the correct password is being used and is 127 characters or less in length. Ensure the domain account referenced is not currently disabled or locked out.

Proper Permissions Were Not Assigned to the Target Service Account

In order to successfully connect to the Microsoft AD CS host, proper permissions must be assigned. These permissions are defined here in the Venafi as a Service documentation:

the target username or a group it belongs to must have been granted the following permissions on the target CA:

  • Issue and Manage Certificates
  • Request Certificates

To check these permissions:

  1. Open the Certificate Authority snap-in (RSAT tools may need to be installed if not on the CA).
  2. Right-click on the CA and select Properties.
  3. Select the Security tab. 
  4. Validate the user or a group it belongs to is granted both permissions stated above.
Was this article helpful?
0 out of 0 found this helpful