Re: Login Script - Drive Mapping


"Hutch" <Hutch@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B94C3B91-1E0F-4975-909C-E2A0F43C6B61@xxxxxxxxxxxxxxxx
It is not a replication issue between domain controllers. I have looked
at
the login script in the NetLogon folder, and they are all the same.

I would not trust "looking" near as much as checking with tools to insure
both the files and the AD objects are fully replicated.

I have
also looked at the AD groupings, and they are all up to date.

What is an "AD Grouping"?

It is also not a PC authentication issue, as 99% of the login script
works.
We map 5 to 6 drives with this script. The only one that is affected is
the
T: drive.

What about permissions for the users on both SHARE point and on
the NTFS Files?

The reason I looked at user profiles, is when I was running my
troubleshooting tests, I noticed that if I had the user log into a machine
they had never been in before, the T: drive mapped fine.

This tends to imply my earlier suggestion that something (else) is already
mapped to T:.

So on their home machine, I deleted their profile, and had them
login....and
it worked.

The only other thing that immediately comes to mind is that something in
the NTUser.dat (main part of profile) is causing the problem but the main
thing that would do that would be a previous (persistent) mapping.

On another note, I have also verifed that if I remove the login script
from
their profile, that no drives map....so it is not a persistent issue.

I would still explicitly delete the T: map to make sure it is clear.

The only thing I can think of is that I "renamed" 4 or 5 Active Directory
groups....and these groups seem to be the ones impacted.

Groups cannot be renamed (through any tool I know) so HOW did you
do that?

Recreating a group to "rename" it would create a NEW SID so you would
also have to re-add that group to both any other groups or reset permissions
on any resources (NTFS, share, registry, etc.)

"Herb Martin" wrote:


"Hutch" <Hutch@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A6120BA1-115A-4D27-83B9-AF905930665B@xxxxxxxxxxxxxxxx
To set the stage, we are running Windows 2003 Active Directory, in
native
mode. Currently have 3 domain controllers, 2 in main site, one remote.
We
use Kixtart for our login script.

Everything has been working fine, until some changes were made to
permissions, and script this week. To begin with, the Login Script
runs
fine, except when it comes to the T: drive mapping.

We use the T: drive, to indicate what team membership an employee
belongs
to, and then map that drive based on group membership (like this -
CASE
Ingroup ("Domain Group") USE T: "\\servername\sharename".

Now for most staff, this is working fine. However, I recently renamed
existing groups in Active Directory, and changed their T: drive
mappings.
For some staff, their T: drive will not map at all (no errors..just
does
not
map). We have confirmed the following:

1) Not a domain controller issue...all three have the same login
script,
and
I have tested logging into all 3.

2) Not permissions. Even though the drive won't map, I can manually
map,
and the account has the correct permissions.

3) The problem appears to be PC specific. That same user account on
their
home PC that doesn't work, will work on another PC.

Then most likely is that some of the PCs aren't authenticating -- likely
due
to using the wrong DNS servers.

It also could be DC replication (DCDiag /C should be proven to be clean
of
FAIL and WARN messages on every DC.)

The final thing I tried (which worked) was to delete the users profile
on
their PC. When they signed in, and the profile was re-created, the T:
drive
mapped properly.

This tells me it is a client issue...However....what???? For our OS,
we
are running XP SP2 (it is also not a firewall issue).

I would like to find the exact issue, so I don't have to delete user
profiles and re-create. I am thinking it is a combination of the
renamed
Groups in Active Directory, and some sort of caching on the client
machine,
that is profile specific.

That just sounds flaky -- what even gave you the idea to do that?

Unless the reason is that T: is already persistenly mapped to something.
Do you always CLEAR (delete) the T: mapping before remapping it?
(You should).

net use T: /d

Also you if you must you can first copy that profile, and then re-copy it
over
the top once it is recreated.


--
Herb Martin, MCSE, MVP
http://www.LearnQuick.Com
(phone on web site)





.

Relevant Pages

  • MapNetworkDrive, can I map without a share?
    ... How do I map a network drive when there is no share name? ... I am now working on a unified login script for all ... office and will map drives to the current office. ... office's iShared \ a server in the remote office \ the desired path on ...
    (microsoft.public.scripting.wsh)
  • Re: Drive mapping problem
    ... The problem is not with the local profile. ... the login script, one of the map drive (wich is on a windows 2k3 standard ... edition SP1,(let's call him Server X =D)) refuse to connect. ...
    (microsoft.public.windows.server.general)
  • Re: Mapping to a DFS Root
    ... We just recently joined a laptop w/Vista Business to our domain. ... login script that runs, which maps 3 drives - F, S and T for all users. ... does not map. ...
    (microsoft.public.windows.vista.networking_sharing)
  • Re: Login Script - Drive Mapping
    ... Currently have 3 domain controllers, 2 in main site, one remote. ... To begin with, the Login Script runs ... drive will not map at all (no errors..just does ... When they signed in, and the profile was re-created, the T: ...
    (microsoft.public.windows.server.active_directory)
  • Re: Login Script question...
    ... > I was curious if there is a way that I can some how create a login script ... > be able to create a login script that will map out the drives that this ... > Is there a variable that we could use that would get the local server name ...
    (microsoft.public.win2000.group_policy)