Several years ago, I published an article describing how to configure Windows for remote access to event logs. Since then, we have received many support requests related to connectivity and authentication problems. As a result, we added a built-in Connectivity Test to Event Log Explorer to simplify troubleshooting and help identify the most common configuration issues.
Although this article focuses on Event Log Explorer, the troubleshooting steps apply equally to Windows Event Viewer and any other software that accesses Windows event logs remotely.
The most common error reported by our users is “The RPC server is unavailable.” Windows Event Viewer may display “Access is denied” instead. While these messages are often accurate, they do not provide enough information to identify the actual cause of the problem.
To make troubleshooting easier, Event Log Explorer includes a Connectivity Test that reproduces the initial stages of establishing a remote Event Log connection and reports any problems it detects.
To run the test, first add the remote computer to the tree. Even if automatic discovery does not work, you can add the computer manually by entering its name or IP address. Then right-click the computer and select Connectivity Test. The program performs a series of network and RPC checks and displays the result of each step.
For a complete description of all diagnostic results, see the Event Log Explorer documentation:
https://eventlogxp.com/help/remote_computer_connectivity_test.html
Below are the most common problems and their causes.
Connectivity Problems
RPC port available
This check verifies that TCP port 135 (the RPC Endpoint Mapper) is accessible on the remote computer.
If this check fails, it usually means that TCP port 135 is blocked by a firewall or that there is no network connectivity between the two computers.
Event Log dynamic port resolved
If this step fails, the problem is usually not network-related. Instead, the Event Log service on the remote computer is probably not running or is unable to register its RPC endpoint.
Event Log dynamic port available
Passing the first RPC test does not guarantee that the Event Log service can be reached. After connecting to the RPC Endpoint Mapper on port 135, Windows obtains the dynamically assigned RPC port used by the Event Log service and connects to that port.
If this check fails, TCP port 135 is reachable, but the Event Log service cannot be reached through its dynamically assigned RPC port. In most cases, this means that the Remote Event Log Management (RPC) firewall rule is not enabled on the remote computer or is enabled for the wrong network profile (Private, Public, or Domain).
If you connect by computer name rather than IP address, also make sure that the name resolves to the correct computer.
Authentication Problems
Even after all connectivity problems have been resolved, opening the remote event log may still fail with “Access is denied.” In this case, the problem is usually related to authentication or permissions rather than network connectivity.
Workgroup networks
In workgroup environments, the most common cause is that Windows authenticates you as a Guest user instead of using your local credentials.
To fix this, make sure that the Network access: Sharing and security model for local accounts security policy is set to Classic – local users authenticate as themselves on the remote computer.
If possible, create a local user account on the remote computer with the same user name and password that you use on your own computer. If this is not practical, Event Log Explorer can prompt you for remote credentials or you can store them in its built-in Credential Manager.
Event Log permissions
Even if authentication succeeds, your account may not have permission to read remote event logs.
For most logs, adding your account to the Event Log Readers group is sufficient.
This may seem surprising, but users who are members of the local Administrators group can sometimes have more difficulty accessing remote event logs than users who are members of Event Log Readers because of User Account Control (UAC) remote restrictions.
UAC remote restrictions
By default, not all event logs are accessible to members of the Event Log Readers group. Some logs under Microsoft\Windows require administrative privileges, including AppXDeploymentServer/Restricted, ASN1/Operational, CAPI2/Operational, Crypto-NCrypt, Diagnostics-Performance, and several others.
Although these logs are not frequently used, you may occasionally need to examine them.
In this case, administrative access is required. However, local administrator accounts may still be restricted by UAC when connecting remotely.
To disable UAC remote restrictions, open Registry Editor (regedit.exe) on the remote computer and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Create (or modify) the LocalAccountTokenFilterPolicy DWORD value and set it to 1.
In Active Directory domain environments, this configuration is usually unnecessary because domain accounts that are members of the local Administrators group are typically not affected by these remote UAC restrictions.
Kerberos authentication and VPN clients
Another possible cause of “Access is denied.” is a Kerberos authentication issue.
Some VPN clients modify the local DNS configuration or change the preferred network interface, which may prevent Windows from obtaining or using the correct Kerberos service ticket for the remote computer. Although the remote computer remains reachable over the local network, authentication may still fail.
As a workaround, try adding the remote computer by its IP address instead of its host name. Kerberos authentication requires a Service Principal Name (SPN) associated with the host name, so connecting by IP address usually causes Windows to fall back to NTLM authentication instead.
This workaround may not work in environments where NTLM authentication is restricted or disabled by Group Policy. In that case, temporarily disconnect the VPN client, establish the remote connection, and then reconnect the VPN if necessary.
Time synchronization
In Active Directory environments, Kerberos authentication also depends on accurate time synchronization.
If the clocks on the client computer, the remote computer, and the domain controller differ by more than the allowed tolerance (typically five minutes), Kerberos authentication may fail, resulting in an “Access is denied.” error.
Conclusion
The issues described above are the most common causes of remote event log access failures, although they do not cover every possible scenario.
Unlike Windows Event Viewer, which usually reports only a generic error message, recent versions of Event Log Explorer include a built-in Connectivity Test that helps identify the actual cause of connection problems and significantly simplifies troubleshooting.
If you regularly work with Windows event logs, give the latest version of Event Log Explorer a try. Its built-in Connectivity Test helps diagnose remote access problems much faster than standard Windows Event Viewer, making troubleshooting easier for both administrators and support engineers.
