• How is running NTSMF different from Microsoft's Perfmon or the Windows System Monitor?
• Is NTSMF easy to install?
• What do I need to do to get started with NTSMF?
• What key metrics in Windows I should collect and report on?
• What do I need to do to monitor my servers running MS Exchange, SQL Server, or IIS?
• What is the right version of NTSMF to use with Windows Server 2003?
• What is the right version of NTSMF to use with Windows Server 2000?
• What is the right version of NTSMF to use with Windows XP?
• Is NTSMF compatible with the Microsoft Cluster Server?
• What is the overhead of running NTSMF?
• How big are the nightly NTSMF data files?
• What is the format of the NTSMF data files?
• Why is NTSMF not collecting a specific performance Counter (or Counters) that I need to look at?
• How does NTSMF handle the Disable Performance Counters flag that is used in Windows 2000, XP and Server 2003?
• What does the Module collection function do?
• How does the Module filter work?
• Can I run the NTSMF collection service under a User Account, instead of LocalSystem (or SYSTEM)?
• Can the NTSMF collection service impersonate a User Account to gain access to secured network resources?
• I don't care about resolving module information for container processes like the Java Virtual Machine or dllhost.exe. What User Rights and Permissions does the User Account that I will run the NTSMF collection service under require?
NTSMF and the Performance Monitor (Perfmon) or System Monitor all access the same performance data and all access it the same way. This performance data encompasses an enormously rich set of metrics on resource usage of key hardware and software components that is available on every Windows server and workstation. We think this is a very strong statement about the fundamental importance that the vendor places on performance management. Microsoft also includes excellent performance monitoring tools like Perfmon and the System Monitor in every version of the operating system that is installed.
Nevertheless, the built-in tools Microsoft provides fall short of the precision tools that experienced professionals demand, especially those that are responsible for managing multiple machines that are part of a larger, enterprise computing infrastructure. Because NTSMF was designed for centralized administration of Windows performance data collection across hundreds or thousands of machines, there are some crucial differences between our product and the freebie utilities that Microsoft includes. Some of these crucial differences are summarized below:
 |
NTSMF runs as a service and collects Windows performance data continuously. Perfmon and Sysmon have to be invoked for data to be collected (Perfmon and Sysmon do have a logging function, which we will address next). Typically with Perfmon or System Monitor, you are trying to determine what the cause of a problem is after the problem is discovered. Said another way, someone will call the help desk with a problem, you log into Perfmon and view the current status of the system. More than likely, the data you need to analyze the cause of the problem is gone. Since NTSMF is collecting data continuously, on an interval basis, the data you need to analyze your problem has been collected, before and while you realize a problem exists. |
|
NTSMF runs in background mode and has close to zero impact on system performance. When Perfmon logging is turned on it can use as much as 40% of the CPU Utilization and the file sizes can be enormous. Collecting data in text file format suitable for analysis by an application other than System Monitor, for example, you are likely to find that the overhead of System Monitor is prohibitive. If you want to read more about NTSMF overhead, click here. |
|
NTSMF augments the information available through the standard Windows 2000 performance monitoring interface with static configuration data so that you have all the information required for management reporting, asset and inventory management, and capacity planning at your fingertips from a single source. |
|
NTSMF logs the NT performance data in an open, comma delimited format designed to be processed readily by third party products like SAS and MXG. This allows you to create Windows 2000 performance charts with the same look and feel of your other platforms. Data from virtually any number of machines can be correlated to analyze trends and for performance tuning and capacity planning. |
|
NTSMF has filters for process and thread data that allows you to collect data only when it exceeds thresholds that you define. This ensures that you can see detailed enough data to detect, diagnose, and resolve most common performance problems without collecting excessive amounts of data. |
|
NTSMF is designed for hassle-free, automated, unattended operation. It has built-in scheduling facilities that are used to automate routine data file consolidation and aging, for example. It also supports an automation interface that you can use to control the operation of the collection agent using a .bat file or script. |
|
NTSMF has a single GUI interface which makes it easy for to establish and maintain uniform data collection procedures for all of your Windows 2000/2003 servers. |
Easy as pie.
The standard installation package that we ship on your CD contains three separate Setup routines that can be run separately or together. One setup routine is used to install the SeNTry Administration GUI which is used to administer NTSMF data collection. You can install as many copies of the SeNTry Administration program as necessary to administer NTSMF across your network. (It is often helpful to run separate copies of SeNTry Administration in front of and behind your firewall, for example.
The second setup routine is for the NTSMF collection agent. You can run this setup routine right from the distribution or copy it to disk and run it separately. There is even a silent mode setup option so that you can install the NTSMF collection agent unattended. Finally, the User Manual shows how to create a simple installation script that you can use to roll out NTSMF across your network of Windows machines. A scripted installation of the collection service has the advantage of being able to assign a Data Collection set (DCS) of your own during installation and also allows you to assign a User Account to be impersonated during Cycle End processingThe User Manual also provides a sample script to use to distribute the NTSMF collection agent using SMS.
For those customers who develop their own distribution and installation procedures, the required set of files needed to install the current version of the collection service is:
DbgHelp.dll
DmCmd.exe
DMDCSMASTER.OMI
DMPerfss.exe
Dmperfss.cfg
Dmperfss.sdb
DMSumMsg.dll
DMSumSMF.exe
DTSFnd.dll
msvcp71.dll
msvcr71.dll
PSSMsg.dll
Unable to copy the PSSMsg.dll file during installation. Running an installation script to upgrade the collection service, you are likely to find that the PSSMsg.dll file is in use and cannot be replaced. The PSSMsg.dll file is an application Event log message dll that is loaded and used by the Event Log service. Any other utility programs that you run that access the Event log are likely also to have opened the PSSMsg.dll file. In order to copy the latest PSSMsg.dll file, you may have to shut down the Event Log service and any other service that accesses Event Log message dlls. Make sure you restart these services after you complete the file copy successfully.
Please do not agonize over the fact that your script cannot replace the PSSMsg.dll file because it is in use. It is not the end of the world to run the most current collection service with a slightly out-of-date Event Log Message dll.
Optional runtime files. Diagnostic symbols are no longer included in the program's binary executables like DMPerfss.exe and DTSFnd.dll due to Microsoft compiler changes. Diagnostic symbols are now found in filenames ending with a .pdb suffix. Installing these debug symbol files is optional, but highly recommended so that we can maintain the high quality of the collection service code.
DmCmd.pdb
DMPerfss.pdb
DTSFnd.pdb
msvcr71.pdb
msvcp71.pdb
Installing the enclosed version of PKZIP25.exe is also optional.
Note that this list of required files updates the list found on on page 21 of the User's Guide.
The runtime files listed here can be found in the \NTSMF24 folder following the installation of the collection service following setup, or in the folder \Performance SeNTry\Collection Sevice Files following the installation of Performance SeNTry Administration component.
The third setup routine is for Performance Gallery. You will need to contact us for a permanent Registration Code keyed to the machine where you are installing Performance Gallery to run this setup routine once you have licensed the product.
Installation is a three-step process:
1. Prepare the machine you want to use to administer Performance SeNTry.
Run the Setup program contained on the installation disk to install the SeNTry Administration program on the Win2K workstation or server you intend to use to administer Performance SeNTry. SeNTry Administration is used to define and activate NT performance Data Collection Sets (DCSes) on the local machine and any remote computers that you want to monitor.
A Data Collection Set defines (1) which of the available performance Counters you want to collect, (2) the data collection interval and other runtime parameters that control the operation of the collection agent, and (3) the filtering options that ensure that you are collecting the right amount of information. The program ships with standard defaults that are appropriate for most environments. We also provide you with a large number of pre-defined DCSes that are appropriate for different application servers. With SeNTry Administration, you can assign any of the DCSes we provided, use the DCS Editor to modify them in a jiffy, or create your own.
2. Prepare the machine you want to monitor.
Install the NTSMF collections engine as a service on any NT/2000/XP computer that you wish to collect information about and start it. The Performance SeNTry service collects the performance data you specify on the Windows NT/2000/XP computer on which it is installed. You can install as many copies of the Performance SeNTry service as you are licensed to run. By default, DMPerfss.exe writes an NTSMF format data file to a \Data subdirectory of the installation directory on the monitored system's local hard drive. You can change the Data directory to point anywhere you want, even to point to a remote hard disk
3. Automate the process for consolidating Performance SeNTry collection files for processing by SAS IT/SV, MXG, or other performance reporting packages.
Once installed, the Collection Service runs automatically from the time your NT machine starts up until it shuts down. At the end of the collection cycle, Performance SeNTry closes the current .smf data logging file to free it up for processing. It immediately opens a new collection file so no collection intervals are lost. At this time you can schedule a process to copy the older collection file to a central location for consolidation and processing. This may involve setting up a connection to a remote drive on a machine you designate as a central collection file consolidation point and scheduling a program to move the old collection files to that machine at regularly scheduled times.
If the machine being monitored is behind a firewall, it may be necessary to run a simple ftp script to consolidate the daily data files.
Once NTSMF is installed and you are able to collect and process Windows performance data on a consistent basis, it is a good idea to familiarize yourself with some of the more important data elements that you will be collecting with NTSMF. There are several ways to approach this.
To help you get started, we produced an annotated list of some of the more useful Performance Counters, which also documents some of the common gotchas that you can read more about online in this FAQs section.
The Default Data Collection set (DCS) is enabled at the factory and runs until you assign your own DCS. This is a good, general purpose set of metrics to collect and is consistent with the built-in report templates that are included with Performance Gallery. There is an extensive set of documentation that accompanies these report templates which is included on your Performance Gallery CD. We recommend you read this document both for tips on what kinds of reports to build if you are not using Performance Gallery and for an overview of the most important performance Counters that you will encounter.
If you want to get involved at a deeper level with the interpretation and analysis of NTSMF performance data, we recommend that you pick up a copy of the Microsoft Server 2003 Resource Kit. The Resource Kit contains a volume written by Mark Friedman on server performance and tuning. Mark is the founder of Demand Technology, and he worked with Microsoft technical staff to create this volume, drawing from his extensive experience using the NTSMF data to analyze the performance of Windows machines.
Everything you need to monitor Windows NT/2000/XP servers running MS Exchange, SQL Server, IIS, or any other application is included in NTSMF. You only need to assign a Data Collection set (DCS) appropriate to the application that runs on these machines to start gathering data on these applications, too.
Version 2.4.6 or above of the NTSMF collector solves all known issues with Windows Server 2003 systems. We strongly suggest you upgrade to version 2.4.6 or above if you are running NTSMF on any systems with Windows Server 2003 installed. You will always get better results if you are running the most current version of the product.
While earlier versions of NTSMF version 2.3 and version 2.4 are compatible with Windows Server 2003, version 2.4.6 will perform much more reliably in many Windows Server 2003 environments.
Version 2.4.3 or above of the NTSMF collector solves all known issues with Windows 2000 systems. We strongly suggest you upgrade to version 2.4.3 or above if you are running NTSMF on any systems with Windows 2000 or Windows XP installed.
While earlier versions of NTSMF version 2.3 and version 2.4 are compatible with Windows Server 2003, version 2.4.6 will perform much more reliably in many Windows 2000 environments. The new threaded architecture of the version 2.4.3 collection agent was specifically designed for Windows Server 2003 systems. It detects and recovers from most of the problems that are prevalent in Windows Server 2003 due to balky Perflib DLLs.
Version 2.4.3 of the NTSMF collector . Architecturally, Windows XP is quite similar to Windows 2000. New Windows XP Counters are also supported in NTSMF version 2.4.3.
Yes. Microsoft Corp. defines a server “cluster” as a group of independent servers managed as a single system for higher availability, easier manageability and greater scalability. The minimum requirements for a server cluster, according to Microsoft, are (a) two servers connected by a network, (b) a method for each server to access the other’s disk data, and (c) special cluster software like Microsoft Cluster Server and Microsoft Advanced Server Windows NT 4.0 or Advanced Server Windows 2000.
Running NTSMF under MS Cluster Server Windows NT 4.0
The process to run NTSMF under a Windows NT 4.0 cluster environment is very simple:
This ensures that the NTSMF Collection Service is notified of the failover operation and to restart collection of shared resources managed by the surviving and new server owner.
Running NTSMF under MS Cluster Server Windows 2000
To run NTSMF under a Windows 2000 cluster environment is even simpler:
It is recommended that the Performance SeNTry service starts after the MS Cluster Server is started so that NTSMF can “see” the presence of cluster share drives and logical disk in the respective nodes. This service dependency can be accomplished by adding a “DependOnService” registry value under:
HKLM\System\CurrentControlSet\Services\Dmperfss
At typical collection intervals (we recommend at least once per minute), NTSMF overhead is well under 1% of a single processor. Chapter One of the User's Manual contains a lengthy discussion of Windows 2000 performance monitoring overhead considerations.
You can expect data files on the order of 2-4 MB daily. If you find that your daily .smf data files are significantly larger and that amount of data is causing unacceptable problems and delays in post-processing, there are several approaches that you can use to trim them back in size without sacrificing clarity and detail.
Review your Filter definitions.
The Filter definitions that you activate can have a major impact on the size of the .smf data files that you collect. If you are collecting an excessive number of process instance records, check your Process Filter settings. By raising the threshold for collecting data a little bit you might be able to reduce the amount of data in the file considerably.
If you find that it is the high volume of Object instances other than Process that is causing the problem, please contact Customer Support and send us a copy of your data file. We are always looking for ways to make the filtering process more intelligent.
Use the Summarization Utility
Running the Summarization Utility before you post process the .smf data file can reduce the amount of data to be processed significantly. We developed the Summarization Utility because performance management and capacity planning both work off the same source data, but at different levels of granularity. To spot performance problems and diagnose, you need detailed data. To do trend long term capacity requirements, you need summary data. Problem diagnosis normally requires recording measurement data at one minute intervals, while capacity planning trending can often work with 15, 20, 30 or 60 minute intervals. To reconcile both needs, collect detailed data for performance management, invoke the Summarization Utility at Cycle End to reduce the size of the data file, and then transmit the summarized file for post-processing.
Output files generated by the Summarization Utility conform in all respects to the original NTSMF data file format, except that the collection interval between data records is longer. They are managed by the same hierarchical file management parameters that control the automatic archiving and deletion of the detail files. Remember that the the Summarization Utility requires the use of the Type 6 Counter Type format records to summarize the input data correctly.
We write text files, comma delimited by default, in an open, documented format that can be easily read in almost any application. To make it easy for third party products to process our data, we developed a self-defining file format. At the start of each file, we write Configuration records and other identifying data. Then we write the dictionary records (or Format Records) which describe the contents of the file to follow. Then we write the actual data records that are collected each measurement interval. Each Object instance is written as a separate data record. Data fields have a default precision of two decimal places, but whenever more precision is required, we write the data field with an explicit decimal point.
Appendix B of the User Manual provides a complete description of the NTSMF file format.
There are a number of reasons why NTSMF may not be collecting some performance Counter or Counters that you need to look at. Sometimes the reason is fairly trivial and easy to rectify. Sometimes the reason is more difficult to determine. Sometimes, it is a problem with the NTSMF collection service itself, which we want you to report to us as soon as possible, with all the supporting documentation we will need to resolve it.
Ever notice all those Messages that the NTSMF collection service writes to the Application Event log and the <computername>.ntsmf.log file? These messages are designed to help diagnose data collection problems. By reviewing the Collection service Event log Warning messages that document most of the more common data collection anomalies that occur, you can usually identify and resolve a data collection problem quickly. This FAQ tells you how to use these Warning messages to solve data collection problems.
Please follow this simple procedure whenever you have a problem collecting data. First, answer the question below, and proceed to the next page of instructions based on your answer.
Is the Counter you need visible using the Microsoft System Monitor?
Start an interactive System Monitor session and see if the Counter or Counters you need are visible.
If the Counter you need is visible in System Monitor, the NTSMF collection service should also be able to collect it.
If the Counter value you need is not visible in System Monitor, the NTSMF collection service probably cannot collect it either. However, it is quite possible that NTSMF will generate a diagnostic error or Warning message that will help you understand why the data you are interested in cannot be collected.
Note that beginning in NTSMF version 2.4.5, the NTSMF collection agent does not honor the Disable Performance Counters Registry flag when it is set. Neither will any action performed by the NTSMF collection agent ever cause the Disable Performance Counters Registry flag to be set. However, when the Disable Performance Counters Registry flag is set, it may indicate there is an underlying problem with a Performance Library DLL that could effect NTSMF's ability to gather the associated performance data.
Instead of Disable Performance Counters, NTSMF version 2.4.6 and higher utilizes a comparable facility that allows you to specifically exclude Performance Library DLLs that are troublesome. Specific Performance Library DLL excludes and includes are noted in a configuration file named DmPerfss.cfg.
The Disable Performance Counters flag is used in Windows 2000, XP and Server 2003 to block calls to the Performance Library DLL via the standard Registry, Performance Data Helper, and WMI interfaces to gathering performance data. The NTSMF Collection service honors the Disable Performance Counters flag in versions prior to 2.4.5. The Disable Performance Counters flag stops NTSMF from attempting to call the disabled Performance Library DLL in versions prior to 2.4.5. If the the Disable Performance Counters flag is set in the Registry Performance key for the Performance Library DLL responsible for serving up the Object/Counter you are missing, NTSMF versions prior to 2.4.5 will honor this flag and not attempt to collect any data from the disabled Performance Library DLL.
NTSMF version 2.4.5 and higher does not honor the Disable Performance Countersflag. Instead of Disable Performance Counters, NTSMF version 2.4.6 and higher utilize a comparable facility that allows you to specifically exclude Performance Library DLLs that cause collection problems. When specific Performance Library DLLs fail to return properly when Opened or create other anomalies because they cannot be shared properly when the NTSMF collection agent does open them, you can exclude them from all NTSMF-related processing. Instructions to exclude specific Performance Library DLLs are contained in a configuration file named DmPerfss.cfg that is stored in the NTSMF root directory.
Performance Library DLLs are the software modules installed on the machine responsible for gathering specific performance data. These modules are not installed by NTSMF -- some are installed as part of the operating system and some are installed by various applications. There is one specific Performance Library DLL responsible for gathering data for each performance Object and its Counters. (Many Performance Library DLLs gather data for more than one Object.) NTSMF calls the Performance Library DLLs each collection interval to gather the performance data you specified in the DCS Data Definition.
During its Discovery phase at the beginning of each collection cycle, the NTSMF collection agent inventories the Performance Library DLLs installed on the local machine and tries to match them up against the DCS Data Definition that specifies which performance Objects and Counters you want to gather. In this fashion, the collection agent figures out which Performance Library (Perflib) DLLs to call to gather the performance Objects and Counters you specified in the Data Collection set Data Definition.
Performance Library DLLs are identified by entries in the Registry under HKLM\SYSTEM\CurrentControlSet\Services\<servicename>\Performance. If you look through the HKLM\SYSTEM\CurrentControlSet\Services\subkeys using the Registry Editor, you will normally find many Perflib DLLs defined. A typical example is reproduced below for the perfdisk.dll Perflib, which is responsible for gathering disk performance statistics from the diskperf filter driver.:
The fields in the HKLM\SYSTEM\CurrentControlSet\Services\<servicename>\Performance key identify the Library module name and the entry points that the Performance SeNTry collection services calls for the Open, Collect, and Close functions.
Like any complex piece of software, Performance Library DLLs can malfunction. The OpenTimeout value in the HKLM\SYSTEM\CurrentControlSet\Services\<servicename>\Performance key, for example, determines how long an application like System Monitor will wait during its Discovery phase for a call to a Perflib DLL's Open routine to return. If a call to a Perflib DLL's Open routine does not return within the prescribed amount of time, the operating system software responsible for communicating with Perflibs DLLs aborts the call to the Open routine and sets the Disable Performance Counters flag to disable the Perflib DLL.
According to the official Microsoft documentation in the Windows 2000 Resource Kit,
The Performance Library (Perflib) uses [the Disable Performance Counters flag] to disable counters that cause serious errors. This prevents the troublesome counters from jeopardizing the display of all performance counters on the system. You can use this entry to reenable the counters for a service after the counter DLL has been repaired or replaced.
A Resource Kit Performance tool called Extensible Counter List (exctrlst.exe) can be used to check for all Perflib DLLs that are disabled. This tool is illustrated below:
Using the Extensible Counter List tool from the Resource Kit, you can manually disable a malfunctioning Perlib DLL or re-enable a Perflib DLL after you have found and fixed the problem that caused it to become disabled in the first place.
With regard to calling Perflib DLLs to gather Windows performance Counter data, the Performance SeNTry collection agent functions just like other performance monitoring applications, including the built-in System Monitor application that Microsoft supplies. However, there is one critical difference in the way the Performance SeNTry collection service works. The Performance SeNTry collection agent bypasses the operating system software responsible for communicating with Perflibs DLLs that is used by other performance monitoring applications. Instead, NTSMF calls each Perflib DLL directly. Because the threaded collector bypasses the Microsoft-supplied plumbing that other applications like SysMon use to gather data from Performance Library DLLs, the Performance SeNTry collection service is never responsible for a Perflib DLL becoming disabled (with the Disable Performance Counters flag set). If you find that this flag is set and you are running version 2.4.3 or higher of the Collection service, it is because some other performance monitoring application on your system tried to access that Perflib and failed.
Threaded collector. Beginning in version 2.4.3, each call to a Perflib DLL is performed under a dedicated collection thread. We call this version of the collection agent the threaded collector because the main dispatcher thread of the Collection service generates a separate collection thread for each Perflib DLL that it finds installed on the local machine. In the threaded collector, it is possible to detect and recover from most failures involving calls to Perflib DLLs. This allows the NTSMF collection service to continue to function even when there are bugs in third party Perflib DLL modules. In earlier versions of NTSMF that utilized the Microsoft-supplied plumbing to gather data from Performance Library DLLs, it was not always possible to determine which Perflib DLL had failed or to recover from some Perflib DLLs failures.
Because we found the Disable Performance Counters flag mechanism was a nightmare to administer, beginning in version 2.4.2, the NTSMF Collection agent generates a Warning message whenever it encounters a disabled Perflib DLL during the initial Discovery phase of a collection cycle. A typical Warning message that is written to the Application Event log is illustrated below:
Please note that the collection service generates this Warning message each and every collection cycle until the the Disable Performance Counters flag is reset manually using the Extended Counter List utility discussed above. We have found that Perflib DLLs are sometimes disabled for relatively trivial reasons and there is little harm in re-enabling them and trying again with NTSMF. However, if the problem with the Perflib DLL persists, it is something that should be investigated with the supplier of the malfunctioning module.
A performance data Object called Module is created internally, when you include the Module Object in your Data Collection set data definition. Each instance of the Module Object shows a load module name, usually a DLL (dynamically linked library module) that is loaded within the specific process. The Module Object also has a parent instance, which is the name of the process that has loaded the module.
The Module data is for identification purposes. The only Counters available for each Module are the process ID, which is used to identify the parent process uniquely, and the Load Address of the Module within the parent process virtual address space.
The Module data is intended to assist in identifying the application being executed within a container process, which is something we notice occurring more and more frequently in Windows 2000 and XP. There are three specific container processes that you are likely to collect Module Object information about: mtx.exe in Windows NT 4.0, dllhost.exe in Windows 2000 and XP, and svchost.exe in Windows 2000 and XP. The function of these container processes is described below:
mtx.exe is a container processes used by the Microsoft Transaction Server (mts) to execute COM components (which are DLLs). When COM program DLLs are loaded as server components and execute out-of-process, the component is executed inside the mtx.exe container process.
dllhost.exe is the Windows 2000 and .Net Server version of mtx.exe that executes COM+ components. When COM+ program DLLs are loaded as server components and execute out-of-process, the component is executed inside the dllhost.exe container process. dllhost.exe is also used to execute Active Server Pages application scripts in IIS 5.0 in separate container processes, when Medium or High Application Protection is specified. Medium Application Protection, a runtime option introduced with IIS 5.0 and is the default setting, leads to all ASP script running inside a single copy of dllhost.exe. When a High level of Application Protection is chosen, each ASP script executes in an isolated instance of dllhost.exe. ASP scripts can be identified inside dllhost.exe by looking for the presence of wam.dll.
svchost.exe is used in Windows XP to host system services like Browser, Redirector, and Server. In Windows XP, those system services that used to execute within the services.exe container process in earlier versions of Windows NT, are arrayed across multiple instances of the svchost process, each executing under a different security profile, either SYSTEM, LOCAL SERVICE, or NETWORK SERVICE.
If you are experiencing application-related performance problems and notice lots of mtx.exe or dllhost.exe processes executing, use the Module function to identify which applications were running inside which container processes. During reporting Merge the Module instance with the parent process, using the ID Process field to uniquely identify specific processes, and replace the generic process name with the Module instance name.
Unless you are prepared to deal with much larger NTSMF data files than usual, you should use appropriate filter settings when you collect Module data. Collecting the Module information is costly, and the average Windows 2000 executable routinely loads 50-100 assorted DLLs. Please be careful with this new function and implement a Module filter for all container processes that you need to resolve.
A screen shot that illustrates how the Module filter works is shown below in Figure 1:
Figure 1.
This filter definition instructs the collector to report Module instances only for the dllhost.exe and svchost.exe processes. In addition, only the specific Module instances named will be collected, which is the information needed to identify the application running inside these container processes.
On a typical Windows XP or .Net Server machine, you will several instances of the svchost container processor executing. svchost is a container process that hosts various system services. Different services run in different copies of svchost depending on their security requirements. You will see them identified with different Used Names in Task Manager, for example. For instance, services that do not need network access with execute inside a copy of svchost that executes under the security profile associated with local service. Other copies of svchost run under the SYSTEM or NETWORK SERVICE. In order to figure out which services are running inside which copy of svchost, use this Module filter definition to identify modules that are unique to a specific instance of svchost.
With this filter definition active, we expect to report:
one instance of the Module Object for browser.dll associated with a specific svchost.exe parent process and
another instance of the Module Object for rpcss.dll associated with a different svchost.exe parent
another instance of the Module Object for regsvc.dll associated with a different svchost.exe parent
another instance of the Module Object for winspool.drv associated with a different svchost.exe parent
Using the SAS Merge function, you could then report process level statistics for the svchost container process by application.
Similarly, for dllhost.exe, filtering on wam.dll will allow you to identify specific instances of dllhost that are executing ASP script code. COM programs executing inside the mtx.exe container process and COM+ programs executing inside the dllhost.exe container process can be identified, too, if you build a filter list of component application DLLs. To populate the Module filter list, use the "Browse for Modules" function to point to a folder where these component application DLLs reside in your installation. You should wind up up with something that looks like the Module Filter definition in Figure 2:
Figure 2.
The effect of this filter is to report a Module instance associated with each process instance of dllhost.exe where the COM+ components dasserver.dll or gam.dll are loaded.
To populate the Module filter list that is illustrated in Figure 2 for either dllhost.exe or mtx.exe, use the "Browse for Modules" function to point to a folder where these component application DLLs reside in your installation. If necessary, use the Component Services Explorer (CSE) applet, illustrated in Figure 3, to locate the names of the COM+ modules that want to resolve. (CSE is available under Administrative Tools.)
Figure 3.
Using CSE, drill down to Component Services, My Computer, and determine what COM+ Server applications are installed. COM+ Server applications are identified by an icon that shows the component residing inside a box, which represents the dllhost.exe (or mtx.exe) container process (e.g., IIS Out-of-Process Pooled Applications). The icon for COM+ Library applications shows the component being loaded into the calling process (e.g., IIS In-Process Applications). If you are not sure if the COM+ component is a Library or Service application, right-click to access the Component Properties and check the Activation tab, as illustrated in Figure 4.
Figure 4.
Only COM+ Server applications that are activated in a dedicated local server container process (dllhost.exe or mtx.exe), as shown, need Module name resolution.
Finally, find out the COM+ component module name so that you can prepared the Module Filter definition. Drill down to the COM+ Components and right-click to access Component properties. Under the General tab, illustrated in Figure 5, the fully qualified DLL module name is shown. Enter the Module name shown, without any elements of the path, in the dllhost.exe or mtx.exe Filter definition.
Figure 5.
In this example, the GAM.dll, a COM+ component associated with the Microsoft sample FMStocks application, is defined as a Server application. When the FMStocks application calls this component, it executes inside an instance of dllhost.exe. When the NTSMF collection services finds an instance of dllhost.exe with gam.dll running inside it (the module name is not case-sensitive), it generates a Module Object instance associated with gam.dll, that shows a parent instance of dllhost.exe. Since there are likely to be multiple copies of dllhost.exe executing, the Module instance record contains an ID Process Counter that identifies the unique instance of the dllhost container process where the Module is loaded and executing. In reporting on COM+ components, we suggest you Merge the Module name with its associated Process records, based on ID Process, and report the Module name, rather than the uninformative name of the dllhost container process.
No, to function properly the NTSMF collection service should be set up to run under the LocalSystem (or SYSTEM) account. The LocalSystem (or SYSTEM) account is a built-in account used by many services with an extraordinary level of privileges for accessing local system resources. These include privileges that cannot be granted to any User Account, include members of the Administrators group. The NTSMF collection service requires these SYSTEM-level privileges for some data collection functions.
More specifically, the Module collection function requires the PROCESS_QUERY_INFORMATION process-specific access right, which can only be granted programmatically by a process running with System level privileges to begin with. Unfortunately, there is no User Right that you can grant a User Account that allows the Performance SeNTry collection service to execute the EnumProcessModules Win32 function call it makes to enumerate all the modules loaded in a process.
You can run the NTSMF collection service under a User Accountby following the guidelines discussed below. All collection service functions will execute normally, once you grant the User Account the appropriate User Rights and Permissions. However, the Module collection function, introduced in version 2.4.4 will not run under a User Account. In order to collect Module identification data, you must run under the built-in LocalSystem (or SYSTEM) Account.
Yes.
By design, the NTSMF collection service (dmperfss.exe) is installed to run under the built-in LocalSystem (or, XP or .Net Server, SYSTEM) account. This built-in account, which most services use, has the authority to perform almost any internal function on the local machine. However, the LocalSystem account has no built-in facilities to access secure network resources, such as shared network folders.
The NTSMF collection service performs two sets of functions where security considerations may apply:
There are two ways to authorize the collection service to perform these secure functions:
Impersonation allows the collection service to adopt temporarily a different security identifier (SID) than the the one specified when the service is started. You assign the User Account and Password that the collection service will impersonate when you install the collection service. The User Account you assign will be used whenever the collection services performs any function that might need to done under a security context other than LocalSystem (or SYSTEM). If you assign a User Account and Password during installation of the collection service, the collection service will impersonate that User Account when it launches the Cycle End command. This allows the Cycle End command or script to execute under a User Account that is authorized to perform network file operations on a secure shared folder. In addition, if the NTSMF \data\ Folder is protected from uncontrolled access by the LocalSystem account, you may need to assign NTSMF a User Account to impersonate when it performs any function that accesses the \data\ Folder.
You assign the User Accountto be impersonated during NTSMF collection service installation using the -account and -password options, as illustrated below:
dmperfss -install -f MyDCS.dcs -account DomainName\myAccount
-password xxxxxxx
For more details, see Chapter 2 of the User's Manual.
OK, you asked for it. If you do not need to gather Module identification information, you can run the Performance SeNTry collection service under a User Account. You can only set the NTSMF collection service to run under a User Accountmanually using the Services Administrative Tool, which is illustrated below:
To function correctly, the User Account that the NTSMF collection service runs under requires the following User Rights:
 |
Logon as a service |
|
Increase scheduling priority |
with the following Registry Key Permissions (in Windows 2000 and above):
 |
Read access to the Registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib |
|
Read access to the Registry key HKLM\\SYSTEM\CurrentControlSet\Services |
|
Control access to the Registry key HKLM\\SYSTEM\CurrentControlSet\Services\Dmperfss. Note that this Registry key is created by the system's Service Control Manager when the Performance SeNTry collection service (dmperfss.exe) is installed. |
A sample installation script that installs the the Performance SeNTry collection service under a User Account and grants these local Registry Key Permissions to the Account is shown below. The subinacl utility used here to grant Registry Key permissions is available in the Windows 2000 Resource Kit.
net stop "Performance SeNTry"
dmperfss -remove
dmperfss -install -fdevncci.dcs -accountdomain\username -passwordpassword
subinacl /verbose /keyreg "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib" /grant=domain\username
subinacl /verbose /keyreg "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009" /grant=domain\username
subinacl /verbose /keyreg "SYSTEM\CurrentControlSet\Services\DMPerfss" /grant=domain\username
subinacl /verbose /keyreg "SYSTEM\CurrentControlSet\Services\DMPerfss\Control" /grant=domain\username
subinacl /verbose /keyreg "SYSTEM\CurrentControlSet\Services\DMPerfss\Security" /grant=domain\username
net start "Performance SeNTry"
and with the following Folder Permissions:
 |
Control access to the NTSMF \data\ Folder and subFolders where the .smf data file is written. |
|
Control access to any shared Network folders that the Cycle End Command or command script requires access to. |
In addition, some Performance Library DLLs that the Performance SeNTry collection service will attempt to load and run may reside in secure folders. You will need to grant the User Account the collection service runs under Read access to the folders. During the Discovery phase of each collection cycle, when the collection service attempts to load the Perflib DLL modules, the Load will fail. You will see a Warning message similar to the following in the Application Event log or the local <computername>.ntsmf.log message file:
In this example, in order for the Performance SeNTry collection service to load the SQLCTR80.dll Performance Library DLL that is responsible for gathering SQL Server 2000 performance Objects and Counters successfully, you must first grant Read Access to the C:\Program Files\Microsoft SQL Server\MSSQL\Binn Folder where SQLCTR80.dll resides to the NTSMF agent User Account.
