Version 2.4.7 of the Performance SeNTry (NTSMF) data collector will not execute if DEP is active. This does not apply to versions after 2.4.7

For details and options, see this Technical Note.

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 during the Discovery phase at the beginning of every collection cycle. (Follow this link for more .) Each Open and Collect call to a Perflib DLL is performed under a dedicated collection thread. With the threaded collector, it is possible to detect and recover from most failures involving direct calls to Perflib DLLs, sometimes even when calls via the Microsoft PDH and WMI plumbing that other products use, including System Monitor, fail. Under normal circumstances, the NTSMF collection service continues to gather performance data even in the face of buggy, third party Perflib DLL modules.

There are extenuating circumstances when it is desirable for the NTSMF collection agent to ignore completely specific Performance Library DLLs that are defective and perform no processing on these modules. Performance Library DLLs that malfunction in the following ways are candidates for exclusion from all NTSMF processing :

• The Perflib fails to return properly from any Open or Collect call and causes the collection agent, the application being monitored, or the system to hang.
• When NTSMF successfully opens the Performance Library DLL, the module cannot be shared properly with other applications that also attempt to Open them.

When defective Perflibs are excluded from processing, the NTSMF collection agent does not attempt to load the DLLs or call their Open routines during the Discovery phase at the beginning of every collection cycle. You exclude these defective Perflibs from all NTSMF-related processing using entries in the DmPerfss.cfg configuration file.

Note: the use of the the DmPerfss.cfg configuration file is optional. A default DmPerfss.cfg configuration file is installed automatically when you run the standard software Setup routine. The default DmPerfss.cfg configuration file contains entries for Performance Library DLLs that we have seen cause severe problems in some of our customer sites. We recommend that you install and use the default DmPerfss.cfg configuration file.  You can modify the defaultDmPerfss.cfg configuration file using any text editor if you determine there are additional Performance Library DLLs that need to be excluded from NTSMF processing. We recommend that you contact Customer Support before you make modifications to the DmPerfss.cfg configuration file for your environment. If you are having a problem, there may well be other solutions to consider. If the Performance Library DLL is defective, we might like to let other customers know about it.

The <Perflibs> section of the DmPerfss.cfg configuration file can contain an Exclude list and an Include section. These sections identify specific Performance Library DLLs by module name (and optionally by version) that are to be excluded or included for processing at the beginning of a collection cycle.

Exclude list. The Exclude list causes the collector to exclude the modules listed (by version, if specified) from all NTSMF collection agent processing. The collection agent will not attempt to load a Perflib DLL module on the Exclude list at the beginning of a collection cycle. The Version specification is optional. Module entries without a version specification cause all versions of the Perflib DLL to be excluded. If specific Perflib DLL module versions are to be excluded, then they must be listed in the Version section. If there are duplicate entries, the Exclude list takes precedence over modules on the Include list .

Code a <Module FileName=”filename“></Module> section for each Performance Library DLL that you want to exclude from processing. Optionally, you can add one or more <Version> specifications that qualify which versions of the Performance Library DLL should be excluded. If the <Version> specification does not exist, any version of the Performance Library DLL that is found is excluded.

An example DmPerfss.cfg configuration file with an Exclude list is coded below:

<PerfLibs>

<Exclude>
<! — Sybase ASA object –>
<Module FileName=”dbctrs8.dll”></Module>

<!– .NET CLR Data, NET CLR Networking –>
<Module FileName=”netfxperf.dll”><Version>1.0.3215.11</Version></Module>

<!– .NETFramework –>
<Module FileName=”mscoree.dll”><Version>1.0.3215.11</Version></Module>

<!– FileReplicaConn, FileReplicaSet –>

<Module FileName=”NTFRSPRF.dll”><Version>5.1.3590.0</Version></Module>

<!– WmiApRpl –>
<Module FileName=”wmiaprpl.dll”><Version>5.1.3590.0</Version></Module>

<!– Lotus Notes –>
<Module FileName=”nnotes.dll”> </Module>

</Exclude></PerfLibs>

Text inside a <! This is a comment > Comment section is ignored.

During the Discovery phase at the start of every collection cycle, the DmPerfss.cfg configuration file is processed to determine what Performance Library DLLs should be excluded from processing during that cycle. An Event ID 214 Informational message is written to the <computername>.ntsmf.log file that documents the Performance Library DLLs that were specifically excluded from processing, as illustrated below:

08/02/04-00:00:11 – Event ID: 214, Category: Discovery, Severity: Info

The following Performance Libraries are excluded from processing as specified in DmPerfss.cfg. Performance data from these libraries will not be available this cycle.
.NET CLR Data (.NET CLR Data), “netfxperf.dll”, version 1.1.4322.573
.NET CLR Networking (.NET CLR Networking), “netfxperf.dll”, version 1.1.4322.573
.NETFramework (.NETFramework), “mscoree.dll”, version 1.1.4322.573
WmiApRpl (WmiApRpl), “C:\WINDOWS\System32\wbem

Error Messages. In the case of errors accessing the DmPerfss.cfg configuration file, the configuration file is ignored and collection cycle processing proceeds as if theDmPerfss.cfg configuration file did not exist.

If the the DmPerfss.cfg configuration file is invalid, then the following Warning message is written:

08/02/03-00:50:13 – Event ID: 96, Category: None, Severity: Warning
The configuration file failed to open.
The Inclusion/Exclusion list will not be used this cycle.

If the DmPerfss.cfg configuration file contains syntax errors, then the following Warning message is written:

08/02/03-00:50:13 – Event ID: 96, Category: None, Severity: Warning
Failed to load, “E:\DmPerfss 2.4.6\bin\Debug\DmPerfss.cfg”.
Parse error, 0xC00CE503, encountered on line, 25, at position, 14.
Reason = Incorrect syntax was used in a comment.

Unfortunately, there is not much written that documents AD performance issues and how to use these counters. This TechNet overview article is a good place to start. There are two main objects to monitor:

1. Information related to the NTDS Object:

http://technet2.microsoft.com/windowsserver/en/library/6a2abace-5fab-49f0-8c6d-5daea891a5f71033.mspx?mfr=true

2. Information related to the Database Object:

http://technet2.microsoft.com/windowsserver/en/library/26bfde1e-7938-4573-b12f-6e4e9cedf4a51033.mspx?mfr=true

The following represents Microsoft’s recommendations when monitoring Domain Controllers:

http://technet2.microsoft.com/windowsserver/en/library/c5d72b6f-5974-4263-b29f-2eece0ab44371033.mspx?mfr=true

It will at least help you get acquainted with the basic terminology that AD uses.

In semiconductor fabrication, “stepping” refers to the chip manufacturing process which is called a stepper that deposits successive layers of etched material conducting material and insulation. Our best guess is that this is an internal reference to the plant/stepper technology that produced the chip.

The CPU configuration data in the Registry is actually a narrow subset of the information Intel places in WMI today. See for example, http://msdn.microsoft.com/en-us/library/aa394373.aspx for the complete win32_processor spec. See the table that documents the processor family. However, most of these fields are null when you query them in WMI, as in the following script, for example:

Set colSettings = objWMIService.ExecQuery _

(”SELECT * FROM Win32_Processor”)

For Each objProcessor in colSettings

    Wscript.Echo “System Type: ” & objProcessor.Architecture

    Wscript.Echo “Processor: ” & objProcessor.Description

    Wscript.Echo “Family: ” & objProcessor.Family

Next

will return a Processor Description identical to what is contained Registry, but Processor.Family is null.

There is a a new field available for some of Intel’s newer processors at HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString that may provide you with what you are looking for.

You can harvest this Registry value using the NTSMF Registry data collection feature. Add the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString field name to the Registry values on the DCS Parameters “File Contents” Tab, as in the following illustration:

to gather the information stored in this Registry field.

The Performance Sentry Collection Service performs two sets of functions where security considerations may apply:

1. Control the Performance Sentry data and log files in the \data\ Folder. You can normally tell that the NTSMF \data\ Folder is protected from uncontrolled access by the LocalSystem account if the service terminates prematurely at start-up and no <computername>.ntsmf.logfile is generated in the NTSMF \data\ Folder. 
2. Execute the Cycle End command or command script. The Cycle End command or command script runs in a separate process that inherits its Authority from the Performance Sentry service process that creates it. If the Cycle End command or command script fails to complete successfully, but works fine when you execute it under your Logon Account, your Logon Account probably has Folder Permissions that are not granted to the LocalSystem account.

There are two ways to authorize the collection service to perform these secure functions:

1. If you have implemented Active Directory, it is possible to grant the LocalSystem (or SYSTEM) Account the Folder Permissions required to access secured network resources. The LocalSystem Account corresponds to the named Computer in Active Directory. However, some installations prefer not to grant the LocalSystem (or SYSTEM) Account any Folder Permissions.
2. You may assign a User Account with access to the appropriate network resources that  the collection service will impersonate whenever it performs one of the two secured functions discussed above.

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 Performance Sentry a User Account to impersonate when it performs any function that accesses the \data\ Folder.

You assign the User Account to be impersonated during the Performance Sentry Collection Service installation using the -account and -password options, as illustrated below:
     dmperfss -install -f MyDCS.dcs -account DomainName\myAccount -password xxxxxxx

You may also assign the User Account by using the automation interface command dmcmd.exe found in the root NTSMF folder: 
     dmcmd.exe -account DomainName\myAccount -password xxxxxxx

For more details, see Chapter 2 of the User’s Manual.

Performance Sentry Administration is used to assign Data Collection Sets (DCSs) to machines running the data collection service.  An administrator has two options when assigning data collection sets to machines: The first one is called a Registry DCS and the second a File DCS. The Registry DCS parameters are written to the Registry key: “HKEY_LOCAL_MACHINE/SOFTWARE/DemandTechnology/PerformanceSeNTry/CollectionParameters”

These parameters are read by the Performance Sentry Collection Service  (Dmperfss.exe) for processing. The File DCS is simply the same information written to a file with the file extension of “.DCS”.

Under Windows 64-Bit machines the registry configuration has changed a bit. There is a new level of registry keys introduced called Wow6432Node to support native 32-bit Windows applications.  Because Sentry Administration is a 32-bit application it writes to the Wow6432Node.  The new registry hive now looks like:

“HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/DemandTechnology/PerformanceSeNTry/CollectionParameters”

Thus, Sentry Administration performs its function of assigning a DCS and successfully writes to the registry However, since the  Collection Service is running in 64-bit mode, it reads the root key looking for DCS information, but does not traverse the Registry hive any further and does not find the information written in the Wow6432Node sub-key.  Therefore, the collector defaults to operate with internal parameters.   If you display the collection service status in Sentry Administration after attempting to assign a collection set in a 64-bit Windows environment, you will see the following screen:

Solution:

The collection service will be modified in the near future to look in the Wow6432Node sub-key, if no Performance Sentry key is found in the root key.

In the meantime, as a workaround to this limitation, we recommend using the File DCS process when assigning a new DCS to a 64-Bit machine.

You can do this by implementing the following steps:

1.      From the DCS Administration pane, highlight the DCS you want to export.
2.      Right-Click on the DCS and select Export DCS
3.      Export the DCS to the NTSMF31 root folder on the x64 target machine.
4.      From the Network Browser window, select the machine where you exported the File DCS.
5.      Right-Click and select Exported DCS and navigate and select the exported DCS.
6.      Once you assign the new File DCS the machine being managed should turn green indicating it operates with a File DCS.
7.      You can verify that the new file DCS is in use by right clicking on the machine in the Network Browser window and selecting ‘Display Collection Service Status’.

Contact support@demandtech.com if you have any questions on assigning a Data Collection Set in a Windows 64-bit environment.

There is another MS KB entry that specfically discusses “HarddiskDmVolumes” names. See
http://support.microsoft.com/?kbid=274311. This KB article explains that after you convert a hard disk from Basic to Dynamic, the volumes on that hard disk are not identified by their drive letter in System Monitor. Instead, volumes that are displayed in System Monitor in a form similar to the following:

HarddiskDmVolumes\MachineName\Volume#

You need to re-assign drive letters to dynamic disks after you convert them so that the drive letters are reported properly.

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 chart templates that are included with Performance Sentry Portal.

If you want to get involved at a deeper level with the interpretation and analysis of Performance Sentry 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 Performance Sentry data to analyze the performance of Windows machines.

To function correctly, the User Account that the Performance Sentry 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 Server 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 Performance Sentry agent User Account.

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 Performance Sentry collection service under a User Account by following the guidelines discussed here and here.  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.