none
Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer

    Question

  • ·                                                                                                                                                                                             I haI have been accessing one of my windows 7 remotely using RDC. For some reasons  I can’t access it any more with this message:  

    "Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer. Make sure your computer's clock is set to the correct time, and then try connecting again. If the problem occurs again, contact your network administrator or the owner of the remote computer."

    I have tried to access this windows 7 from Vista and windows 7 workstation, but all get the same error.  I have checked the date and time are the same on all computers.

    What could be the problem? 


    Bob Lin, MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on

    http://www.ChicagoTech.net

    How to Setup Windows, Network, VPN & Remote Access on

    http://www.howtonetworking.com

    Tuesday, May 17, 2011 12:59 AM

Answers

All replies

  • That started happening to me this morning connecting to Server 2008 R2 from Win 7 Enterprise.  It was working fine a few days ago. 
    • Edited by anonymiss1 Wednesday, November 02, 2011 7:32 PM
    • Proposed as answer by jamesdfox Tuesday, December 16, 2014 8:52 PM
    • Unproposed as answer by jamesdfox Tuesday, December 16, 2014 8:53 PM
    Tuesday, May 17, 2011 1:55 PM
  • Check the timezone on both computers.  This error can happen if they are set for different zones, even if the date and time are the same on both.  (also check the AM/PM setting - it's easy to overlook...)
    Tuesday, May 17, 2011 3:20 PM
  • I have done a lot search and collected many cases. My problem is the default gateway changed. All cases I collected can be found this link:

    Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer - http://www.chicagotech.net/remoteissues/rdc4.htm


    Bob Lin, MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on

    http://www.ChicagoTech.net

    How to Setup Windows, Network, VPN & Remote Access on

    http://www.howtonetworking.com

    Tuesday, May 17, 2011 5:07 PM
  • Ours was a DNS issue.  Someone put an entry in the wrong firewall.

     


    Tuesday, May 17, 2011 6:09 PM
  • Thank you for the tip. I will add it to the case colelctions.
    Bob Lin, MVP, MCSE & CNE Networking, Internet, Routing, VPN Troubleshooting on

    http://www.ChicagoTech.net

    How to Setup Windows, Network, VPN & Remote Access on

    http://www.howtonetworking.com

    Thursday, May 19, 2011 3:51 AM
  • If you cannot rdp using machine name, you can use ip address to connect it. Once you are able to connect to the remote machine, you can change the time zone or time to match your current time. Then you can connect back using machine name.

    I had same issue and i solved it this way.

     

    Thanks.

     


    Merin
    • Proposed as answer by BirukSolomon Friday, March 02, 2012 7:21 PM
    • Unproposed as answer by BirukSolomon Friday, March 02, 2012 7:21 PM
    • Proposed as answer by Paul D Thomas Monday, September 08, 2014 8:30 PM
    Monday, August 08, 2011 5:17 PM
  • Mine was DNS issue as well just replace with IP address.That will solve the issue

    Friday, March 02, 2012 7:22 PM
  • I had similar issue when trying to connect from 2008r2 to Win7 server. The Windows 7 PC had IPv6 enabled and 2008r2 did not. After disabling the IPv6 support from Windows 7, everything started to work just fine.

    Most propably some other network configuration change would had the same results, but I do not have need for IPv6, so this was the fastest trick to get it working :)


    Henkka

    Wednesday, October 30, 2013 7:33 AM
  • Thursday, January 02, 2014 6:15 PM
  • Thanks Merin,  It helped my case.   I have intentionally changed the system date of a remote machine  that contains our backend DB  in order to run some tests with future date. And after the system got locked I was unable to login because of datetime difference on my computer and the remote computer.

    Logging in using the IP address solved the problem.

    thanks Again

    Venkatesh.


    Wednesday, May 21, 2014 6:15 AM
  • I know this is an old thread but I found that if a DC server (which hosts the DNS server) has been changed in an environment, anything that is pointed to that old DNS server will cause this issue.

    We pointed our server to the correct one and we were good to go. 

    Tuesday, June 24, 2014 6:24 PM
  • Merin had the right idea.  This worked for me as well.  Whew!
    Monday, September 08, 2014 8:31 PM
  • Saw this in my environment recently and I traced it back to DNS.  The server that had this problem had multiple NICs (two different IP Addresses) and two A records in DNS.  This link explains why I was seeing the error; maybe this will help someone else https://support.microsoft.com/kb/168321?wa=wsignin1.0

    Tuesday, December 16, 2014 8:59 PM
  • Here's another one to add Bob.

    We had a load of servers throw up the error. Their time was correct but it turned out the DC was one hour ahead. It had been syncing from a switch that was replaced.

    Micmaher

    Wednesday, May 13, 2015 9:14 AM
  • We are seeing this almost every week now on several RDP servers.  Simply rebooting server with no changes to the network always fixes this, but starting to get real annoying.  So has anyone pinned down the culprit?  DNS not changed, Gateways not changed and logging in via IP works.  Clocks all right and rebooting server with no changes always resolves issue.

    Thanks Duane

    Monday, September 14, 2015 4:58 PM
  • We are also seeing this symptom occur in a brand-new Win 2012 R2 RemoteApp server farm.  Randomly, one or more of the Session Host servers will refuse to allow RDP access to the desktop.  Thankfully the farm is not yet in production, so it's not yet an emergency, however we still need to identify a cause and solution before that occurs.

    This issue may have an effect on the published RemoteApps, however I have not personally seen the message appear when executing a RemoteApp, I only see it when attempting to connect to the desktops session of one of the Session Host Servers.  The funny thing is that there are no indications of errors or failures prior to the symptoms occurring.
    I'm guessing that whatever the root issue is (when it occurs) is server specific and the farm may either recognize the issue and exclude the problematic Session Host server from connections, or if a connection attempt fails the farm simply handles it and tries another server.

    There are several symptoms to this issue as far as I've observed.
    -- The most immediately obvious is the refusal to accept Desktop RDP connections, citing time/date differences.  When we check the time/date on the server's console logon screen, the time/date is all correct, so I know that this message is misleading.
    -- The second symptom is that Group Policy updates are repeatedly failing which is indicated in the event log.  The event log entries are citing either lack of connectivity to a Domain controller or DNS issues, however I can safely say that we have triple redundancy for both of those services and they're all on the same subnet/switch fabric, so there is absolutely no way that this can actually be the root cause.  Besides, if there was a DNS or DC issue, we would have other symptoms occurring at other servers.
    -- The last symptom that I've noticed is kind-of tied to the first one.  The Session  Host server refuses to talk to the rest of the RemoteApp farm citing Kerberos failures and when logging into the console (the only login permitted during the problem occurrence) the server also displays a notice in the notification area about the Terminal Service licensing being not available and trial period will time-out.

    I know that the Kerberos authentication mechanism is utilized for all 3 of these functions, so I can only surmise that the root cause of this may very well be some kind of a bug in the Kerberos implementation in Win2012 r2.  As far as I can tell the server(s) are fully patched, we maintain our own internal WSUS infrastructure and I can see that 8 Microsoft Updates were successfully applied (as of this writing) 2 days ago. with a total of 196 updates installed on one of the problematic servers and I have no reason to suspect any of the others are out of sync with the updates.

    As far as correcting the issue - We can seemingly correct the issue without ever having to make any changes to the server configuration or reboot it.  It seems that simply logging into the Desktop using the Console Session and waiting a few minutes causes the issue to abate and life goes on as normal - Group policy updates begin to apply successfully and Desktop RDP access resumes.  When we check the event log for warnings or errors prior to any of the symptoms being displayed there is nothing out of the ordinary to speak of, so whatever is failing is either not failing badly enough to cause an event to be recorded or the failure is not occurring on the server that is exhibiting the symptoms.


    The solution is always the last thing you look at... -M

    Tuesday, November 24, 2015 6:44 PM
  • +1  add this happen in my environment a while back as well.  
    Monday, January 25, 2016 5:13 PM
  • In my environment, we have 2 2012 domain controllers, and 1 file server with 2008 r2. One we were adding the new domain controllers, someone forgot to change the primary dns server in the ip4 settings on the file server. We got the same error, "Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer."  Once we changed the primary DNS to the correct new domain controller, we simply flushed dns on the file server, and things started working again no problems. So if the date and time are fine, it could also be a DNS issue.




    • Proposed as answer by Broxin Thursday, February 04, 2016 2:06 PM
    • Edited by Broxin Thursday, February 04, 2016 2:06 PM
    Thursday, February 04, 2016 2:05 PM
  • I found that some idiot had put in two static ips into the advanced view of the lan connection, so it had an identity crisis, having 2 ips on the same range.
    Friday, July 22, 2016 2:24 PM