Remote Monitoring Account Hints
The most common problem when trying to monitor remote server resources (disks, PerfMon counters, running services, Event Log, etc.) is getting the remote server to allow access to the resources. Windows security won't simply fulfill any requested access issued by any random machine on the network (imagine the chaos!). A token representing the user making the request is sent along with the request. The remote server checks the token against an access control list which protects the target resource and determines whether to allow access or not.
So which user is making the request?
Go to the Services control panel applet (under Administrative Tools), and open the properties for any service. You will see a Log On tab. This tab controls which user account is used to launch the service. All services run as some user. A special user account named Local System is often used which has full access to the local machine, but no access outside the machine. In addition, you can right-click on a computer in the Console and select "Set Login Credentials" to set computer-specific credentials to use when monitoring that computer.
If no computer-specific credentials are entered, then all requests are made as the user which is listed on the Log On tab (also shown in Settings). In the examples below, we assume that there are no computer-specific credentials.
Consider the scenario where machine "OPS" is running a service (like the Power
Admin monitoring service) and wants to look at the Event Log on machine "SERVER". If the service
is running as Local System, the Event Log request would contain a token
referring to user "OPS\Local System". The problem is, machine SERVER doesn't know
anything about "OPS\Local System". For all it knows, that account might be a
simple guest account. Access will be denied.
What solutions exist?
There are two basic ways to get around this
problem, and they both involve getting the request on OPS to run as a user which
SERVER will recognize.
Solution 1
The first solution is to use synchronized username and passwords on the two machines. You can create a user account named "Inspect" on OPS with password "baseball". Then go to SERVER and create a user account named "Inspect" with password "baseball". When user "Inspect" runs the service on OPS, and sends a request to SERVER, the token turns out to contain not just the username, but a hashed form of the password as well. When SERVER receives the request, it checks its local user database and finds a matching user, hashes the local password and finds that they match. It then allows the request as though it had originated from the local user "Inspect". Any access to resources granted to the local user "Inspect" on SERVER can be accessed remotely from the similar user "Inspect" on machine OPS. The downside to this solution is it requires all monitored machines to have synchronized usernames and passwords. This doesn't work for "Local System" because Local System is a special operating system account tied to the local computer (and you can't set Local System's password).
NOTE: Starting with Windows XP a security policy was introduced that causes incoming local credentials (from a remote host) to be assigned Guest user rights. That won't help. You'll need to set the policy back to Classic mode. Microsoft documents this here: [1] and [2]. This can be corrected by switching to Classic file sharing, or by going to Administrative Tools -> Local Security Policy -> Security Settings -> Local Policies -> Security Options. Look for "Network Access:Sharing and Security model for local accounts" and set it to "Classic".
Solution 2
The second solution requires using domain accounts. Imagine that the machines OPS and SERVER are both in a domain named DOMAIN. The domain could then have a user created named "Inspect" for example. The service on OPS should then have it's Log On user set to DOMAIN\Inspect. On SERVER, you would grant access to any resources that should be monitored to user DOMAIN\Inspect (or as a shortcut, make DOMAIN\Inspect part of the local Administrators group). When Server Monitor tries to monitor the Event Log on SERVER for example, a token representing DOMAIN\Inspect will be passed with the request. SERVER will recognize the token and allow access according to the rights granted to DOMAIN\Inspect.
IMPORTANT NOTE: Both solutions above discuss changing which user the monitoring service runs as. You can also set the login credentials on each individual server from within the Console. Right click the server and you'll see the Set Login Credentials option. You can choose to communicate with the server as the user running the service, or pick a specific username/password for that server. When choosing a username/password for that server, the username still has to satisfy what is discussed above (i.e. it needs to be a locally synchronized username or a domain username).
Is there any other way?
There is a third alternative: Install
the monitoring product on the remote server. It can then run as Local System and look
just at the server itself. Power Admin monitoring products install quickly, and the Easy
Configuration feature makes it simple to copy a monitoring configuration
from one machine to another.
