What is a login script?
A login script, which Windows tools call a logon script, is a file of commands that runs each time a user signs in. In a business network it gives every user the same starting setup without a technician visiting each PC: the right network drives, printers and environment for who the user is or which group they belong to. Login scripts are usually batch files (.bat or .cmd) or PowerShell scripts (.ps1). Older networks also use VBScript (.vbs), which Microsoft has deprecated.
Ways to assign one
- Active Directory user account: in Active Directory Users and Computers, open the user's Properties > Profile tab and enter the file name in the Logon script field. The script lives in the domain's NETLOGON share (
\\domain\NETLOGON), which is replicated to every domain controller. - Group Policy: User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff). The script then runs for every user in the site, domain or organizational unit where the policy is linked, and PowerShell scripts have their own tab. Computer Configuration has matching Startup and Shutdown scripts that run as the computer before anyone signs in.
- On a single PC: the Local Group Policy Editor (
gpedit.msc, Pro and higher) has the same Logon setting, and Task Scheduler can run a script with an At log on trigger. A shortcut in the Startup folder (shell:startup) also launches something at sign-in, but it is a per-user convenience rather than a managed login script.
What login scripts typically do
- Map network drives, including a personal drive such as
net use H: \\fileserver\home\%USERNAME% /persistent:no. - Connect printers or set a default printer.
- Set environment variables or copy a configuration file into the user's profile.
- Show a sign-in notice or launch a required app.
- Collect inventory data, such as logging the user name and computer name to a file share.
A minimal batch login script might contain only these three lines:
@echo offnet use S: \\fs01\sales /persistent:nonet use P: \\fs01\public /persistent:no
Scripts usually map with /persistent:no because they recreate the mappings at every sign-in anyway.
Login scripts vs newer methods
Many organizations now map drives and printers with Group Policy Preferences, whose Drive Maps and Printers items can target users by group without code, or push settings and scripts to cloud-managed PCs through an MDM platform such as Microsoft Intune. Login scripts remain common for custom tasks and older networks, and they are the classic answer for "give every user the same drive letters at sign-in".
Troubleshooting a login script
- Drives missing after sign-in: run
gpresult /rto confirm the policy applied, then run the script by hand to see its errors. Check that the user can read the NETLOGON share and the target shares. - Policy changed but nothing happened: run
gpupdate /force, then sign out and back in, because logon scripts run only at sign-in. - Drives appear in File Explorer but not in an elevated Command Prompt: under UAC, mappings made in the standard session are not visible to the elevated session.
- Slow sign-in: a script waiting on an unreachable server delays the desktop. Remove dead mappings and keep scripts short.
- A PowerShell script will not run: check the execution policy and any script restrictions that apply on that PC.
Login script on the CompTIA A+ exam
Login scripts link two Core 2 (220-1202) objectives: 2.2, which covers managing Windows users with tools such as Active Directory and Group Policy, and 4.8, which covers scripting file types and everyday uses for scripts such as remapping network drives. Know the common script file types (.bat, .ps1, .vbs, .sh, .js and .py), that a login script runs at every sign-in, and that it is a standard way to give many users consistent mapped drives and printers across many PCs.