Missing mapped drives in my computer / explorer

microsoft.public.windowsxp.network_web

6 Sep 2006 11:16 PM

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?

7 Sep 2006 2:24 PM

Ian

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

8 Sep 2006 3:13 PM

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.

13 Sep 2006 8:12 PM

kevmar

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

kev***@gmail.com wrote:
Show quoteHide quote

> 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?

15 Sep 2006 6:46 AM

Vic

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

Show quoteHide quote

"kev***@gmail.com" wrote:

> 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?
>
>

19 Sep 2006 6:05 PM

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.

Vic wrote:
Show quoteHide quote

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

21 Sep 2006 1:52 AM

Vic

Thanks KevMar,

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

Show quoteHide quote

"kev***@gmail.com" wrote:

> 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.
>
>
> Vic wrote:
> > I am having the exact same issue. Can't find a resolution. Several other
> > posts with this issue but nobody has a fix
>
>

3 Oct 2006 2:46 AM

Vic

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.

Show quoteHide quote

"Vic" wrote:

> Thanks KevMar,
>
> I will give this a try and let you know how it goes.
>
>
>
> "kev***@gmail.com" wrote:
>
> > 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.
> >
> >
> > Vic wrote:
> > > I am having the exact same issue. Can't find a resolution. Several other
> > > posts with this issue but nobody has a fix
> >
> >

12 Oct 2006 8:53 PM

ML from the IP

Does the same symptom occur when mapping Network Places?

Show quoteHide quote

"Vic" wrote:

> 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.
>
> "Vic" wrote:
>
> > Thanks KevMar,
> >
> > I will give this a try and let you know how it goes.
> >
> >
> >
> > "kev***@gmail.com" wrote:
> >
> > > 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.
> > >
> > >
> > > Vic wrote:
> > > > I am having the exact same issue. Can't find a resolution. Several other
> > > > posts with this issue but nobody has a fix
> > >
> > >

13 Oct 2006 8:03 PM

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[s]

    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