arcserve-KB : Unable to see recovery points form UDP Agent

Last Update: 2018-03-22 13:08:41 UTC
Problem: No recovery points are visible from UDP agent even after the backup is completed successfully.


UDP Server version: Arcserve Unified Data Protection Version: 6.0.3792
Operating system version: 2012
Arcserve UDP Agent Version: 6.0.3792 or higher version of UDP
Plan Details: Agent based plan

LOG Analysis:

Failed {tomcat8.exe:: AFCoreInterface.dll(3792.303)}
AFSrvConfig::GetAdminAccountFlag: The flag file [C:\Program Files\Arcserve\Unified Data Protection\Engine\Configuration\6FD0E15A-149B-41ac-90B2-DCD16C42AD57] exists, the admin account is the same with registry {tomcat8.exe:: AFCoreFunction.dll(3792.303)}
0X0000052e] AFImpersonate: The admin acccount[SERVER\USER_admin] is invalid  {tomcat8.exe::AFCoreFunction.dll(3792.303)}
0X0000052e] AFCreateConnection: Fail to do impersonate {tomcat8.exe:: AFCoreInterface.dll(3792.303)}
AFConnectRemoteSource: v_connect to[\\\CA_UDP_ARCS0000\adminserv[28755033-f8da-49da-b243-50491b13decc]] by [NYMC.EDU\ca_ebbackup] session [084160x00000000:0x000003e7]  {tomcat8.exe:: AFCoreFunction.dll (3792.303)}


Change to UDP  View in the backup destination folder  for the “Node name” and verify if able to perform the restore

Using the Restore  GUI the recovery points are not shown and gives an error 'No Recovery points found on the selected  backup location.

Perform the following steps on the Agent machine
Edit the registry
Navigate to the key 'HKEY_LOCAL_MACHINE\SOFTWARE\Arcserve\Unified Data Protection\Engine' 

- Create a REG_ dword 'LogonType'  and set the decimal Value to 3 
- Restart UDP services by following the article below

- Should be able to see the recovery points and restore from the UDP agent GUI.

Information on what Logon type 3 does in your environment :

This logon type is intended for high performance servers to authenticate plaintext passwords. The LogonUserExExW function does not cache credentials for this logon type.

User Impersonation allows an application to execute a task using the security context of another user. For example, a service running as LocalSystem could access network resources by impersonating a specific user account. This account would have been configured with the necessary permissions to access a network resource, something the service would not be able to do otherwise. 

Reference : Microsoft article :
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request