Some time ago I posted with respect to creating a facility for automating the MOM service account password change process. I did indeed complete the program, which can be summarized as follows:
- Expose a UI for collecting the Configuration Group and credential information, for starting the update process, and for notifying the user of progress through the various steps.
- Stop the MOM service on all management servers using the following .NET classes:
- System.ServiceProcess.ServiceController
- System.ServiceProcess.ServiceControllerStatus
- Shut down the DAS COM+ application using the following COM+ interface:
- COMAdmin.COMAdminCatalog
- Change the DAS identity using the following COM+ interfaces:
- COMAdmin.COMAdminCatalog
- COMAdmin.COMAdminCatalogObject
- Change MOM action account, using the following .NET class to exec an updated version of SetActionAccount* that allows for providing the password as a command line parameter:
- System.Diagnostics.Process
- Restart MOM (DAS is restarted automatically with it) using the following .NET classes:
- System.ServiceProcess.ServiceController
- System.ServiceProcess.ServiceControllerStatus
Along the way, however, I encountered a number of roadblocks that made this process impractical, the most significant of which was a COM+ behavior that results in the current credentials being cached beyond the application shut down. This results in having to reboot all of the management servers anyway, one of the key things I was trying to eliminate as part of this new process.
In the end, the best workaround I came across is documented (though not with respect to this issue specifically) in the MOM 2005 Security Guide, the URL for which and the key section from which are appended at the end of this post. It is important to note that this workaround only works on Windows Server 2003, since only it to date supports the use of the Network Service account. Also of particular note related to the guide’s instructions are:
- Creating the SQL server login with the indicated database access results in the new database user being created for the OnePoint database, so you can skip the new database user step.
- By “computer name” the guide is referring to each management server in your configuration group(s). You must add a login for each management server for this to work properly.
- A reminder is provided in the guide, but I will add it again here as a key to avoiding possibly confusing SQL errors: Remember to add the “$” symbol to the end of the computer name for each login, i.e. domain\mgtserver1$.
By following the steps outlined in the appended section of the security guide with the above notes in mind, you can simply automate through batch file or script the stopping and restarting of the MOM service and the use of SetActionAccount to reset the MOM action account credentials on the management servers; no reboot required. You also no longer have to worry about the DAS application, since it is running within the Network Service context.
At least one other large IT group here at Microsoft beside ours is operating MOM 2005 this way, so far without any known problems.
Kent
* The new version of of SetActionAccount I refer to herein is available currently as a hotfix, which you can obtain by contacting Microsoft Product Support Services, or as part of MOM 2005 Service Pack 1 due out later this year.
Microsoft Operations Manager 2005 Security Guide (Partial)
Link to the complete document:
http://www.microsoft.com/technet/prodtechnol/mom/mom2005/secguide10.mspx
To use Network Service for DAS
This process requires procedures to be done on both the MOM Database Server and then the MOM Management Server.
Important
You can only do this if the Management Server is running on Windows Server 2003. Windows 2000 does not support the Network Service account.
On the MOM Database Server:
1. On the MOM Database Server, verify that the MSSQLSvc Service Principal Name is registered by using “setspn.exe -L <SQL Server FQDN>" at the command line, where <SQL Server FQDN> is the Fully-Qualified Domain Name of the MOM Database Server Instance.
2. In SQL Server Enterprise Manager, expand the OnePoint folder.
3. Add a new database user by right-clicking on the Users sub-node of the OnePoint database folder and selecting New Database User.
4. In the Database Users - New User dialog, enter the computer name in the Login name text box. Computer names follow the format domain\computername$. Do not forget the trailing “$”.
5. Grant this computer account user the db_owner database role membership and click OK.
6. Navigate to the Security folder for the SQL Server instance.
7. Add a new SQL Server Login by right-clicking on the Logins folder and selecting New Login.
8. On the General tab of the SQL Server Properties - New Login dialog, enter the computer name in the Name textbox. Computer names follow the format domain\computername$. Do not forget the trailing “$”.
9. On the Database Access tab, grant this computer account db_owner access to the OnePoint database by selecting the Permit checkbox next to the OnePoint database and then the db_owner checkbox below.
10. Click OK.
On the Management Server
1. On the Management Server, stop the MOM Service.
2. In the Component Services snap-in, expand Component Services / Computers / My Computer / COM+ Applications.
3. Right-click the Microsoft Operations Manager Data Access Server node and click Shut down.
4. After the application has stopped, open its properties.
5. On the Identity tab, select the System Account and the Network Service options, and then click OK.
6. Start the MOM Service.
7. After the MOM Service has started, open the MOM Administrator console and confirm that you do not see any DAS errors.
