ArchersIT

Hi there, 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: 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 End Select 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. 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 Set objWshNetwork = CreateObject("WScript.Network") objWshNetwork.AddWindowsPrinterConnection "\\SERVER\Room T1 - Laser" objWshNetwork.SetDefaultPrinter This still caused problems with the Z: drive - but only in that room, again indicating a problem with the script. 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. Cheers Jonathan

Hi there, I would point it at the Exchange server - no point in setting up another SMTP server just for one application. Cheers Jonathan

Thanks for the helpful links - I have followed them all and there were no references to the old DC anywhere (other than this one entry in DNS). For peoples interest I have added the DCs into that DNS folder and am now happier that the DNS is correct. Unfortunately it hasnt yet solved my joining the domain problem. I think I will have to get a sniffer setup and try to see what traffic is failing - automatic builds are OK until they are going wrong! Cheers Jonathan

Thanks - these do not highlight any problems, which is wierd as I can see DNS entries in there for the server that no longer exists! Fairly sure that DNS has a problem - there are references to servers that no longer exist, which doesn't feel like a good thing. While it may not fix the issue I am having it is probably something that I should sort out sooner rather than later. As to the new PC - it was actually a bank of ten new laptops all being built from an OSD image that has worked before. My suspicion was that the load caused by all 10 being built at once was causing it to try to find other name servers rather than just using the normal one and this might be why it was trying to find a different server from normal (and so possibly picking up the references to the old server). I am not sure if the entries in the DNS are the cause of this issue, but they are a problem to solve on the way. Cheers Jonathan

Hi there, I need some kind person to check their AD DNS so I can reset mine correctly (if needed). A long time ago (in a ....etc ) our AD was rebuilt. This was initially with one domain controller but that one has passed on and we have two new DCs. All the FSMO roles were transferred and everything has been working for well over a year. However, I have recently had a couple of problem joinging a PC to the domain and the help has pointed me towards DNS. In looking around I noticed that we still have a couple of DNS entry pointing at the original DC. Most of these areas also have entries for the new DCs so I am planning to just remove the entries for the old DC. Unfortunately, there is one area that there is *only* an entry for the old DC. This is in "Forward Lookup Zones/AD site name/_msdcs". This folder is a different shade from the others, although I dont think the shade indicates a problem. Could some kind people have a look in their DNS and tell me what they have in that folder? I just have a NS record for the old DC - so I would like to know: - Are there just NS entries in here, or should there be other records as well - Are all the DCs listed, or just one? If there is not all the DCs listed, is it and particular FSMO roles that are listed (e.g. global catalog servers etc). Many thanks for any help Cheers Jonathan

I have a similar problem to this, until I realised that the password was fine, it was just the script had DisableAdminAccountOnDomainJoin set. One of those "Doh!" moments when I realised - may be worth checking? Jonathan