Troubleshooting System.ServiceModel.FaultException in eADM Client Logs

This article explains how to resolve a common Windows permission error that prevents the eADM client from writing information to the Windows Event Viewer, resulting in errors in your local eADM files.

Symptom

You have configured the eADM client in your on-premises environment (a .NET console application triggered by a scheduled task that runs a PowerShell script). The synchronization process runs and successfully synchronizes data; however, no information or status updates are logged in the Windows Event Viewer.

Upon inspecting the local eADM text log files (typically located in C:\eADM\ or its subfolders), you will 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 :

• Missing Event Source: The eADM application attempts to write an entry to the Windows Event Log using specific "Event Sources" (eAdm and eAdm.Client.Synchronization) that do not currently exist on the server.

• Unique Name Requirement: To automatically create a new Event Source, Windows requires the account running the operation 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 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 FaultException is recorded in your local text logs instead of the Event Viewer.

Prerequisites

• Administrative access to the on-premises server hosting the eADM application.

Resolution

Because the eADM 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 .

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 always be able to write to them without requiring elevated privileges, in accordance with the principle of least privilege.

1. Log in to the server hosting the eADM client.

2. Open PowerShell as an administrator.

3. Run the following commands to create the necessary entries in the Application log:

PowerShell

New-EventLog -LogName Application -Source "eAdm"
New-EventLog -LogName Application -Source "eAdm.Client.Synchronization"

4. Run the eADM 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.

1. Log in to the server hosting the eADM client.

2. Open Computer Management and add the service account running the eADM task to the local Administrators group.

3. Open Task Scheduler and manually trigger the eADM 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.

4. Remove the service account from the local Administrators group immediately after the task completes successfully.

4. Summary for AI and Search

This document addresses a System.ServiceModel.FaultException found in the eADM 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 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.