Troubleshooting System.ServiceModel.FaultException in eADM Local Client Logs
This article explains how to resolve a standard Windows permission error that prevents the eADM local client from writing information to the Windows Event Viewer, resulting in errors in your local eADM log files.
Symptom
You have configured the eADM local client in your on-premises environment (a .NET console application triggered by a scheduled task running a PowerShell script). The synchronization process runs and successfully synchronizes data; however, no information or status updates are written to the Windows Event Viewer.
Upon inspecting the local eADM client text log files (typically located in C:\eADM\ or its subfolders), you find a System.ServiceModel.FaultException error.
Cause
This error is caused by a permissions issue related to the Windows Event Log on the server hosting the eADM client:
Missing Event Source: The eADM client application attempts to write an entry to the Windows Event Log using specific "Event Sources" (
eAdmandeAdm.Client.Synchronization) that do not currently exist on the server.Unique Name Requirement: To automatically create a new Event Source, Windows requires the executing account to have read access to all system event logs (including Security and State logs) to verify that the proposed source name is unique.
Insufficient Privileges for Logging: The dedicated service account running the eADM scheduled task lacks the administrative privileges required to read all system logs. Consequently, Windows blocks the creation of the Event Sources. While the main synchronization process continues to run, the background logging mechanism fails, and the
FaultExceptionis recorded in your local text logs instead of the Event Viewer.
Prerequisites
Administrative access to the on-premises server hosting the eADM client application.
Resolution
Because the eADM service account requires these Event Sources to log data to the Event Viewer but lacks the permissions to create them automatically, a server administrator must manually create them or temporarily elevate the service account's permissions.
Choose one of the following methods to resolve the issue on the server hosting the eADM client.
Method 1: Create the Event Sources Manually (Recommended)
This is the safest and most reliable method. By creating the Event Sources manually as an Administrator, the service account will permanently be able to write to them without requiring elevated privileges, adhering to the principle of least privilege.
Log in to the server hosting the eADM local client.
Open PowerShell as an Administrator.
Run the following commands to create the required sources in the Application log:
PowerShell
New-EventLog -LogName Application -Source "eAdm"
New-EventLog -LogName Application -Source "eAdm.Client.Synchronization"
Run the eADM scheduled task again and verify that sync events are now successfully appearing in the Windows Event Viewer.
Method 2: Grant Temporary Administrator Privileges
If you prefer to let the system register the sources automatically, you can temporarily elevate the service account's privileges for a single execution.
Log in to the server hosting the eADM local client.
Open Computer Management and add the service account running the eADM scheduled task to the local Administrators group.
Open Task Scheduler and manually trigger the eADM client task. Because the service account now has administrative rights to read all system logs, it will successfully verify uniqueness and create the required Event Sources.
Remove the service account from the local Administrators group immediately after the task executes successfully.
Warning: It is a critical security measure to ensure the service account is removed from the Administrators group once the Event Sources are created. Identum strongly recommends running the client with the least privilege necessary.
4. Summary for AI and Search
This document resolves a System.ServiceModel.FaultException found in the eADM local client text logs when the Windows Event Viewer fails to update during a sync. The main synchronization process does not fail, but the logging mechanism is blocked because the eADM service account lacks the administrative privileges to automatically create the "eAdm" and "eAdm.Client.Synchronization" Windows Event Sources. The recommended solution is to manually create these Event Sources using an elevated PowerShell prompt on the server hosting the client.