How-to configure Windows System Resource monitoring

Posted: April 21st, 2008 | Author: TnT Admin | Filed under: How-Tos | Tags: , , | No Comments »

Let’s dive down to the detail configuration of Windows System Resource monitoring. First, I’m leaving out the configuration in Controller and will be discussing only the monitoring setup outside of LoadRunner. If you want the details for configuring in LoadRunner, I encouraged you to refer to the Controller User Guide that comes along with the installer. (Which I may discuss it if feasible in future).

Second, concepts and fundamentals must be aligned before proceeding and these, can be found in the previous posts, “How does the monitoring work in LoadRunner?” and “4 Monitoring Implementation Models”.

For Windows System Resource Monitoring, it requires (1) port 139 to be opened between Controller to the System Under Test (SUT) in a two-way traffic, (2) Perfmon to be working on the Controller, (3) Perfmon to be working on the SUT and (4) sufficient privileges to monitor the system.

[1] Conventional Setup

So what does it mean? It means you must ensure the following to before going even deeper.

  1. Ping from the command prompt, Run > cmd the SUT from the Controller.
  2. Telnet from the command prompt, Run > cmd the SUT from the Controller on port 139. Command as followed: telnet 139.
  3. Telnet from the command prompt, Run > cmd the Controller from the SUT port 139. Command as followed: telnet 139.
  4. Run Perfmon from SUT and Controller: Run > type “perfmon”.
  5. Ensure that you have a equivalent user account on the Controller as well as the SUT for the perfmon to connect. E.g. if you are using loadtestadmin in Controller, loadtestadmin must exist in the SUT with administrator rights.
  6. When you have successfully launched Perfmon, ensure that you are able to connect to the SUT and Controller vice versa by adding the Controller in the “Select Counters from computer:”. The data should be plotted accordingly.

Perfmon

7. If [1] till [5] was diligently performed and no special exceptions (usually there is), you will be able to monitor the data from the Controller.

[2] Windows 2003 and Performance Monitor User privileges

This is actually a simpler configuration as compared to the initial conventional method. If you have Windows 2003, you can actually assign a privilege for monitoring.

  1. Create a user account on both Controller and SUT. E.g loadtestadmin.
  2. In the SUT, assign the user account with Performance Monitor User privileges! That’s all!
  3. You should be able to monitor from there on Perfmon.

Thanks to Richard Iarrobino that contributed to this from the User Contributed Knowledge Base in the Mercury/HP support.

[3] Monitoring using only User privileges

There are always times that the security policy in the organisation does not permit administrator rights to be given to the load tester. We can assign Performance Monitor User privileges on Windows 2003 but what if we weren’t able to and only User privileges is allowed?

No worries, below is the configuration needed for User privileges to monitor the resources:

1. Create a user account (eg. loadtestadmin) in Windows and grant it User privileges.

2. Allow the lists of registry and policy access for this user.

Required Registry with at least READ access for User Account:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

b. Required group policies with access for User Account:

  • Profile single process
  • Profile system performance

c. If %SystemRoot% is on an NTFS partition, must have at least READ access on the following files for User Account:

  • %SystemRoot%\System32\Perfc009.dat
  • %SystemRoot%\System32\Perfh009.dat

3. You should be able to monitor from there on Perfmon.

NOTE: In order to configure the security settings for the file, turn off “Use simple file sharing (Recommended)” in Windows Explorer > Tools > Folder Options > View > at the bottom of “View all settings”.

[4] Troubleshooting Windows Resource Monitoring

a. Account Lockout

In the event that you encountered a Account Lockout error, you can try the following which is actually extracted from Microsoft site for Windows NT 4.0.

In this release of Windows NT, your user account can become locked out when you try to connect to network resources using the Run dialog box (accessed by clicking Run on the Start menu). When this problem occurs, the following error message appears:

The referenced account is currently locked out and may not be logged on to.

This problem occurs when the following conditions are true:

  • Account Lockout is enabled on the computer you are attempting to connect to.
  • You have an identical account name on the computer you are attempting to connect to.
  • The two accounts have different passwords.
  • You are specifying a UNC path containing both the server and share names (for example, \\Server\Share).
  • You are attempting to connect to the server using the Run dialog box (accessed by clicking Run on the Start menu).

This problem does not occur when you attempt to access a computer that is a member of the domain you are currently logged on to (but which also has a local account name that is identical to yours). This problem is more likely to occur in a workgroup environment or between domains where there is no trust relationship.

This problem occurs because Windows NT attempts the remote logon multiple times instead of displaying the Incorrect Password dialog box. Even if the server administrator increases the number of bad logon attempts that are allowed before account lockout occurs, for example to 10, the problem still occurs. After the sixth logon attempt the Incorrect Password dialog box appears and you are given the opportunity to enter the correct password. However, after you log off, log back on, and then attempt to connect to the same share again, your account is locked out due to the number of previously recorded bad logon attempts. If this problem occurs, map a drive by right-clicking on Network Neighborhood, clicking Map Network Drive, and entering the server and share information in the Path box.

b. Troubleshooting Tips from Mercury/HP

Lastly, you can logged on to Mercury/HP support website to find troubleshooting articles related to Windows Resource Monitor

Some articles that will be useful to you are as followed:

We’ve covered much of the requirements needed for Windows Resource Monitoring and provided tips & tricks, troubleshooting materials from Windows as well as Mercury/HP. They should all be useful in your monitoring setup. However, point to note, if you do encounter into problem, do not limit yourself to the information here and try googling online

Related Posts

Leave a Reply