3 min read

Importing objects in a multi tenancy environment

The following posting is based on a support request where a partner wanted specific instructions what the process should be when trying to import a FOB file in a true multi tenant environment. If you simply import the FOB file, the
following message box will first pop up to you:

This box is new in Dynamics NAV 2015 and is not part of the scope of this blog posting. It is the other message box that needs more explanation:

The first suggestion is to verify if the server is indeed running (of course it is) and the suggestion from support would be to always verify if the server is accessible via the mentioned port. If these are all true, then the second suggestion is to ensure all tenants are dismounted except one. This is because there should only be one tenant mounted that does have the option “Allow application database write to” enabled.

Note that if you import objects into a multitenant deployment of Microsoft Dynamics NAV 2013 R2, you will see a different error message if you have more than one tenant mounted against your service instance:

Tenant ‘Default” could not be found.

Check that:

1. Tenant ‘default’ is mounted on the server, or

2. Specify a different Tenant in Tools|Options.

The meaning is the same as shown in the screenshot from Microsoft Dynamics NAV 2015: Before you import objects into a multitenant application, you must ensure that only one tenant is mounted against that Microsoft Dynamics NAV Server instance, and that this tenant is mounted with the database synchronization mode set to Force.

The following configuration will generate the warning “Unable to process table changes because the request cannot be processed by the specified Dynamics NAV Server instance”:

If you dismount all the tenants except the one that does have the option “Allow application database writes” enabled, the warning will not pop up and you will be able to continue the object import. The following configuration will therefore not generate the warning “Unable to process table changes because the request cannot be processed by the specified Dynamics NAV Server instance”:

To dismount a tenant, you can utilize the Microsoft Dynamics NAV 2015 Administration Shell which may need to be start up with Run as Administrator:

Dismount-NavTenant –ServerInstance DynamicsNAV80SSL –tenant marketing –force
Dismount-NavTenant –ServerInstance DynamicsNAV80SSL –tenant production –force
Dismount-NavTenant –ServerInstance DynamicsNAV80SSL –tenant sales –force
Dismount-NavTenant –ServerInstance DynamicsNAV80SSL –tenant staff –force

After you have done the necessary work to get the application upgraded with the latest rollup or whatever fob file you are trying to import, you need do mount the tenants again:

Mount-NavTenant –ServerInstance DynamicsNAV80SSL –DatabaseInstance NAVDEMO –DatabaseName marketing –DatabaseServer SQL-02 –DefaultCompany ‘CONTOSO Marketing Ltd.’ –id marketing
Mount-NavTenant –ServerInstance DynamicsNAV80SSL –DatabaseInstance NAVDEMO –DatabaseName production –DatabaseServer SQL-02 –DefaultCompany ‘CONTOSO Production Ltd.’ –id production
Mount-NavTenant –ServerInstance DynamicsNAV80SSL –DatabaseInstance NAVDEMO –DatabaseName sales –DatabaseServer SQL-02 –DefaultCompany ‘CONTOSO Sales Ltd.’ –id sales
Mount-NavTenant –ServerInstance DynamicsNAV80SSL –DatabaseInstance NAVDEMO –DatabaseName staff –DatabaseServer SQL-02 –DefaultCompany ‘CONTOSO Staff Ltd.’ –id staff

Last but not least you need to synchronize the tenant with the application

Sync-NavTenant –ServerInstance DynamicsNAV80SSL –tenant marketing 
Sync-NavTenant –ServerInstance DynamicsNAV80SSL –tenant production
Sync-NavTenant –ServerInstance DynamicsNAV80SSL –tenant staff 
Sync-NavTenant –ServerInstance DynamicsNAV80SSL –tenant sales

Hope this makes the process a bit more clear.


Marco Mels

This posting is provided “AS IS” with no warranties, and confers no rights

This blog post was updated on March 21, 2015, to include a note about the same scenario in Microsoft Dynamics NAV 2013 R2.