Event ID 20499: RDS logons hang for minutes loading the user configuration

Fix it now

Remote Desktop Services is waiting on the chain of directory, profile and policy lookups it has to finish before it can hand over a desktop. The host is almost never the slow part. Find which step is taking the time before you change anything, because every fix below makes something worse if aimed at the wrong step.

gpresult /h C:\temp\gp.html /f
nltest /dsgetdc:contoso.local
nltest /dsgetsite

1. Open Event Viewer at Applications and Services Logs, Microsoft, Windows, GroupPolicy, Operational. Each client-side extension records its own start and finish, so the slow one is visible by reading the timestamps rather than by guessing.
2. Measure the profile. A roaming profile is copied across the network before the desktop appears, so its size is added directly to every logon.
3. Time each path used at logon from the host itself: the profile share, the home directory, script locations and every mapped drive. Measure-Command { Get-ChildItem \\server\share } gives you a number instead of an impression.
4. Read the report the first command wrote and count the policy objects applying to the user. Remove the ones that no longer do anything.
5. Confirm the host is authenticating locally. nltest /dsgetdc:contoso.local queries DNS for domain controllers and contacts each to check connectivity, and nltest /dsgetsite returns the site name in use. A controller in another location is your delay.

Set your own baseline before you tune anything. Time a logon on a healthy host with a small profile, then compare. Chasing a published number tells you nothing about your estate.

If one step in the policy log accounts for the delay, fix that and stop. If the time is spread across everything, the next section explains what the host is waiting for and in what order.

Why it happens

Before a desktop is drawn, Remote Desktop Services has to assemble the user’s configuration. It reads the account’s Remote Desktop settings, profile path and home directory from the directory. It processes Group Policy for the user. It loads or copies the profile. It maps drives, deploys printers and runs whatever scripts are attached. Most of that happens in sequence, and each step is at least one round trip to a server. The host itself is idle for nearly all of it.

That sequencing is why a single slow component ruins the whole logon. A home directory on a server that is answering slowly, a mapping to a share that was decommissioned last year, a policy that queries WMI on every logon, a profile that has grown to include a mail cache: any one of them stalls the chain while everything behind it waits. Adding processors to the Session Host does nothing, because the host is not computing.

The Group Policy operational log is the fastest way to find the culprit, because it timestamps each client-side extension separately. Sort a slow logon by elapsed time and the answer is usually the first line. Do that before you change anything: most of the fixes below are trade-offs, and applying the wrong one leaves you with the same slow logon and a new problem.

Microsoft does not publish meanings for the Remote Desktop and profile event numbers people quote for slow logons, this article’s headline number included. Read the text of each entry and the timings in the policy log; those are real measurements. The numbers themselves are not a diagnosis.

Full reference

Where the time usually goes

Turning impressions into numbers

Measure-Command { Get-ChildItem \\fileserver\profiles }
Measure-Command { Get-ChildItem \\fileserver\home }
gpresult /h C:\temp\gp.html /f
nltest /dsgetdc:contoso.local

Run these from the host, not from your desk. A path that answers instantly from your machine can be slow from a Session Host in another site, and that difference is often the entire problem. gpresult /h writes an HTML report of what actually applied; /f overwrites the previous one so you can run it repeatedly without renaming files.

Folder redirection and roaming profiles together

This pairing is worth getting right because it is the single largest lever and it is routinely misunderstood. When you deploy folder redirection alongside roaming user profiles, the redirected data is not part of the roaming profile: Windows synchronises it in the background with Offline Files after the user has logged on, rather than copying it at logon and logoff. The user does not wait for it. That is the whole benefit, and it arrives without any matching exclusion setting.

The Exclude directories in roaming profile policy is for the things you cannot redirect, which in practice means caches under AppData: browser profiles, mail caches, and application working directories that regrow on their own. Excluding a folder you have already redirected achieves nothing. Excluding something an application needs across sessions produces a support ticket a fortnight later, so keep the list short and write down why each entry is on it.

What not to do

• Do not disable client printer redirection on a production host during working hours as a diagnostic. It is a computer policy, it applies to everyone connecting to that host, and it lands on all new sessions.
• Do not raise timeouts to make a dead mapping stop hurting. You have made the logon slower on purpose and hidden the fault.
• Do not add CPU or memory before reading the policy log. An idle host with a slow logon is telling you something specific and hardware is not it.
• Do not pin a Session Host to a named domain controller. It works until that controller is rebuilt, and then it fails in a way nobody remembers configuring.

Measuring the improvement honestly

Test with a user who has a large profile and a long history, not just a fresh account. A new account is fast on a broken host, so a test with one proves nothing. Compare elapsed times in the Group Policy operational log for the same user before and after, and repeat the test at the same time of day: a host that is fine at eleven in the morning and slow at nine has a contention problem rather than a configuration one.

Every code this article covers

Confirm the fix worked

1. Elapsed times in the Group Policy operational log are lower for the same user, for the same extension you targeted.
2. A timed logon for an affected user is close to your healthy baseline.
3. Every path used at logon answers quickly when timed from the host itself.
4. nltest /dsgetdc: returns a domain controller in the site nltest /dsgetsite reports.
5. A user with a large profile improves, not only a freshly created test account.

Questions people ask about this