Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have 2 HP Proliant servers with Windows Server 2008 R2 installed on them. They are headless servers, and I do not have a way of visually seeing the user interface of the servers. I do however know the IP addresses and computer names. I recieve an error that says

Remote Desktop cannot connect to the remote computer because of authentication certificate "...." possible time difference between machines.

Would there be a possible way to know what time zone is set by default on Windows server? Before connecting the servers to the network, I believe they were not hooked up to any power for some time, and so the time settings may have been reset or could it really be the certificate, and is there a way to get past it?

share|improve this question
Unless these Proliants are really, really old you should have a way of seeing the console - via iLO. Not that it will really help you in this scenario, just thought you should know. – Mark Henderson Mar 31 '14 at 0:56
@MarkHenderson: These are HP Proliant DL380s, so they are not very old at all. – Kevin Mar 31 '14 at 12:31
As @RyanRies pointed out, you might have a dead battery on one and during the last reboot your real time clock lost its current time. If that happens, it will drift too far from the real time to let windows correct to the domain controller or internet time. FWIW, I am still rocking DL380 G5s, G6s and G7s over here and all have ports on them for video (front and rear), so unless you don't have access physically to them, you should be able to login locally and take a look. – MikeAWood Apr 1 '14 at 23:46

It's not a timezone problem - the system clock is skewed too far. Timezones... don't really affect the computer in this fashion - they use epoch time anyway. (Yes, even Windows uses a system based on epoch time.)

Try using the /console switch (call mstsc.exe from a command line) and a local account - otherwise, you'll have to connect physically to the machine (or using the iLO, assuming you have one) and reset the time manually before you'll be able to connect.

(As pointed out in the comments and by Ryan, you want the /admin switch for newer versions of mstsc.exe - it was renamed in Vista SP1/Server 2008.)

And, once you get this sorted, it might not be a bad idea to set up some synchronization on your domain... and/or not power off your servers for an extended period of time.

share|improve this answer
See /console isn't supported with Windows Server 2008 R2. You might try PowerShell remoting. – 0xFE Mar 30 '14 at 21:53

Uh, well, the default time zone on a Windows OS is Redmond, Washington time. :P But that's irrelevant, since as HopelessN00b points out, timezone differences don't equal clock skew.

But I'm going to bet time differences aren't your problem anyway. The error message mentions that the server gave you an invalid certificate. In order for that to happen, that means the server's clock would have to be so off that it hasn't created a new self-signed certificate because it thinks its living in the past... that means the clock would probably have to be off by... months, maybe even more. And if the servers have working CMOS batteries in them, the clocks should not be off that far even if the machines were powered off for months.

And /console is for 2003/XP... in 2008 and above, it has been replaced with the /admin switch.

Here's an idea... try connecting to the server with a WinXP/2003 client that still has the old RDP client that doesn't support TLS. That means (unless you've turned it off) the remote desktop server will negotiate down to native RDP encryption instead of TLS, which will make the server certificate irrelevant. (Or disable TLS on your Remote Desktop Client on 2008... temporarily.)

Or, try opening an MMC on your server and opening the Services snap-in, then connecting your problem server remotely from there. If you can connect (RPC connectivity, credentials works,) then restart the Remote Desktop Configuration service from there.

If all that fails... out of band management to reset the clock, or reboot the server, or at least restart the Remote Desktop Configuration service and it should generate a new self-signed cert with an appropriate time period on it if the server's clock is decently accurate.

enter image description here

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.