Al
Sun May 04 12:01:29 CDT 2008
Interesting - but puzzling. But this still would seem to have something to
do with the profile being built during the first logon, as the behaviour is
normal on subsequent logons.
Here is a question you might want to consider: why do you run your logon
script asynchronously? If there is no specific reason, making it synchronous
may fix this bug^H^H^H "feature". If the reason is to allow the user to get
to his desktop with less delay, well, what if he wants to do something that
needs a drive mapping that has not yet been established?
/Al
"Greg" <Greg@discussions.microsoft.com> wrote in message
news:DFE49989-2D47-4EE1-95AE-74F5F20E62A4@microsoft.com...
> This might not be a scripting problem after all. After some various
> trouble-shooting I noticed that the drives are being mapped, I just could
> not
> see them. What I was doing was launching Windows Explorer by either
> double-clicking on the My Computer icon on the desktop or right-mouse
> clicking on the My Computer icon and selecting Explore or by pressing the
> Windows key on the keyboard and the letter E simultaneously. All three of
> these methods don't show the drive mappings other than the home drive
> which
> is mapped automatically as part of the users profile.
>
> However, if I open a command prompt and switch to one of the mapped drives
> I
> have full access or if I launch Windows Explorer by selecting it from the
> Start Menu ... Programs ... Accessories. Also, the network drives appear
> to
> be available from within File ... Open and File ... Save As menus within
> applications.
>
> At this point I guess I will just consider this to be a "feature not a
> bug"
> and spread the word to my help desk and desktop support staff so they will
> know what to do if they get called by and end user.
>
>
> Thanks for all of your help.
>
> Greg Brown
>
> "Al Dunbar" wrote:
>
>>
>> "Greg" <Greg@discussions.microsoft.com> wrote in message
>> news:C50BFCD5-B913-4294-86B4-80400110F895@microsoft.com...
>> > Hi Al,
>> >
>> > Thanks for taking the time to help me with this.
>> >
>> > Here is the code that I use to map conditional network drives. When
>> > the
>> > script runs I get the popup message
>> > and the variable strListOfDriveMap does have the correct data. This
>> > tells
>> > me that the test for group
>> > membership is working properly. When control is returned to the main
>> > body
>> > of the script from this subroutine
>> > I popup another message with the contents of strListOfDriveMap so I
>> > know
>> > that the script is not just dying.
>> >
>> > If IsMember("IS GROUP") Then
>> > strListOfDriveMap = strListOfDriveMap & "460" & strDelimiter
>> > If Not InStr(strPhysicalDrives,"H:") Then
>> > If oFSO.DriveExists("H:") = True Then oNet.RemoveNetworkDrive
>> > "H:",
>> > bForce, bUpdateProfile
>> > oNet.MapNetworkDrive "H:", "\\filstorage01\iscommon", true
>> > wscript.echo "mapping H: drive"
>> > End If
>> > Else
>> > strListOfDriveMap = strListOfDriveMap & strDelimiter
>> > End If
>> >
>> >
>> >
>> > Code is being executed after the map network drives section. For
>> > example,
>> > some data is written to log files with
>> > basic information about the computer including IP address info and this
>> > report is properly created.
>> >
>> >
>> >
>> > Regarding the run logon scripts synchronously group policy setting this
>> > is
>> > currently "Not configured" which I
>> > believe defaults to disabled.
>>
>> If synchronous is disabled, that means that the script is running
>> concurrently with the logon process, which includes the building of the
>> profile at the first logon. If you could enable synchronous operation in
>> a
>> test OU, it would be interesting to see if that resolves the problem, but
>> that does not explain the cause of the problem, and might not be
>> acceptable
>> for your company for other reasons.
>>
>> If the mapping operation is failing and you have "ON ERROR RESUME NEXT"
>> in
>> effect, then the only way you'd notice a problem is if you found the
>> drives
>> were not mapped - sound familiar? Try adding an "ON ERROR GOTO 0"
>> statement
>> just before the code above, and testing on a machine where you have
>> deleted
>> your profile.
>>
>> >
>> >
>> >
>> > The profile tab of the user property page in ADUC directly lists the
>> > vbscript (logon.vbs) and not a batch file that
>> > then launches the vbscript.
>> >
>> >
>> > I don't think the script is timing out because other tasks appear to be
>> > working correctly.
>>
>> I agree.
>>
>> >
>> >
>> >
>> > No path is specified for the logon script itself. Just listed as
>> > "logon.vbs" in ADUC. The script is directly in the NETLOGON
>> > share on the domain controllers and not in a subdirectory or other file
>> > share.
>>
>> As it should be.
>>
>> >
>> >
>> >
>> > I could post the entire script but it is over 2000 lines long. I would
>> > prefer to send a copy directly to anyone who
>> > wants to see it.
>>
>> I'd rather not... ;-) Try my above suggestion, and/or try setting a test
>> account's logon script to one that simply maps a share unconditionally.
>>
>> /Al
>>
>> >
>> >
>> > Thanks again for your help,
>> > Greg Brown
>> >
>> >
>> >
>> > "Al Dunbar" wrote:
>> >
>> >>
>> >> "Greg" <Greg@discussions.microsoft.com> wrote in message
>> >> news:716120CA-EBCE-4A8E-A0C1-9CCD0D488928@microsoft.com...
>> >> > Greetings All,
>> >> >
>> >> > I am having a problem with mapping network drives the very first
>> >> > time a
>> >> > user
>> >> > logs onto a computer while their profile is being created. For some
>> >> > reason,
>> >> > during the very first interactive logon when a new user logs onto a
>> >> > PC
>> >> > they
>> >> > do not get their network drives. Other parts of the logon script
>> >> > (vbscript)
>> >> > appear to be working correctly. I can test for group memberhip,
>> >> > display a
>> >> > pop-up message, write to a log file etc. just not map a drive.
>> >>
>> >> Hmmm, interesting. Could you post your code?
>> >>
>> >> > If I manually run the logon script again once the desktop is up then
>> >> > all
>> >> > of
>> >> > the drives map correctly and every time after that first logon the
>> >> > drives
>> >> > get
>> >> > mapped properly.
>> >> >
>> >> > I have tried explicitly specifying the value for bUpdateProfile
>> >> > instead
>> >> > of
>> >> > relying on the default, which should be false, as indicated here:
>> >> >
http://msdn2.microsoft.com/en-us/library/8kst88h6(VS.85).aspx
>> >> >
>> >> > I have tried enabling userenv logs but I don't really know what to
>> >> > look
>> >> > for
>> >> > and I nothing jumped out as an obvious error.
>> >>
>> >> The things that you say are working in your logon script - does that
>> >> include
>> >> code executed *after* the share mapping code? Have you tried using the
>> >> ERR
>> >> object to see if the .mapnetworkdrive method is reporting an error?
>> >>
>> >> > My environment is a Windows 2003 native mode domain, Windows XP Pro
>> >> > with
>> >> > SP2
>> >> > on the destktops and the logon script is a vbscript that is
>> >> > specified
>> >> > on
>> >> > the
>> >> > Profile tab of the user account in active directory users and
>> >> > computers.
>> >>
>> >> Exactly the same as our environment, yet I have never seen this
>> >> problem.
>> >>
>> >> > Any thoughts or suggestions would be appreciated. Work arounds
>> >> > would
>> >> > be
>> >> > ok
>> >> > too. Perhaps if there is a way for the logon script to detect that
>> >> > a
>> >> > new
>> >> > profile is being created then I can take some other actions.
>> >>
>> >> If you could figure out what those alternate actions are, then it
>> >> would
>> >> be
>> >> simpler to just use that method to do the mapping so that you do not
>> >> have
>> >> to
>> >> determine if this is the first logon on the machine.
>> >>
>> >> A few questions and thoughts:
>> >>
>> >> Are you running your logon script synchronously or asynchronously?
>> >>
>> >> Does the logon script attribute point to the vbscript directly, or to
>> >> a
>> >> batch script that runs the vbscript using cscript or wscript?
>> >>
>> >> It could be that the script is timing out because it is taking so long
>> >> to
>> >> create the profile. What do you do to ensure that the timeout is not
>> >> in
>> >> effect?
>> >>
>> >> Is the logon script setting qualified with a path? If so, what does it
>> >> look
>> >> like? Could this depend indirectly on something that might not be
>> >> available
>> >> until it runs when the profile is already built? Or does it depend on
>> >> a
>> >> mapping that cannot yet exist?
>> >>
>> >> Might there be some conflict with a group policy object? Or with
>> >> something
>> >> the computer does differently on the first logon?
>> >>
>> >> I'd suggest you show us what the logon script setting is, and post at
>> >> least
>> >> parts of your code.
>> >>
>> >> /Al
>> >>
>> >>
>> >>
>>
>>
>>