[wiped large answer, summarizing for clarity. See edit-history for sordid tale.]
There is a single well-known SID for the local system. It is S-1-5-18, as you found from that KB article. This SID returns multiple names when asked to be dereferenced. The 'cacls' command-line command (XP) shows this as "NT Authority\SYSTEM
". The 'icacls' command-line command (Vista/Win7) also shows this as "NT Authority\SYSTEM
". The GUI tools in Windows Explorer show this as "SYSTEM
". When you're configuring a Service to run, this is shown as "Local System
".
Three names, one SID.
In Workgroups, the SID only has a meaning on the local workstation. When accessing another workstation, the SID is not transferred just the name. The 'Local System' can not access any other systems.
In Domains, the Relative ID is what allows the Machine Account access to resources not local to that one machine. This is the ID stored in Active Directory, and is used as a security principle by all domain-connected machines. This ID is not S-1-5-18. It is in the form of S-1-5-21[domainSID]-[random].
Configuring a service as "Local Service" tells the service to log on locally to the workstation as S-1-5-18. It will not have any Domain credentials of any kind.
Configuring a service as "Network Service" or "NT Authority\NetworkService" tells the service to log on to the domain as that machine's domain account, and will have access to Domain resources. The Windows XP Service Configurator does not have the ability to select "Network Service" as a login type. The SQL Setup program might.
"Network Service" can do everything "Local System" can, as well as access Domain resources.
"Network Service" has no meaning in a Workgroup context.
In short:
NT Authority\System
= Local System
= SYSTEM
= S-1-5-18
If you need your service to access resources not located on that machine, you need to either:
- Configure it as a Service using a dedicated login user
- Configure it as a Service using "Network Service" and belong to a domain
To connect using Hyper-V manager from a workgroup machine to an Hyper-v domain member server you also need allow anonymous DCOM remote access.
There is a tool from Microsoft that configues automatically all the necessary things for you: Hyper-V Remote Management Configuration Utility.
If this not work i would recommend you to check the Windows Credential Manager of the client machine looking for bad entries. If you are not sure, delete all of them.
And finally, off course could be a really RPC error, the RPC error could be failing in your server. For be sure that it is not the issue connect to the server using MMC with other Snap-in as example Local Users and Groups.
Best Answer
Without knowing the specific answer, the steps I would take to troubleshoot it would be do create an any/any exception for your host in the Private profile of the Windows firewall of the host you're trying to manage, just to determine whether or not it's a firewall issue or whether there's something else at play. If it works when you do that, you can use Message Analyser to determine which ports you're accessing on the remote host (I suspect at the very least you'll need to allow 135 for RPC). You can then remove the exception for your management host and create an appropriate firewall rule.
I suspect that will resolve your issue, if not then it's not the firewall causing the problem but something else, but I doubt it will come to that.