2

I've changed the logon.bat file (on the DC shared NETLOGON folder) The changes are basically altering the location of a mapped drive.

When users log off, and log back on, they are still being mapped to the old location - is there anything I've missed?

alex
  • 1,720
  • 15
  • 43
  • 63
  • Grrr... There are no "PDC" computers in Active Directory. All domain controllers host equal copies of the Active Directory database. There is a "role" held by a single domain controller, "PDC Emulator", but that role only slightly changes the behavior of Active Directory. It's not like NT 4.0 where there is only a single writeable copy of the database. – Evan Anderson Nov 10 '09 at 13:36
  • thanks for correcting me. how about a useful comment? perhaps even an answer? I can edit the question if it really helps.... – alex Nov 10 '09 at 13:38
  • 1
    I'm with Evan....there is no PDC... Have you looked at the Group Policy where the Logon/logoff script is defined? You probably have to update the script in the policy folder which is located in the "sysvol" folder on one of your domain controllers. – mrTomahawk Nov 10 '09 at 13:39
  • What's a PDC? i don't see that in my question...? lol – alex Nov 10 '09 at 13:42
  • The logon script is defined in the profile tab on the user accounts - i realise this is a bad way of doing it, however it was set up by a previous employee - im not a systems admin, i'm a developer... but unfortunately theres no one else to sort this out! – alex Nov 10 '09 at 13:43

4 Answers4

2

It sounds like you don't know if the users are executing the new version of the script or the old version. (I'm guessing that you have a single domain controller and that this isn't a file replication issue between the DCs. Theoretically, it could be, but we'll go there only if you indicate that you're seeing replication problems with the NETLOGON share between your DCs.)

My gut says that you're doing something like a "NET USE ..." and the users have persistent "drive mappings" enabled. As such, when the "NET USE ..." attempts to "map" the "drive" letter the command is failing because the "drive" is already "mapped".

I'd add a "NET USE x: /D" on the line before the drive letter in question, like:

@echo off
NET USE Q: /D
NET USE Q: \\server\sharename

This deletes the existing "mapping" for "drive" Q: before creating one.

By default, these "legacy logon scripts" run visible during logon. As such, you can add debugging line "echo on" and/or a "pause" at the end of the script, then logon as a user and see what's actually executing. This is your best bet if you can't get it to work-- see what's actually executing and debug it.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
2

Sounds like a cahced credentials/cached profile problem. Try picking on one user (preferably someone this won't impact too much on), deleting their local profile on their PC, and getting them to log on again.

If that works then you may need to either instruct users to do a gpupdate /force or to log off and back on up to 3 times before it will kick in.

If that doesn't work you may have an issue where users are being authenticated against a different DC to the one you made the change on, and your sysvol replication is broken. Let's hope it's not that...

Maximus Minimus
  • 8,987
  • 2
  • 23
  • 36
  • 2
    I agree, cached credentials can cause the problem, but no need to delete whole profile, delete only mapping under the key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 – alexm Nov 10 '09 at 15:56
0
  • Force Group Policies update
  • Check that users see domain and are able to synchronize
  • Check that old mappings were deleted, sometimes they are screwed and can be deleted only manually by deleting MountPoints2 entries from registry
alexm
  • 458
  • 3
  • 11
0

We have had a similar issue, where new drive mappings did not occur because the old drive mappings were not removed.

You can test if this is the problem by

  1. mapping to a new (unused) drive letter - and if that works
  2. set it back to the original, and then manually unmap the drive prior to running the script.

If that works, then your script is not unmapping the drive properly.

Hope that helps!

Brent
  • 22,857
  • 19
  • 70
  • 102