Article ID: 111439, created on Jun 13, 2011, last review on May 3, 2016

  • Applies to:
  • Operations Automation 6.0
  • Operations Automation 5.5
  • Operations Automation 5.4


After automatic failing over of Exchange 2007 virtual server between hardware servers in Active-Active-Passive cluster POA Agent cannot start with various errors:

Can't resolve RootPOA


ServiceProc of "POA Agent" failed to start with error 0.

POA provisioning tasks which are going to provision services on the Exchange virtual server fail with the CORBA/OBJECT_NOT_EXIST error message like in the example below:

Destination host '' (#44), IP '' : Host operation error.

Details: system exception, ID '' Unknown vendor minor code id (0), minor code = 0, completed = NO

In POA log on the Management Node:

May 16 05:25:01 EXMBXNODE4 : [4624:00001834] ERROR: lib: [Loader_impl::Loader_impl] {module_id="Common"; code="1"} Internal error: Can't resolve RootPOA.
 May 16 05:25:01 EXMBXNODE4 : [4624:00001834] ERROR: lib: [plesk_daemon_main] ExSystem: module_id:'Common', ex_type_id:'1',Message:'Internal error: Can't resolve RootPOA.',
 deprecated_codes = (0, 0), properties = { reason: 'Can't resolve RootPOA', }

In the Event Viewer on Exchange server:

Event Type:     Error
 Event Source:   POA
 Event Category: None
 Event ID:       6
 Date:           1/6/2011
 Time:           3:26:30 PM
 User:           HOSTING\pem_admin
 Computer:       P01NMBX09
 ServiceProc of "POA Agent" failed to start with error 0.`
`Event Type:     Error
 Event Source:   ClusSvc
 Event Category: Generic Script Resource
 Event ID:       1233
 Date:           07/01/2011
 Time:           14:39:16
 User:           N/A
 Computer:       PEMEXMBX03
 Description: Cluster generic script resource PEMEXMBXVS02 - PEM Agent: Request to perform the Online operation will not be processed. This is because of a previous failed attempt to execute the LooksAlive entry point in a timely fashion. Please review the script code for this entry point to make sure there is no infinite loop or a hang in it, and then consider increasing the resource pending timeout value if necessary. In a command shell, run "cluster res "PEMEXMBXVS02 - PEM Agent" /prop PersistentState=0" to disable this resource, and then run "net stop clussvc" to stop the cluster service. Ensure that any problem in the script code is fixed.  Then run "net start clussvc" to start the cluster service. If necessary, ensure that the pending time out is increased before bringing the resource online again.

Cluster Management MMC snap-in shows POA Agent clustered resource as failed:


The reason of problem is incorrect values of keys in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SWsoft\PEM\FQDN_OF_THE_NODE registry hive on currently active node in cluster, namely:

  • communication.ip
  • host_id
  • component_id
  • sc_id
  • orb.endpoint.addresses
  • orb_endpoint
  • shared_ip.interface
  • These keys may have incorrect values due to wrong registry replication in Microsoft Failover cluster, see Microsoft KB article for more details.

Additional Information

In clustered Exchange installation we do not register physical servers of the cluster in POA, we register cluster groups. POA Agent registry configuration therefore only cares about a cluster group and not about the actual physical server which owns the group in a particular moment of time.

During cluister failover in Active-Active-Passive clusters, POA relies on Windows cluster registry replication feature to replicate POA Agent registry branch to a new owner, registry checkpoints are used for that. Here is example of registry checkpoints for POA Agent working on virtual server:

 EXVS01:`C:\>cluster res "EXVS01 - PEM Agent" /checkpoints
 Listing registry checkpoints for resource 'EXVS01 - PEM Agent'...
 Resource             Registry Checkpoint
 -------------------- ---------------------------------------------
 EXVS01 - PEM Agent   'SOFTWARE\SWsoft\PEM'
 EXVS01 - PEM Agent   'SOFTWARE\Wow6432Node\SWsoft\PEM'`
 During failover of POA Agent resource Windows cluster should take these registry branches from current owner and replicate them to a new owner.

This, however, does not always work correctly due to the above-mentioned MS issue. For Active-Passive clusters this is not a big deal, there is only one group moving around and registry is always the same. For Active-Active-Passive, on the other hand, we can run into issues - when required registry branch is not replicated properly, POA Agent ends up on a new server with registry branch which belongs to a different resource group. Naturally, in this case POA will not even be able to start up, e.g. just because IP address POA Agent try to bind itself to in registry will be from a different group and not even exist on the server.

The issue is actual for clustered Exchange 2007 installations. In Exchange 2010 there is only one cluster resource, so there are no such problems, and in Exchange 2013 for DAG members we register each DAG member in POA as a separate host, so there is no need to rely on registry replication at all:


The main point in the resolution is to restore correct registry keys in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SWsoft\PEM\FQDN_OF_THE_NODE hive on the problem server.

The correct values may be taken in POA Provider Control Panel in the properties of the 'pleskd' package installed on the problem host and in POA database.

  1. Log into POA Provider Control Panel
  2. Go to Deployment Director > Server Manager > Hardware Nodes
  3. Find the problem virtual server and remember its ID
  4. Click on the server
  5. Switch to the Packages tab
  6. Click the icon right to the pleskd package
  7. Switch to the Package properties tab
  8. Find values of the needed parameters like shown on the screenshot - the required parameters are marked by red:

  9. The value of the host_id registry key is the value you found on the step 3 above.
  10. The value of the component_id key may be found in the POA database using the SQL query below:

    SELECT component_id from components WHERE pkg_id IN (SELECT pkg_id FROM packages WHERE name = 'pleskd') AND host_id = HOST_ID; 

Replace HOST_ID in the SQL query with the value of the host_id registry key you already found.

11.The value of the sc_id registry key may be found in POA database as well: SELECT pleskd_id FROM hosts WHERE host_id = HOST_ID; Replace HOST_ID in the SQL query with the value of the host_id registry key you already found.

12.Start POA Agent service, not clustered resource. * Run Start > Run > cmd * Execute the command 'net start pem' 13.Run Cluster Management MMC snap-in 14.Find and refresh state of the 'POA Agent' clustered resource 15.Make sure it is started 16.Stop and start 'POA Agent' clustered resource To prevent manual restoring of broken registry keys in the future create backup copy of the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SWsoft\PEM registry hive on every single server in Exchange installation when cluster is properly working and then just import it when problem appears again.

Search Words

Cluster POA Agent

Cannot establish connection to the host

Cluster generic script resource

Can't resolve RootPOA

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07 5b048d9bddf8048a00aba7e0bdadef37 2554725ed606193dd9bbce21365bed4e ac82ce33439a9c1feec4ff4f2f638899 956c448bddc7e1f3585373687602379f 6f1456866eed87488c0f02b298a741c0

Email subscription for changes to this article
Save as PDF