Loginscript versus GPO

Dear janhoedt,

Check out this nice article on EE site.

https://www.experts-exchange.com/Software/Server_Software/File_Servers/Active_Directory/A_5175-Replacing-Your-Login-Scripts-with-Group-Policy-Preferences.html


joyofsharing

Are you trying to comapre  workstation mode with domain mode Login process?

In a domain when a user logs on,  Group policy is processed fist and then depending on what scripts you may have you can use the script to run at logon as logonscripts.

So GPO is always processed first and logonscript can overwrite ... until GPO refreshes (after 15 minutes)?

The simplest way to think of it is this - Group Policy Objects are basically ways of manipulating the computer or user hives of the registry. These are executed at logon, and then at regular intervals thereafter.

Logon/startup/shutdown scripts are exactly that - they are scripts (BAT file, VBScript, PowerShell etc) that execute when certain condition occur - a computer startup or shutdown event, a user logon or logoff.

In an ideal world, you should be able to manipulate everything via GPO, but in the world we really live and work in, some things just can't be manipulated this way - as an example, the library views in Windows 7/2008 R2 are registry keys that have no associated GPOs so for one customer I've just had to write a login script that loops through them when a user logs on and removes the public folders from the users' documents library view. Mapping different drives based on user group is another example.

If it's possible to do via GPO or GPP then that is preferrable but if not, then scripts can help. Usually :-)

So there is no rule that you have to move login scripts to a GPO (group policy preferences).  you can go that way.    I would start to go that way but in my last job we had a 3000 line login script that had grown over 9 years...that was not something we could easily move.

The login script in the user's account properties will run first.  

Thanks

Mike

Oh and you define which scripts run via group policy, by the way, but these are again just basically registry entries and will be executed during / after group policy processing.

And yes, an update to a group policy may well update and therefore change a setting defined in a script.

Group policies tend to give the perception of being quicker and of course if you edit them, they apply without a logoff or reboot (most times - some settings will still require this).

But if you have a complex login script that is quick enough to run and your users are happy with there is no definable requirement to change except perhaps to streamline it and for neatness.

As I say, in most instances you will have both in your environment.

Usually with GPO's you will assign a startup / login script for the user config or computer config.  Login scripts attached to the domain level will fire, but if there are other login scripts in the GPO settings down below linked to OU's then they will get fired next.

I will link login scripts in the GPO for OU's that I want to capture data or map drives, etc....