After the database was restored to another server, SQL Server gave it a new internal database ID. Scout's licence data still holds the old ID, so the Scout Server stops at start-up ("Database GUID is different"). That check itself is expected after a restore.

Normally the Scout Console would then show the repair dialog (validation code). On 15.2508.1001 it never appears: a bug prevents the server from saving the "needs repair" flag, so the Console always sees a healthy licence. The same bug is in 15.2605 to 15.2609. The fix is tracked on this ticket for 15.2611.

Scout database was restored to another SQL Server. 

Make sure eluxd.ini (and the SEPE Console tab) point to the database they want to use. Stop all Scout services (Scout Server and the ScoutBoard services) and close all Scout Consoles. Take a full backup of that database.

Check the licence rows:

SELECT ScoutLicenseID, Modified, DATALENGTH(LicenseBlob) AS blob_len FROM ScoutLicense;

Continue only if there is a row with ScoutLicenseID = 200 and blob_len greater than 5. Otherwise stop and send us the output.

Reset the LS licence row to its new-installation state:

UPDATE ScoutLicense SET LicenseBlob = 0x8886726839 WHERE ScoutLicenseID = 200;

Start the Scout Server service. It sets up the LS licence the same way a new installation does and stores the new database ID. It should keep running; eluxd.log should show the License Server / LAS lines and no "Database GUID is different". Restart the Scout Server service once more to confirm it still starts, then start the ScoutBoard services and open the Console.

Side effects: the stored License Server state (last contact, grace period) is rebuilt on the first contact with the License Server, and the licence log may show the standard new-installation entries. Devices and configuration are not touched.

The database was restored to another SQL server and the Scout Service afterwards does not start > it starts briefly and shows "Running" but then stops after few seconds.