1

Prior to my starting where I work now this configuration came to be. I would have advised against it for exactly this reason.

We have a domain controller that no one ever set up the iDRAC on, since the separate interface port is not in the system, I don't want to enable the piggyback access on the production interface. according to the system config at Dell, it shipped with a iDRAC8 Basic

I have not been able to tell if I'll be able to verify the status of the Vbat though the iDRAC8 Basic config from inside the operating system without bringing down the system. I know how to do this on Supermicro where they have tools for this exact issue, but I haven't been able to tell if there is a way to talk to the i2c/ipmi interface on the dell from inside Operating System, MS Server 2012.

Does anyone have this experience?

The reason I want to check the VBAT is because the server recently decided to make a 30ish second time hop and then several others which queried it also did the same. 30 seconds isn't enough to break certificates, but it could be an early indicator of another issue, and I have seen failing VBATs cause weird time drift issues before.

Rowan Hawkins
  • 620
  • 4
  • 18

1 Answers1

0

You can install DELL Open Manage to monitor your server from inside the OS.

That said, the CMOS battery is used to keep the "wall clock time" when the system is powered off only. This means that any clock drift during power-on time can not be due to a failing battery.

I would suggest to correctly configure the Windows time service and, if problems continue, try using something as NetTime, which uses the SNTP protocol to keep time synchronized.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • this is mostly correct, however I have seen poorly implemented RTC circuits cause the clock to skew when the battery is weak. Telling me to configure the ntp (which is done already) in windows doesnt fix a fast or slow running clock that is consistenly reporting a divergent time adjustment. – Rowan Hawkins Feb 26 '20 at 20:53
  • When powered on, any recent OS uses other clocksources than RTC; so, even a bad (or failed) CMOS battery should not cause clock drift after boot. Anyway, I suggested using an `SNTP` client, rather than `NTP`, for a reason: `SNTP` converges **much** faster, and `NetTime` can be configured to check the clock each hour. – shodanshok Feb 26 '20 at 22:13