5

Is it best practice to store logon scripts centrally in \\DOMAIN\Netlogon or in the policy folder they get put in by default, eg. \\DOMAIN\SysVol\DOMAIN\Policies\{DE22B6FB-315E-4C55-BF06-A7709913CD9E}\User\Scripts\Logon?

What are the implications (if any) of choosing one location over the other?

I'm inclined to just keep them all in Netlogon for ease of access /review...

8

The default location for user logon scripts is the NETLOGON share, which, by default, is replicated on all DC in your forest, and is physically located in:

%SystemRoot%\SYSVOL\sysvol\<domain DNS name>\scripts.

or

%SystemRoot%\SYSVOL_DFSR\sysvol\<domain DNS name>\scripts (for DFS-Based FRS since this is recommended from Server 2012R2+)

If you set a user logon script (ADUC > User > Properties > Logon > Logon-Script > hello.cmd), it is executed from NETLOGON.

"Official" best practice is:

  • store them along with the GPO, if you set it through GPO.
  • store them in NETLOGON, if you set it as a user property in AD.
1
  • 1
    I approve of this technique. The advantage is – as yagmoth555 already wrote – that scripts managed with a GPO are deleted if the GPO is retired (read: deleted).
    – Daniel
    Apr 28 '16 at 14:58
3

Both location are sync'ed between domain controller, thus for me it's only a personal's choice.

My personal's opinion is that after over a certain numbers of GPO, having all in netlogon can be hard to manage. (as when you delete a GPO, the script would not be erased in example)

1

Not sure is this is "best practice", but I have seen a few blog post recommend this, and I prefer it:

We have a file share that contains all the supporting files for our GPOs, including scripts. The scripts are all checked into version control.

The file share is setup with DFS, so it is \domain.com\DFS\GPO-Files

The scripts are in a subdir \domain.com\DFS\GPO-Files\Scripts

In the GPO, you call the script "powershell.exe" and for the parameters you do -File PathToScript.

I like this approach because the GPO files and scripts are in a well known location, not buried in a folder with a GUID name.

It also allows more control over how powershell.exe is invoked, like ExecutionPolicy.

3
  • 1
    How is that different to storing them in netlogon, aside from the extra management overhead you've created? Apr 29 '16 at 12:14
  • 1
    @bluecompute It's decoupled from the domain controller. I have more flexibility on permissions. I don't have to care about how big it gets, potentially filling up the C drive of my domain controllers. Also, the file share in question can be a central script repository and contain things that are not "netlogon" related. Apr 29 '16 at 12:26
  • I like this approach as making changes to the scripts are easier and don't rely on having to open the GPO or the GUID path to make such changes. If you disable or remove a GPO that points to one, it's not a big deal for me either. These script are usually small anyway and are only used when other non-script GPO/GPP settings are not robust enough to handle whatever it may be. I also think having scripts buried in policies makes it harder to troubleshoot when there are issues with policies (inherited ones in particular someone else built). If you comment your scripts, you can put GPO names, etc. Oct 9 '20 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.