Windows RDS (Terminal Server) - Stuck Applying group policy

Had a lovely time yesterday when the terminal server (2008 R2 running RDS) that our users use to access programs/files from off site decided to tank. Luckily we have a backup server... except that one was tanking as well.

The short version is that, at some point over the weekend, the server began taking inordinate amounts of time applying group policy settings, making user log on take upwards of 5 minutes and killing server performance. Some of the error available in event viewer included

• warning|grouppolicy|eventid:1090|"Windows failed to record Resultant Set of Policy (RSoP) information, which describes the scope of Group Policy objects applied to the computer or user. This could be caused by Windows Management Instrumentation (WMI) service being disabled, stopped, or other WMI errors. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately."
• warning|winlogon|eventid:6005|"The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (CreateSession)."
• warning|winlogon|eventid:6006|"The winlogon notification subscriber <GPClient> took xxx second(s) to handle the notification event (Logon)."

On the user side you would see "Applying user Policy..." for 5+ minutes while trying to login. When I tried to reboot one of the servers it took (quite literally) several hours to get past the "Applying computer settings" screen. On reboot, in task manager you'd see an svchost process using 2+GB of ram and 100% cpu (limited to one core, so it was ~13% in my case). Killing this process would cause all sorts of interesting errors to occur - best I can tell this was the GPclient service. 

After a few hours of trying different things - notably de-joining  from the domain, which didn't work and took forever - I finally figured out it had something to do with the WMI repository. From command line I tried:

winmgmt /verifyrepository

winmgmt /salvagerepository

Neither of these ever returned anything (let them both run, separately, for 30 minutes).  While either was running there would be a winmgmt.exe process in task manager using 100%/13% CPU and progressively more RAM. So, since neither of those worked I tried:

winmgmt /resetrepository

Boom! Everything was back to normal. It was almost disconcerting how quickly everything started working again. Rebooted the server and it shutdown and restarted in its normal couple of minutes. I have yet to discover exactly what caused the wmi repository to corrupt but at least for the time being users are able to get to their stuff.