The Service Tier

My first technical blog post is going to describe some details about the service tier, that some people might find interesting (and some people might think that this is common knowledge:-))

What is the Service Tier?

Very briefly - the Service Tier is the middle tier in a Microsoft Dynamics NAV 2009 installation. This is where all database access is performed and all business logic is executed, meaning also that this is where the application is running. The Database Tier needs to be SQL Server 2005 or higher and the Client Tier needs to be the Role Tailored Client. When installed, the Service Tier does nothing but to wait for a connection from a Role Tailored Client, so even if the Service Tier is started it really doesn't consume a lot of resources until some Clients connects to it.

The Service Tier can also be configured as a Web Service listener making part of your application accessible from any Web Service Consumer. It is not recommended that you expose Web Services Directly on the Internet due to security - but you could easily create a high level proxy for some Web Services and expose those to the Internet.

The Role Tailored Client doesn't connect to the SQL Server directly at all - and the SQL Server could in fact be hidden behind a firewall and be inaccessible from the clients.

When a Client connects to the Service Tier he is authenticated using Windows Authentication and the Service Tier will impersonate the user when connecting to the Database Tier. The Service Tier of course needs permission to do that, we cannot have random computers on the network running around impersonating users - more on this topic later.

What is installed?

When you install Microsoft Dynamics NAV 2009 (The Demo install), the installer will create 2 services for you:

Microsoft Dynamics NAV Business Web Services
Service Name: MicrosoftDynamicsNavWs
This is the Web Service listener. By default this is set to start Manually and without starting this service - you will not be able to do anything with Microsoft Dynamics NAV 2009 Web Services.

Microsoft Dynamics NAV Server
Service Name: MicrosoftDynamicsNavServer
This is the Service Tier. By default this service is set to start Automatically.

Both services are set to run as the NETWORK SERVICE user, and by default the Web Service listener has a dependency on the HTTP protocol.

This is what you can see when looking at properties for the service in the services list (Control Panel -> Administrative Tools -> Services).

Another interesting thing pops up if you query the Service Controller for info about the services:


Notice that the services are running with a flag called WIN32_SHARE_PROCESS - meaning that even though you start both services, your task list will only reveal one process running:


Why is this important?

First of all - the two processes share caches of metadata, memory consumption and everything - meaning that you will save some memory when running in the same process.

Secondly if you at some point want to restart your service tier in order to flush these caches - you actually need to restart both services to achieve that goal.

Configuration of the Service Tier

The default installation path of Microsoft Dynamics NAV 2009 varies according to version and language of the operating system - but on my machine it is under:

C:\Program Files\Microsoft Dynamics NAV\60\

Note that if you install on a 64bit computer, it will be installed C:\Program Files (x86) because the Service Tier in NAV 2009 is 32bit only.

In this directory you will find a folder called Service (if you installed the demo) and in this directory a configuration file called:


Among the keys in the config file you will find the following 5 keys:

DatabaseServer / DatabaseName
These values are used when the Service Tier connects to the Database Tier - this is the location of your SQL Server and the name of the Database you want to connect to.

After changing these values, you need to restart the Service Tier (both services if started) in order to make the Service Tier connect to a new database.

It seems cumbersome if you are working as a single user using multiple databases - but one Service Tier has one database connection - that is just the way it is.

If you have multiple databases, you want to install multiple Service Tiers - and I will create a post on how to do this. You can also install multiple Service Tiers connecting to the same databases and you can do that on the same computer if you would want that.

ServerInstance / ServerPort / WebServicePort
These are the values that differentiates multiple service tiers on one box.
The default ServerInstance installed by the installer is DynamicsNAV, the default serverport is 7046 and the default WebServicePort is 7047.

Again - for one Service Tier, these values are fine.

On the Client computer you will connect to a Service Tier using the Select Server dialog, in which you specify the URL of the Service Tier as:




as you can see - the server URL contains the computername of the Service Tier computer, the port and the Service  Tier instance and if you have multiple Service Tiers, one of these has to be different.

Also the WebService listener uses the Instance in the URL needed to connect to WebServices


More about this in a later post on web services.

BTW. Microsoft recommends that you use the Instance name to differentiate between service tiers and not ports.

Is the Service Tier interpreting C/AL code?

As you probably already know, the answer to this question is No. In NAV 2009

The majority of the Service Tier is written in C# and runs managed code and the application is also converted into C# and at runtime executed as compiled managed Code.

The way this happens is, that whenever you compile an object in C/SIDE, the object is behind the scenes compiled to C# (by the classic client) and the C# code is stored in the Object Metadata table (in the BLOB field called User Code). Furthermore the Object Timestamp field in the Object Tracking table is updated allowing the Service Tier to pickup these changes. When the Service Tier needs to run code from an object - the C# code from the object is written to disk and through some magic compiled into a module, which is loaded dynamically, allowing the Service Tier to replace single code units, pages etc. on the fly.

The directory in which the Service Tier stores the C# files can be found in:

<Program Data>\Microsoft\Microsoft Dynamics NAV\60\Server\<process ID>\source

where <Program Data> is

C:\Documents and Settings\All Users\Application Data\ on my XP and my Windows 2003 Server and
C:\Users\All Users\ on my Vista box

and the process ID can be found in the Task Manager by choosing to show the PID column.

Having the C# files available in this directory actually allows you to debug this code as described in Claus Lundstrøm's post:

but note that:

  • You will be debugging the C# code - and you cannot see the AL code
  • You will have to install SP1 on VS2005 or VS2008 in order to debug
  • You are debugging the Service Tier meaning that you debug every connection (can be pretty confusing:-))


Freddy Kristiansen
PM Architect
Microsoft Dynamics NAV

Comments (8)

  1. says:


    which SQL Server Version is requiered for 3-Tier? Can I assume I can’t use SQL Server Express – is this right?

    Best regards,


  2. FreddyDK says:

    Honestly I don’t know – I haven’t tried.

    The .bat files are only concerned about service tiers, I haven’t tested a lot with SQL Server SKU’s – nor do I know a lot about what you can do in the express SKU and what not.

  3. Jut says:


    Is it possible to create files in the root directory of that Service Tier? I tried to create files in

    C:Documents and SettingsAll UsersApplication DataMicrosoftMicrosoft Dynamics NAV60

    C:Documents and SettingsAll UsersApplication DataMicrosoftMicrosoft Dynamics NAV60Server

    C:Program FilesMicrosoft Dynamics NAV60Service

    but if I try to access these files like


    I only get HTTP 400 Bad Request Errors. Is there any physical path that is mapped to the root path?



  4. FreddyDK says:

    You will not have folderaccess like that through Web Services. Web Services is a programatic API, where you need a web service consumer.

    What is exposed as web services is setup in the Web Services table, thats what you can get to.

  5. says:


    Are there plans in place to create a 64 bit version of the service tier?


  6. FreddyDK says:

    Yes – I don’t think it is a secret that we are working on removing the last pieces of unmanaged code underneath the Service Tier to make it 64bit – but I cannot tell you anything about when that will be unfortunately.

  7. larsl says:

    Hi Freddy,

    Do you know if there is any way to get the DatabaseServer and DatabaseName from within C/AL?

    Like eg. a virtual table (like Server which could be used to show the name of the SQL Server in the Classiv client).

    I’m creating an add-in that can show the customer if they are working in a test-database or the production-database.

    Reading the command-line won’t work since the user can change the server after starting NAV.

  8. FreddyDK says:

    I would think that creating a server side COM which would read the CustomSettings config file in the app directory would give you the database server.

    Yes, you can change the service tier at runtime, but in effect that will restart your session and you would get the new database next time.

    Also – you cannot change the database connection in a running service tier.

Skip to main content