Setting up a Logon Script through Active Directory Users and Computers in Windows Server 2008
You can use logon scripts to assign tasks that will be performed when a user logs on to a particular computer. These scripts can carry out operating system commands, set system environment variables, and call other scripts or executable programs. Some tasks commonly performed by logon scripts include:
- Mapping network drives
- Installing and setting a user’s default printer
- Collecting computer system information
- Updating virus signatures
- Updating software
Basically, there are two ways to assign Logon scripts. The first is done on the Profile tab of the user properties dialog in the Active Directory Users and Computers (ADUC). The second is done via Group Policy Objects (GPO). This article will focus on the first method.
It’s worth noting that using the first method – via the Profile tab of the user properties – will work for any Microsoft-based operating system, and is especially useful when you have older clients such as Windows 95/98 or Windows NT. These types of operating systems do not use Group Policies. If you assign the logon script in both ways for a user, if the user logs on to a computer running Windows 2000 or above, both logon scripts will run. Therefore it’s recommended you only use one of the methods. You can read more about it on my “Setting up a Logon Script through GPO in Windows Server 2008” article.
Note: Using Windows Server 2008 Active Directory Users and Computers (ADUC) to assign logon scripts is mostly the same as it was in Windows 2003, but having some people asking me questions about it in Windows Server 2008 has triggered the writing of this article.
Creating the logon script
The logon script is the file that does the actual action. It could be almost any action, as noted above. So we’ll start by creating that script. The default location for logon scripts is the NETLOGON share, which, by default, is shared on all Domain Controllers in an Active Directory forest, and is located in the following folder:
%SystemRoot%\SYSVOL\sysvol\<domain DNS name>\scripts
Where %SystemRoot% is usually “C:\Windows” and <domain DNS name> is the DNS name of the domain, similar to “Petri.local”. This folder, which is a part of the SYSVOL special folder, is replicated to all the Domain Controllers in the domain.
Note: The actual process of creating the script is beyond the scope of this article, there are plenty of good resources with great examples on the Internet.
- Create the logon script and give it the appropriate name (for example: logon.bat, logon.cmd, logon.vbs, etc.) The script can use ANY name, just make sure you know what that name is, and give it the right file extension type.
- Make sure that the script runs and performs the required action when it is manually run (double-click on it).
- Copy the logon script (CTRL+C).
- Paste the logon script in the NETLOGON share on one of the Domain Controllers. The NETLOGON share is located in the following path: c:\Windows\Sysvol\Sysvol\Domain Name\Scripts.
Note: You can enter a UNC path in the “Logon script” field and place the file in another location. However, this location should be one that is replicated to all Domain Controllers, and unless you have such a folder available, I’d suggest you keep to the NETLOGON share.
What permissions are required for Logon scripts to run?
Logon scripts run with the credentials of the user. It is recommended that the “Domain Users” group shall be given permission to any resources used by either of these scripts. For example, if the logon script writes to a log file, the group “Domain Users” should be given read/write access to the file or the folder where the log file is located. Most users have limited privileges on the local computer, so logon scripts will have the same limited privileges.
Assigning the script to the user
Next, we need to decide what user should have the logon script. We will work in that user’s user account in Active Directory Users and Computers. With this procedure, you can only link ONE logon script to each user, and you must do it ONE USER AT A TIME, or, if you have the knowledge – script the changes in Active Directory (there are methods to do this, but I won’t get into detail here).
If you plan to have more than ONE logon script, and if you wish to assign that/those script(s) to more than one user, you might want to look into the “Setting up a Logon Script through GPO in Windows Server 2008” article.
- Open Active Directory Users and Computers from the Administrative Tools folder (or dsa.msc from RUN).
- Expand the domain tree, locate the OU where the user is located.
- Right-click the user object, select Properties.
- In the Profile tab, locate the Logon Script box.
- In the Logon Script box type the name of the script from step #2. You DO NOT need to enter the path, since it is located in the NETLOGON share. Make sure you enter the full name (i.e. logon.bat or logon.vbs etc.).
- Click Ok.
Replicate the DCs
Now we need to replicate the DCs in the domain by using either Active Directory Sites and Services, Replmon, Repadmin, or wait a few moments (depending on the number of DCs). As a simple follow up to this article, I suggest you use Active Directory Sites and Services.
Testing the logon script
- On one of the computers that is part of the domain, logoff the specific user account.
- Logon and test.
If the logon script doesn’t work for you, go back to the basics and see if it works at all by double-clicking on it. See if it’s placed in the right path – the NETLOGON share on one of the DCs, and see if it has replicated to the other DCs. Also check permissions by trying to manually run the script from the right path but while logged on as the user, and not as an administrator.
Recent Windows Server 2008 Forum threads
Got a question? Post it on our Windows Server 2008 forums!
More in Windows Server 2008
Microsoft Acknowledges New Netlogon Issues On Windows Server Machines
Feb 25, 2022 | Rabia Noureen
How to Fully Patch the PrintNightmare Vulnerability
Jul 9, 2021 | Brad Sams
Everything You Need to Know About Windows – January 2020
Feb 3, 2020 | Russell Smith
Paul Thurrott's Short Takes: Microsoft Earnings Special Edition
Jan 31, 2020 | Paul Thurrott
SCARY: “Atom Bomb” Windows Security Hole said to be Unfixable
Oct 31, 2016 | Richi Jennings
Microsoft’s New Patching Philosophy Sacrifices A Few For The Many
Aug 19, 2016 | Brad Sams
Most popular on petri