It will happen in the first week: a user reconnects, finds a clean desktop instead of their session, and is certain the server ate their work. This page is the calm playbook - verify, explain, recover what can be recovered, and tune what should be tuned.
A fresh desktop on reconnect means one thing: the old session ended, and a new one began. If your auto logoff policy fired, that was the design working - the session sat idle or disconnected past its limit and was logged off. But design working and a user standing in your doorway are two different problems, and both deserve a proper answer.
This page walks the incident in order: prove what happened, say it honestly, recover what the applications themselves can recover, and decide whether the policy or the user needs adjusting. Handled this way, the worst day of your rollout becomes the day the policy earned the office's respect.
Never guess and never argue from memory. Two sources tell the truth. On the server, query session and query user show the sessions that exist now and their idle times. For the past, open Event Viewer and look at the Remote Desktop Services logs under Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager - session logoff events are recorded there with the session ID and time.
Three outcomes are possible: the policy logged the session off at the limit (expected), an administrator ended it manually (possible, and recorded), or the session crashed with its applications (a different problem - go and fix that instead of blaming the policy). Your conversation with the user starts from whichever of these the logs support.
The honest sentence is short: 'Your session was left idle past the limit we announced, so the server logged it off - the same way it will for everyone. Anything that was saved is safe; anything open and unsaved was closed with the session.'
Do not say 'the server did it' as if the server has a mind. Do not apologise for the policy existing if it was announced and agreed - an apology that sounds like the rule was wrong teaches the office that complaining repeals rules. Be kind, be factual, and move immediately to the useful question: what of the work can be recovered?
A logoff closes applications, but good applications leave footprints. Work through them in this order:
Then write down, for this user, what was actually lost. Usually it is minutes of work, not the morning they feared - and seeing that in writing ends most incidents on the spot.
Every incident is data about one of two things. If the user's work pattern genuinely involves long untouched stretches - monitoring a dashboard, reading long documents, supervising a process - the limit may be wrong for their role, or they may belong in a gentler collection or on the reviewed exception list.
If the pattern is the old habit - session left open over lunch, over meetings, overnight - then the policy did its job and the habit is the thing to change. Say which of these you concluded, and why. Users respect a tuned system; they despise an arbitrary one.
Log the case in whatever your office uses for IT notes: date, user, what the logs showed, what was recovered, what was agreed (same limits, new limits, or an exception). Two minutes of writing prevents the same argument from restarting from zero next month, and a pattern of three similar entries is exactly the evidence you need if the limits genuinely need renegotiating.
The rollout that survives is the one where incidents make the system smarter in public - not the one where nothing is ever written down.
The video shows the complete auto logoff setup for idle RDP users, click by click. Watch it end to end before you change a production server.
▶️ Watch Full VideoCheck the evidence before anything else. query session and query user show current sessions and idle times, and the TerminalServices-LocalSessionManager log in Event Viewer records session logoffs with their session IDs and times. A policy logoff, a manual admin logoff and a crashed session each leave a different trail - work from the logs, not from memory.
Only the unsaved part. Everything saved to disk is untouched. Many applications also keep their own safety nets: Office suites keep AutoRecover copies, accounting applications write posted entries to their data files as you go, and browsers can restore tabs. Walk those recovery options with the user before concluding anything is gone for good.
Look at the pattern honestly. If their role truly involves long idle stretches - supervision screens, long reads, unattended jobs - their limits, collection or exception status should change. If it is the habit of leaving sessions open indefinitely, the policy is working and the conversation is about saving before stepping away. Let the logged incidents decide which it is.