Why You Should Stop Using Login Scripts


Summary:   Milad Aslaner , a Microsoft Premier Field Engineer based in Germany, gives Login scripts a lashing and encourages us to move on to using Group Policy Preferences. Enjoy!


Microsoft Windows LogoWhen I’m delivering Microsoft Premier Support Workshops like XPERF View on Windows Client Performance or Supporting Windows Client Effectively I usually ask my customers if there is someone in the audience whose company does not have logon scripts.  If I’m lucky. perhaps 1 customer out of an audience of 10-12 people will say that they replaced their logon scripts with Group Policy Preferences (a.k.a. GP Preferences) .

Most of the time the conversation goes like this:

Me: Do we have anyone in the audience whose company is not running a logon script?
Audience: ……silence……
Me: What are you typically doing within a logon script?
Audience: Driver mapping, printer configuration, displaying messages, etc…
Me: Are you aware that you could do that with GP Preferences?
Audience: Yeah.
Me: So why not change to use GP Preferences?
Audience: Yeah, you know… umm… those logon scripts have been around since I started there… and umm we need to look into it someday… But umm…

Without going into a ton of details, the bottom line is that the processing of GP Preferences is faster than logon scripts. Even if you decide to go with item-level targeting it’s still faster than your script.  Microsoft’s official recommendation is to use GP Preferences whenever possible over logon scripts. You should only keep using logon scripts if the script is so complex and/or mandatory that it’s simply too hard or impossible to set up GP Preferences.

If you want to analyze the impact of your logon scripts, why not utilizing XPerf and drill into the nanoseconds of your boot? Have a look at What Is Bootckcl.etl and Why Does It Get Generated At Every Boot? or XPerf for the layman using the Windows Assessment Toolkit .

Btw, why not get a Premier Field Engineer onsite to do a deep dive analysis of your boot experience? Contact your Microsoft Premier Support Technical Account Manager (TAM) today and set one up!


Written by Milad Aslaner; Posted by Frank Battiston, MSPFE Editor