I’m not going to go into all the boring technical details, but today I faced an immediate need to change a particular local account password across hundreds of machines, ASAP. For all the computers still in our old management system, that was easy (albeit tedious) since I’ve already built the rigging for that, years ago.

In the new system, though? The one we’ve only started migrating clients to in the last few weeks? I had nothing.

By pure luck, however, earlier in the morning I’d found a way to use Conditions in Policies to trigger scripted actions on a faster timetable than the “once per day at a precise time” scheduling option otherwise available. Handy! Thus I incorporated the technique into the password-change system. The flow goes something like this:

1. Create a new Custom Field, single line of text, to be populated by the password change script once the needed steps are completed. Value will be in ‘YYYYMMDD’ format, so 20241108 for today’s event.
2. Create the script that does the thing. Test it. Test it some more. Fix the things that turn out to be wrong once you put it into production. Hmm, wait, I’m getting ahead of myself. Anyway.
3. Go into the Policy for the type of system (Windows Workstation, for instance) that you need to do this for. Add a Condition, which is the mechanism for triggering an alert state. Set it to see if the new Custom Field value is not set to the current day’s event value, and if the condition “triggers” then have it run the script.

And weirdly enough, that’s all there is to it. For future events all I have to do is edit the script to change the local account password and update the Custom Field with a new event value, then set the Policy’s Condition to look for that event value. As machines check in online and “trigger” the Condition, the script will run. Fully automated.

This is the fun part of my job. Mind you, having to do it under high-pressure conditions in a hurry took a lot out of me today, but… I did get it done.

It shouldn’t have been this difficult.