Member Avatar for ArtChess

Where does the Active Directory know to find the *.bat file found in a user's profile properties Profile tab.

For example when I go into the Microsoft Management console and I'm under a certain OU and open the properties of a user. there are several tabs:
1. Member OF
2. Environment
3. Sessions
etc,...etc..

and under the Profile tab: there is a Logon Script.
In our company there is a batch file for each OU. Where in Active directory do you set the settings so it knows where to look for that particular batch file.

for example if Joe Shmoe has ILOVEU.BAT in his Logon Script that actuall file "ILOVEU.BAT" must physically reside somewhere on a network server nah? Or Does it?

and how does it know where to get it?

thanks in advance for your help..and I hope my question makes sense.

  • 4 Contributors
  • 6 Replies
  • 261 Views
  • 4 Months Discussion Span
  • Latest Post Latest Post by kc0arf

Dani AI

Generated

Short answer: the user object’s Profile → Logon script field writes a value into the AD attribute named scriptPath (it usually contains just a filename or a relative path). At logon the client resolves that name against the domain’s central scripts area; scripts deployed by Group Policy are kept in the policy’s Scripts\Logon folder under SYSVOL. See the AD schema for scriptPath and Microsoft guidance on assigning logon scripts. (learn.microsoft.com)

To inspect what a particular account points to, query the ScriptPath attribute. For example:

Get-ADUser -Identity JoeShmoe -Properties ScriptPath | Select-Object Name,ScriptPath

The Profile UI accepts a filename or a relative path if the script lives in a subfolder of the domain script share (e.g., Folder\ILOVEU.BAT). For GPO-based scripts use the GPMC editor’s “Show Files” to see the exact script location. (learn.microsoft.com)

Troubleshooting checklist (quick, practical):

  • Confirm the file exists in the script location visible from a client and that the name in scriptPath matches exactly (including extension and any subfolder).
  • Verify share and NTFS permissions let users read/execute the script.
  • Confirm SYSVOL/NETLOGON replication and health (use dfsrmig/repadmin/dcdiag as appropriate).
  • Use gpresult /r (or gpresult /h report.html) and check Event Viewer (Application/System) on the client for script errors.
    These checks address the most common failure points (name/path, permissions, replication, and GPO vs. user-script conflicts). (learn.microsoft.com)

As and noted, the script must be reachable from the domain’s central area (not the user’s local Windows folder unless the script is explicitly local). For easier management in modern environments prefer GPO-assigned scripts or centralized file shares and keep SYSVOL replication current (migrate to DFSR if still on FRS). (learn.microsoft.com)

Recommended Answers

All 6 Replies

Member Avatar for MAD_DOG

You know I think I got the beef of your question I been playing around with that and drop it in the Windows Folder the batch file and make sure you point inside just the Windows folder let me know the results that should work I had no luck running them on another drive or anywhere else expect in the Windows folder.

Where does the Active Directory know to find the *.bat file found in a user's profile properties Profile tab.

For example when I go into the Microsoft Management console and I'm under a certain OU and open the properties of a user. there are several tabs:
1. Member OF
2. Environment
3. Sessions
etc,...etc..

and under the Profile tab: there is a Logon Script.
In our company there is a batch file for each OU. Where in Active directory do you set the settings so it knows where to look for that particular batch file.

for example if Joe Shmoe has ILOVEU.BAT in his Logon Script that actuall file "ILOVEU.BAT" must physically reside somewhere on a network server nah? Or Does it?

and how does it know where to get it?

thanks in advance for your help..and I hope my question makes sense.

Member Avatar for kc0arf

Hello,

On each Domain Controller, there is a folder called SYSVOL, and inside that folder is a folder with your domain name, and inside there, is a scripts folder.

Only Administrators should be placing items inside there.

You should also be able to put the UNC (\\servername\sharename\folder) into that property page, if you need to reference other locations.

And, under Server 2003, the items in the SYSVOL folder will be automatically replicated among the Domain Controllers. No need to setup special replication paths.

Christian

Member Avatar for MAD_DOG

Thanks you cleared up a lot I just threw in my two cents. Kc0arf you an Administrator? Let me know I would like to share some knowledge I always like to talking to Admin's that know Active Directory because there aren't so many that know there stuff.

Member Avatar for ArtChess

Thanks Christian,..

Man how much i have forgotten already...See,.. i attained my MCSE NT4.0 some time ago, and started the W2K MCSE and only did 3 of the four core...

Well anyway to make the long story short...i can't believe how much i forgot and how hard i studied, but didh't follow through, b/c i only got a 'help desk' job,... and forgot all i've learnt. Isn't that a shame...But yeah from what you have just replied, it all comes back.. Thank you,

On each Domain Controller, .............

And, under Server 2003, the items in the SYSVOL folder will be automatically replicated among the Domain Controllers. No need to setup special replication paths.

Christian

Edited by TrustyTony because: format
Member Avatar for grc1uk

On each domain controller there is a folder called NETLOGON

All log on scripts are stored here

Member Avatar for kc0arf

Hello Guys,

Yes, I am a network administrator, and was certified NT 4.0 Server some time ago. Working to upgrade that certification to Windows 2003.

Feel free to write / post questions and discussion points.

To be honest though, I really prefer Linux.

Christian

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.