4. Requirements

4.1.   Operating Systems (Local machine where System Tools is installed)

System Tools can be installed on the following operating systems:

  • Windows XP, Windows Server 2003
  • Windows Vista, Windows Server 2008, Windows Server 2008 (R2)
  • Windows 7
  • Windows 8 / 8.1
  • Windows 10, Windows Server 2012, Windows Server 2012 (R2), Windows Server 2016

4.2.   Operating Systems (Remote Host)

System Tools can manage the following operating systems on remote hosts:

  • Windows XP, Windows Server 2003
  • Windows Vista, Windows Server 2008, Windows Server 2008 (R2)
  • Windows 7
  • Windows 8 / 8.1
  • Windows 10, Windows Server 2012, Windows Server 2012 (R2), Windows Server 2016

4.3.   Typical problems.

The remote computer is not Online.
Sometimes the simplest explanation is the best: if a computer is offline you won’t be able to connect to it using System Tools (or using much of anything, for that matter). If you are getting a “Remote server machine does not exist or is unavailable” error the first thing you should do is verify that the computer is actually online; you can do this by trying to ping the remote machine, or by trying to connect to it using a command-line or GUI tool. Difficulties with the network tend to be more common than difficulties with the WMI service; because of that, you should investigate problems with the network before investigating problems with WMI.

Windows Rights.
Because System Tools intensively uses WMI interface to control remote hosts and to execute the actions, it is highly recommended to use Administrator credentials configured in the System Tools settings.
As a regular user (that is, a non-Administrator) you have limited ability to run WMI queries on the local/remote computer; typically, you will be able to retrieve information using WMI but will not be able to use WMI to change settings / execute remote commands.

WMI User Credentials.
Connecting to the WMI service on the local system avoids any issues with user credentials (indeed, it refuses to use them), and will always connect with the account of the user running the WMI query. When connecting to a remote server, however, you can use different credentials to connect.
The simplest case is where the account used to connect to WMI on the remote computer is a domain account in the Administrators group (not necessarily a domain Admin.) Because of User Account Control, the account running the WMI query must be in the Administrators group on the local computer to have the ability to run with elevated rights. This means that the user you connect as must be a domain account in the administrators group, on the
computer you are querying WMI on.
If you are using an account other than your own to connect to remote servers via System Tools, it is recommended that you set “password does not expire” on this user account – otherwise when the password expires, it may block an access.

To use WMI remotely, you must have local Administrator rights on the remote machine. If you do not, access to that computer will be denied.

WMI Service
WMI interface used by System Tools runs as a service with the display name “Windows Management Instrumentation” and the service name “winmgmt”. WMI runs automatically at system startup under the LocalSystem account. If WMI is not running, it automatically starts when the first management application or script requests connection to a WMI namespace. So, if you experienced the problem of controlling remote host, the first thing to check if “Windows Management Instrumentation” is running on remote machine.

Remote Registry Access
The “Remote Registry” service must be running on the remote host(s) for any feature that accesses the remote registry (e.g., Registry, Logons) to work correctly.

User Account Control (UAC)
Even though most features of  System Tools technically wouldn’t require elevated privileges on Microsoft Vista and later,  System Tools has been configured to always require elevated permissions to work correctly. This is to avoid problems with the functionality of the product and to ensure that all included features can be utilized to its full extent.

A Firewall is blocking access to the remote computer.
WMI uses the DCOM (Distributed COM) and RPC (Remote Procedure Call) protocols to traverse the network. By default, many firewalls block DCOM and RPC traffic; if your firewall is blocking these protocols then your script will fail. For example, the Windows Firewall found in Microsoft Windows XP Service Pack 2 is configured to automatically block all unsolicited network traffic, including DCOM and WMI: in its default configuration, the Windows Firewall will reject an incoming WMI request and give you a “Remote server machine does not exist or is unavailable” errorIf you are sure that a computer is online and you know that you have local administrator rights on that computer, then problems getting past a firewall often explain why your script is failing. We can’t tell you how to configure your firewall to permit DCOM and RPC traffic; that obviously depends on the type of firewall you have.  

Because WMI uses DCOM (Distributed Component Object Model) by default to communicate between computers, it doesn’t use a single port – so it’s not easy to allow through firewalls. DCOM uses TCP port 135 to initiate connections, but then dynamically chosen ports are used to actually transfer data.

The actual port numbers are different depending on the version of Windows. On older versions of Windows (i.e. Windows 2000, Windows XP and Windows Server 2003) the dynamically chosen ports are in the range of 1025 to 5000. On newer versions of Windows (Vista, Windows Server 2008 and later) ports are in the range of 49152 to 65535. See this Microsoft article for details. This makes it hard to run WMI through firewalls without opening up a wide range of ports.

The Microsoft built in firewall can deal with the dynamic ports, but by default will block WMI. To enable remote WMI access while using the Windows Firewall:

  • You can use a netsh firewall command at the command prompt to allow for remote administration. The following command enables this feature:

netsh firewall set service RemoteAdmin enable
or (depending on your version of Windows)
netsh advfirewall firewall set rule group=”windows management instrumentation (wmi)” new enable=yes

  •  You can use either the Group Policy editor (Gpedit.msc) or a script to enable the Windows Firewall: Allow remote administration exception. To use the Group Policy editor, use the following steps in the Group Policy editor to enable “Allow Remote Administration”:
    1. Under the Local Computer Policy heading, double click Computer Configuration.
    2. Double-click Administrative Templates, Network, Network Connections, and then Windows Firewall.
    3. If the computer is in the domain, then double-click Domain Profile; otherwise, double-click Standard Profile.
    4. Click Windows Firewall: Allow remote administration exception.
    5. On the Action menu, select Properties.
    6. Click Enable, and then click OK.

There are other approaches to making WMI more firewall friendly – such as limiting the range of ports that DCOM will use via dcomcnfg, or configuring the WMI service to run in standalone mode with a fixed port via WinMgmt.exe /StandAloneHost – but, as in most systems administration tasks, the less things that are changed from default, the less problems you are likely to run into, so we won’t explore these methods.

The version of WMI on your local computer is not compatible with the version of WMI on the remote computer.
Unfortunately, not all versions of WMI are created equal. If you are running Windows XP or Windows Server 2003 (and assuming you have the appropriate Administrator rights and have your firewalls configured properly), you should be able to connect to any remote computer. This is not necessarily the case with older versions of Windows. For example, suppose you have Windows 2000 with Service Pack 1 installed. With this setup you will not be able to connect to a remote computer running Windows Server 2003. Instead, you must have Service Pack 2 (or a later service pack) installed in order to connect to remote machines running Windows Server 2003.

4.4.   Troubleshooting WMI.

WMI is great when it works, but when it doesn’t – it can be frustrating. Generally, the first step is ensuring that WMI works locally, using System Tools. This eliminates any firewalls and username password/domain issues. But even then, you will sometimes run into oddities – in which case these are some things to check.

WMI Services & Dependencies.
All of the following services should be running and set to an “Automatic” startup type for WMI monitoring to work correctly:

  • DCOM Server Process Launcher
  • Remote Procedure Call (RPC)
  • RPC Endpoint Mapper
  • Windows Management Instrumentation

And the following service(s) may be set to a “Manual” startup type:

  • WMI Performance Adapter

Weird Data from WMI.
Sometimes you’ll find that while some WMI queries work fine, some WMI data cannot be retrieved – even for objects that do in fact exist. You may retrieve errors such as “Empty result set”, or the permission error on some objects, but not others.
In this case, Rebuilding the Performance Counter Library may be necessary. Why? Because .. well…, the registry……. Just try it. It does actually fix issues.
If System Tools works locally, but for remote hosts does not – you most likely have either a firewall issue, or are passing in incorrect user credentials. For further WMI troubleshooting advice – see this Microsoft page.

Posted in User Manual Tagged with: , ,
Share ›