Starting the RemoteRegistry service did not help in my case.
Apparently, there is a difference between the remoting that is accessed via the ComputerName parameter in some cmdlets such as Get-Service and the newer form of remoting accessed with cmdlets such as Invoke-Command.
Since traditional remote access is implemented by individual cmdlets,
it is inconsistent (uses different techniques and demands different
requirements) and available only in selected cmdlets. The technology
used for remote access can vary from cmdlet to cmdlet and is not
readily known to you. Each cmdlet uses whatever remoting technology
its author chose. Most cmdlets use Remote Procedure Call (RPC), but
might also require additional services and settings on the target
system.
Beginning in Windows PowerShell 2.0, there is an alternate and more
universal way of accessing remote systems: Windows PowerShell
Remoting. With this type of remoting, Windows PowerShell handles
remote access for all commands. It transfers your commands to the
remote system using the relatively new and highly configurable WinRM
service, executes the code in a separate session that runs on the
remote system, and returns the results to the calling system.
http://powershell.com/cs/media/p/7257.aspx
When I swapped from this command
get-eventlog -LogName System -computername <ServerName>
to this
invoke-command {get-eventlog -LogName System} -ComputerName <ServerName>
I no longer got the following error
get-eventlog : The network path was not found.