Get Live Help
Windows 2008 R2 restrictions are more severe then previous Windows versions. Special registry permissions are required to be set, before the Agent OS user is allowed to connect to the remote WMI components.
When an agent connects to a monitored Windows host from a UNIX or Linux machine using WMI, you must make certain registry changes in order to allow the required DCOM services to run.
This KB is a subset of Setting up a DCOM connection for WMI (Windows Management Instrumentation) on host machines (4295692)
Add the required domain\user to the Administrator's group
Windows registry changes are often necessary on the monitored Windows server for WMI connections from Linux-based FglAMs to be successful.
Edit the Registry Key Permissions
In some cases hacking the Registry as described above doesn't help. In such a case, disabling User Account Control (UAC) can solve the issue or at least point to Windows permissions issue which should be checked on the Windows platform itself. In order to disable UAC (from Microsoft):
WbemScripting.SWbemLocator class (WMI locator) is essential to gain administrator DCOM access to the computer. Having DCOM access to this class is very powerful (e.g., you can listen to any kind of events on the machine, you can retrieve performance counters etc…). By default the WbemScripting library cannot be accessed through DCOM because DCOM is not allowed to directly access DLLs. This will not even work when establishing the DCOM connection with administrator credentials. As a workaround, DCOM is can access Executables (.exe) and Windows offers a process named dllhost.exe which can act as a surrogate for libraries to access via DCOM. This means that dllhost.exe can load the WbemScripting.SWbemLocator class, making it available for remote DCOM connections.
COM classes load the Scripting.FileSystemObjects into memory. This is located here. This is used for extracting and writing files, like the error logs in DB2.