Introduction

The following basic scheme illustrates how Parallels Operations Automation (POA) performs provisioning operations on Windows servers using the Microsoft Provisioning System (MPS or HMC):

In the picture above, we can see an example of an operation related to the Microsoft IIS website:

  1. The POA IIS Service Controller (IIS SC), which is running on the POA Management Node, sends a request to POA Agent (pleskd.exe) on the IIS web server.

  2. POA Agent on the IIS server, in turn, sends it to the local MPS Provisioning Client.

  3. MPS Provisioning Client connects via DCOM to the Provisioning Engine on the MPS Management Node and sends a request to it.

  4. The Provisioning Engine activates the corresponding MPS Provider (IIS Provider) and routes the request to it.

  5. The IIS Provider sends the request via DCOM back to the IIS Server using a low-level Microsoft native API.

  6. When all the above operations are complete, the result is sent back to all parts of the chain.

An error may occur on any step of the chain of requests. This article contains examples of possible problems and ways to troubleshoot them, as well as general information related to Windows service provisioning.

Troubleshooting Windows service provisioning tasks

A Windows provisioning-related task may fail with error messages like these:

    No provisioning engines are available to process the request.

    Provisioning request failed. The RPC server is unavailable.

    Provisioning request failed. The RPC server non available

    Failed to instantiate new Provisioning transaction procedure, see application event log for possible errors.

    The remote procedure call failed.

    Unable to find any suitable MPF client nodes

    There is no active MPS server found

If you see any error message from the list above in a failed POA task's properties or in the logs, check the following in the POA-managed environment:

  1. Is POA Agent up and running on the managed server where the operation is to be carried out (e.g., on the IIS server on which the task will create/remove/change the website)? If not, start it.

  2. Is the MPS engine running on the MPS server? If not, start it.

  3. Is POA Agent running on the MPS server? If not, start it.

  4. Is the Microsoft SQL Server used by MPS up and running? If not, start it.

  5. Ensure that communication is possible between all the servers involved in the service provisioning process. Check that network interfaces are up and running on the server, and that the firewall is configured in accordance with the Parallels Automation Firewall Configuration Guide.

Use the following KB articles to check the status of POA Agent and correctly restart it and the MPS Provisioning Engine:

How to check POA Agent status

How to restart POA system services: UI, Management Node, Agents

How to restart MPS Provisioning Engine properly

In some cases, the MPS Provisioning Engine can be running but become stuck (you will usually see that the "dllhost.exe" process consumes a lot of memory in the Task Manager on the MPS server). In this case, you need to restart it.

How to find the required server

There may be many servers in a POA-managed environment. As a result, it may be difficult to understand which server is involved in a provisioning task during troubleshooting. Use the advice below to detect which server the POA Management Node sends requests to (keeping in mind that requests are sent to POA Agent first) while executing a task.

Method #1: The target server may be clearly stated in the POA background task properties in the Last execution output field. For example:

Destination host_id #262 : Provisioning request failed. The RPC server is unavailable.

In this case, POA sends a request to host #262, which can be found in the POA Provider Control Panel:

  • Hardware server - Deployment Director > Server Manager > Hardware Nodes

  • Virtual server - Service Director > Virtuozzo Manager > VPSes

Method #2: The target server may be found in the log on the POA Management Node (/var/log/poa.debug.log on Linux, C:\Program Files\SWsoft\PEM\Logs\poa.debug.log on Windows) using the grep utility:

# grep TASK_ID poa.debug.log | grep host_id | grep "SELECT pleskd"

Replace "TASK_ID" in the command above with real ID of the failed Windows provisioning task.

For example:

# grep 1204706 /var/log/poa.debug.log | grep host_id | grep "SELECT pleskd"
Jun  8 16:08:44 poa : DBG [1:14086:b4df9b90:3526 1:14040:b2342b90 Kernel]: STMT [Con: 13880, 0xb1448330 task:1204706] 'SELECT pleskd_id FROM hosts WHERE host_id = ?'($0 = 262)

In the output of the command, we can see that the target host is host #262, because POA fetches information from the database about the Agent on the host with this ID.

Note: Refer to the article Support Tools pack to learn how to install grep and other useful Unix utilities on a Windows server.

Troubleshooting problems with POA Agent

POA Agent may be one of the points of failure in service provisioning tasks. POA will not be able to provision any service on a managed host if POA Agent is down.

Refer to the following articles to check the status of POA Agent on a Windows shared hosting server and restart it if required:

How to check POA Agent status

How to restart POA system services: UI, Management Node, Agents

How to deal with multiple MPS servers

POA may work with multiple MPS servers to provide load balancing and fault tolerance. Find below instructions on determining which MPS server POA Agent will direct requests to.

Open an RDP connection to the shared hosting server where the provisioning task will be executed, and check the content of the following registry key:

  • 32-bit server: HKEY_LOCAL_MACHINE\SOFTWARE\SWsoft\PEM\remoteEngine

  • 64-bit server: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SWsoft\PEM\remoteEngine

In the remoteEngine registry key, you should see the hostname of the MPS server that will be used. Make sure this resolves to the correct IP address from the Windows shared hosting server.

If the registry key mentioned above is empty:

  • Open the POA Agent log on the shared hosting server:

    32-bit server: C:\Program Files\SWsoft\PEM\Logs or C:\Program Files\Parallels\PEM\Logs

    64-bit server: C:\Program Files (x86)\SWsoft\PEM\Logs or C:\Program Files (x86)\Parallels\PEM\Logs

  • In the log file, perform a search using the failing POA task ID. Look for lines like:

    Jun  8 16:51:45 IIS6 : INF [1:14086:b4af6b90:3272 262:2664:724 pleskd]: [task:1204767 Plesk::MPFClient::MPFClientImpl::processRequest] MPF request executed via legacy mode on node 'MPS01'
    Jun  8 16:51:45 IIS6 : INF [1:14086:b4af6b90:3272 262:2664:724 pleskd]: [task:1204767 Plesk::MPFClient::MPFClientImpl::runRequest] MPF request will be executed on node 'MPS01'
    

In the example above, the MPS server used is MPS01.

To see a list of all servers that have the MPS engine installed:

  • Log in to the POA Provider Control Panel.

  • Go to System Director > Configuration Manager > Services > and filter services with the name MPSEngine.

How to find the provisioning request

In many cases, troubleshooting necessitates seeing the exact request that was sent from POA to the Provisioning Engine, including the values of all parameters.

Refer to these KB articles for instructions on retrieving the full content of a POA provisioning request:

Microsoft Provisioning System

Parallels Windows Provisioning Engine

See also the following Parallels Knowledgebase articles for more information about Shared Hosting Services in POA and ways to troubleshoot problems with them:

Internal content