We have the following domain setup:

  • Domain Function level: Server 2008
  • 5 Server 2003 terminal servers
  • 5 Server 2008 R1 terminal servers
  • 150 staff who use mandatory profiles on their PCs
  • Those staff do not have a terminal server profile path in AD as we found it meant for quicker logons.

Our issue is that when the staff log onto the Server 2008 terminal servers they are automatically logged off after just over 5 minutes.

In the security log of the terminal server is this event:

    User initiated logoff:

    Security ID:        contoso\bloggsjoe
    Account Name:       bloggsjoe
    Account Domain:     contoso
    Logon ID:       0x1c66ba

This event is generated when a logoff is initiated but the token reference count is not zero and the logon session cannot be destroyed.  No further user-initiated activity can occur.  This event can be interpreted as a logoff event.

and then 10 seconds later is this:

An account was logged off.

    Security ID:        contoso\bloggsjoe
    Account Name:       bloggsjoe
    Account Domain:     contoso
    Logon ID:       0x1c66ba

Logon Type:         10

This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

The end user gets a message that they will be logged off in 2 minutes. There is no event recorded on the client machine (all Windows XP)

I've looked through the Terminal Services Configuration but the disconnection time is set to 2 hours and the Active Session Limit is set to "Never"

We have used terminal server mandatory profiles but that made no difference. The problem does not happen for administrators.

I wonder if any of you can help?

UPDATE1: For people asking about CALs, the DC is the terminal server licensing server and always works well. At the moment on the 2008 TS it shows as 426 CALS available for clients. They are licensed in per device" mode.

UPDATE2: There is something odd about the timings in the Terminal Services Manager. Many dates show up as the time that all computer times are worked from - 01/01/1601. Here is a screenshot as the problem user is logging on:

logging on year is 1600 Larger image

When the username is resolved the time is corrected also - does that make it look like the user have been loggged on for over 400 years though?

Once the user is logged on the times is correct Larger image

Have any of you seen this kind of thing before and would you know how to resolve it? I've checked with another site and the 1601 year is not the same there.

UPDATE3: Forgot to say that the logoff does not happen because of 5 minutes of inactivity - it happens no matter what the user is doing.

UPDATE4: Licensing issues. It looks like there is some kind of terminal server licensing issue - though none of the servers are giving licensing errors. The licensing server is a DC which showed plenty of valid licenses available (all Per Device) it showed a lot of temporary device CALs issued however and those could not be revoked. I completely removed the licensing role and set it up again. This left me with 500 Server 2003 and 500 Server 2008 Per Device CALs free, but only a few machines are being allocated a CAL, some are being issued temporary CALs, but most seem to be not showing up at all. There are some devices being listed as "unknown" as the machine name, so I'm sure this must be at the heart of the licensing problem - though I have no idea if this is in any way connected to my logon problems. BTW, when I click on the Terminal Server Configuration page on any terminal server they report that there are no licensing issues detected.

  • 2
    Run a Group policy results against one of the users. It sure sounds like somehow you have gotten a session limit applied against your users.
    – Zoredache
    Feb 2, 2012 at 22:15
  • Thanks for the suggestion. Yep ran rsop against one of the users on the machine and no timeouts or anything else odd that I can see. Feb 3, 2012 at 8:10
  • Just out of curiosity, what version of the RDP client is installed on the XP machines?
    – JohnThePro
    Feb 8, 2012 at 18:31
  • Hi John, the clients are XP and fully updated, so the version of mstsc.exe that I've just checked is 6.0.6001.18589. Thanks. Feb 8, 2012 at 23:24

6 Answers 6


I've seen this happen when I've left the default trial licenses installed in terminal services licensing manager. What happens is that the TS License server hands them out before the bought ones for some reason - i never dug into this too deeply just deleted the demo licenses.

  • Zypher, this is interesting. Everything is set to "Device CALs" and for 2003 & 2008 there are a few hundred still available. There are 14 TS 2003 temporary device CALS issued, and 30 TS 2008 temporary device CALs issued. There is no way to delete them :(. When I right-click any of the issues temporary CALs then "Revoke TS CAL" is greyed out. Any idea? Feb 12, 2012 at 0:34
  • IIRC you need to revoke the CALs that have been issued first, then you can get rid of the temporary CALs. You might have to restart the licensing service as well. Sorry I can't be more specific it's been a while since i've had to deal with this particular issue.
    – Zypher
    Feb 12, 2012 at 21:42
  • Thanks - was unable to revoke the CALs at all. I'll update the main post with some other licensing information. Feb 12, 2012 at 22:03
  • Temporary ones are a feature. Real licenses aren't issued on first connect, but on second. technet.microsoft.com/en-us/library/cc738962(v=ws.10).aspx Feb 14, 2012 at 0:40

Check the settings on the RDP listener.

  • 1
    Hi, I've not come across that before - do you mean HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp ? If so, there are things like KeepAliveTimeout, MaxConnectionTime, MaxDisconnectionTime, MaxIdleTime which sounds like those could be an issue, but they are all set to 0. Feb 3, 2012 at 8:14
  • 1
    Yes, that is what I mean. It can be configured from the Remote Desktop Session Host Configuration tool. Feb 3, 2012 at 13:10
  • Thanks - It's there in Terminal Services Configuration all right - no restrictions there I'm afraid :( Feb 3, 2012 at 14:23

Check your domain timing. Also check the sessions tab of the user in Computers and Users.

  • The actual server time is correct though. Feb 3, 2012 at 11:18
  • What about the sessions settings?
    – Jonathan
    Feb 3, 2012 at 12:06
  • Good point - hadn't thought to look in the individual properties of users in AD. Unfortunately all looks good there - All set to "Never" I'm afraid. Thanks for the idea though. Feb 3, 2012 at 12:11

We had similar connectivity problem when time at server and client wasn't synchronized. Time synchronization helps.

  • Thanks - all the times are synced to a single DC time server and all looks right I'm afraid :( Feb 9, 2012 at 14:43
  • @kieran Last resort: viruses?
    – Putnik
    Feb 10, 2012 at 16:06
  • The problem happens on multiple 2008 servers, but not the 2003 servers though, so that "seems" unlikely to me, but you'd never know. We also have Symantec Endpoint protection 2011 installed on all servers and it appears to be working properly. Thanks. Feb 12, 2012 at 0:29

Sounds like we've hit all the normal config places...

  • Terminal Server Configuration: RDP-Tcp Properties > Sessions
  • ADUnC > User Properties > Sessions
  • GPO RSOP i.e. > Computer > Admin Templates > Windows Components (look for Session Time Limits)
  • No warnings/errors on TS CAL licensing

So to help troubleshoot I would temporarily set the server TS Configuration Properties > Sessions "Active session limit" to Never (force it by overriding user settings) and see if that fixes it.

Terminal Server Config

  • Hi Bret, thanks for your suggestion. In the last few days I had set it to that already - especially because of the 1601 issue. Strange one, eh? :-) Feb 12, 2012 at 0:28

I see your time is setup correctly on your machine. Did you setup the timeserver for the machine in your network? Did you check at least one of the machines other than yours? Check the time on them?

  • Yep, times on all machines are correct - one of the DCs acts as the domain time server. Feb 12, 2012 at 0:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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