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.
Best Answer
Take a look at your logon scripts. Are they trying to access a network resource which isn't available when the machine in not connected to the domain network?
I've seen a similar problem during boot, which turned out to be a computer start up script trying to access a network resource that wasn't available offline.
Another option is to enable userenv logging to determine exactly what causes the delay.