Monday, 5 December 2011

Windows 7 "Please Wait" or Welcome Screen hang


Just thought I'd share a hotfix that resolved an issue that has been plaguing our Windows 7 desktop PCs for the past few weeks. Hopefully it will save someone all of the investigating we had to do!

Symptoms
Windows 7 (SP1) hangs for up to 60 minutes either at:

the"Please Wait" screen before logon screen
the "Welcome" screen after logon (Somebody coined this the "Welcome Screen of Death")
or occasionally at log off

You may see events in the Application Log under ID 6006:
The winlogon notification subscriber took xxxx second(s) to handle the notification event (CreateSession) - "Please Wait" hang
The winlogon notification subscriber took xxxx second(s) to handle the notification event (Logon) - "Welcome" screen hang
The winlogon notification subscriber took xxxx second(s) to handle the notification event (Logoff) - log off hang

This event clearly suggests a problem with the GPClient (Group Policy Client)  so we started  moving the PC to an OU with limited GPOs which reduced the problem. However, the problem is apparent when there is a large number of user profiles on the system (we had ranges of 50 to 250) and deleting profiles can appear to alleviate the problem. The more profiles, the longer the delay.

We only spotted the root cause of the issue by removing and re-applying group policies whilst logged onto a problem PC and noticing that RSOP was hanging. Using Process Explorer we spotted that one of the svchost processes was using an entire CPU core. Since this instance of svchost runs both the Winmgmt (WMI) service and the gpsvc (GPClient) service (amongst other key Windows services) so it appears that the GPClient has to wait for WMI to finish, causing the long delay.


Resolution
Install hotfix kb2617858

"This issue occurs because the Windows Management Instrumentation (WMI) component unnecessarily performs a full validation of the WMI repository"

Since each user profile adds to the WMI repository, the more profiles, the longer the delay (although their seems to be a limit of 60 minutes).

See also kb2505348 which references kb2617858

Tuesday, 8 March 2011

Emails from "Microsoft Exchange" classed as "Outside the organization" in Transport Rules

It appears that emails from the built in "Microsoft Exchange" sender in Exchange 2007 are classed as "Outside the organization" in Exchange Transport Rules. Here's how I discovered the issue and was able to work around it:


It’s quite common at the moment for phishers to send “Your mailbox is almost full” type messages, requesting users to click on a link, ultimately compromising their email accounts. One of the methods our organization uses to block such messages is to have an Exchange Transport Rule to block emails with such subject lines and redirect the emails to a monitored mailbox, but for external senders only.


I don’t normally look after this system but I checked the monitored mailbox this morning and found it was full of genuine “Your mailbox is almost full” messages from the “Microsoft Exchange” sender. Numerous users won't have received this message and will potentially hit their quota, and not be able to send emails in the next few days.


My first port of call was the check the Transport Rule was set to only apply to external senders, or as Microsoft put it "from users Outside the organization", which it was. I assumed, therefore that the "Microsoft Exchange" sender is classed as being external as it has no real mailbox.


Comparing the message headers from a genuine "Microsoft Exchange" email and a phish email, I noticed the genuine email is automatically stamped by Exchange with an SCL of -1


X-MS-Exchange-Organization-SCL: -1


I added this as an exception to the Transport Rule using "except when the text specific words appears in a message header" using X-MS-Exchange-Organization-SCL as the message header and -1 as the value.




Messages that match the subject line but come from "Microsoft Exchange" now reach their intended recipient.