Error: "A Server Error Occurred" encountered while logging into the DR site recovery manager
Article ID: 388848
Updated On:
Products
Issue/Introduction
Symptoms:
- SRM/VR URL may not be accessible.
- Unable to login to the site recovery page from vCenter UI.
Validation:
- Accessing the SRM/VR URL fails as below:
- Open site recovery option is greyed out. vSphere Replication is reported with read configuration error, and we see "
The VRMS Solution user is missing or outdated". Visit the vSphere Replication VAMI and reconfigure the appliance"as informational message.
Procedure to login to the site recovery page: Login to the vSphere Client and navigate to the Site Recovery section. You’ll see that vSphere Replication is listed as a registered service. Click on OPEN Site Recovery:
- Registering vSphere Replication fails with
Server returned 'request expired' less than 0 seconds after request was issued, but it shouldn't have expired for at least 600 seconds.
- Reconfiguring the appliance may fail with below Time skew errors.
Environment
Cause
1.This issue is caused due to the time skew between vCenter Server and the vSphere Replication Appliance. These issues are seen when there are time synchronization issues between the vCenter Server and the SRM appliance which is more than 30 seconds.
2.NTP (Network Time Protocol) synchronization between the SRM/VR and vCenter Server are not functioning correctly.:
- Watch the time on vCenter and the VR appliance by either running command
"watch date"or same can be checked under VAMI page >Time.
To watch the date and time using watch date and You may see similar output as below:
On vCenter appliance
On VR appliance
Same can be checked on VAMI page of the vCenter appliance. Link to login into VAMI: https://<FQDN_or_IP_address_of_appliance or vCenter:5480 > Time
Validate the time synchronization issues.
1. Manually restarting the timesyncd service using the below command
watch date command. Check either if ntpd or systemd-timesyncd.service are active:admin@srm-02 [ ~ ]$ service ntpd status* ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor pres> Active: active (running) since Fri 2025-02-21 11:00:09 PKT; 1min 25s ago Docs: man:ntpd systemd-timesyncd.service are runningadmin@srm-02 [ ~ ]$ systemctl status systemd-timesyncd.service* systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disable> Active: inactive (dead) Docs: man:systemd-timesyncd.service(8)active (running) and systemd-timesyncd is reported to be inactive (dead).systemd-timesyncd.service as to see the if the appliance gets time synchronized as per vCenter.root [ /home/admin ]# systemctl start systemd-timesyncd.serviceroot [ /home/admin ]# systemctl status systemd-timesyncd.service* systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disable> Active: active (running) since Fri 2025-02-21 11:04:29 PKT; 2min 18s left Docs: man:systemd-timesyncd.service(8)root [ /home/admin ]# service ntpd status* ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor pres> Active: inactive (dead) since Fri 2025-02-21 11:04:29 PKT; 2min 9s left Docs: man:ntpdsystemd-timesyncdactive (running) and ntpd is reported to be inactive (dead).root [ /home/admin ]# cat /etc/systemd/timesyncd.conf# See timesyncd.conf(5) for details.[Time]#NTP= >>>>>>>>>>>>>>>>>>>> Here you may see NTP server IP is not updated.#FallbackNTP= *****#RootDistanceMaxSec=5Resolution
There are several workarounds to fix the time skew issues as below.
1.You may reconfigure the time synchronization by disabling and enabling the NTP on vCenter and VRMS appliance.
if reconfiguring the NTP via vCenter and VR VAMI does not help to fix the issue then you may further check the time services as below.
2.Manually restart the timesyncd service using the below command. Keep a watch on current date and time by running a watch date command. Either one of the below services should be used for time sync and should be active. This can be checked vice versa.
systemd-timesyncd.service:systemctl start systemd-timesyncd.servicesystemctl status systemd-timesyncd.servicentpd:service ntpd startservice ntpd statusntpd or systemd-timesyncd.service do not fix the issue, then you may try to update the timesyncd.conf file with correct NTP server IP details.- Please note that it is recommended to have the same time source in the entire vSphere or VCF environment
- If the appliances and the VMs are joined to a AD domain, it is recommended to make the domain controller as the time source
- If you have a few VMs joined to the AD domain and a few VMs which are not joined to the domain, it is still recommended to use the domain controller for all the vSphere or VCF entities
cat /etc/systemd/timesyncd.conf - To view the conf file.vi /etc/systemd/timesyncd.conf - To edit the conf file.timesyncd and verify time synchronization - systemctl restart systemd-timesyncd.servicewatch date and compare with vCenter appliance. This should fix the time synchronization. If you still see time deviates more than 30 secs, then you can update the time manually as below.date --set="DD MONTH YYYY HH:MM:SS"For example:date --set="24 May 2015 16:25:00"watch date on SRM/VR and vCenter appliance after manual date/time update. Ensure that the time synchronization between the vCenter Server and the SRM/VR appliance is within 30 seconds which is essential to prevent time skew issues.vCenter Appliance:root [ /var/lib/sso-user ]# dateFri Feb 21 11:22:22 PKT 2025SRM/VR appliance:root [ /home/admin ]# dateFri Feb 21 11:22:30 PKT 2025Feedback
