Like others have pointed out since the start of the year there are issues with the CPU and PerfMon tests when accessing them remotely. So far I have been able to deduce the following.
When running AHM in Interactive Mode, unless the user you are logged in as has administrative privilages you will have to specify an administrative username and password in the connect as area of the test. I have tested this with AHM running outside of a domain and this works.
If you run AHM as a service you need to specify a user to logon as in the properties for the service. If AHM is running in the same domain simply using an account with Domain Admin privilages will allow the remote tests to function. If the AHM server is not part of the domain things get tricky.
You are supposed to be able to specify a username and password for a test to connect with to a remote server but this does not appear to work as in my case running AHM as a service, outside of the domain returns "Unknown" for Perfmon and CPU tests. Unless I'm missing something this appears to be a bug.
However there is a workaround. By default the windows OS will always try to authenticate the current username and password regardless of the domain. As soon as a local user with the same username and password as the user that the AHM service is running as was created on the remote server, the test completed successfully.
So when running AHM as a service the "Connect As" details do not work. Alex I know you have tried to look into why these remote connections do not work, have you made any progress.
Regards,
Doddsy
Remote CPU issues. Hopefully the final thread
Its hard to find solution 
HostMonitor uses specified account information exactly in the same way, in service mode and in application mode. Manual from Microsoft (topics that are related to network functions used by HostMonitor) does not contain information about some problems that may occur in service mode. But somehow real life is different from documentation
If we have access to Windows source codes... no, we will spend years to learn it anyway.
Sorry, we do not have solution
Regards
Alex
HostMonitor uses specified account information exactly in the same way, in service mode and in application mode. Manual from Microsoft (topics that are related to network functions used by HostMonitor) does not contain information about some problems that may occur in service mode. But somehow real life is different from documentation
If we have access to Windows source codes... no, we will spend years to learn it anyway.
Sorry, we do not have solution
Regards
Alex
Re: Remote CPU issues. Hopefully the final thread
I am asking you this because it's obvious to me that you know more about this than I. What I have is a problem that I'm sure is my Windows XP SP2 setup. Because I have the same problem with both AHM and TASKLIST in a .bat file. I am trying to test another computer from my desktop that is in the same workgroup. Neither of them is in a domain. I can not come up with a password that the remote computer accepts. I'm setting the user as computer-name\user (shed-z60crunch1\xxxxxx (xxxxxx has admin priv)) and have tried both a blank and an account password yyyyyy. I have also tried user names of just "xxxxxx" and "administrator" without the computer-name.doddsy wrote:... When running AHM in Interactive Mode, unless the user you are logged in as has administrative privilages you will have to specify an administrative username and password in the connect as area of the test. I have tested this with AHM running outside of a domain and this works.
Doddsy
The same sort of failure occurs with this command below in a .bat file and returns "ERROR: Logon failure: Invalid or unknown user name or bad password."
TASKLIST /S 192.168.xxx.x /u shed-z60crunch1\xxxxxx /p yyyyyy /FI "imagename eq boinc.exe" /NH
Any help appreciated, Skip
have you tried using two usernames and passwords that are the same??
We have had success by creating local users called "hm" and giving them all the same password. Then when AHM tests anything over RPC and the like we use this user/pass combination. THe other thing is to also log in on your XP PC with the same user/pass combination as the other PC.
In simpler terms, what appears to happen is that when the windows process encounters a security restriction it automatically tries its current credentials and the service on the other end accepts them if they are identical without checking the machine name. Its weird but its been in Windows since 95.
We have had success by creating local users called "hm" and giving them all the same password. Then when AHM tests anything over RPC and the like we use this user/pass combination. THe other thing is to also log in on your XP PC with the same user/pass combination as the other PC.
In simpler terms, what appears to happen is that when the windows process encounters a security restriction it automatically tries its current credentials and the service on the other end accepts them if they are identical without checking the machine name. Its weird but its been in Windows since 95.