When AuthLite is already running on your network and then you install AuthLite on the first DC in a new site, there is a chance it can accidentally create extra copies of the AuthLite data partition containers instead of seeing the old ones. 

These extras will replicate (after up to three replication cycles, sometimes taking 2-3 hours depending on your topology) and cause a naming conflict, and the directory will then rename the old (real) containers, accidentally hiding the real data and making everything seem broken.

If settings are already lost

If this has happened to you, log in with a break-glass DA account, and run FixConflicts.ps1 on a DC (just one, it should not matter which).  See if it finds and restores any settings. After the replication has completed again between sites, everything should be restored to a working condition.

(Don't forget to re-set your break-glass DA account with a fresh random long password once you're done using it, and record the new value for an emergency.)

To prevent naming conflicts at install time

We are working on a new version of the installer that will try to detect and prevent this case from happening, but it's challenging to proactively detect.  As of 2.5.22, the best procedure to prevent is the following:

When installing AuthLite on new DCs, you can call it from the command line with additional argument CREATEPARTITION=0 .  For example

AuthLite_installer_x64.exe  CREATEPARTITION=0

Note if this is the very first install of AuthLite on a DC you must let the partition create; do not run it with createpartition=0 , or there will be nowhere to store settings.