Troubleshooting: FileSync Fails to Create, Read, or Sync SyncManifest.xml

Version Affected: All (SecureAuth FileSync 4.0.9 and higher for Cause 1)
 
 

Overview

This article covers several unrelated ways FileSync can fail to keep its manifest file, D:\SecureAuth\SecureAuth0\SyncManifest.xml, up to date between the primary and secondary servers.

• See Cause 1 - SyncManifest.xml Is Corrupted or Blank
• See Cause 2 - An IIS Site and Its Realm Folder Don't Correspond
• See Cause 3 - SMB Port 445 Is Blocked Between the Servers
• See Cause 4 - The FileSync Service Account Lacks Share Permissions
• See Cause 5 - The Primary Server's IP Isn't Correctly Defined

These causes are not related, so a fix for one cause will not resolve the others.

 

In this article

• Cause 1: SyncManifest.xml Is Corrupted or Blank
• Cause 2: An IIS Site and Its Realm Folder Don't Correspond
• Cause 3: SMB Port 445 Is Blocked Between the Servers
• Cause 4: The FileSync Service Account Lacks Share Permissions
• Cause 5: The Primary Server's IP Isn't Correctly Defined

Cause 1: SyncManifest.xml Is Corrupted or Blank

FileSync tracks which items need to be kept in sync using the manifest file D:\SecureAuth\SecureAuth0\SyncManifest.xml. If this file becomes corrupted or its contents go missing, FileSync can no longer determine what to sync and stops, logging Event ID 7117 in the Application Event Log with the message Unable to deserialize manifest from D:\SecureAuth\SecureAuth0\SyncManifest.xml.

Recreating this file has a second, unrelated use: FileSync treats a freshly created manifest as if nothing has ever been synced, so deleting and recreating it on purpose is a reliable way to force every realm to fully resync to the secondary node(s).

Resolution 1:

To resolve this:

1. Stop the FileSync Service on all Identity Providers (IdPs).
2. On the FileSync master, rename D:\SecureAuth\SecureAuth0\SyncManifest.xml to SyncManifest_old.xml.
3. Start the FileSync Service on the master, then the remaining IdPs.
4. On the next sync, a new SyncManifest.xml is created on each IdP.
5. Verify in the Application Event Log that sync is starting and completing successfully.

Cause 2: An IIS Site and Its Realm Folder Don't Correspond

FileSync builds the manifest by walking each realm's Internet Information Services (IIS) site and matching it to a corresponding SecureAuth realm folder on disk. If a site and its folder don't correspond -- a site exists in IIS with no matching folder, or a folder exists with no matching site -- FileSync cannot build the manifest at all.

On the primary server, this shows up as Event ID 7117 in the Application Event Log, with the message Error creating manifest. ---> System.NullReferenceException: Object reference not set to an instance of an object. On a secondary server, since the primary never finished creating the file, FileSync instead logs Event ID 7117 with Unable to retrieve manifest at \\<primary>\<share>\SecureAuth0\SyncManifest.xml.

Resolution 2:

To resolve this:

Compare each realm's IIS virtual directory against the SecureAuth realm folders on disk, and correct whichever side is missing an entry:

1. In IIS Manager, list every SecureAuth realm site.
2. In D:\SecureAuth, list every realm folder. Folder names may appear in lowercase -- that doesn't matter.
3. Compare the two lists. A realm site with no matching folder, or a folder with no matching site (including any realm using an alias -- there still needs to be an IIS entry named for that realm number), is the mismatch causing the error.

4. If both sides already match, confirm each realm folder actually has a web.config in it.
5. Once the missing site, folder, or web.config has been corrected, restart the FileSync service and confirm the error no longer occurs.

Cause 3: SMB Port 445 Is Blocked Between the Servers

The secondary server retrieves the manifest from the primary over Server Message Block (SMB), which uses TCP port 445. If that port is blocked between the two servers, the secondary can't reach the primary's share at all.

Resolution 3:

To resolve this:

From the secondary server, test whether port 445 is reachable on the primary:

1. Open a command prompt and run telnet <primary IP> 445.
2. If the connection hangs at Connecting To..., port 445 is blocked -- check the firewall on both servers and any network device between them.

3. If the connection succeeds, the terminal window goes blank instead of hanging or returning an error.

Cause 4: The FileSync Service Account Lacks Share Permissions

The FileSync service account needs at least Read access to the primary server's SecureAuth share to retrieve the manifest. If that account's permissions were removed or never granted, the secondary can't read the file even though the share itself is reachable.

Resolution 4:

To resolve this:

On the primary server, check the FileSync service account's permissions on the SecureAuth share in two places: the share's Sharing tab and its Advanced Sharing > Permissions dialog. The account needs at least Read -- Full Control if the account also needs to write to the share.

Cause 5: The Primary Server's IP Isn't Correctly Defined

Each secondary server uses D:\SecureAuth\SecureAuth0\server.list to know which IP address to sync from. If the primary server's IP isn't correctly listed there, the secondary has nothing to connect to.

Resolution 5:

To resolve this:

On the secondary server, open D:\SecureAuth\SecureAuth0\server.list and verify it lists the primary server's current IP address. Correct it if it's missing or out of date, then restart the FileSync service.

Special Considerations

If you change the FileSync service account's password, update it on every secondary appliance as well -- FileSync will not sync correctly if the secondaries still have the old password.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.