Windows cannot access the specified device, path, or file.

Cannot open logon scripts on DC's other than on the Main DC.

I have 4 DC's throughout my Domain, but only the Main DC can open/edit the logon scripts that are assigned to GPOs.  If I attempt to open/edit a script through any of my other DC's I get the following error:  "Windows cannot access the specified device, path, or file.  You may not have the appropriate permissions to access the item."

I am logged in with my account, which is a Domain Admin, and can edit the file(s) fine on the Main DC.  I have also attempted to open/edit the files by exploring the SYSVOL share but I receive the same error on the 3 DC's.

My first question is:  If I cannot edit/open the scripts through the 3 DC's, is there a utility I can use to log whether the scripts are running for the end-user or not?

My second question is:  Why can I not edit/open these files through my 3 DC's?

I am running a Windows 2003 Domain, all 4 DC's are Windows 2003, with Windows XP workstations.
uxphreakAsked:
Who is Participating?
 
LauraEHunterMVPCommented:
If the GPO is assigning a logon/logoff script, by default it must be linked to the container that actually contains the user objects.  If you have a subset of computers where GPO settings should be applied to the user based on the computer that they are logging into (for Terminal Servers, etc.), you can configure loopback processing as described here: http://support.microsoft.com/kb/231287
0
 
LauraEHunterMVPCommented:
What syntax are you using to attempt to modify the files on the other DCs?  (It may be as simple as you're entering the wrong UNC path.)

As a starting point if that's not the case, install the Windows Support Tools on one or more DCs and run dcdiag /v, netdiag /v, and repadmin /replsum to confirm that replication is taking place between your DCs.
0
 
Brian PiercePhotographerCommented:
Sounds like a FRS issue - anything in the event log
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
uxphreakAuthor Commented:
All:

I ran DCDIAG, NETDIAG, and REPADMIN against all the DC's having the issue and no failures were reported.

I checked the FRS event log on each DC, and for each time I have rebooted each DC an event is recorded that states, in part:  "The File Replication Service is no longer preventing the computer <NAME OF DC> from becoming a Domain Controller".  This follows immediately after an event is recorded when FRS has started after the server has been rebooted.

I appreciate your assistance with this.
0
 
uxphreakAuthor Commented:
I forgot to mention:

I can browse, from the DCs having the issue, to \\<SERVERNAME>\SYSVOL\<DOMAIN NAME>\Policies\<SID>\User\Scripts\Logon and edit/open the script in the policy, however, if I attempt to edit/open the same script by browsing \\<DOMAIN NAME>\SYSVOL\<DOMAIN NAME>\Policies\<SID>\User\Scripts\Logon I receive the error:  "Windows cannot access the specified device, path, or file.  You may not have the appropriate permissions to access the item."
0
 
LauraEHunterMVPCommented:
What happens if you do an nslookup of <domain name>?  It should return the ip addresses of one or more of your domain controllers.  If it does not, there's an issue with the SRV records registration for your domain controllers.  Assuming you're using AD-integrated DNS with dynamic updates enabled, restart the DHCP Client and Netlogon service on each DC one at a time to re-register their A and SRV records to see if this alleviates the issue.
0
 
uxphreakAuthor Commented:
nslookup <domain name> returns the IP's of all my DCs from a client computer.

From <SERVER0>, which is the Main DC, nslookup <domain name> returns the IPs of all my DCs
From <SERVER1>, which is at Location 1, nslookup <domain name> returns the IPs of all my DCs
From <SERVER2>, which is at Location 2, nslookup <domain name> returns the IPs of all my DCs, but it also states "Can't find server name for address 192.168.2.240: Non-existent domain"  The address specified in the error is the IP of <SERVER2>
From <SERVER3>, which is at Location 3, nslookup <domain name> returns the IPs of all my DCs
0
 
uxphreakAuthor Commented:
UPDATE:

I restarted the DHCP Client and Netlogon services on <SERVER2> and now nslookup is not reporting a problem, however, I still do not see the logon scripts running for my users at Locations 1, 2, and 3.  My Main location is not having any issues with logon scripts.

Thanks again.
0
 
uxphreakAuthor Commented:
UPDATE #2:

I modified the first Logon Script, which is VBS and is located on the top of Domain, to output the date and time to a text file with the name of the computer as the filename.  I then edited my logon scripts that are configured for each underlying OU so that it would append the output of date, time, and "script ran" to the same text file.

At my Main location the scripts run perfectly, and the files are created with the date and time that each script ran as well as on which computer they ran.  At Location 1, 2, and 3, a Command Window pops up and displays:

'\\<DOMAIN>\sysvol\<DOMAIN>\policies\<SID>\user\scripts\logon' CMD.EXE was started with the above path at the current directory.  UNC paths are not supported.  Defaulting to Windows directory.

The <SID> matches the OU that the Logon Script was associated with.  After this message, another below it is displayed which indicates that the Domain Level logon script is running, and the output of this is sent to the text file, but only the Domain Level logon script is running.

It appears that the OU Logon script attempts to run but fails, then the Domain Level script runs and succeeds.  The first thing that pops into mind is, how come the Domain Level script runs last when it's at the top of the tree, and the second is, if the OU script fails then shouldn't the Domain Level fail as well?
0
 
LauraEHunterMVPCommented:
I would run the Resultant Set of Policy wizard against a user/computer combination in each of your locations to confirm that GPOs are being applied as you think they are; the RSoP report will also indicate any errors relevant to GPO processing that may be affecting users/computers in your other sites.
0
 
uxphreakAuthor Commented:
LauraEHunterMVP:

I ran RSoP, and interestingly all of the GPOs that need to run on the Computer are running, but the one GPO that contains the logon script that is not running is not listed for the User.  If the computer is located in an OU Container, does the user object need to be listed in the same container in order for the GPO on that OU to apply to the user?
0
 
uxphreakAuthor Commented:
Thanks LauraEHunterMVP.  I applied the setting in the GPO and it worked like a champ.  My only concern is how this will affect future changes to my OU organization, however, I may end up creating more logic in my logon script so that I don't have to rely on GPO Loopback.

Thanks again.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.