SRM/VLSR IP customization fails with exit code -1 due to inactive VGAuth service on target VM
search cancel

SRM/VLSR IP customization fails with exit code -1 due to inactive VGAuth service on target VM

book

Article ID: 447641

calendar_today

Updated On:

Products

VMware Live Recovery

Issue/Introduction

When running a Recovery Plan in Test or Recovery mode using VMware Site Recovery Manager (SRM 8.x) or VMware Live Site Recovery (VLSR 9.x), the IP Customization process fails on the target site (DR site).

The following behaviors are observed:

  • The newly generated test virtual machine on the target site powers off automatically during the customization phase.

  • SRM/VLSR tasks report a guest customization failure "A general system error occurred: vix error codes = (1, 0)"

When the affected target virtual machine is manually powered on to inspect the guest customization log file located at C:\Windows\Temp\VMware-imc\srmDeployGuestAlias.log, the following specific error sequence is present:

Running: "C:\Program Files\VMware\VMware Tools\VMware VGAuth\VGAuthCLI.exe" remove --username "SYSTEM" --subject SRM-<UUID>@vsphere.local --file <certificate_path>
Returned: -1
Running: "C:\Program Files\VMware\VMware Tools\VMware VGAuth\VGAuthCLI.exe" add --global --username "SYSTEM" --subject SRM-<UUID>vsphere.local --comment SRM --file <certificate_path>
Returned: -1
Getting output from: "C:\Program Files\VMware\VMware Tools\VMware VGAuth\VGAuthCLI.exe" list
New Alias List:

Running: "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" --cmd "info-set guestinfo.srm.deployPkg.result -1"
Returned: 0
Completed with error; reporting exit code: -1

Environment

VMware Site Recovery Manager (SRM) 8.x
VMware Live Site Recovery (VLSR) 9.x

Cause

The root cause of this failure is that the "VMware Alias Manager and Ticket Service" (VGAuthService) is NOT running inside the target VM at the moment of power-on during the SRM/VLSR test.

When SRM/VLSR executes a Test Recovery Plan, a snapshot-based clone of the VM is booted on the target site, and the customization engine immediately attempts to modify the network settings. To perform this action securely, SRM/VLSR relies on VGAuthCLI.exe to inject authentication certificates (Aliases) into the Guest OS.

If this service is inactive on the target VM — due to a startup type configured as Manual or Disabled, or because the service crashed during the boot sequence — the VGAuthCLI.exe command fails and returns exit code -1. Consequently, SRM/VLSR cannot apply the IP Customization and aborts the process by shutting down the VM.

Note: Because the target VM is an exact replica of the source VM, all service configurations (such as Startup Type) are inherited from the source. If the service is misconfigured or disabled on the source VM, the resulting target VM will consistently fail to start the service upon boot during any subsequent SRM/VLSR test.

Resolution

To resolve this issue, an immediate validation can be performed on the target VM, but a permanent fix must be applied to the source VM to ensure future replications inherit the correct behavior.

Phase 1: Immediate Root-Cause Verification (On target Site)

To verify that the inactive service is the definitive cause before applying a permanent fix:

  1. In the target vCenter, manually Power On the failed test VM.

  2. Log into the Guest OS, open the Run dialog (Win + R), type services.msc, and press Enter.

  3. Locate the "VMware Alias Manager and Ticket Service".

  4. Check the service status: The service will typically be found stopped, with the Startup Type configured as Manual or Disabled.

  5. Note: Manually starting the service or changing settings on this target VM will only fix the current temporary instance. Once the "Clean up" task is executed in SRM/VLSR, this temporary VM will be deleted and the modifications will be lost.

Phase 2: Permanent Fix (On source Site)

To ensure the service runs automatically when the target VM boots up in future SRM/VLSR tests:

  1. Log in to the original live VM on the Source site.

  2. Open services.msc and locate "VMware Alias Manager and Ticket Service" (Service Name: VGAuthService).

  3. Right-click the service, select Properties, and change the Startup type to Automatic.

  4. Click Start to ensure the service runs successfully without errors.

  5. Allow the replication mechanism (vSphere Replication, VMware Live Cyber Recovery, or Array-Based Storage Replication) to complete at least one successful delta sync cycle. This ensures the updated "Automatic" startup configuration is replicated to the target site.

Phase 3: Retry the SRM / VLSR Test

  1. In the SRM/VLSR console, execute the Clean up task to remove the failed test environment.

  2. Initiate the Test Recovery Plan again.

  3. The new target VM will boot with the VGAuthService automatically started, allowing the IP Customization to succeed.

Additional Information

If the service startup type is already set to Automatic on the source VM but still fails to start on the target VM, inspect the VGAuth log file C:\ProgramData\VMware\VMware VGAuth\logfile.txt.0 inside the VM to identify the underlying root cause.

Powered by Wolken Software