Or at least not entirely useless

I recently tried to implement Server Group Patching to patch a group of servers in a particular order and failed because that apparently does not work. Before I got there though I needed to set up some node scripts. In this instance we needed to tell Exchange to use another node in the database availability group (DAG) so that we could patch and reboot the current server. That seems like the exact kind of thing the node scripts were designed for. However, we came up against a couple of issues that I discuss below.

Node Script Permissions

The node scripts will run under the local system account. My Exchange admins were uncomfortable granting the local systems access to administrate Exchange so they created a task in Task Scheduler to run under a service account. From there I could use the node drain scripts to initiate those tasks. When creating a node script remember to take in account that currently your only option is to run the script under the device’s local system account.

Node Script Length

When creating a node script you are limited to 512 characters. That’s right, you are supposed to create a node drain script in less space than you get to tweet four times. It took a few iterations but eventually I came up with the script below. It will run the named Scheduled Task, wait until it finishes, and then exit with the result code.

Is There a Better Way?

While the above issues can be worked around it feels out of place given that the feature is named and designed to drain and fill cluster nodes. It seems impossible to drain a cluster node in a safe way with 512 characters. With the new ‘Run Powershell Script’ feature introduced in Current Branch 1706 I think the way forward is clear … integrate the two features. Add in a run-as component and the peasants will rejoice. If you feel the same, be sure to say as much on UserVoice: Implement native cluster aware patching within SCCM to support cluster aware updating.

Bryan, in an effort to get around the 512 char limit… Do you know if you can save a longer powershell function as a .psm1 file, and just call it with an import-module c:\somefolder\somefile.psm1. This way you could pass bits of information to the module.