An approach to automate SCOM service account password change – part 1/3: background and process

  • Article

Changing SCOM Service account passwords can be challenging and complex. MVP Marnix Wolf has written an excellent blog post about all necessary steps we have to take to change passwords in all the different locations like AD, Windows OS (Service), RunAs accounts, SQL Reporting configuration etc.

But as SCOM is a powerful and mighty tool in the heart of your datacenter it is recommended to change all SCOM service accounts frequently according to your corporate policies to increase the overall security.

There is no official way to automate all these steps. I have recently been tasked by a customer to do just that. So I took a deep look and scripted a bit.
This three part blog post is about sharing my experiences gathered and a demo proof of concept:

  • Part 1: describes the overall process and the terms and scope of an automation solution
  • Part 2: describes the necessary prerequisites and steps to take
  • Part 3: demonstrates the proof of concept

So, let’s get started and set the stage:

The process

As Marnix truly mentioned, we need a formal process which describes all necessary steps and responsibilities. This is my currently recommended process:


Caution and attention

Automating password changes in a complex and distributed environment is a dangerous task. If something goes wrong, you definitively interrupt SCOM service availability.
To minimize the risk you have to

  • verify the requirements (access rights, connectivity etc.) upfront as much as possible
  • built in error handling as much as possible
  • log as much as possible
  • and most important: set the scope of automation.
    You will probably never create a general “one size fits it all” solution for all available SCOM environments. So focus on your own environment!

Terms and scope of automation

When you look at the process above you will probably immediately understand the challenges of automating all that stuff:

  • We have to touch several technologies (SCOM, AD, SRS, IIS, Windows OS)
  • We have to deal with different product versions (SQL 20008 – 2014 e.g.)
  • We have to handle different configurations (local System vs. Domain Accounts e.g.)

Considering all this different environmental settings automation can be a nightmare. So before I started I set some terms for my automation solution:

  • SCOM is installed according to our best practices. That means
    • We use dedicated, single purpose domain accounts for SDK/Action/DW Reader and DW Writer accounts
    • No local system account will be used
    • SCOM installation has been performed according to our deployment guide
  • I focus on the most common product Version combination to day: SCOM 2012 R2 running on Windows 2012 R2 and using SQL 2012

See part two about the detailed requirements and the individual steps to take...