A network packet capture at the client would probably help here. It would show you the total amount of data transferred during logon, and for sysvol/gpo operations, you could determine if the client is spending an unusual amount of time on a specific gpo(s).
After installing Microsoft Network Monitor 3.4, save the following to a cmd file, and run it as a scheduled task at system startup. That will create a capture file that you can analyze after the logon has completed.
cd /d "C:\Program Files\Microsoft Network Monitor 3"
nmcap.exe /network * /capture /DisableConversations /file c:\temp\test.cap:100M
Here are some registry settings that you can test on the client workstation to determine if they help:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"BufferPolicyReads"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoRemoteRecursiveEvents"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoRemoteChangeNotify"=dword:00000001
More information:
319440 - Logon delays occur over a slow connection if opportunistic locking is not granted for the policy file in Windows
http://support.microsoft.com/kb/319440
http://blogs.technet.com/b/mrsnrub/archive/2009/09/03/windows-server-2003-x86-tuning-for-performance-based-on-role.aspx
Microsoft Network Monitor 3.4 Open Source Windows Parsers 3.4.2654
http://nmparsers.codeplex.com/
After downloading and installing the Windows Parsers, in Network Monitor, under Tools > Options > Parser Profiles, select Windows, and click Set As Active.
When viewing the capture, in the Frame Summary window, the SMB/SMB2 protocol packets will display the UNC path to the location where the Group Policies are being read. You can further refine the display by applying a filter such as SMB2 && tcp.DstPort == 445
(or SMB if SMB2 is not being used). This should provide a fairly concise display of the GPO processing.
The "Right" Way:
There is, yes (sort of), but before I tell you the way I know to do this, let me advise that the safer approach to this issue is to use group policy to force a default domain on the users - so by default, they log into the domain you dictate, and don't have to worry about the domain drop down list.
The "Disable the Domain List" way:
Anyhow, to remove the drop down list, which will force users to use the full UPN (user principal name):
- Navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
- Create a new
DWORD
of NoDomainUI
- Set the value of this
DWORD
to 1
- Reboot the machine.
The logon screen will no longer show a drop-down list of domains when the machine boots up, and users will need to enter the full UPN to log on.
Obviously, as this is just a registry change, you can push it out by GPO or GPP to all your machines instead of doing it manually.
Using a Documented Bug to Hide All Domains but One:
EDIT: In response to @Massimo's comment with more explicit requirements, I found this Technet thread, which suggests the bug in this KB as a workaround.
Basically, as a result of the Netlogon.ftl
file not having the proper permissions to be opened by the winlogon
process, the list of trusted domains cannot be displayed, resulting in only the domain the machine/user belongs to being displayed.
Based on a quick test, this seems to work, in a 2003 FL forest, on an XP client (all virtualized in the lab environment on my laptop). I can't do more extensive testing at the moment, but would be really curious if someone else can and report whether it works for newer OSes or in different environments.
Using a bug like this has to be the hackiest thing I've ever done, and am morbidly curious to hear about how this fares in other environments.
Best Answer
You can't filter it, you can only hide it. It's built and automatically populated from the list of domains that are trusted by the domain your machine is a member of.