NAV Web Client and Help Server side by side

29 Oct

When reading the post of my fellow MVP Luc van Vugt I was feeling like ‘Ah, that’s very familiar’. He was struggling with installing two versions of the NAV Help Server side by side. And apparently, when looking at his screenshots, the installed NAV Web Client wasn’t installed correctly either.

Default port numbers and IIS

The default port for these web components haven’t changed between releases, so if you install it without changing the configuration you will end up with web sites that use the same port number. And that is simply not possible with IIS. Well, at least not possible without some more configuration. I’ll come to that later in this post.

The default port numbers are as follows:

Dynamics NAV Web Client: 8080
Dynamics NAV Help Server: 49000

After a clean installation of NAV 2013 R2 and NAV 2015 and without changing anything in the configuration, IIS shows that two sites couldn’t be started.

image

You can try to start the web site by selecting it and click on Start under Manage Website at the right hand side.

image

But this will result in the an error message:

image

The most logical thing is now to change the port number of one of the web sites. How to do this?

Site Bindings

The port settings can be changed in the Site Bindings settings of the web site. The Site Bindings can be opened in two ways:

1. Right click the web site and choose Edit Bindings

image

2. Select the web site and click on Bindings under Edit Site at the right hand side.

image

 

In the Site Bindings settings window it is possible to edit existing bindings to the web site. You can also add new bindings so the web site will become available on multiple ports. As long as you don’t add a binding to a port that is already in use by another web site on the same server, of course…

Select the binding, click on Edit and change the port number (e.g. 49001 instead of 49000).

image

Click on OK and Close to apply the modified binding to the web site. It’s that simple!

Well, that’s to say, you have of course to communicate the new address of the web site. The Help Server address and port number is configured in the ClientSettings.config, so you need to change the config file of each and every existing Windows Client installation. And in the web.config of the Web Client. Luc explained that in his post, so I’m not going to repeat that here. By the way, I never understood why the settings of the Help Server are controlled in the ClientSettings.config and not via the NAV server settings, but that’s a different discussion…

So let’s assume that the name of the server is dynamicsnav and the domain is mycompany.com. Then we can have URL’s that start with:

NAV 2013 R2
Web Client: http://dynamicsnav.mycompany.com:8080/
Help Server: http://dynamicsnav.mycompany.com:49000/

NAV 2015
Web Client: http://dynamicsnav.mycompany.com:8081/
Help Server: http://dynamicsnav.mycompany.com:49001/

Change during installation

Now I want to mention some alternatives.

The first thing I want to mention, is the possibility to change the port number during installation. If you are going to install the web components side by side, you should notice before and choose what port number each web site will run on. The config files will be changed accordingly, so no need to change them afterwards.

image

 

Using aliases

The second one is a bit more complicated. But it is an option you should consider, it has some advantage. I’m talking about using aliases, in other words, changing the host name of the web site.

With using an alias it becomes possible to change the first part of the URL’s into a more meaningful name:

NAV 2013 R2
Web Client: http://nav2013r2.mycompany.com:8080/
Help Server: http://nav2013r2help.mycompany.com:49000/

NAV 2015
Web Client: http://nav2015.mycompany.com:8080/
Help Server: http://nav2015help.mycompany.com:49000/

As you can see, the URL’s are using the same port number, but the first part of the URL is different. This is called the host name. You can think of the host name as an alternative name or alias for your server. To change the host name of a server open the site bindings again and change… well… the host name:

image

The combination of host name and port number must be unique. Each request from a browser to the web server contains the host name and port number, so IIS can determine which web site will respond to that request.

But wait, a server has a unique IP address, but what about the alias? How can we add an alias to a server name so the browser knows the IP address where the request must be send to?

The aliases can be set up in the Domain Name System (DNS). This can be the DNS of a Windows domain controller for internal servers. Or an external DNS when the web server must also be available from outside. The DNS translates a server name to the IP address. This is done by DNS records. There are several types of DNS records, each with a specific goal. I’m not going to deep dive into DNS here, rather tell what I think is a reasonable set up:

Again with the dynamicsnav.mycompany.com server. Let’s give this server a fictional ip-address 100.99.88.1

The first DNS record is then an A record, which maps a server name directly to a static IP address. The other records are CNAME records which defines the alias for a server name.

Type Name Value
A dynamicsnav.mycompany.com 100.99.88.1
CNAME nav2013r2.mycompany.com dynamicsnav.mycompany.com
CNAME nav2013r2help.mycompany.com dynamicsnav.mycompany.com
CNAME nav2015.mycompany.com dynamicsnav.mycompany.com
CNAME nav2015help.mycompany.com dynamicsnav.mycompany.com

Advantages of this approach are:

  • Easy to remember URL’s
  • Use the same port numbers for different versions
  • And last, but for sure not least, it becomes possible to move the NAV web components to a different server without changing the URL. Only the CNAME record changes and users will not even notice it.

3 thoughts on “NAV Web Client and Help Server side by side

  1. Pingback: NAV Web Client and Help Server side by side - Microsoft Dynamics NAV Thoughts - Dynamics User Group

  2. Thanks for sharing. In my opinion, if you use host headers, you can bind them to the same IP and port number. So it simplifies for the user, not to learn the port number, just the hostname with the base URL :-).

Leave a Reply

Your email address will not be published.