Annoying Logon Problems

[SpuffMonkey]

We're having some problems at logon time - any thoughts would be appreciated.

Sometimes on some PCs, at logon, the PCs are not picking up the GPOs and are using old local settings, which leads to Folder Redirection failing (amongst other things). A full reboot often sorts this out (but not always).

I have ticked the boxes to disable "Slow Network Connection" stuff in the GPO and for the PC to wait until it gets a GPO (I think) - but this hasn't helped. I've also started running delprof on a weekly basis.

Any other ideas - coz I'm starting to get that nasty slouchy feeling inside now when the phone rings about it.

[Gatt]

I get this problem too - but i reckon its our NIC card - sis900's - which im trying to resolve by rolling the NIC back to a 2001 Microsoft Version

it only seems tohappen in PC's with this card -

Whilst the above fixes it - the same thing soon happens again so i'm wondering if XP is switching the driver back to the newer version periodically

May need to replace the NIC's to be sure.

[Ric_]

Have you checked the event logs and GPMC for error messages?

[SpuffMonkey]

OK - checked the event log - on the local PC - it gives a Redirected Folder error - as its trying to apply redirection to a location that no longer exists - (I moved user's folder to a new location some months ago) - so I assume its falling back to locally cached profiles.

Looking in the Event Logs on the servers (tricky as we have 9 DCs (don't ask!)) - there are no apparent errors.

Any ideas on what to look at next?

[ajbritton]

Use Policy Reporter (see the WiKi) to enable full UserEnv debug logging and analyse the UserEnv log. This can help if it's a client issue.

[inkyscribe]

We have this problem too and I have a workaround and also managed to reduce occurrences, but no fix as yet - I have a call logged with MS about it.

Workaround: Batch file on the shared drive which runs gpupdate /force and reboots machine automatically. Not good if the student wants to save a file and can't though - the GP problem usually coincides with a read only error on their home drive.

Reduce occurrences: upgraded NIC drivers, and changed registry keys on all workstations:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Win dows\System
and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

With these two keys you can increase the timeout value that the workstation will wait for the network before processing the GPO.

I have also tried to change registry key which disables DHCPMediaSense but although similar in principle to the keys above, it had less effect.

HTH

Marcus

[Frazer]

We are having a similar problem here.
I rolled out a new version of our registration system (PARSql to Pars.net) using Group Policy->Computer Configuration->Software Settings->Software installation.
After I did this I added a new line to the staff logon script to check that they were all getting the software installed.

if exist "c:\program files\pars\bootstrap.exe" echo %DATE%,%TIME%,%USERNAME%,%COMPUTERNAME%,Yes >> \\hhapps\vars$\pars.txt
if not exist "c:\program files\pars\bootstrap.exe" echo %DATE%,%TIME%,%USERNAME%,%COMPUTERNAME%,No >> \\hhapps\vars$\pars.txt

What I found was that some staff laptops werent even processing this new part of logon script to output to my text file and others werent even getting pars installed.
Its was a mixture of dell(d505) and toshiba(1400/2100) with the same image across the board for each (so network drivers etc are the same).
To me this says that the group policy wasnt being updated properly (even over a period of one week) or that the network interface wasnt getting a connection quickly enough - this is still ongoing. We used to be able to login to the domain as soon as the login box appeared, now you have to try 2 or 3 times before the domain becomes available - This started around January.
Another problem is that some network points cant get a connection at all one day then its perfectly fine the next - tried patching into a different port and even a different switch - still the same. One thing I have found is when one particular room works, another does not, then they swap round.
Its proving very hard to track because people arent reporting it often enough and wont log it themselves.
HELP (perhaps I should have started my own thread, but its semi-related )

[inkyscribe]

Semi relevant to all these problems.

I had consistently not been able to apply GP to my own PC. I found that DFS was not enabled in the registry but enabling it did not fix it. Enabling TCP/IP Netbios Helper service then did fix the problem.

However, this service was already enabled on the student PCs where I get the intermittent problems!

(sigh)

Hope this might help someone anyway!

[inkyscribe]

I have fixed this problem on our network now - I think! It is intermittent and random so it is difficult to know if it is really fixed or not.

I disabled Fast (cached) logon. This is in the Default Domain Policy and in the Local Machine Policy too. (But not in a custom OU level policy.)

Computer Config / Admin templates / system / logon / wait for network. Made this Enabled.

In WinXP this is "not configured" (in practice "disabled") by default. This means that group policy processing doesn't wait for the network connection. It just logs the user on with cached credentials and settings. Setting to Enabled forces GP to wait for the network and then apply each policy synchronously, ie one at a time.

Of course, because by definition some of my workstations were having trouble applying Group Policy, I had to enable this setting on the workstations' local policy too.

HTH

Marcus