Skip to main content
it helpdesk support

"Login Scripts vs. Group Policy" by David Stein

"Login Scripts vs. Group Policy" by David Stein

March 09, 2015

David M. Stein. Endurance IT Services

There was a time when login scripts were the logical, efficient, and straightforward way to handle most user-based chores in a Windows environment. That time ended in 2008, when Microsoft completed their acquisition of PolicyMaker, merging their wonderful product into Windows Server 2008 as Group Policy Preferences. It's now 2015, so...

If you're still using login scripts to map drives, printers, create and remove shortcuts, add and remove Registry keys and values, create folders and files, or to manage local Scheduled Tasks stop! There's a better way.

The time has long since passed for you to put down the plastic hammer and pick up the cordless power tool with a bazillion attachments. There's nothing wrong with writing scripts. But writing scripts to solve problems just because you like writing scripts to solve problems is a problem in and of itself. If you work in IT, your entire career is tied to two words: efficiency and automation. Group Policy Preferences (GPP) hands you both without any added cost. Maybe you should check it out.

5 Reasons Why GPP is Better

1. It's easy. Checkboxes and drop-down lists. Done.

2. It's flexible. You can add WMI Filtering (aka Item-level Targeting) if you need to apply condition checks based on all sorts of environment aspects. You can leverage the power of Group Policy features like inheritance, blocking, merging and loop-back.

3. It's reliable. It runs along with the built-in Group Policy processing service, so it just runs and you don't need to monkey with it a lot.

4. It's robust. You can hide drive mappings from Windows Explorer and handle pre-mapped scenarios with different methods. Using GPO features and linking, you can create hierarchical settings, as well as zone-based settings if needed.

5. It's scalable. It can fly as high as your Active Directory (or Azure Directory) can go, and if you or your code writer is run over by a bus, you don't need to find a coder to support it.

I've been writing scripts and program code for thirty years. As bad as it sounds, I have to admit that I love writing code. But I'm also a pragmatist, and a professional consultant. So my customers trust me to help them address their challenges within their budget and without wasting time. If there's a built-in solution that works, I'm going to try that first.

Example 1: Standard Drive Mapping

In this example, we'll create a new X: drive and map it to an internal share named Docs on server FS01. For this demo we'll create a new functional GPO, rather than a bundled GPO. A functional GPO only contains functionally related settings (e.g. drive mappings), and nothing else.

1. Open GPMC (part of RSAT: Windows 7 or Windows 8)

2. Create a new GPO named Drive Mappings

3. Right-click and Edit the GPO

4. Expand User Configuration / Preferences / Windows Settings

5. Expand Drive Maps

6. Right-click and choose New / Mapped Drive

7. Select Create from the Action list.

8. Enter the UNC path in the Location box (e.g. \\FS01\Docs)

9. In the Drive Letter section, check use and select the drive letter from the drop-down list (e.g. X:)

10. Check the Reconnect option.

11. Click OK

12. Close the Group Policy Editor.

13. Link the GPO to a suitable test OU in your domain. This should be an OU where the desired test user accounts reside. Be sure to use a test OU before linking to a production OU, just until you verify everything works properly.

14. Log onto a computer in the domain using the test user account which resides in the test OU. Open Windows Explorer and verify the drive mappings.


If you were already logged onto a computer with the test user account, you may need to either log off and log back on, or open a CMD console and type GPUPDATE /Force in order to update the policy settings the first time.

If you have time, you should compare various settings against different scenarios, just to make sure you understand how they work and what the impacts are. For example, try Create and Replace on a user who already has the same drive mapping, but to a different UNC target.

What is CRUD?

CRUD is a half-baked acronym that stands for Create, Replace, Update, Delete. This is a shorthand way of remembering the four (4) options from the GPP Actions list.

Create “ Instantiates the setting if the target does not already exist. In this example, if the user already has an X: drive mapping, the GPP setting will skip it.

Replace “ Will create the drive mapping if it doesn't exist. But if the user already has an X: drive mapped, this will disconnect it first, then reconned to the GPP mapping.

Update “ Works similarly to Replace, but doesn't disconnect the mapping. It simple reconfigures it while mapped.

Delete “ This should be self-explanatory

Using the above example, if you wanted to force all users to a standard X: drive, even if some of them already have their own X: drive mapping, you could select Replace or Update. With Update and Replace, be sure to consider impacts for situations where a user may have shortcuts, or application settings which reference specific items under the affected drive letter.

Example 2 “ Custom Drive Mapping by AD Group

Background: GPP now refers to WMI Filtering as Item-Level Targeting, or ILT. It works roughly the same, but if you're not familiar with either term, I'll try to explain, without going into the history or details behind WMI itself.

WMI provides an abstraction layer between applications and things under the Windows hood. It also provides a nice object model with a built-in query engine, that enables searching and filtering information somewhat like a relational database. For example, you can search for all logical drives which have a certain model number or which have less than 5 MB of free space. It can also be used to query things like user accounts, and group memberships; both locally and within an Active Directory domain.

ILT puts a really simple graphical interface on this so you can set up a powerful query with just a few clicks.

In this example, we'll create a Y: drive mapping for users who are members of a domain group named Engineering Managers. The mapping will refer to a share named Apps on server FS01.

Follow the same steps described in Example 1, up to step 7.

1. In the Location box, enter the UNC path (e.g. \\FS01\Apps)

2. In the Drive Letter panel, select Y: drive.

3. Click the Common tab.

4. Select Item Level Targeting and select Targeting

5. Click New Item

6. Select Security Group from the list of items

7. Enter the Group Name or browse for the name.

8. Check User in Group

9. Click OK

The GPP setting will only apply to users if they are a member of the group you specify.

Warnings and Cautions

Just as fire can cook or kill, technology comes with mixed power.

* Always follow the basic best practices of Group Policy. Start small and build slowly. Only configure the absolute minimum set of changes as you need.

* Avoid using a lot of Item-Level Targeting, as it does impose some additional processing overhead during logins.

* Research any and all settings that you aren't familiar with before you make a change to them.

* Test, Test, and Test again! Never try something new in a production environment without thorough testing.

* You can also disable Computer settings processing on the GPO by right-click and opening its Properties, to improve login performance.


We'll take care of every detail.

Even if you don't know exactly what you need, our experts make it easy to talk about your project and work out the requirements. We'll quickly help frame it up and add some structure so it can be properly estimated and ultimately developed and delivered.