No thoughts from anyone?
I am having a few problems with home drives loosing their mappings after trying to introduce a printer mapping script via group policy.
Some history - We have had an AD for several years, but not really utilized group policy for running scripts. All users have their home drive set in their AD user account profile (mapped to Z: ) and a login script (connect.bat). This has been fine and works well.
In the past, all printers (even network ones) were installed as local printers with the effect that all the computers held their own queue which obviously causes problems with monitoring and management.
On to the changes. We created printer queues on one of our servers and shared them into the AD. We then decided to use one of the scripts from here to assign the printers through a login script. The script is:
This worked fine on all my tests, so we rolled it out to the students and we started to get problems with the Z: drive not being mapped for some of the students when the logged in. It would map to \\server\share but not the \\server\share\userid folder. We rolled the script back and the problems went away, so it was clearly an issue with the script.Code:Set objWshNetwork = CreateObject("WScript.Network") Set objAdsSystemInfo = CreateObject("adsysteminfo") Set objComputerName = GetObject("LDAP://" & objAdsSystemInfo.ComputerName) Set objOU = GetObject(objComputerName.Parent) strOU = replace(objOU.Name,"OU=","") Select Case strOU Case "Room T1" objWshNetwork.AddWindowsPrinterConnection "\\SERVER\Room T1 - Laser" objWshNetwork.SetDefaultPrinter Case "Room T2" objWshNetwork.AddWindowsPrinterConnection "\\SERVER\Room T2 - Laser" objWshNetwork.SetDefaultPrinter
I could see no problem with it, but decided to trial a simpler version of the script targetted at just one room. The script them became
This still caused problems with the Z: drive - but only in that room, again indicating a problem with the script.Code:Set objWshNetwork = CreateObject("WScript.Network") objWshNetwork.AddWindowsPrinterConnection "\\SERVER\Room T1 - Laser" objWshNetwork.SetDefaultPrinter
I took out the SetDefaultPrinter line and tried this, and the script ran for a week without causing a single Z: drive mapping problem.
I decided that it must be the SetDefaultPrinter causing a problem, and so removed this from the original script, but on applying this back to the students the z: drive mapping problem happended again straight away.
So - I am at my wits end - there are no entries in any logs I can find, but there seems to be some issue between the home drive mapping, the profile login script and the group policy login scripts. Has anyone seen something like this before - any ideas of what could be wrong?
Many thanks for any help - apologies for the long post - just wanted people to see what I had tried so far.
No thoughts from anyone?
does the script get called before or after the Z: drive is mapped?
does the default printer need ot be set if only one printer is added?
if it is specified to have a default wont you need to supply the printer pathCode:objWshNetwork.AddWindowsPrinterConnection "\\SERVER\Room T1 - Laser" objWshNetwork.SetDefaultPrinter
if the printer script is called before the mapping and the script needs to have the printer specified to default the it may never get around to mapping the drive.Code:objWshNetwork.SetDefaultPrinter \\SERVER\Room T1 - Laser"
Have you tried changing the drive letter used? I'm sure Z: is a reserved drive letter used by some system processes.
We map printers by adding a printer variable value in system properties of our xp machines, we then access using the .dll file to add the correct printer, example shown below.....
if %PRINTER%==whatever rundll32 printui.dll,PrintUIEntry /y /n\\servername\printer
never failed me yet, and its completely away from mapping drives.
There are currently 1 users browsing this thread. (0 members and 1 guests)