KB000006: Migrating the Access Manager Database

Summary

This document outlines the steps required to migrate the Access Manager database from the built-in SQL express instance, to a standalone SQL server or cluster.

Procedure

As always, take a full system backup of the AMS server before making any changes
Stop the Access Manager service
Backup the existing database. You can install SQL Management Studio to do this, but it can be done any way you prefer such as using command line tools.
Stop the SQL Express service instance
Restore the database onto the new SQL server
Once restored, you'll need to grant the AMS service account db_owner rights on the database, and set the default database for the user to AccessManager. These permissions won't exist, as SQL Express uses a service-based ACL that won't work on a remote server.

You can run the shown in the installation guide to set the appropriate permissions. It won't create the database if it already exists, but it will fix the missing permissions. If you use the script, make sure you replace the value of the @ServiceAccount variable to match the AMS service account you use.

Using the registry editor on the AMS server replace the ConnectionString value inside HKEY_LOCAL_MACHINE\SOFTWARE\Lithnet\Access Manager Service\Parameters, with the new server details. For example, for a server called SQLDBServer.domain.local the connection string will become Server=SQLDBSERVER.domain.local;Initial Catalog=AccessManager;.
Start the Access Manager service, and you should be back up and running.
Uninstall SQL express and delete any old database files

Troubleshooting

If the service fails to start, check the access-manager-service.log file in C:\Program Files\Lithnet\Access Manager Service\logs for more details on why the service did not start
Check the Lithnet Access Manager application event log for error information
Check the windows Application event log for error information
Validate that the permissions on the DB were granted correctly. The service accounts needs permission to connect to the database server, and db_owner permission on the database itself.

PreviousKB000005: Access Manager stops working after applying the November 2022 Windows update NextKB000007: Adding JIT groups via Group Policy doesn't work with NTLM Disabled

Last updated 10 months ago

Was this helpful?

Procedure

As always, take a full system backup of the AMS server before making any changes

Stop the Access Manager service

Backup the existing database. You can install SQL Management Studio to do this, but it can be done any way you prefer such as using command line tools.

Stop the SQL Express service instance

Restore the database onto the new SQL server

Once restored, you'll need to grant the AMS service account db_owner rights on the database, and set the default database for the user to AccessManager. These permissions won't exist, as SQL Express uses a service-based ACL that won't work on a remote server.

Using the registry editor on the AMS server replace the ConnectionString value inside HKEY_LOCAL_MACHINE\SOFTWARE\Lithnet\Access Manager Service\Parameters, with the new server details. For example, for a server called SQLDBServer.domain.local the connection string will become Server=SQLDBSERVER.domain.local;Initial Catalog=AccessManager;.

Start the Access Manager service, and you should be back up and running.

Uninstall SQL express and delete any old database files

Troubleshooting

If the service fails to start, check the access-manager-service.log file in C:\Program Files\Lithnet\Access Manager Service\logs for more details on why the service did not start

Check the Lithnet Access Manager application event log for error information

Check the windows Application event log for error information

Validate that the permissions on the DB were granted correctly. The service accounts needs permission to connect to the database server, and db_owner permission on the database itself.