Distributed Automation using Native Tools and Scripts

For this post, we’ll focus on automation with Windows hosts. Specifically, I’ll be covering a framework that I use to deploy automation to Domain Controllers that can help solve a common problem in Disaster Recovery scenarios. For now, we’ll just call this the DAUNTS framework. For the last few years, I’ve spent quite a bit of time working in the AD Disaster Recovery space, primarily teaching DR techniques for AD, DNS, Group Policy, and other infrastructure. A major gap in many environments is completion of prerequisite steps prior to a disaster that would make recovery significantly more manageable. After writing a number of scripts to help with this problem, I still needed a better deployment mechanism…which eventually culminated into this technique. Note that while I’m writing about this with regards to Disaster Recovery, you’ll see that it can be used with any domain-joined Windows host for many other use cases.

Quick plug: If your organization is a Premier customer, I would strongly recommend talking to your TAM about an Active Directory Recovery Execution Service (ADRES).

Task Scheduler, Group Policy, and scripts. Better. Together.

There are a number of criteria to consider when implementing an automation strategy, such as:

  1. Cost: Minimize the cost of the solution to enable the greatest adoption
  2. Privileged account requirements: Reduce the privileges required and storage of credentials on computers where the automation is implemented
  3. Ease of management: Reduce the number of new tools needed to implement the solution. Ideally, we’d use tools that we already own.

Since I’m a huge fan of using built-in tools in novel ways to solve existing problems, we will be using tools you are probably already familiar with: Group Policy, Task Scheduler, and scripts.

At a high level, we’re going to create a Group Policy Object to deploy a Scheduled Task running in the context of SYSTEM that calls a Script embedded inside the GPO. This will remove the need to create a privileged service account, cleanup old scripts, or purchase a new product…all while using tools you can already access or create.

Do it!

For a a specific problem to solve, take a look at my previous article on Bootstrap Recovery of DNS. In that post, I specifically mention the need to implement DNS zone backups in a scalable way that enables many or all Domain Controllers to be effective DNS DR solutions. I use custom scripting implemented with this approach to solve the DNS backup problem.

Now that I’ve talked through the what and why, let’s jump into the how.

  1. Pick a script that you’d like to deploy to your Domain Controllers.
    • In this example, I will be deploying a DNS backup script written in PowerShell.
    • DCAuto_1_PickScript
  2. In the Group Policy Management Console, create a new GPO
    • In my example it’s named [DC] ScheduledTask – BackupDNS – Daily
    • DCAuto_2_CreateGPO
    • DCAuto_2b_NameGPO
  3. Select the GPO
    • In the Security Filtering section, remove Authenticated Users
    • Add one of your Domain Controllers (to test against a single DC)
    • DCAuto_3_TestSecurity
  4. Edit the new GPO and navigate to Computer Configuration>Policies>Windows Settings>Scripts and double-click Startup
    • DCAuto_4_StartupScripts
  5. At the Startup Properties screen, click Show Files…
    • DCAuto_5_ScriptsShowFiles
  6. In the new Explorer window:
    • Copy your script to the GPO script location.
    • DCAuto_6a_CopyScript
    • Copy the UNC path to the script. You’ll need this later. (Ex: \\contoso.com\Sysvol\contoso.com\Policies\{86B97D4A-C08C-486F-BEBB-51AB17BE6721}\Machine\Scripts\Startup)
    • DCAuto_6b_CopyUNC
    • Important: The UNC path will be different in your environment. Both references to the domain and the GUID of the GPO’s sysvol folder will be specific to your environment.
  7. Navigate to Computer Configuration>Preferences>Control Panel Settings>Scheduled Tasks
    1. DCAuto_7_Tasks
  8. Right-click Scheduled Tasks and select New > Scheduled Task (At least Windows 7)
    • DCAuto_8_NewTask
  9. At the General tab, configure with:
    • Name (My Preference is to use the same name as the GPO)
    • Click Change User or Group, enter System, and click OK.
    • Select Run only when user is logged on
      • Note, this is a unique function of using System. It will change to Run whether user is logged on or not when deployed.
    • DCAuto_9_GeneralTab
  10. At the Triggers tab:
    • Click New…
    • Select an interval (ex: on Sunday / Wednesday for DNS)
    • Check Delay task for up to (random delay) if you want to add a task delay. Please see below for more details on this.
    • Check Stop task if it runs longer than and enter 30 minutes
    • DCAuto_10a_TriggersTab
      • IMPORTANT: If you intend to set a Delay task value, you should generally pick a number less than the GPO Refresh interval on the computer that will receive the task. Depending on the delay value and the GPO refresh interval, the task may effectively never (or rarely) run. As an example:
        • A Domain Controller will refresh group policy every 5 minutes.
        • A scheduled task is deployed for 7:00am every morning.
        • The randomized delay is set to 8 hours.
        • The DC has the next run time set for 9:45am.
        • At 9:30am background refresh of GPO runs and resets the next run time to 7:00am + 2 hours (9:00am).
        • Since 9:00am has already past, the next run time is incremented to the next day/week/whatever and doesn’t runs today.
        • In this scenario, the task will rarely run because the delay offset is reset every 5 minutes to a random time from 7:00am to 3:00pm.
        • An important note, is that even setting the randomization to 1 minute may cause it to occasionally fail to run on a particular day if the background GP Refresh just happens to run in the 60 second window between original start time and offset and resets it to a value within the first 60 seconds of the window.
      • What to do
        • Option 1: Set the delay interval to None and use another approach to randomize. Examples:
          • Add a randomized delay to the script execution.
          • Create different tasks actions for separate groups of computers (by OU, by AD Site, by AD Group, etc)
        • Option 2: Set the delay lower than the GP Refresh interval. Again, note that systems will still not consistently run the task and the closer you set the task delay to the GPO background refresh intervals, the greater chance of failure.
          • None, 30 seconds, 1 minute, 30 minutes, and 1 hour all work consistently on clients / member servers.
          • None, 30 seconds, and 1 minute work consistently on Domain Controllers.
          • In both cases, the higher the delay, the lower the consistency.
        • Option 2a: In addition to the lower delay value, repeat the task more frequently. For example, instead of running the task every Friday, run the task every Monday/Wednesday/Friday and add logic to the script to prevent running more frequently than 1/week.
        • Option 3: Leave the longer refresh interval, repeat the task more frequently, and understand that many systems will not execute on any particular run.
        • Option 4: Add a Startup task in addition to the Schedule Task. You may also delay the startup task.
      • DCAuto_10_TriggersTab
  11. At the Actions tab
    • Click New…
    • If PowerShell:
      • Program: powershell.exe
      • Add arguments: -ExecutionPolicy Bypass -File “<UNC Path to PS1 file>”
        • Note: If you perform code signing, sign any PS1 script and don’t use the ExecutionPolicy bypass switch. Ideally, all scripts would be signed and PowerShell configured to require signed scripts.
    • If cmd:
      • Program: cmd.exe
      • /c “”
    • The UNC path should include the script filename at the end. In this example: \\contoso.com\SysVvol\contoso.com\Policies\{86B97D4A-C08C-486F-BEBB-51AB17BE6721}\Machine\Scripts\Startup\backup-dns-zones_v7.1.ps1″
    • DCAuto_11_ActionsTab
  12. At the Settings tab
    • Check Allow the task to be run on demand
    • Set Stop the task if it runs longer than: 30 minutes
    • DCAuto_12_SettingTab
  13. At the Common tab
    • Check Remove this item when it is no longer applied.
    • Click OK to close the GPP editor and then close the Group Policy Management Editor
    • DCAuto_13_CommonTab
  14. Verify new Scheduled Task on the test Domain Controller:
    • On the Domain Controller, open Task Scheduler
    • After AD / SYSVOL convergence has completed (which will vary depending on your environment), run gpupdate /force
    • Refresh Task Scheduler and verify that the new Scheduled Task is now available in the Task Schedule Library folder.
    • DCAuto_14c_TaskPresent
    • Right-click the Task and select Run.
    • DCAuto_14d_RunTask
    • Confirm the task ends with ‘The operation completed successfully’ and whatever action the script was designed to take did in fact completed.
    • DCAuto_14e_TaskSuccess
  15. Fix GPO permissions:
    • Assuming all goes well, select the GPO in the GPMC
    • Add Domain Controllers to the Security Filter.
    • Remove the references to the specific test DC.
    • DCAuto_15_FixSecurityFilter
  16. Verify the Task is successfully deployed to at least one other DC.
  17. NOTE: If you’ve created a script that should only run from a single Domain Controller, I prefer using the method mention in this post to create a WMI filter for the PDC role holder and WMI filter the GPO to that DC.

That’s it!

Now you just need some good example scripts that work with this deployment model. I’ll update this post with examples as I publish them.



Directory Service Restore Mode password automation

DSRM Password Sync by Task

GPO Backup by Distributed Automation Task


Posted in Active Directory, Group Policy, Scripting
4 comments on “Distributed Automation using Native Tools and Scripts
  1. […] a previous post (here), I wrote about an automation framework to deploy scripts using GPP Scheduled Tasks to Domain […]

  2. […] a previous post (here), I wrote about an automation framework to deploy scripts using GPP Scheduled Tasks to Domain […]

  3. […] Take a look at my other post on Deploying Scheduled Task drive PowerShell scripts via Group Policy Preferences: Distributed Automation using Native Tools and Scripts […]

  4. […] model. This is intended for deployment using the Distributed Automation approach mentioned  in this post…with one notable exception. My preference is to use the same approach to filter this to only […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: