Freigeben über

An approach to automate SCOM service account password change – part 2/3: prerequisites and execution steps

  • Artikel

This is part two of my little blog series about how to change SCOM service accounts. In part one I talked about the challenges and the overall process. This part explains the necessary prerequisites and steps to perform the automated password change.

Prerequisites

So what prerequisites do we need and why?

Software (on a workstation where we want to run the script)

  • PowerShell >= 3
    Reason: Obviously my preferred scripting tool 
  • SCOM 2012 R2 Console installed
    Reason: for obvious SCOM access
  • AD PowerShell Module installed
    Reason: to get AD accounts and reset there password

Connectivity (between the workstation and all other components)

  • WMI access to all SCOM role machines
    Reason: I use WMI for service account password changes. Yes, I know we could do this only by using WinRM…
  • WinRM access to all SCOM role machines
    Reason: I am using WinRM to perform most of the remote tasks
  • SCOM SDK connectivity to a Management Server (preferably RMS emulator)
    Reason: for obvious SCOM access
  • AD PowerShell connectivity to a Domain Controller with AD WebService installed (TCP Port 9389)
    Reason: obvious AD access

Access rights

  • User right on the workstation executing the script
  • Local admin right on all SCOM role machine where we need to change service account password
    Reason: only possible with local admin rights
  • SCOM admin role membership
    Reason: only admins can change RunAs account passwords
  • Local admin right on SRS server to change service account password
    Reason: only possible with local admin rights
  • Local admin right on Web console server
    Reason: to check IIS application pool configuration
  • Manage account right on all service accounts in AD
    Reason: to change account passwords

Steps to perform

These are the steps I will perform in my script. I have included some hints, pitfalls and used commands, methods or classes for your reference, because finding the right methods was the most cumbersome part of the project...

1. Test and verify the environment

  • Are all required PowerShell modules available?
  • Can I connect to SCOM and am I member of SCOM admin role?
  • Can I create a WinRM session to all required machines?
  • Can I create a WMI session to all required machines?
  • Can I detect and access the SRS server via WMI root\Microsoft\SqlServer\ReportServer\RS_MSSQLServer\v11\Admin and class MSReportServer_ConfigurationSetting?
  • [optional] Create a backup of SRS encryption key (Method backupencryptionkey ) for safety reasons
  • Test successful password creation with [System.Web.Security.Membership]::GeneratePassword

2. Collect account information

  • Connect to RMS emulator and collect service accounts using WMI win32_Service class
  • Connect to SCOM MG and collect RunAs accounts with get-scomrunasaccount
  • Create either default or random passwords for each account. This allows you to either set the same password for all accounts or use individual complex passwords.
  • Write all information about accounts and passwords into a custom object collection
  • Present collected account to the executing user and ask for consent
    This is very important as I cannot be 100% sure that my collected accounts are correct. I want to give the user the ability to cancel the process before changing passwords for wrong accounts.

3. Reset AD passwords

  • Process each account in account collection
    • Get User information with get-aduser
    • Reset password with Set-ADAccountPassword
    • Modify account description to reflect automatic change

4. Reset SDK and Config service on all SCOM Management Server

  • For each Management Server
    • [optional] Save OpsMgr event log and clear the log for better error analysis later on by using WinRM and wevtutil epl
    • Reset SDK service password and restart service by using WMI Win32_Service class and methods
    • Reset Config service password and restart service
    • Wait until each service is up and running again

5. Change RunAs accounts

  • Connect to SCOM Management Group
  • Foreach account in (Action, DW reader, DW writer)
    • Reset password by using Update-SCOMRunAsAccount -RunAsCredential
    • Modify account description to reflect automatic change by using .Description property and .update() method of RunAs object

6. Change SRS password

  • Get SRS accounts via WMI (DB connection, unattended execution and service account) using the class mentioned in step 1
  • Only proceed if all three accounts are the same and we do have this account in our account collection
    This check is also for safety reasons. In a standard setup this check should always be sucessful. In a non-standard environment,this check prevents the script from changing only some or even worse - wrong account passwords.
    • Change SRS db connection password by using .SetDatabaseConnection method
    • Change SRS unattended execution account by using .SetUnattendedExecutionAccount method
    • Change SRS service account password by using Win32_Service method
    • Restart SRS service

7. Verify web console settings

  • Check if SCOM uses a web console by collecting information via Get-SCOMWebAddressSetting
    • Connect to web server and get IIS application pool information from default web site using Microsoft.Web.Administration.ServerManager class from Microsoft.Web.Administration
    • Verify, if all SCOM related application pools are using built-in identities or not by translating SID to User name using System.Security.Principal.SecurityIdentifier class
  • Inform the user about the result

8. Finalizing and closing

  • Create a detailed log file with all steps taken
  • Create a detailed PS error log file
  • Create a CSV file with all account Information
    Be careful: This file contains all new passwords in plain text

Ok, after so much text and theory have a look at part three for a demonstration...