If you administer a small business Windows environment, you have probably inherited a folder full of logon scripts — a .bat that maps drives, a .vbs that copies a shortcut, and a third one nobody can explain. Group Policy Preferences (GPP) does all of that without scripts, with item-level targeting and built-in reporting. But GPP is not always the right answer, and knowing where the boundary sits saves you from broken logons and a week of debugging.
What Each Mechanism Actually Is
| Mechanism | How it runs | When it runs | Reversibility |
|---|---|---|---|
| Logon script (.bat/.ps1) | An executable attached to a user object | At logon (and optionally logoff) | Manual — you must write undone logic |
| Group Policy Preferences | Declarative settings in a GPO, applied by the Group Policy engine | Logon, boot, or background refresh | Optional “Remove when no longer applied” flag |
| Group Policy (classic) settings | Registry-based policy, fully managed | Boot / logon + refresh interval | Automatic — policy removal reverts the setting |
The important distinction: classic Group Policy is tattooing-free — remove the GPO from scope and Windows reverts the setting. Preferences (GPP) are tattoos by default unless you enable the removal option per item. Logon scripts are permanent by nature. That single behaviour difference explains most of the “why is this setting still here?” tickets in small business environments.
Where GPP Clearly Wins
- Drive mappings. A Drive Maps preference with item-level targeting by security group replaces an entire script library. Use “Update” action plus “Reconnect” so it survives reboots.
- Item-level targeting. This is the killer feature — apply a printer, drive, or registry setting based on group membership, IP range, OU, OS version, or WMI query, all declaratively.
- Local users and groups. Creating a local admin account across 30 machines is a ten-line GPP item; the script equivalent is error-prone around idempotency.
- Registry settings. GPP can write arbitrary registry values to HKCU or HKLM with targeting — covering the 90% of “tweaks” that previously lived in .reg files pushed by scripts.
- Planned printers per site or floor. Target
Printerspreferences on a site-name condition and you never hand-edit a script per location again. - Auditability. Settings appear in
gpresult /hreports; a failed script shows up as nothing at all.
Where Logon Scripts Still Win
- Loops and conditionals with real logic. “If the user is in one of these three groups, check whether a resource exists, then map it” is one line of PowerShell and a GPP nightmare.
- Anything requiring API calls. Querying a web service, an HR API, or a licensing endpoint is script territory.
- Ordering guarantees across actions. GPP has no
Syncequivalent for ensuring one action finishes before the next begins across different CSEs. - One-off migrations with a deadline. A script that copies a profile folder and then removes itself from the policy is faster to ship than designing GPP items and waiting for a rollout window.
- Third-party tooling integration. Vendor agents that expose only a command-line interface.
The Decision Table You Can Hand to a Junior Admin
| Task | Use | Reason |
|---|---|---|
| Map network drives by department | GPP Drive Maps | Targeting + auto-removal |
| Map a drive only if a DFS path responds | Logon script | Requires a live check |
| Deploy printers per site | GPP Printers | Site/IP targeting built in |
| Copy a shortcut to the desktop | GPP Shortcuts | Declarative, idempotent |
| Create local admin account | GPP Local Users and Groups | Idempotent, no script errors |
| Set registry tweaks | GPP Registry | Targeting, removal flag |
| Install software with licensing logic | Script or MDM | Too conditional for GPP |
| Enforce a security baseline | Classic Group Policy | Auto-reverts, not a tattoo |
| Set a default browser homepage centrally | Classic GP (where a policy exists) | Use built-in policy over scripts |
| Synchronize a local cache to file share | Script | Requires error handling |
Migrating From Logon Scripts to GPP Safely
Do it in this order and you will not lock anyone out. Build the GPP in a test GPO, link it to a pilot OU containing one or two machines, and keep the logon script running at the same time — idempotent operations are safe to double up.
- Inventory the script. Every action in
net use,net time, and copy commands becomes a candidate GPP item. Anything else stays a script. - Create the GPO in a pilot OU with the same items, targeting the same security groups the script referenced.
- Run both in parallel for a week. Drive mappings and shortcuts should look identical.
- Verify with `gpresult /h report.html` on a pilot machine and confirm the preference items are listed as applied with the expected winning GPO.
- Remove script actions one at a time from the
.bat, not the whole file at once. - Retire the script and leave the last-known-good version in a versioned folder in SYSVOL, not in a user’s Documents folder.
The Traps That Break Small Business Rollouts
- GPP passwords in the old format. Group Policy Preferences had a well-publicised vulnerability in credentials stored in the older
cpasswordformat. Never store credentials in a preference item; use a managed service account or scope the action with security filtering instead. - Forgotten “Run in logged-on user’s security context”. A drive map that needs to run as the user behaves differently from one that runs as the computer. Getting this wrong produces silent failures.
- Action type confusion. Create fails if the item exists; Update is almost always what you want. Replace deletes the existing value first, which can wipe user customisations.
- No removal flag. If a user moves departments, the old drive mapping stays forever unless you enable “Remove this item when it is no longer applied”.
- Scripts that block logon. A logon script with a long network timeout adds minutes to every login. Wrap network operations in timeouts and run non-critical work as a scheduled task instead.
Group Policy design sits on top of a working Active Directory. If your AD foundation is thin, start with Group Policy basics for small business servers and the Active Directory setup walkthrough before you migrate anything, then validate that the policies actually arrived using the PerfMon baseline approach for slow-logon symptoms.
What to Run This On
Group Policy requires a domain controller, and for a small business the cheapest sane topology is a single Windows VPS running AD DS plus your file services. Give it at least 2 vCPU and 4 GB RAM, more if the same box also hosts IIS or SQL Express. A licensed Windows VPS from InterServer is price-locked, comes with promo code TRYINTERSERVER for $0.01 in month one, and can hold the DC role alongside light application workloads. Windows Server edition and CAL considerations for that setup are covered in our licensing guide, and current plan options are compared at windows-vps.org.
The rule of thumb: GPP for declarative state, scripts for procedural logic, classic Group Policy for anything enforced and security-relevant. Most small business logon scripts shrink by 80% when those three lanes are respected — and the remaining 20% becomes code you can actually read and maintain.
