During a loginVSI load testing scenario on physical servers, I’ve encountered a specific problem: around 170 to 180 users (with a 15 second logon rate), the XenApp server stops opening new session because of a CPU outage. After a couple of dozens of minutes, the server was returning to a more expected value (about 60% of CPU usage). After this pause, the server is re-performing well and new sessions could connect without any problem.
During this CPU peak period, the most consuming process is “wmiprvse.exe” (around 40%). A Microsoft support case have been opened and we found that there is a lot of process enumeration through the win32_processes WMI class. By viewing the WMI query with a Microsoft internal tool, we found out that this was caused by a WMI filtered GPO (with a select * from win32_OperatingSystem).
The “funny” part is:
- This GPO is a computer GPO with user settings disabled
- Each time a select * from win32_operatingsystem a process enumeration is performed
In fact, GPO WMI filters are applied before verifying if there is a user setting in the GPO. The workaround is to deny the involved GPO to the domain users group.
Once done, the WMI query was no longer performed during user login and the load testing test could continue.