Move servers into a new AD domain

We have SAGE 2021 Premium, and due to an acquisition we need to move the SQL server and App Server to a new AD domain.

Is there a best practice on this process?

During Testing, we joined both the SQL and App server to the new domain, updated the service accounts.  The SAGE Client connected successfully on the app server, but not from any of the workstations, which are already in the new domain with a two-way trust between the domains.  We reinstalled the client workstation on a test workstation but it still did not work. 

The error we got was “SQL not enabled”

We ended up rolling back to a snapshot, putting the servers back in the old domain.

any suggestions would be appreciated.

  • 0

    One suggestion is to do an upgrade migration to a new server in the domain (...doing an upgrade at the same time to save project costs overall, by pairing the server move with the upgrade, which involves a similar amount of effort as a pure server move).  That way you only need to get the trust relationship working server to server during the migration.  Low risk too, because you don't need to tear apart the source server to do it.

    My guess for the SQL not enabled error would be name resolution... where you can use the server IP address in the Sage-SQL settings.

  • 0 in reply to Kevin M

    Thank you for the suggestion.  Unfortunately in my case I don’t think I can sell the business on an upgrade to SAGE, as a migration to SAP is on the roadmap, but security won’t let us keep the AD trust in place u til SAP will be ready.

    Name resolution is a possible issue, I will need to get the network team to check it.  Would a change to IP require changes to the sota.ini on every client?

  • 0 in reply to Bill Noyes

    You can still do a migration to a new server, without the upgrade.  Same process, just using the old version's software installers to prepare the new server for the migration.  There are many little pieces that can go wrong, and it is best just to start fresh.  We've tried domain switches, and the amount of time spent dealing with issues... could have been greatly decreased by just doing a server change / migration.

    Changing the SQL address should not involve touching clients.  Workstations connect with the Sage server, and the Sage server connects with SQL.  You have to use an address for the SQL server that can be functional for workstations though, because printing data access is done directly from SQL to the client (with SQL connection details sent runtime by the program).

    Be sure you don't have any blocking firewalls between SQL/Sage/workstations... and add rules as required.  That is the other most common issue for SQL not enabled errors (in my experience).