Restore database to new environment doesn't show company information


I have succesfully restored my AX 2009 database to a new environment (new domain and everything).

Now when I look in SQL at the COMPANYDOMAINLIST table and DATAAREA table I can see the list of companies. But when I load up Axapta, I can only see one default company.

When I try to create a new company with the same name as the records in the database I get a duplicate error.

I’ve tried updating sysserverconfig table but that doesn’t do anything.




When you migrate from one AD domain to another AD domain (ex. contoso to contoso2), I believe the only table you may need to modify is the UserInfo table. When you say you don’t see other companies, that isn’t AD domain-related, it sounds AX-Domain related…like a security issue.

Just a few things for you to check…what domain is the AOS service account running as? Original AD domain or new AD domain?

Try refreshing your security by running this job:

static void job1(Args _args)





Thanks for getting back to me.

The database source is the contoso 3.5 vpc. The destination is a custom made vpc on a custom domain called ‘vanilla’.

The contoso vpc uses ‘contoso/administrator’ to run the AOS, where as my custom one uses NETWORK SERVICE, which is what I selected when I installed AX.

I tried to refresh the security , but that didn’t seem to work.

I’ve tried to change the AOS account to Vanilla/administrator but that didn’t work either.

It’s strange because when I try to manually create a new company within AX, it will save the company, but then disappear.




There about half a dozen things to check when data is moved across domain or even across environments. More info is available here -

Even after you made all the changes mentioned in the above article and still have issues, try running Consistency check under Basic > Periodic. If you are not familiar with this job and require more info on this, try searching in this forum as I believe we already discussed about this.

The things listed in that article are valid, but don’t relate to companies appearing/disappearing. The only thing I could see is perhaps the very last one "Unique GUID per Dynamics AX environment". The rest are mostly with EP, SRS, SAS, etc.

Try changing the AOS service account to a domain user contoso2\administrator or something, then changing the DB owner in SQL to that user. There are two stored procedures CreateUserSession and CreateServerSession that might be causing an issue…but I think the AOS will just die if they can’t execute correctly.

Give the consistancy check like Harish said a shot.

Try Tools>Development Tools>Application Objects>[Refresh Data, Refresh Dictionary, Refresh AOT].

If none of those options work, I’d just re-try the DB move honestly. Are you going from SP1 RU5 to SP1 RU5 VPC? Perhaps there has been a SYP layer change that’s causing companies not to appear.

Hi Anthony, I have the same problem with COMPANYDOMAINLIST and DATAAREA table that are empty after the database restoring. I try to look to the suggestion, modify the user with which the service is running and so on, but actually I CAN ONLY SEE DAT COMPANY and not other rows from database…

Have you solved your issue ?

Please could you share the solution ?


This issue can also be caused by mis-matched AX builds. If your client is on a higher version (5.0.1500.6491 SP1 RU8) and your AOS is on a lower (5.0.1000.52 SP1), you can experience this. Are the rows present in SQL?

Have you checked the event viewer on the AOS machine itself? That is often very telling of these types of issues.

Thank you Alex, my client is on 5.0.1500.5660 as kernel version meanwhile the application version is 5.0.1500.2985.

The rows are available in DB for all tables: company is present and also dataarea and also all the other tables coming from the production environment. for example I have 2.200 rows of customers but when I open the form from the Menu I see only the first row. I already check rows in db and there are no differences between the first and the second one

I think that the problem is concerned with the .syp layer but I’m not sure because this is a new virtual machine where I try to restore the production database.

Have you any idea ?

What is your AOS’s Kernel/Application build? Log directly into the AOS machine and open a client locally there.

I am guessing you installed some hotfixes on your client machine, but not on your AOS and that’s causing your issue.

Good morning Alex, thank you for your reply. I’m already connected via terminal server to the AOS machine.

The number presented is obtained clicking on ? on my client .

I don’t know where to look but I’m quite sure that the problem is concerned with patches…

Another idea is that i have created a new AOS and I’m using a different name from the production machine.

If it coul be useful I attach a screen shot from my Appl directory


I check the dimensions of the file with the production environment where everything work correctly but they are identicals…

Have you a different situation on you AOS

Thank again for support



EManuele, there could be any number of reasons why you’re having this issue. That screenshot only tells me that you have a Sys, Syp, Bus, Var, Cus, and Usr layer, ALL with customization in each layer.

I’d have to look at your system to figure out the issue, but an experienced developer shouldn’t take more than a couple hours to solve this. Do you have a partner or record? Who is doing all of these customizations?

Good morning Alex and thank you for response. All the customization has been made by a supplier working with our company since 2009. We asked them to create a new virtual machine as copy of the production one with all the newer patches installed and then check if everything is ok… Unfortunately the new machine has the problem reported in this issue and at the moment we haven’t find a solution.

Anyway we will submit our situation to the supplier asking for an analysis of the problem.

The problem is not this virtual machine, that we can format in a moment, but the fact that we are not confident that our production machine with installed patch can continue to work… Actually we can’t install any patches in our production environment and this is very dangerous.

Anyway let me thank you for support



Emanuele, I had similar issue. It looks like you have to install AOS service with the same version as in the original environment. In my case, I had original AOS in 5.0.1500.4570 version and after instalation in new environment there was a 5.0.593.0 AOS version. After SP and Hotfix instalation I achieve the same AOS version and data appeared in application.

So in your case I guess you need do something like this:

  1. create virtual machine

  2. restore DB

  3. copy Application files

4.install AOS with the same version

  1. try to install updates and patches.

I hope it will helpful.


Daniel Wojt

PS: The easiest way to check AOS version is checking version of Ax32Serv.exe file. For example in C:\Program Files\Microsoft Dynamics AX\50\Server\InstanceName\Bin .