Automating the Build Process for New Workstations and Servers

Building new workstations and servers often involve repetitive tasks that traditionally involve a checklist and an engineer’s significant time to complete. It’s a task many MSPs do manually. Fortunately, for users of the Datto Remote Monitoring and Management (RMM) solution, most of the process can be automated using the initial audit or on connect job scheduler.

Let’s look at how to set up this type of automation.

Starting the Build Process for New Workstations and Servers

Below is an example checklist of items for a new build process:

• Remove toolbars and 3rd party software
• Disable the guest account
• Create a new MSP local admin account
• Install Java, Shockwave, Adobe Reader, Chrome
• Enable bitlocker and encrypt the drive – be sure to take note of the recovery key
• Make a note of the Windows license key
• Install all available Windows updates

However, there are certain things that you don’t want to do if the new device is a server, for example.

Workstations only:

• Remove toolbars and 3rd party software
• Install Java, Flash, Shockwave, Adobe Reader, Chrome
• Enable bitlocker and encrypt the drive – taking note of the recovery key

Both servers and workstations:

• Disable the guest account
• Create a new MSP local admin account
• Make a note of the Windows license key
• Install all available Windows updates

The Script: Next Steps

Next, we can use some PowerShell code in our new build component. This will help us determine the operating system type—that information will dictate the next steps the script will take.

Let’s determine if we are executing on a server or workstation using PowerShell.

$osInfo = Get-WmiObject -Class Win32_OperatingSystem

We can now extract the product type out of the Product Type object:

$osInfo.ProductType

Workstation (1)

Domain Controller (2)

Server (3)

The next step is to make the return value from our query useful. To do this, we need to evaluate the variable $osInfo.ProductType with an IF statement.

There are two operators we can use with the IF statement

-eq Equals

-ne Not Equal

Determine if the script is running on a workstation operating system

if ($osInfo.ProductType -eq 1){

write-host Workstation OS Detected

}

Determine if the script is not running on a workstation operating system

if ($osInfo.ProductType -ne 1){

write-host Server OS Detected

}

If we wanted to, we could further define what type of server the script is running on (Domain Controller or member server) by testing for a return value of 2 or 3 as detailed above.

Using ELSE in your IF statement

To simplify the PowerShell code we could use ELSE in our IF statement rather than testing for each Operating System type in turn. For example, if the script is not running on a Server Operating System, it must therefore be running on a Workstation Operating system.

if ($osInfo.ProductType -ne 1){

write-host Server OS Detected

}

else {

write-host Workstation OS Detected

}

Now that we can determine what OS type the script is executing against, we can start to perform the automated actions…

if ($osInfo.ProductType -eq 1){

write-host Workstation OS Detected

<insert your custom PowerShell code here>

}

The next thing to do is run this automatically against all new devices that join a site. Have you been using the platform for a while? If so, you will likely have sites with existing agents that you don’t want to execute your new computer prep script against.

To do this, you could create a new site called “Workshop” and use this as the staging area for all new builds, moving the devices to their correct site once the build process is complete. Note: Remember to disable all the monitoring policies for the new “Workshop” site and ensure it does not sync to any external applications!

Download the agent installer for the new “Workshop” site and use this for all new devices you are building. This ensures all the new devices first join the “Workshop” site.

Select the new ”Workshop” site and then click the “Scheduled Job” icon.

Name the job and click the “Schedule” button.

For our purposes, it doesn’t matter if you chose the “On Connect” or “Initial Audit” option. This is because we are using PowerShell to control what parts of the script are executed against which type of Operating System. We are only using one of these options as a trigger to detect that a new device has been added.

Add your new custom machine prep component.

Ensure that you set the job never to expire – we want to ensure it executes when the device is available.

Lastly, set the notification options if you want to be informed if the machine prep script fails to execute.

Once the machine prep component has been completed, you can move the device from the “Workshop” site to the proper customer site.