2

I'm having an issue with network drives. Suddenly some computers and users aren't getting their mapped network drives from the logon script. I am NOT a domain admin, I don't have permission to login to the domain controller. And I know very little about Active Directory.
The issue seems random, some users this day, different users tomorrow. Some computers run fine and some won't map no matter who logs in. They are mixed OS's XP (SP3), Vista, and 7. I was looking at the domain in windows explorer and I have found the batch file(s) that maps the drives in several locations, how do I know which one is actually being ran?

The .bat file is located in
\DOMAIN\NETLOGON\script.bat and
\DOMAIN\SYSVOL\DOMAIN\scripts\script.bat and
\DOMAIN\SYSVOL\DOMAIN\policies\GUID(Right? It's a crazy string)\User\Scripts\Logon\script.bat

So, how can I figure out which one is actually being ran per computer or user? Cause they are all slightly different from each other and one of them doesn't map properly.
Do all the files in NETLOGON get ran? Cause there are 15+ files in there. Or is it specified in Group Policy which one(s) get ran?

EDIT: I am able to access a program called Active Directory Users and Computers, but the properties tab for any user is blank for the logon script.

uSlackr
  • 6,337
  • 21
  • 36
user2517266
  • 123
  • 1
  • 1
  • 4

1 Answers1

3

You can not unless you have access to the Group Policies and can see which ones. Not every thing in the NETLOGON folder is executed.

To see what group policies (GPO) are being applied you can go Start, Run, CMD or WinKey+R and CMD and then type either gpresult on Windows XP or gpresult /r on Windows 7 and above. This does not tell you what scripts are being ran or what is actually in the group policies, just the ones being applied.

Also, since you are not the controller of the Group Policies, you shouldn't be the one troubleshooting it. Elevate it to the person that is in charge of that because you are wasting your time attempting to do it. Especially with little knowledge of how AD work.

Travis
  • 870
  • 8
  • 23
  • I have ran the command and it gave me an output that listed 5 groups that were "Applied Group Policy Object". I elevated this issue on monday. But the next elevation for this issue is to HQ which likes to take there sweet time 1 email a day, don't return phone calls, not much help. And when the HR Manager and GM can't get there personal drive to map they come to me since it is a "network issue." And I'm the network engineer here. – user2517266 Jun 28 '13 at 12:54
  • One of those Groups would tell me what script is being ran correct? – user2517266 Jun 28 '13 at 13:00
  • There are two, `Applied Group Policy Objects` within the GPRESULT. One for Computer (top one) and one for user (bottom one). These are the policies being applied to the computer. The name tells you nothing about the real underlying policy. To solve your situation temporarily, I think it may be easier to create a shortcut to the HRM and GM's personal drives with the UNC path instead of network maps. – Travis Jun 28 '13 at 13:02
  • OR try to run `gpupdate /force` to get it to re-pull the GPO. It is possible they logged in and did not get the GPO or the startup script did not run due to lack of network connectivity. – Travis Jun 28 '13 at 13:02
  • I can run a bat script to remap the drive and 50% of the time it will work the other 50% it will say 'access is denied'. Or will map it then after 2-3 minutes it will disappear. – user2517266 Jun 28 '13 at 13:09
  • Sometimes, the logon script works just fine. Then they lock their computer and it loses the map. It just randomly started happening, nothing has changed on the network or file server. And according to HQ no one has even messed with AD for our building. – user2517266 Jun 28 '13 at 13:12
  • It would be impossible to diagnose without being on the machines and server viewing event logs and what not. – Travis Jun 28 '13 at 13:12
  • Yea, I figured so. Thank you for your help anyways! – user2517266 Jun 28 '13 at 13:16
  • @user2517266 Those access denied errors indicate to me there is more going on. Seems the connection to the domain controller is flaky or you are having general network issues of some kind. Duplicate ip-addresses ? Switch with messed-up CAM-tables ? Spnning-tree or excessive broadcast issues. Is DCHP coming through properly, before the PC actaully logs in ? If the domain controller isn't local an overloaded WAN uplink ? (You can tell which DC the user is on by looking at the environment var LOGONSERVER. Hopefully they are talking to the correct one.) – Tonny Jun 28 '13 at 14:01
  • @Tonny Well, I have narrowed it down a little. The script was failing on checking if a directory existed. "if exist \\FILESERVER\folder1\folder2" was the original command. Users do not have access to folder1. But when I changed it to "if exist \\FILESERVER\folder1\folder2\" (putting that last slash) it mapped fine. But this script hasn't been changed for MONTHS, why would that suddenly matter? – user2517266 Jun 28 '13 at 15:05
  • There doesn't seem to be any network issue, I did recently setup an ether channel on the core L3 switch, but I can't imagine that has anything to do with this issue. – user2517266 Jun 28 '13 at 15:09
  • @user2517266 if exists is scary. Behavior is not well defined between various Windows versions and SMB/CIFS implementations. if exist \NULL (testing for a file called NULL in the folder) is guaranteed to always work. (The NULL file always exist if the folder is present.) – Tonny Jun 28 '13 at 18:18
  • @user2517266 I'm still not convinced about the LAN. You may not have done anything but maybe a user plugged in something weird? I remember with horror a $20 un-managed 8-port switch that advertized priority 0 BPDU packets (and there was no bpdu-guard...) Just to be sure: run a Wireshark capture for 10 minutes. Look for excessive broadcasts and bpdu packets. – Tonny Jun 28 '13 at 18:24
  • There are options to GPO. As you saw in AD Users & Computers (ADUC), the login script can be run from the user's AD setting as well. It could also be run as a shortcut from the user's startup folder (a hack for sure). – uSlackr Jul 01 '13 at 16:09