Missing mapped drives in my computer / explorer

[kevmar]

I have a problem with users missing mapped drives in my computer /
explorer when they first login to a new computer (and build a profile).
NET USE will list them, command line can see them, applications can
file open and see them, and killing and starting explorer will show
them. But looking at my computer will not show them.

I see other people post that they have the problem, but I have not seen
any solutions.

Here are some more details.
If the drive gets mapped after the desktop loads, it is not a problem.
Once the user relogs, they will have most (if not all) the drives.
All machines are XP sp2 and are mapping several different 2003 servers
in the same domain. All are workstations.


To map the drives I normaly use a vb script using WScript.Network, but
the net use command has the same problem.
The script can either be in the policy or in the users logon script and
it will have the same problem.
Setting the drives to persist in the profile fixed the fallow up logon
attempts, but the initial logon where the profile is built is giving us
the problems.
I tried toggling the setting to have explorer process to run in there
own threads with no luck.
Our most restriced users and domain admins (my self included) all
suffer from the problem.

We have a large group of users (300) that use any number of machines
(150) that get ghosted nightly. Every login they do is a new profile
building login on that machine.

My current workarounds include adding a 35 sec delay on each mapping
(but thats forever on users that log in quickly). I am also
considering fliping the policy that make script run in synchronous mode
on. but that has other problems that will cause me to rework lots of
other scripts (that were desigend to run forever in the background or
require user interaction to close). Those other scripts currently
prevent the user from loggin on in that mode.

Anyone have any ideas of things to try? or having the same problem?

 

[Guest]

Might be worth trying MyLogon as your authentication mechanism, as that
would allow you to have the entire computer complete with fixed profile
ghosted.

MyLogon does still connect the mappings before the desktop loads, though it
happens slightly later, after all other winlogon process have finished. Not
sure if this will make any difference, but easy enough to give it a try
anyway.

http://mylogon.net

 

[kevmar]

I only took a quick look at the alternate authentication tool, but it
does not look like it will work in our environment.

The bigest detail is the screensaver password or locking the
workstation is the local machine password and not the domain password.
This is a medical environment and that would not meet our security
requirements. That was one item that was listed in the FAQ.


At face value, this would get us past this problem. I would need to do
lots of testing with our domain policies. there are some minor details
that make me uneasy with it in our environment.

I think this is more a bug in explorer, but cant find any supporting
information.

 

[kevmar]

can anyone direct me to a good place to find the solution to my
problems.

 

[Guest]

I am having the exact same issue. Can't find a resolution. Several other
posts with this issue but nobody has a fix

 

[kevmar]

I have been fighting this issue for a long time. I have used several
fixes that partialy solve the problem.

Having the mappings persist in the profile will help once a profile has
been created. In most environments, this is all thats needed. When a
user gets his new machine, just make him log in twice.

Vic, what I have done to get past this problem is to make the scripts
run synchronously via policy.
Computer configuration -> Administrativ Templates -> System/Scripts ->
Policy -> run logon scripts synchronously = Enabled

Take caution when setting this. If you have any long running scripts,
they have to finish before the user will see a desktop. If a script
never ends, they never get in.

I had to make large adjustments to our existing scripts. I had a few
background processes run while the user was on his machine that would
never end.

I have deployed this change to a limited number of machines already and
the mappings are showing up for first time users.

 

[Guest]

Thanks KevMar,

I will give this a try and let you know how it goes.

 

[Guest]

Seeting the login scripts to run synchronously did not fix the issue. We have
also just moved to a new building with a whole new network and switching
gear, so I think I can rule out comms issues.

One thing I have noticed is that although the drive does not appear in
Windows Explorer, if I go to the DOS prompt and change to that drive, it is
there.
Also if I select "disconnect network drive" the drives appear in the list of
mapped drives.

 

[Guest]

Does the same symptom occur when mapping Network Places?

 

[rvalstar]

So the issue is the user profile needs to be created on these machines?
Once a user has gotten in, if they reboot the machine and wait a
minute after the Ctrl-Alt-Del prompt before logging on, is there an
issue?

I believe you HAVE to run logon scripts synchronously for reliability.
It's the only thing that has worked for me over the many years I've
been doing this. If you have a long running one, shell / run it from
the quick sync script and don't wait on it to finish.

Also, I always set

\\Local Computer Policy\Computer Configuration\Administrative
Templates\System\Logon\Always wait for the network at computer startup
and logon = Enabled

This was an attempt to make sure the network and NET WORKSTATION, were
started for impatient users. Found WiFi added extra delays so I have
included looping to test as follows:

echo Verifying Network
echo.

for /L %%I in (1,1,10) do (
ping %COMPUTERNAME% -n 1 | find "Reply from 127.0.0.1" > nul

if not errorlevel 1 (
rem Wait till a non-loopback IP occurs
) else (
ping %COMPUTERNAME% -n 1 | find "Reply from "

if not errorlevel 1 (
net view \\%COMPUTERNAME% > nul 2> nul

if not errorlevel 1 goto server_test

echo NET VIEW failed. Probably waiting on WORKSTATION service to
start
)
)

sleep 3

echo Tried %%I time

set logon_too_early=Yes
)

:server_test

Yes, I'm old school. Even though I'm quite the VB hack, I started
these scripts before WSH and haven't been motivated to switch.

If the script sets "logon_too_early", I do a "sleep 6" at the end to
allow time for the system tray to setup else I found these machines
would miss an icon or too.

Once again, my problem was with WiFi users (yes, I did promote their
WiFi NIC ahead of their wired NIC in Network Connections' Advance
settings).

Don't know if this will help but sometimes it's just nice to get a
different point of view to activate a different part of the brain ;-)

Ciao,

Rick Valstar
Star Consulting
r + last name + at + gmail + dot _ com