Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Foglight Agent Manager 5.9.5 - Foglight Agent Manager Guide

Configuring the embedded Agent Manager Installing external Agent Managers
Understanding how the Agent Manager communicates with the Management Server Deploying the Agent Manager cartridge Downloading the Agent Manager installer Installing the Agent Manager Starting or stopping the Agent Manager process Frequently asked questions
Configuring the Agent Manager Advanced system configuration and troubleshooting
Configuring Windows Management Instrumentation (WMI) Configuring Windows Remote Management (WinRM) UNIX- and Linux-specific configuration
Monitoring the Agent Manager performance Deploying the Agent Manager to large-scale environments

Tuning WMI connections

The following parameters can be used to fine tune the Windows Management Instrumentation (WMI) connections made by Foglight® agents. You can set these parameters for Foglight Agent Manager either in the baseline.jvmargs.config file as vmparameter options, or specify them directly as jvm options when starting up Foglight Agent Manager via command line. The values used for these parameters vary from environment to environment and so should be used as reference only.

•
Max Active Connections: Defines the number of simultaneous outbound connections that can be made by all agents running on a particular instance of Foglight Agent Manager. The default value is 100.
Sample: -Dcom.quest.connection.regulator.maxActiveConnectionsCap=500
•
Expire connection based on no. of executions: Defines the number of executions that can be made by a connection before forcibly closing it. The default value is 50.
Sample: -Dquest.debug.poolable.wmi.time.to.live.executions=200
•
Timeout by elapsed time: Defines the time (in milliseconds) after which a connection is expired. The default value is 600000 (10 mins).
Sample: -Dquest.debug.poolable.wmi.time.to.live.timeout.millis=900000

Modifying registry key ownership on Windows Server 2008 R2

Configuring the agent to connect to the remote Windows® Management Instrumentation (WMI) and WinShell components on Windows Server 2008 R2 systems requires certain modifications to the registry keys. In some situations, these registry keys may be owned by TrustedInstaller instead of the Administrators group, which prevents modifications from being made even by Administrator accounts.

 
* 
TIP: It is recommended that you create a backup copy of the Windows Registry that you can revert to prior to making any changes.
To modify the registry key ownership:
1
Using the registry editor, locate the registry key that you need to modify.
2
Right-click the registry key and click Permissions.
3
On the Permissions dialog box, click Advanced.
4
On the Advanced Security Settings dialog box, open the Owner tab.
5
In the Change owner to list, select the Administrators group.
 
* 
IMPORTANT: An error indicating insufficient permissions may appear. To resolve, a user with the administrative account intended to use for profiling can change the ownership of the keys to that administrative account, and then set the permissions to Full on the appropriate registry keys.
6
Click OK.
Ownership of the registry key is assigned to the Administrators group, allowing any member of that group to modify the key’s permissions. For more information about required registry changes, see Configuring registry settings for Windows Server 2008 R2 and Windows 7.

Configuring registry settings for Windows Server 2008 R2 and Windows 7

In order to allow the agent to connect to the remote Windows® Management Instrumentation (WMI) components on Windows Server 2008 R2 or Windows 7 systems, special registry settings are required.

To configure Windows Server 2008 R2 registry settings:
1
If necessary, add the required domain\user to the Administrators group.
a
On the desktop, right-click My Computer and navigate to Groups (My Computer > Manage > Configuration > Groups).
b
Double-click the Administrators group.
c
Add the required domain\user to the Administrators group.
d
Click Apply, and then click OK to close the dialog box.
2
Edit the Wbem Scripting Locator registry key.
 
* 
IMPORTANT: There may be multiple instances of each key, especially for 64-bit versions of Windows Server 2008 R2 and Windows 7. Each instance must be updated.
a
Run regedit.
b
Search for all instances of the keys named:
{72C24DD5-D70A-438B-8A42-98424B88AFB8} (Windows Script Host Shell Object)
{76A64158-CB41-11d1-8B02-00600806D9B6} (WBEM Scripting Locator)
{0D43FE01-F093-11CF-8940-00A0C9054228} (Windows Script FileSystem Object)
There may be multiple instances of each key, especially for 64-bit versions of Windows Server 2008 R2 and Windows 7. Each instance must be updated.
c
For each key, right-click the key and navigate to the owner permissions (Permissions > Advanced > Owner).
d
Click Other Users and Groups, and add the Local Administrators group.
e
Select the Replace Owner on subcontainers and objects check box.
f
Click Apply, and then click OK.
The security screen appears.
g
Select the Local Administrators group and grant full permissions.
 
* 
NOTE: An error indicating insufficient permissions may appear. To resolve, a user with the administrative account intended to use for profiling can change the ownership of the keys to that administrative account, and then set the permissions to Full on the appropriate registry keys.
3
Close regedit.

If configuring the registry does not solve the connection issue, you may need to disable Windows User Account Control (UAC).

To disable Windows UAC:
•
Follow the instructions provided on the following website:
http://technet.microsoft.com/en-us/library/cc709691%28WS.10%29.aspx#BKMK_S3

Resolving Access Denied errors when connecting to Windows XP Professional

When attempting to monitor a Windows® XP Professional machine, the remote agent sometimes fails to connect with an Access Denied error message. This error can be caused by the Windows ForceGuest setting, which is enabled by default on machines that are not part of a domain. To resolve the issue, ensure that remote connections are not being coerced to log on as the guest account by following the procedure below.

To disable ForceGuest for remote connections:
1
In the Start menu, type run.
2
In the Run dialog box that appears, type secpol.msc and click OK.
The Local Security Policy editor appears.
3
Choose Local Policies > Security Options.
4
Select the entry: Network access: Sharing and security model for local accounts.
5
If this entry’s security setting is Guest only, right-click the entry and click Properties.
6
In the dialog box that appears, on the Local Security Setting tab, select Classic - local users authenticate as themselves from the list.
7
Click OK.
8
Restart the computer.

For more information, see step 5 in the following VMWare KB article:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2013

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation