IN THIS CHAPTER
Chapter 20, “Security and Delegation in Configuration Manager 2007,” discussed security accounts, groups, requirements, and topics such as how to delegate security rights within Configuration Manager (ConfigMgr) 2007 and secure ConfigMgr. Security is certainly a critical piece of maintaining a healthy and functional environment. Another critical piece of maintaining a healthy and functional system is ensuring its integrity through backup and recovery processes. All production systems should have established backup and recovery procedures in place, and ConfigMgr 2007 is no exception. It is also important to maintain the currency of your data, and ConfigMgr 2007 provides a number of maintenance tasks to help with this. This chapter discusses best practice approaches to backup, recover, and maintain your Configuration Manager environment.
Out-of-the box, ConfigMgr 2007 includes a number of tasks to assist in maintaining your environment. One of these, the Backup ConfigMgr Site Server maintenance task, can greatly simplify the process of backing up your ConfigMgr environment. The next sections discuss backing up and restoring your ConfigMgr database and site.
Site maintenance tasks are located in the ConfigMgr console at Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Site Maintenance -> Tasks.
The “Site Maintenance Tasks” section in this chapter contains information regarding each of these tasks.
The first task in the list, Backup ConfigMgr Site Server (selected in Figure 21.1), defaults as not enabled. The Backup ConfigMgr Site Server task provides an automated method to backup the site including the site database, ConfigMgr files, Registry keys, and system configuration information. Using the Backup ConfigMgr Site Server task is the recommended approach for backups versus using third-party vendor solutions because this is the only supported backup when restoring the ConfigMgr environment using the Configuration Manager Site Repair Wizard.
Perform the following steps to enable the Backup ConfigMgr Site Server task and configure it to backup your site.
- Right-click on the task shown in Figure 21.1 (Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Site Maintenance -> Tasks) and choose Properties.
-
The first option on the Backup ConfigMgr Site Server Properties is to enable the task, which you can check on the top part of the dialog box in Figure 21.2.
After that is checked, click the Set Paths button to define the path to which to back up the site and SQL information. The default configuration is to back up the information to a local drive on the site server, although the Set Paths option allows you to back the information up to a network path.
A commonly used configuration accepts the default backup timeframe to start between 12:00 AM and 5:00 AM and perform the system backup to the local drive on the site server (in this case a c:ackup directory), as shown in Figure 21.2.
- You can configure the schedule for ConfigMgr backups to run more frequently if that is a requirement for your environment.
A successful backup creates the following folders, shown in Figure 21.3:
• <Site Code>Backup. (This is DALBackup for the DAL site in the SCCMUnleashed environment.)
• A subfolder called SiteDBServer (which contains the mdf, ldf, and xml files).
• A SiteServer subfolder, containing:
• SMSServer folder—includes backups of ConfigMgr inboxes, logs, and the files that control the information collected during hardware inventory (configuration.mof and SMS_Def.mof). Also included in the inbox backup is the site control file (Sitectrl.ct0), which contains many of the settings used by the ConfigMgr site.
• ConfigMgrPrereq.log
• ConfigMgrSetup.log
• SMSbkSiteRegNAL.dat
• SMSbkSiteRegSMS.dat
Both of the two log files—ConfigMgrPrereq.log and ConfigMgrSetup.log—backed up during this process are generated during site installation and upgrades.
Note
Troubleshooting ConfigMgr Backups
ConfigMgr uses the Volume Shadow Copy service. Verify this service is not disabled, or your ConfigMgr backup will not run.
A recommended backup approach uses a daily backup timeframe but sends the backup information to a Universal Naming Convention (UNC) path, specifying a location that is not on any of the ConfigMgr server systems. Data backups are daily, with the backup retained for at least one month. Using this approach minimizes the risk that if the site server’s drive fails, it would cause the loss of all information for ConfigMgr including the backup copy of the information. Performing this task on a daily basis minimizes the amount of information lost in comparison to restoring from a backup that might have occurred a week earlier.
Tip
Protecting Yourself Further with Backups
The default approach of backing up to a local drive (shown in Figure 21.2) is commonly used as a quick way to back up ConfigMgr information. However, this provides little benefit by itself because the backed up information resides on the same drives as the site server. To augment this approach, schedule a weekly backup to back up the information stored on the local site server into an offsite rotation using a backup product such as System Center Data Protection Manager (DPM) or third-party backup solutions.
You also need to back up the files required to restore the operating system on the site server in case of a full operating system (OS) crash. Using DPM or third-party products to provide a full backup of the OS is critical for system restores in the case where the operating system no longer functions. Performing monthly operating system backups is recommended for all ConfigMgr site server systems.
With your ConfigMgr information backed up, let’s discuss the process of restoring it. There are two common scenarios where recovering ConfigMgr might be required:
The next sections discuss these situations.
If a server operating system crashes, the first step is to restore the server from a backup. The “Backing Up ConfigMgr” section in this chapter discussed the requirement to back up the operating system on a monthly basis. After installing the OS, the process can then continue through the steps required to restore from a ConfigMgr functional crash.
In the situation where ConfigMgr is no longer functional (or the site server operating system is no longer functional as discussed in the “Site Server Operating System Crash” section), you can use the Configuration Manager Site Repair Wizard to recover your ConfigMgr environment. This wizard is installed on the site server and all computers with the ConfigMgr console and is available by navigating to Start -> Programs -> Microsoft System Center -> Configuration Manager 2007 -> ConfigMgr Site Repair Wizard. Perform the following steps:
- Launch the wizard, which by default runs recovery on the same site server as the wizard. The example displayed in Figure 21.4 shows repairing (recovering) the Wildflower server.
-
On the next screen, tell the wizard the location of the backup files it needs to use for the site restore. You can also choose to repair or reconfigure a site and specify whether to restore the database when performing a site restore. This example performs a simple restore of files stored to a local hard drive in the c:ackup directory, as shown in Figure 21.5. In this case, the database backup is not restored, so leave the Do not restore database check box in the default configuration, which is unchecked.
The other option available on this screen provides a way to either repair or reconfigure an existing site and do so without creating a new site and without restoring database files from backup.
- During the repair process, several steps execute and provide status while they are restored, as shown in Figure 21.6.
-
After the restore process completes, the next step involves determining if the system is a central site or the child of another ConfigMgr site. This example is restoring the CEN site (the central site in the SCCMUnleashed environment), so the restoration would include checking the option indicating that This is a central Site, as displayed in Figure 21.7.
Select this first option for those environments with a single site or when restoring the central site. If however a child site is being restored, such as the DAL site in the SCCMUnleashed environment, choose the second option in Figure 21.7, specifying that this is a child site of and identifying the parent site. (For the DAL site, the parent is the CEN site.)
- The following screen, Verify Site Hierarchy, provides the opportunity to validate the site hierarchy information you are restoring is correct. You can add additional sites and configure addresses for the selected sites. For a single site restoration or restoration of a central site, the only site shown would be the one specified on the previous screen, as displayed in Figure 21.8.
-
Clicking Next takes you to the Package Recovery step of the Site Repair Wizard. Several options are available:
• You can specify here whether to verify the package source files are accessible, and if so, whether to update the distribution point on the site server.
• You can choose to skip package verification completely.
The distribution point in the ConfigMgr SCCMUnleashed environment is already populated, so accept the default configuration to verify that the source files are accessible, as shown in Figure 21.9.
- The restoration process continues through a series of processes (displayed in Figure 21.10), shows a summary of the actions performed, and provides a screen indicating that the restoration process is complete.
After successfully restoring the ConfigMgr environment, the next required step is to perform a site reset. A site reset reapplies default file and registry permissions. It also ensures that accounts used by ConfigMgr components are correct, resets the access control lists used by remote site systems, restores ConfigMgr registry keys, and restores the ConfigMgr directory tree. Take the following steps to perform a site reset:
- Run the ConfigMgr Setup program (Start -> Programs -> Microsoft System Center -> Configuration Manager 2007 -> ConfigMgr Setup).
- Click Next on the Welcome screen. On the Available Setup Options page, choose the option to Perform site maintenance or reset this Site, as shown in Figure 21.11.
- On the next screen, check the option to Re-apply default file and registry permissions on this site server, displayed in Figure 21.12. On the following screen, confirm you want to perform the site reset by choosing Yes.
- The setup program performs a series of tasks, and when they are completed (shown in Figure 21.13), you can validate the functionality of the ConfigMgr environment.
- The final screen of the site reset provides an option to review the log file for the site reset and a check box to launch the ConfigMgr console after closing. Select the option to launch the ConfigMgr console because you need to validate functionality of the ConfigMgr environment after resetting the site. You also need to review the log file if you encounter any errors.
After completing the process of restoring the ConfigMgr environment, you need to validate that it is functional. There are three major areas to verify:
• Checking site addresses— Navigate to Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Addresses. If you have a multiple ConfigMgr site hierarchy, verify that the appropriate site addresses still exist.
• Checking site settings— Navigate to Site Database -> Site Management -> <Site Code> <Site Name> Site Settings. Validate the configurations of each of the major sections and change any settings that might not be correct for your environment (Boundaries, Client Agents, Client Installation Methods, Component Configuration, Certificates, Accounts, Discovery Methods, Senders, Site Maintenance, Status Filter Rules, Status Summary, and Site Systems).
• Monitoring site processes— Navigate to Site Database -> System Status -> Site Status -> <Site Code> - <Site Name> -> Component Status. Check the status of all components. Review the messages on any status that does not display as healthy. You also need to address any issues identified that exist after completing the restore and site reset.
You can utilize the steps used to back up and restore the site to move an existing environment to new hardware or build out a new environment. The next sections discuss each of these scenarios.
A frequently asked question is how to move an existing ConfigMgr environment to new physical hardware. This often happens if the original hardware for ConfigMgr was not assessed adequately or the scope of what ConfigMgr is has significantly increased.
If the server name does not need to be changed, a backup, re-install, and restore process can be done. Here are the high levels steps required to perform this type of migration:
- Back up the existing ConfigMgr server. When the backup is completed, shut down the ConfigMgr server.
- Install a new server with the same name and configuration as discussed in Chapter 8, “Installing Configuration Manager 2007.”
- Restore the ConfigMgr database using the steps discussed in the TechNet article on how to move a ConfigMgr database available at http://technet.microsoft.com/en-us/library/bb680707.aspx.
- Additional site settings might need to be transferred; these are discussed in the TechNet article available at http://technet.microsoft.com/en-us/library/bb633056.aspx.
Sometimes it is necessary to build out a new ConfigMgr environment to replace an existing one. This can occur if a ConfigMgr server cannot retain the same name and needs to be put on new hardware (see the section “Moving ConfigMgr to New Hardware”). A new environment might also be required when there are significant issues in an existing ConfigMgr environment to the point where replacing it is the most reasonable solution.
Here are the high level steps required to perform this type of migration:
- Install the new ConfigMgr server as discussed in Chapter 8, using a different site code than used by the original ConfigMgr site.
- Set the ConfigMgr server environment to the settings you require, including AD system discovery. Set the site boundaries to overlap with the original ConfigMgr environment.
- When all systems are listed in the All Systems collection, right-click on the collection and select Install Client to the collection to deploy the client.
In addition to having a solid backup and recovery procedure in place, you also want to maintain the data in your site and site database. There are a variety of concepts to consider when performing site maintenance, including site maintenance tasks, DDR retention, and dealing with obsolete database records.
Site maintenance tasks are a vital part of maintaining your site. After installation and performing other initial configurations, it is imperative you understand and configure these tasks to best suit your particular ConfigMgr hierarchy.
Before making any changes to site maintenance tasks, there are several points about the tasks in general:
• Site maintenance tasks are set at each individual site and not automatically transferred to any other sites in your ConfigMgr hierarchy.
• The Transfer Site Settings Wizard, discussed in Chapter 8, has the capability to copy site maintenance task settings from one ConfigMgr site (or an exported copy of those settings) to any other ConfigMgr site.
• Some of the site maintenance tasks can cause unnecessary and conflicting processing on the ConfigMgr site. These pitfalls are noted with each task.
• Several of the tasks perform maintenance on the database, such as deleting old data or summarizing current data. Balance the amount of data manipulated at one time by scheduling the tasks to run more frequently.
Table 21.1 lists the site maintenance tasks in ConfigMgr 2007. Additional information is also available at http://technet.microsoft.com/en-us/library/bb632595.aspx.
After installing a ConfigMgr site, you add clients and resources to the site. These objects are added using a discovery method. (The only required discovery method is the heartbeat discovery method.) Various discovery methods can be used that search Active Directory or the network for resources. Those resources include computers, Active Directory (AD) objects, site systems, routers, hubs, printers, and Internet Protocol (IP)-addressable devices. Chapter 12, “Client Management,” covers discovery in detail, and Chapter 5, “Network Design,” provides information on network discovery.
As ConfigMgr 2007 discovers resources, it creates records in the Configuration Manager database and files with a .DDR extension. These discovery records are called data discovery records (DDRs), which refer to the .ddr file format and the actual file used by ConfigMgr to report discovery data to a Configuration Manager site database. You can use these DDRs to target installations for client deployment. DDRs are the main method to tell a ConfigMgr site crucial details about clients. Without DDRs, no clients would be in the database for your administrators to manage!
DDRs are generated based upon the type of discovery method used and based upon a polling schedule that indicates when ConfigMgr performs the actions required to execute the discovery, such as querying Active Directory for systems in the container specified within the discovery method. Heartbeat discovery is unique because the ConfigMgr server does not poll these systems; the discovery configuration only specifies how frequently the clients send their heartbeats to ConfigMgr. The specific information contained in each record can vary depending on the particular resource.
As discussed earlier, Chapter 12 covers discovery in detail, but as a reminder, here are the different discoveries available in ConfigMgr 2007:
• Active Directory System Discovery— Not enabled by default; default polling schedule is daily.
• Active Directory Security Group Discovery— Not enabled by default; default polling schedule is daily.
• Active Directory System Discovery— Not enabled by default; default polling schedule is daily.
• Active Directory User Discovery— Not enabled by default; default polling schedule is daily.
• Heartbeat Discovery— Enabled by default; default polling schedule is once a week. Heartbeat discovery is unique in that it is the only discovery method that returns a client Globally Unique Identifier (GUID) as part of the discovery record; it also is the only discovery method to dictate whether clients are displayed as “installed” in the ConfigMgr console. Heartbeat discovery is responsible for letting the site know a client is still healthy.
• Network Discovery— Not enabled by default; no default schedule.
Data collected can include things such as the NetBIOS name of the computer, the IP address, the MAC (Media Access Control) address, and the IP subnet of the discovered computer or device.
You can configure each type of discovery method on its own custom schedule. When ConfigMgr runs discoveries, it generates resource DDRs to keep discovery data current in the database and inform ConfigMgr that the resource is still valid for the site.
DDRs are not intended for use as extended inventory; they contain basic information that gives the ConfigMgr site enough information to place the client in the database and determine if it were reported previously.
The following is a sample of a heartbeat DDR file created for the Alamo server shown in eXtensible Markup Language (XML) format. Note the NetBIOSName information for the Alamo server, IP Address information, AD Site, ConfigMgr Site, and Domain information:
Tip
Capturing Heartbeat Discoveries
If you want to preserve the data collected in the discovery record for troubleshooting purposes, create an empty folder named archive_reports.sms on the agent system at the ccminventory emp directory (stored at c:windowssystem32 on x86 systems and c:windowssyswow64 on x64 systems). You can verify this location by checking the registry entry setting located at
• HKEY_LOCAL_MACHINESoftwareMicrosoftSMSMobile ClientInventoryTemp folder for x86 systems
• HKEY_LOCAL_MACHINESoftwareWOW6432NodeMicrosoftSMSMobile ClientInventoryTemp folder for x64 systems.
After this file is created, the discovery and other inventory records are stored in XML format in this temp folder as they are processed.
The following section shows a sample of an Active Directory system discovery DDR file created for the Wildflower server. (Note the sample includes the NetBIOS name, domain of SCCMUNLEASHED, Active Directory site name, IP address, the discovery method used, and other fields that would be relevant to discovery on a Windows-based server.)
The retention period for obsolete records is defined by settings in the Delete Obsolete Client Discovery Data task. The retention periods of DDRs are a function of whether the system is a current system, meaning that it is sending heartbeats. If the system is not current, the settings are defined in either the Delete Aged Discovery Data task (assuming that the system is not discovered by another method) or the Delete Inactive Client Discovery Data task.
Obsolete records can occur if ConfigMgr detects a duplicate machine in the database. All clients in the ConfigMgr database have several unique identifiers that tell ConfigMgr which machine is which. When two or more of those identifiers come into conflict, an obsolete record can occur.
Obsolete discovery data continues to persist in the database until the Delete Obsolete Client Discovery Data site maintenance task runs. If that task is not enabled, the data persists until the client is marked inactive and the Delete Inactive Client Discovery Data task runs. An obsolete client is, by its nature, inactive, so these records would also be removed when the Delete Inactive Client Discovery Data task runs. If that task is also disabled, or the appropriate steps are not performed to ensure inactive clients are marked, the data remains.
These tasks are available in the ConfigMgr console, at Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Site Maintenance -> Tasks. By default, both tasks are not enabled.
Tip
Setting the Retention Period for the Delete Site Maintenance Task
When configuring the Delete Site Maintenance task, it is important to set the retention period of the task to a time frame that is higher than the discovery frequency. Removing discovery data that is not aged sufficiently causes undo churn on the ConfigMgr site. A good rule of thumb is to set this to twice the heartbeat discovery interval or 7 days; whichever is longer.
For example, the Delete Obsolete Client Discovery Data task deletes the obsolete client database records related to the DDR records discussed in the “DDR Retention” section of this chapter. Obsolete client records are generally marked as such because a newer record that discovered the same client has replaced them. The new client record becomes the current client record, and the previous discovery record is now obsolete. By default, this task is not enabled. To remove obsolete records, enable this task and give it an interval that is greater than the heartbeat discovery schedule (which defaults to once a week) as shown in Figure 21.14, which specifies deleting data older than 7 days and running each Saturday morning.
Note
Delete Obsolete Client Discovery Data Task Thresholds
Because a client is marked as obsolete when a new record is processed for the same client, it is fairly safe to run the Delete Obsolete Client Discovery Data task with a fairly low threshold. Nondiscovery data from obsolete clients is removed by the various other site maintenance tasks.
When maintaining the ConfigMgr 2007 site database, it is vital to back up the database, as previously discussed in the “Backing Up ConfigMgr” section in this chapter. An effective backup strategy is crucial to providing a functional database environment for ConfigMgr; however additional tasks also need to occur to maintain your ConfigMgr database effectively.
Tip
Why Do a Separate Database Backup?
Are there situations where an administrator would want to do a separate database backup if the site maintenance task is handling the backup? A common reason for performing a separate database backup is that by default the maintenance task overwrites the previous backup file. There are ways to deal with this situation by adding the after-backup.bat file to specify which commands should be run after a backup (such as moving the backup file so that it would not be overwritten and stored for longer periods of time), but a simpler solution might be to perform a separate database backup.
Database maintenance is performed using two tasks defined during site installation. These tasks are available in the ConfigMgr console, at Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Site Maintenance -> Tasks. The two tasks of note for database maintenance are the Monitor Keys and Rebuild Indexes tasks:
• Monitor Keys— This task is enabled by default and runs on Sunday mornings between 12:00 AM and 5:00 AM. ConfigMgr works like other database applications in that it uses primary keys to identify unique records in a table quickly. A primary key is a column (or multiple columns) that uniquely identifies one row from any other row in a database. The ConfigMgr Monitor Keys task monitors the integrity of these keys within the ConfigMgr database. As ConfigMgr runs this task itself, the responsibility of the ConfigMgr administrator is to audit this task is occurring and completing successfully when it executes.
• Rebuild Indexes— By default, the task is enabled. This task runs every Sunday between 12:00 AM and 5:00 AM. ConfigMgr, similar to other database applications, uses indexes to speed up data retrieval. As the data in the ConfigMgr database constantly changes, this task improves performance by creating indexes on database columns that are at least 50% unique. The task also drops indexes on columns that are less than 50% unique and rebuilds all the existing indexes to maximize the performance when accessing these columns.
Tip
Running Rebuild Indexes with a Large Amount of Database Data
If your ConfigMgr site database holds a large amount of data, the Rebuild Indexes task can take a considerable amount of time to run. This task is different from most tasks in that running it more frequently does not guarantee a shorter execution time but ensures your ConfigMgr site uses the database in the most efficient manner.
If there are additional database maintenance tasks required beyond the Monitor Keys and Rebuild Indexes tasks, you can add them through the SQL Commands section of the ConfigMgr console (at Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Site Maintenance -> SQL Commands). To add new SQL commands to run custom maintenance tasks against the ConfigMgr 2007 site database, right-click on SQL Commands in the console and choose New SQL Commands. The New SQL Command screen (shown in Figure 21.15) provides a dialog box to define the name of the task, the SQL command to execute, where to log status information to, and a section to schedule when the maintenance task would occur.
You can use custom SQL commands to run a SQL command (up to 255 characters) or execute an existing stored procedure. There are several SQL commands available that provide maintenance functionality. Some examples of the types of SQL maintenance you can run include the following:
• DBCC CHECKDB (Database Consistency Check)— This is a stored procedure that checks the logical and physical integrity of all objects in the site database. Here are some of the tasks the DBCC CHECKDB stored procedure performs:
• Executing a DBCC CHECKALLOC on the database
• Performing DBCC CHECKTABLE on every table and view in the database
• Executing a DBCC CHECKCATALOG on the database
• Validating the contents of every indexed view in the database
• Validating the Service Broker data in the database
• sp_monitor— This system procedure displays SQL Server activities and statistics.
• sp_spaceused— This command displays the number of rows, disk space reserved, and disk space used by a table in the current database. It also displays the disk space reserved and used by the entire database.
• sp_who— This system procedure determines the number of SQL Server connections currently in use by ConfigMgr 2007 and other processes.
• xp_sqlmaint— This command runs database maintenance tasks.
Properly maintaining your ConfigMgr database environment can go a long way toward maintaining the functionality and performance of your ConfigMgr environment.
Status messages provide one of the primary means to look at the health of your ConfigMgr infrastructure and identify any problems that might occur. Nearly all ConfigMgr components generate status messages to report various milestones and events. ConfigMgr clients send status messages to their management point, site systems send status messages to the site server, and child sites can replicate messages to their parent site.
You can choose which messages to replicate and the data priority for each type of message sent between sites. Status messages sent up the hierarchy can account for much of the overall site-to-site traffic. This is particularly true when child sites have a large number of clients. To limit the impact of status message replication, it is important to tune the Status Message System.
The most important settings for status message replication are the status filter rules. All status messages received by a site pass through the site’s status filter, which evaluates the message to determine if it matches the criteria of each of its status filter rules. A match invokes the action you specify for the rule. One of the actions you can specify is to replicate the message to the parent site.
You can configure status filter rules in the ConfigMgr console, at System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Status Filter Rules. As shown in Figure 21.16, two status filter rules for replication are already enabled, by default:
• Replicate all SMS Client messages at low priority
• Replicate all other messages at medium priority
The rule to replicate client settings is higher on the list in Figure 21.16—showing it has a higher priority and will be processed before the rule that replicates all other messages at medium priority. Messages received from clients match the first rule and replicate to the parent site at low priority. All other status messages are replicated at medium priority. You can modify these rules depending on your requirements. For example, if local administrators perform all client troubleshooting at a particular site, you might decide not to replicate status messages originating on client systems from that site to its parent site.
To stop replicating client messages, perform these steps:
- Right-click on the rule.
- Choose Properties.
- Select the Actions tab in the Status Filter Rule Properties page.
- Check the box at the bottom for Do not process lower-priority status filter rules.
By changing the action from the default of Replicate to Parent Site to Do not process lower-priority status filter rules (as shown in Figure 21.17), you can prevent these messages from being processed by the lower priority Replicate all other messages at medium priority rule. This action results in client messages being discarded. As that data is not forwarded, it eliminates data within some reports at higher-level sites and any centralized view of deployments.
Note that the modified rule is still named Replicate all SMS Client messages at low priority, although it no longer actually replicates the messages. To change the name of the rule, you need to delete or disable the existing rule and create a new rule with the appropriate name.
You can create new rules to control replication of specific types of messages. To create a new status filter rule, perform the following steps:
- Right-click the Status Filter Rules node in the console tree; then select New Status Filter Rule to initiate the New Status Filter Rule Wizard.
- Name the rule Replicate Milestones and Informational Messages at Low Priority and check the Message Type and Severity boxes. With the selections shown in Figure 21.18, the filter processes all messages of type Milestone or severity Informational.
- Next, choose the action Replicate to parent site / Replication priority and select Low from the drop-down list, as shown in Figure 21.19.
-
The wizard displays a Summary page for the new rule and asks you to confirm your choice. This completes the New Status Filter Rule Wizard.
After completing the wizard, you need to change the priority of the rule so that it processes in the correct order. The rule should run after the rule that discards client messages, but before the catchall rule to replicate at medium priority.
Right-click the rule in the list and choose Increment priority. Figure 21.20 shows the sixteen rules. This discussion focuses on the last three rules, which configure how status messages replicate within ConfigMgr. As a summary, these are the actions now defined for ConfigMgr:
• All Client messages will be dropped because of the steps taken to stop replicating client messages.
• Informational and Milestone messages will be replicated only during times when the Sender Address setting allows sending low priority data.
• All other messages will be replicated during times when the Sender Address setting permits sending medium priority data.
Figure 21.20. The list of status filter rules, including the newly created rule, in the desired order
In addition to individual status messages, each ConfigMgr site maintains status summary data by default. This status summary data displays the overall status of a system, component, or advertisement as OK, Warning, or Critical based on the number and type of messages received. Similar to individual status messages, you can decide whether to replicate status summary data to the parent site and the data priority to assign to the replication.
Perform the following steps to configure replication of status summarizer data:
- Navigate to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Status Summary.
- Right-click the summarizer you want to configure.
- Select Properties.
- You can now choose if you want to enable status summarization, replicate to the parent site, and replication priority.
Figure 21.21 shows the default settings for the Advertisement Status Summarizer.
Effectively configuring your status filtering rules can help to direct your ConfigMgr environment to show only the status information relevant to your particular ConfigMgr site.
ConfigMgr retains two different types of status data, which are set in the ConfigMgr console, at Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Status Filter Rules:
• Audit messages—Audit messages retention is configured within the Write audit messages to the site database and specify the period after which the user can delete the messages rule. This status filter rule has a default setting of 180 days before the user can delete messages.
• All other messages—Other message data retention is configured within the Write all other messages to the site database and specify the period after which the user can delete the messages rule. This status filter rule has a default setting of 30 days before the user can delete messages.
These messages are removed from the ConfigMgr database through the Delete Aged Status Messages task (navigate in the ConfigMgr console to Site Database -> Site Management -> <Site Code> <Site Name> Site Settings -> Tasks). This task runs daily between midnight and 5:00 AM. The task deletes status messages older than seven days.
As an example, in a default configuration all audit messages are retained 180 days, and all other messages are retained 30 days. Even though the task deletes messages older than 7 days, the actual data is retained in the database for 30 (or 180) days. If you decrease the All other messages setting from 30 days down to 14 days and rerun this task, it does not have what might be the expected results, which is to delete messages older than 14 days (other than audit messages).
This is because when status messages are written to the database, the date they are scheduled to be deleted is written based on the setting on the status filter rule at that point in time. The date is calculated based upon the settings that existed for the appropriate message retention task. When the retention period is changed, the new messages remain for the time defined when they are written. Therefore, by following the example in the previous paragraph, the status messages written with the 14-day retention would be deleted and then the status messages written under the 30-day retention would be deleted.
It is recommended to retain the status messages as long as is required to diagnose the status of your ConfigMgr 2007 system. If you need to minimize the amount of space used by status messages, you can decrease the retention periods within the two rules listed in this section—although making this change is not suggested, unless it is necessary to decrease the amount of data retained.
Status filter rules allow a ConfigMgr administrator to control which status messages are both forwarded to parent sites and which ones are written to the ConfigMgr database. These rules can be a critical method of tuning performance and eliminating unneeded information.
Rules are set in a top-down ranking, meaning that rules listed at the top of the list are processed first, followed by those listed next. This assumes that a higher-level listing does not stop processing of lower priority rules. Think of status filter rules as a series of gates that each status message must pass through. Each gate has a set of criteria against which each message is checked.
• If the message doesn’t match the criteria, it passes through the gate to the next rule.
• If it matches, a set of actions can be taken, including either allowing the message to continue on its path, or stopping all further activity for the message.
ConfigMgr 2007 comes with a number of status filter rules predefined and enabled by default. These status filter rules provide actions that occur when various conditions are met, as shown in Table 21.2.
Using the ConfigMgr console, you can create new status filter rules or update existing ones. Utilize these status filter rules to either change how these configurations function, or add matching and actions for additional configurations not predefined within ConfigMgr.
Chapter 1, “Configuration Management Basics,” introduces the Microsoft System Center product line including products such as Operations Manager, Essentials, Service Manager, Data Protection Manager, Capacity Planner, and Virtual Machine Manager. An important part of a server maintenance strategy should include effective monitoring of what is occurring on the servers and applications within your organization.
System Center Operations Manager 2007 (OpsMgr) provides proactive server and application monitoring and displays the information into a centralized console. OpsMgr provides a way to identify issues before they affect the environment, enabling a quicker resolution for issues when they are identified.
ConfigMgr provides its own method of status reporting through the Status Message System (discussed in the “Making the Status Message System Work for You” section of this chapter), so at first glance it would appear that using OpsMgr to monitor ConfigMgr would be redundant. The status system within ConfigMgr provides a great level of details related to the internals of what is occurring within ConfigMgr; however, it is not designed to provide proactive monitoring or to alert when critical events occur. The status system is designed to only provide information that determines what occurs within ConfigMgr.
Operations Manager provides the ability to monitor the physical hardware, operating system, and core functionality such as DNS, DHCP, and Active Directory; and it provides the ability to monitor applications such as ConfigMgr 2007. OpsMgr’s functionality is available through management packs (free with the product) that are available from the System Center Operations Manager 2007 Catalog on the Microsoft website. The ConfigMgr management pack is available by accessing http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx and searching for System Center Configuration Manager 2007.
The ConfigMgr management pack provides the health state for all ConfigMgr servers and services and provides performance and availability reports for ConfigMgr. It also provides alerting for critical ConfigMgr 2007 status messages and tracks the processing rates and metrics such as the processor, memory, and disk system usage. The management pack includes product knowledge to assist with resolving alerts identified for the ConfigMgr environment.
For more information on System Center Operations Manager, the authors of this book recommend the Microsoft website for Operations Manager (http://www.microsoft.com/opsmgr) and/or System Center Operations Manager 2007 Unleashed (Sams, 2008), available at http://tinyurl.com/27mqnm.
Configuration Manager 2007 uses a variety of maintenance services, which run either on the agent or on the various site servers. Knowing what services ConfigMgr uses and the functions they provide can assist with debugging issues that occur in the ConfigMgr environment. This can be critical when identifying issues that might occur after performing a ConfigMgr recovery. Table 21.3 provides a list of these services and their descriptions.
This chapter focuses on the steps required to backup, recover, and maintain your Configuration Manager 2007 environment. It discusses DDR retention, obsolete records, and database records. It also discusses the ConfigMgr Status Message System and using OpsMgr to monitor ConfigMgr. The chapter finishes by listing the maintenance services used within ConfigMgr.
This chapter completes the last part of the book, which focuses on how to administer Configuration Manager 2007. We hope that this has been a useful guide to ConfigMgr and provides you with an in-depth level of understanding of the product.