Performance considerations

Applies To: Forefront Client Security

Enterprise Manager uses Microsoft® Operations Manager (MOM) 2005, SQL Server® 2005, and Windows Server® Update Services (WSUS) in order to provide Microsoft Forefront™ Client Security management capabilities in a tiered infrastructure that scales to 10 Client Security down-level deployments of up to 10,000 managed computers each.

With up to 100,000 managed computers, the performance measurement and evaluation of the Enterprise Manager instance and the down-level Client Security deployments is paramount. This section provides performance information for Enterprise Manager environments. Performance considerations for stand-alone Client Security deployments and down-level Client Security deployments can be found in the Client Security Performance and Scalability guide (https://go.microsoft.com/fwlink/?LinkID=89661).

Enterprise Manager SQL Server performance recommendations

The Enterprise Manager server is a specialized Client Security one-server or two-server deployment that receives data from all down-level Client Security deployments. Because of the amount of data being passed to the Enterprise Manager server in a 100,000 client scenario, some specific SQL Server configuration must be done on the SQL Server installation on the Enterprise Manager server.

To allow SQL Server to use more than 2-gigabytes (GB) of memory, it is recommended that you add the /3GB and /userva switches to the boot.ini file, as described in Microsoft Knowledge Base article 316739 (https://go.microsoft.com/fwlink/?LinkId=109931). Additionally, you must use the -g SQL Server startup parameter, as described in Microsoft Knowledge Base article 316749 (https://go.microsoft.com/fwlink/?LinkID=109932).

The SQL Server installation for Client Security also requires the installation of SQL Server Service Pack 2 (https://go.microsoft.com/fwlink/?LinkID=84823).

To support 100,000 managed computers, use the hardware recommendations in the following table.

SQL Server log and data file sizing

Data from each of the down-level Client Security deployments is first stored in the Enterprise Manager collection database, moved to the reporting database on the fourth day, and then groomed (deleted) from the database on the 5th day (after a successful transfer to the reporting database).

The following table contains SQL Server database sizing recommendations for the Client Security collection database with 100,000 managed computers, based on the default Client Security Data Transformation Services (DTS) and grooming job configurations.

The Client Security reporting database stores data long-term for historical reporting. The database will increase in size over the course of time; your configuration for data retention duration affects the amount of disk space required for storing this data. The following table provides sizing recommendations for the reporting database.

The physical disk subsystem that the SQL Server databases reside on must be fast enough to handle the data flow during peak load. In testing with 100,000 managed computers, the disk subsystem incurred the following values for input/output kilobytes per second.

For more information about measuring disk performance, see Storage Top 10 Best Practices (https://go.microsoft.com/fwlink/?LinkID=87536).

Report performance in Enterprise Manager

The Client Security console on the Enterprise Manager server queries results for reports from up to 10 down-level deployments. Each down-level deployment has two Client Security databases: the collection database and the reporting database. The following table describes the purpose of each database.

Depending on the Client Security topology on the down-level deployment, these databases may be on a single computer or on two separate computers. Your performance experience when querying data from the down-level databases will depend greatly on the load being experienced on the down-level Client Security database servers (the collection database and reporting database servers). To determine rough performance expectations for the Enterprise Manager reports, you should determine the report response time individually for each down-level Client Security deployment.

Certain reports on the Enterprise Manager server query data from both down-level databases on the down-level deployments. If one of the databases is not available, report delivery time is increased for the whole report, not just the data from the missing database.

The following table summarizes the amount of time it takes to display a report on the Enterprise Manager server once the report has been requested, depending on the total number of managed computers in the enterprise and the hardware on both the down-level Client Security servers and the Enterprise Manager server.

Console performance in Enterprise Manager

The Enterprise Manager console is largely unchanged from the standard Client Security console. Each section of the Client Security dashboard is actually comprised of a database query for that particular data set.

The data sets that define the Client Security dashboard in Enterprise Manager are queried by the Enterprise Manager server on a regular basis (by default, every 5 minutes) and cached on the Enterprise Manager server. The following table lists estimated performance values for 100,000 managed computers.

Performance of the dashboard may suffer if one or more down-level databases are unavailable. When this occurs and the console is displayed or refreshed, the console data consistency banner is displayed. This time-out value is 2 minutes.

Best practices for Enterprise Manager performance

Increasing the IIS time-out value

If your Internet Information Services (IIS) session times out, you may experience SQL Server Reporting Services Report Viewer time-outs on the Enterprise Manager server. To prevent this from happening, you may want to increase the IIS Session timeout and ASP script timeout values.

To increase the IIS Session and ASP script timeout values

1. Start IIS Manager from the Administrative Tools menu.

2. Expand servername, expand Web Sites, and then expand Default Web Site.

3. Right-click Reports, and then click Properties.

4. In the Reports Properties dialog box, on the Virtual Directory tab, click the Configuration button.

5. In the Application Configuration dialog box, click the Options tab.

6. In the Session timeout box, enter the number of idle minutes before timing out the session.

7. In the ASP script timeout box, enter the number of idle seconds before timing out an ASP script, click OK, and then in the Reports Properties dialog box, click OK.

8. Repeat steps 3-7 for the ReportServer virtual directory.

DTS considerations

Because each down-level Client Security deployment may have as many as 10,000 managed computers, the down-level Client Security deployments must be performance tuned. The proper functioning of the DTS job that copies data from the collection database to the reporting database is most relevant to Enterprise Manager.

The DTS job runs daily and moves data from the collection database to the reporting database after the data has been in the collection database for 4 days. After the DTS job has completed successfully, the data can be groomed (deleted) from the collection database.

In certain situations, the DTS job may fail to complete, and the data in the collection database is not groomed. In these cases, the collection database may grow to more than the recommended maximum of 30 GB. Exceeding the recommended maximum size for the collection database may cause problems with Enterprise Manager.

To prevent this from happening, regularly check the Application Event Log in order to ensure the DTS job is completing.