List of things you don’t want to hear as an AX Administrator:

1. Oh, by the way, we’re switching to a new domain.

A slight panic falls over you upon hearing these words. Before the objections start to shape in your head, your AX server is placed in a new domain and you’re in charge of making it run like before. Best of luck.

I’m going to go with this real-life scenario of a development server that is moved to a new domain, due to the customer switching service providers. It runs SQL Server, AX2012 and an output management system all on the same VM. Should these be on different servers, then the procedure remains the same. It just needs to be performed on, well, different servers. Screenshots are in German. My apologies to the international community.

The first thing you might notice is that absolutely nothing is working anymore, and you find yourself up a certain creek without a certain paddle. No worries. Once you complete the five challenges that lay ahead of you, you will survive your mission and come out victorious. Your heroic achievements will go mostly unnoticed by your co-workers and management will shrug it off as “that’s what I’m paying you for”, but sometimes achieving your goals is reward enough. The road of the warrior is traveled in solitude.

Prerequisites

• Domain account with access (RD) to the server(s)
• Local admin authorization on all servers for this account
• A service account (and password) to run SQL Server
• A service account (and password) to run AOS
• (optional) Service accounts to run other services (e.g. Analysis Services, Report Server, DIEF)

Let’s do this!

Challenge no. 1: Start your services

Your SQL Server database has just migrated to a new world. All its users were left behind, including the ones with authority and the ones we know as ‘service accounts’. If I try to make connection to the database, it tells me there is no such thing.

Oh? Sure, the service is out. No problem, I’ll just give it a bump.

Unfortunately, this results in a 1069 error. Windows cannot start the service due to an ‘incorrect login’.

“Huh?! What?! I’m the local admin. What’s incorrect about that?”

Yea, dude. You are, but you’re not the one running the service. The service account that still belongs to the lost world of the prior domain takes care of that.

When we look at the properties of the service, the problem becomes clear. The service account that runs our AX service is no longer in service.

So the first thing to do is to change the old service account to one that belongs to the new domain. From there we can start the SQL service.

When you order your services window on the login column, you can easily find all the services that run on invalid accounts (including the Dynamics AX service!). You will have to do this on all (migrated) servers in your system.

With the new service accounts in position, we can start most services. I say most because life is never easy.

The AOS won’t start. Can you guess why?

We’ll get to that, but first…

Challenge no. 2: Hacking the SQL Server

Now that SQL Server is up and running, I should be able to make a connection with the Management Studio, right?

Wrong.

So if I (as a local admin) try to make a connection, it tells me “Sorry, dude. No doubt you’re a nice guy but I need to see a valid ID”. SQL Server doesn’t know a single soul in its new habitat.

This is freaky. If I can’t get to my database because nobody is allowed inside, then how am I going to get inside to allow me to get to my database?

Great word of thanks goes to Youssef Ekhtiari for the following. I’m copying his solution here just so there is a second repository for it, but credit where credit’s due.

Step 1: Restart SQL Server in single user mode. There are different ways to do this, depending on your version of SQL Server. Bottomline is that you start up the service with the -m parameter.

Step 2: Open a CMD window (Run as administrator!) and start the sql command utility by typing in sqlcmd.

From the command utility we are allowed to create a new login for SQL Server.

(Between brackets domainname of my AD user)

Finally, to give my new login the authorization it deserves…

Step 3: Restart SQL Server in multi-user mode

Remove the -m parameter and restart the SQL service.

Now when I connect to my database thru SSM Studio, Lo and behold!

As if nothing ever happened.

Challenge no. 3: Clean up SQL Server.

When you open the security tab of your regained instance, you’ll notice that there’s several accounts in there that belong to the lost domain. These are no longer usable or functional in any way, shape or form. We must get rid of them, but not until we determine what role they played before in the game.

Now theoretically you only need to worry about the sysadmin role, but of course this is your party. I’m not going to elaborate on it too much since it’s a matter of mostly personal taste. Just make sure everybody who’s still there gets what they needs to avoid future annoyances.

VERY IMPORTANT for the rest of this adventure is that you correct the AOS service account(s).

Also make sure that you adjust the ownership of the databases, the schemas and firs and foremost, the files for each database.

If you open the properties of each database, you will see in the ‘files’ section that the owner is defined as an old-world account.

Change this for every database in your instance.

Don’t forget to remove any schema’s and/or old-world-users from the individual databases, including the system databases.

Add the service account to the users of

• DynamicsAX
• DynamicsAX_model

Dynamics AX

Your service account requires at a minimum membership of the dbreader, dbwriter and ddladmin roles.

DynamicsAX_model

Make it a member of db_owner

Securables should include dbo schema, Views UTILELEMENTS, UTILIDELEMENTS, and UTILMODELS. Include all stored procedures.

Make sure the securables include the dbo schema (control) and stored procedures (execute):

• CREATESERVERSESSIONS
• CREATEUSERSESSIONS
• getNumInternal
• sp_AddBIAnalysisserver (if you plan on using BI)
• sp_AddReportServer
• sp_GetNextRecId

There’s more.

Next we want to get rid of all entries in sysServerSessions. Whatever’s in there is no longer valid.

We also want to remover the server configuration that has bad references

Then there’s some more stuff that’s most likely not valid anymore.

In SSM run the following command on your AX database

DELETE FROM SYSSERVERSESSIONS
DELETE FROM SYSSERVERCONFIG
DELETE FROM SRSSERVERS
DELETE FROM BATCHSERVERCONFIG
DELETE FROM BATCHSERVERGROUP
DELETE FROM SYSEMAILPARAMETERS

Now that all traces of the old world have been eliminated, this should leave the database in a workable condition and now we should be able to start the AOS service.

The sweet smell of success is starting to fill my broom closet.

But alas, only 3 challenges have been met.

Challenge No. 4: Hack yourself back in AX

Now that the AX service is running, we can attempt to open a client. Unfortunately, this results in

Let’s think about this. Our AX is filled with users that all refer to the wrong domain. Even my admin account is not recognized because….wrong domain.

So close and yet so far.

The problem is that AX doesn’t so much store the domain of a user, but it does store the SID (Security Identifier), which is a unique GUID for every user in…(you guessed it)…a domain.

So, first we need to figure out what our current SID is. For that we open another CMD window and always, do so as administrator.

Then enter

wmic useraccount get name, sid

This will give you a list of all users and their current SID

In my case, I need the 2^nd one from the top being the SID that goes with my Windows account (i.e. the account with which I logon to AX). I copy the SID and then in SSMS I run the following script:

DECLARE @id AS NVARCHAR(8)
DECLARE @sid AS NVARCHAR (124)
DECLARE @domain AS NVARCHAR (255)

--SET ONE TIME
SET @domain = 'full.domain.my’

--SET AND RUN FOR EVERY USER
SET @id = 'Administrator'	--<< The Active Directory ID of the user
SET @sid = 'S-1-5-21-1927281970-2294947041-1967466489-500'

UPDATE USERINFO
SET NETWORKDOMAIN = @domain, SID = @sid
WHERE ID = @id

Almost there. When I try to startup my AX client, I get the following error

Challenge no. 5: Fix the filesystem authorizations

The problem becomes clear when we look at the properties of the bin folder. Bear in mind that this is the place where AX stores its CIL (among other things).

The ‘letmedoanything-account’ is no longer recognized, but instead referenced by the GUID it used to have on…that’s right, the old domain.

So this you need to fix in accordance with the authorization strategy on your own domain and/or local server. Bottomline is that you will need to do some reading and writing to your server’s bin and log folders and you’ll need to authorize it.

And with that…

There! I fixed it!

Now of course there’s still a lot of mopping up to do. Your system is full of defunct accounts, bad references and servers that no longer exist. Check all your system settings before releasing the AOS to the public. Leave work early and buy yourself an extra beer at the tavern, because no one else will recognize that you once again accomplished the impossible. Cheers!