Section 2.3. Pre-Installation Configuration Decisions

2.3. Pre-Installation Configuration Decisions

Setting the design and getting the hardware up and configured are just the first steps. More preparation must be done before installing MOM 2005:

Planning out the user accounts, groups, and roles that will be used

Figure 2-2. The MOM 2005 Sizer tool gives you estimates for database size, network load, and minimum hardware suggestions
Calculating the starting sizes for the operations and reporting databases
Preparing the environment and security

During the installation, you will be prompted for specific accounts and starting sizes for the databases. You must have this information before you start. You will not be prompted for other special security requirements, but it will be to your advantage to configure certain security options before installing some components, such as the Web and Reporting consoles. Otherwise, you'll have to redo your work.

2.3.1. User Accounts, Groups, and Roles

The MOM 2005 installation prompts you for two accounts, the management server action account and the database access service (DAS) account. These accounts are not the typical service accounts . You have no choice regarding what user account the MOMService (named momservice.exe in the computer management (MMC) services node) logs on as. For Windows Server 2003, the MOMService runs as the network service account . If you install MOM 2005 on a Windows 2000 server, it will run as the local system account. Since Leaky Faucet has upgraded all of its servers to Windows Server 2003 Standard Edition, only the network service account is covered here. The network service account is a new account in Windows Server 2003. It is a built-in account with limited rights on the local machine and can interact with other systems across the network using the local computer account credentials. For more information on the network service account, see Learning Windows Server 2003 (O'Reilly).

2.3.1.1. Management server action account

In MOM 2005, an agent interacts with the computer that it is on, collecting information from event logs, the registry, and Windows Management Interface (WMI) objects. An agent also runs responses and takes actions on the managed computer based on instructions given to it by management packs. These actions can include running scripts or managed code (e.g., C# or VB.NET).

Any agent may be running more than one action at any given time. To prevent a misbehaving script from impacting the execution of other scripts or the MOMService (the same name is used for this on both management servers and managed computers), the MOMService spawns a new process called MOMHost.exe . This process is responsible for executing performance counter collection, script responses, managed code responses, and batch file responses. If you were to watch the executing processes on an agent-managed computer, you would see multiple instances of MOMHost.exe running from time to time. MOMHost.exe runs in the security context of the computer's configured action account. In the case of a management server, this is called the management server action account and for all other managed computers, it is called the agent action account .

Because agents perform actions on managed computers in the context of the configured action account, this account must have sufficient rights on the local computer to carry out whatever actions are defined in the processing rules that apply to that computer. For example, if the server is a SQL 2000 Server, the agent action account would need to have corresponding rights to interact with SQL objects.

The management server action account has some additional duties. It is used to manage agents on managed computers and can also be used to install and uninstall those agents automatically. In the case of agentless-managed computers, all monitoring is performed by MOMService using the management server action account.

Because the management server action account must interact with machines across the network, it is easiest to use a domain account. Microsoft strongly recommends not using an account with domain administrator rights for the management server action account. A standard domain user account with local administrative rights on the management servers will suffice. If you are going to use fully automated agent deployment, then the management server action account must have full administrative rights on all of the computers that are to be managed. Fortunately, this is not the only way to get an agent installed; you can also provide credentials with administrative rights on the target machines at the time of agent installation. These credentials are disposed of after the agent has been successfully installed. See Chapter 3 for more details.

2.3.1.2. DAS account

The DAS account proxies all communication with the operations database for MOM. The MOMservice.exe and the Operator, Administrator, and Web consoles interact with it to query, insert, modify, and delete data in the database. The DAS is a COM+ application and, as such, requires an identity to provide a security context when communicating with the database. This is the role of the DAS account. It is assigned the db_owner role on the operations database and is a SQL Server login with Permit server access. The Reporting Server can use the DAS account for accessing the operations database as well. SQL-stored procedures are also executed using the DAS account.

The DAS account has no duties outside of the management group, so it does not need any elevated rights in the domain. You can either have a low privilege domain account or the network service account with a DAS account. The low privilege domain account is preferable when the management group contains multiple management servers. This gives you one account to manage on the database server and in SQL, rather than the multiple computer accounts that are required with the network service account.

2.3.1.3. Groups and roles

Access to various levels of functionality in MOM 2005 is controlled by membership in local security groups on the management server and on the operations database server. These local groups are created automatically by the setup process, so you won't be prompted for any information to create them. To use MOM 2005 as quickly as possible, prepare your domain-level security groups so they can be added to the local groups as soon as the setup process is complete. This is in line with the best practice of putting users into global groups, putting global groups into local groups, and assigning local groups to permissions on servers. These local groups are:

MOMService group: This group is for accounts that perform internal MOM functions. This group is empty by default on new installations. Remember that the MOMService.exe process runs in the security context of the local system account for Windows 2000 and the network service account for Windows 2003 servers.
MOM administrators group: Members of this group have full access to all functionality in the Administrator, Operator, and Web consoles.
MOM authors group: This group is for individuals who will be working with management packs in the Administrator console. Users in the MOM authors group can also use all the features and functions in the Operator console.
MOM users group: The MOM users group is for first responders to alerts. These people are responsible for acting on the alerts and other information in the Operator console. They view the Operator console through scopes that have been defined by a MOM administrator.
Systems Center Data Warehouse (SCDW) readers group: This group is created on the server where MOM Reporting Services are installed and will be prepopulated with the account designated for use in communication with the operations database . Members of the SCDW readers group view and run reports in the Reporting console.

Create domain-level groups for the MOM administrators, authors, users, and SCDW readers groups and add your users to them. No accounts or groups should be added to the local MOMService group.

Max created a domain user account for both the management server action account and the DAS account. Because the Leaky Faucet AD domain has a domain-wide password expiration policy set, an additional preparatory step must be taken. To keep the passwords on these accounts from expiring, they should be placed in an organizational unit that is configured not to inherit group policy from the domain. Max works with his team to plan domain group membership for the MOM 2005 groups. His team will be placed in the MOM 2005 administrators domain group and the SCDW readers group. The remote site support staff will be in the MOM 2005 Users domain group and the SCDW readers group. The CFO, business unit director, and the rest of the executive staff will be assigned to the SCDW readers group. The MOM 2005 authors group remains empty. When the business unit director launches a new document management application, her staff could have input into the usage and uptime processing rules, so a domain group is created and left empty in anticipation of this need.

2.3.2. MOM 2005 Operations and Reporting Database Planning

Planning the configuration of the operations and reporting databases completely depends on the amount of data that will be moved. A certain predictable volume will flow into the operations database (in SQL the operations database is called OnePoint ; it is covered in Chapter 7) from the agents. After a configurable period of time, the data is copied to the reporting database. After another configurable interval, the data is groomed out of the operations database. The copying and grooming schedules must be coordinated so that multiple copy cycles occur before a grooming cycle deletes the data.

So, the two databases handle the exact same data, just at different times and for different purposes. The focus of the operations database is current information, the "What is going on in my environment right now" information. The reporting database takes the same information and keeps it because it is no longer relevant to what is going on right now. It provides the answers to the "What happened when..." type of questions.

The operations database needs to be relatively small to quickly move current information. The database can be between 300 MB and 30 GB, but you cannot use all of that40 percent must be kept free. The free space is used by the SQL stored procedures that ship with MOM 2005 (grooming and reindexing) as working space. This leaves you with actual usable space of 180 MB to 18 GB. With this database, you are prompted for a maximum size during setup and the database is configured not to allow growth after that. You can change the setting to allow growth, but it can very quickly get away from you and you'll be in an unsupportable configuration with very poor performance.

Microsoft does not support reducing the database after it has been createdalthough it is possible.

When the maximum operations database size is set, choose a size that can accept all of the of data that will flow into it without requiring growth, and hold it until it is groomed out. You don't want to set your database to be too large because then you will have slower performance.

The Reporting Server database is a different beast. This database is expected to grow and it can grow quite large. As of this writing, Microsoft has tested the Reporting Server database up to 500 GB. However, you should be concerned with how big it will become in your environment so you can plan for disk space appropriately. You also want the jobs that copy that data from operations to reporting, which are DTS packages, to get all of the data in one copy. If the reporting database size is initially set too small and the "Automatically grow file" increment is not large enough, the reporting database will spend unnecessary time growing itself, which can impact the DTS transfer. By default, the DTS transfer occurs every day at 1:00 a.m. It transfers all of the alert, performance, and event data that is more than five minutes old and is new in the operations database since the last transfer.

The sizing of both databases, the grooming and DTS transfer schedules, and the automatic growth settings all depend on how much data will be flowing into the operations database on a daily basis.

Three types of information flow in and are groomed out of the operations database: alerts, events, and performance data.

An individual alert is about 6,000 bytes in size, but you will see few of these.
Events are about 2,500 bytes for each collected event. They occur moderately frequently.
A single sample of collected performance monitor data is the smallest piece of data, at about 200 bytes, but they occur very frequently.

Leaky Faucet will monitor 50 machines and will install about a dozen management packs. So, the last piece for the calculation is how many of each type of data can be expected each day from each monitored machine. Given that each managed computer will only be running the management packs that are appropriate to it and will be generating different amounts of data, an average of the amount of generated data sent across the machines can be developed.

Microsoft publishes guidelines on how many of each data type is generated per agent-managed computer per day. These guidelines can be found in the MOM 2005 Deployment Planning Guide.

Alerts: Approximately four alerts per managed computer, per day
Events: Approximately 200 events per managed computer, per day
Performance: Approximately seven performance counters per minute

The guidelines, data, and number of machines are the base to create a rough estimate of the amount of data written to the operations database per day. This is summarized in Table 2-1.

Table 2-1. Amount of data collected per day and written to the operations database
Type	Size (bytes)	Number per day	Number of machines	Bytes per day	MB per day
Alerts	6,000	4 per machine	50	1,200,000	1.1
Events	2,500	200 per machine	50	25,000,000	24
Performance	200	10,000 per machine	50	100,000,000	95

About 120 MB of data per day will be written to the operations database. Now, since the operations database must have 40 percent of free space for the SQL reindex to complete successfully, multiply 120 MB by 1.4 to yield the minimum size of the operations database that keeps collected data for only one day, which is 168 MB.

Since the minimum size for the operations database is 300 MB, Leaky Faucet can keep about two days' worth of data online just by accepting the minimums. Because so little data is coming in, Leaky Faucet can easily increase data retention to a total of 12 days and create a 2-GB operations database. The operations database transaction logs are automatically created to be 20 percent of the database size, so in this case the transaction logs are about 200 MB.

The reporting database stores the data differently than the operations databaseit includes more indexes, which allows faster searching during reporting operations. So, to store the same data in the reporting database, about twice as much space is consumed than in the operations database. The 120 MB per day into the operations database turns in about 240 MB per day in the reporting database. At this rate, it will take about 100 days to accumulate about 24 GB of data in the reporting database. This gives Leaky Faucet the amount needed to size the disk for the reporting database.

In addition, the DTS transfer uses the tempdb database on the SQL Server, which requires about 200 MB space. The DTS transfer also involves the reporting database transaction logfiles, which requires space equal to about five to six times the amount of data that is being transferredroughly 600 MB (120x5, plus some) for the transaction logs. During the reporting setup, the reporting database size is increased to 2 GB and the transaction log size is set to 500 MB. After setup is complete, the reporting database is configured (its name in SQL Server is SystemsCenterReporting) to grow in 200-MB increments.

Max chooses to make the operations database 2,048 MB. Setup automatically sets the transaction log size to 410 MB or 20 percent of the operations database size. After MOM 2005 is set up and running, Max will change the default grooming values to 12 days. See Chapter 7 for more details on database configuration.

2.3.3. Security and Other Configuration Considerations

With the planning finished, there are a few more details to confirm before moving on to the installation. Specifically, decisions about security and remote operations need to be made.

2.3.3.1. Secure reports

The Leaky Faucet CFO requires secure access for the executive-level reports. This is a two-fold request: the reports cannot be accessible to the public and they must be viewed over a secure channel. Because the reporting console is strictly web-based, the MOM 2005 Reporting web site can be SSL-secured and accessed over port 443 using the HTTPS protocol. For ease of installation, the IIS server should be SSL secured prior to the installation of MOM 2005 Reporting. This is done by obtaining and applying an SSL certificate to the IIS server.

Access to reports is restricted by setting the appropriate permissions on the folders that contain the reports or on the reports themselves in the Reporting console. To meet the second part of the CFO's requirement, a new folder will be created on the MOM 2005 Reporting web site to hold the sensitive reports. Group permissions will be applied to the folder, thereby restricting access (see Chapter 8).

2.3.3.2. Remote Web console

At Leaky Faucet, the remote site support administrators require easy access to the information on the machines that they help manage. There aren't enough managed computers at these locations to warrant a remote management server or additional management groups (see Figure 2-1). Leaky Faucet has chosen to make the MOM 2005 Web console available to the remote site support administrators. The IIS server that hosts the web site will be located at the central headquarters, with a firewall between that location and all remote sites.

The Web console uses port 1272, so the Leaky Faucet administrator, Max, must ensure that port is open on the Internet Security and Acceleration Server (ISA) firewall. If further security was needed, Max could make the Web console web site available via application publishing in ISA.

To filter the machines for the remote site support administrators, Operator console scopes are configured in the Administrator console (see the "Console Scopes" section in Chapter 6). This is the association of AD user accounts groups with MOM 2005 computer groups. This scope is applied in both the Operator console and the Web console.

2.3.3.3. Remote agent installation and agent management

Leaky Faucet must manage two types of agents: agents inside the remote site and internet firewalls, and the agents outside of the firewalls. The steps for installing both types of agents are covered in Chapter 3.

Installing and managing an agent across a firewall is only slightly more complicated and requires two additional preparatory steps in the Leaky Faucet environment:

Ensure port 1272 is open for the Web console users, and open port 1270, TCP, and UDP on both sets of firewalls. All agent-to-management server communication occurs over port 1270 and is encrypted.
Develop a plan to manually install the agents on the remote machines and protect the management servers from rogue agent installations.

In addition to these two steps, there are some management group-wide security and agent management settings that must be planned for. There is no prompt to configure these settings during setup. Most of these settings can be overridden at the individual agent or management server level later on, but some cannot. The following settings cannot be overridden but are relevant to Leaky Faucet's requirements:

Mutual authentication: In a MOM 2005 management group, agents and management servers can be required to authenticate each other before data and configuration information is exchanged. This is a Kerberos v5 authentication and serves the same purpose in MOM as it does in ADit blocks against man-in-the-middle attacks. This provides additional security for the operations data, which is in line with the CFO's interests.
Reject new manual agent installations: The MOM 2005 agent is a Windows installer-based .msi package. As such, the MOM 2005 agent can be manually installed on any computer simply by launching the .msi package. During the installation process, the installer prompts for a management server or group to connect to. If no controls exist at the management group level, anyone with access to the agent .msi could add any computer to any management group. When enabled, this setting automatically rejects all new requests from manually installed agents to join the management group.
Communications ports: By default, the management server and agents communicate over port 1270. This communication is encrypted for security. This port can be changed, but to allow managed computer failover between management servers, all management servers and agents must use the same port.