Sometimes we need to have few Microsoft Dynamics NAV 2013 services connected to different SQL databases but running on the same server. Let us say few developers are working on different databases and want to see how RTC works with their customizations. Or maybe we want to compare how different RTC versions/builds work and want to compare functionality.In article http://blogs.msdn.com/b/nav/archive/2009/11/17/how-to-run-2-rtc-on-the-same-pc-and-connect-it-to-different-db-how-to-run-pages-reports-from-diff-db.aspx I described how to have few RTC on the same client computer in NAV 2009. This is also very useful now in NAV 2013, but let us look what new we have in NST site in NAV 2013
With Microsoft Dynamics NAV 2013 we have few solutions how to create new NAV service (NST). First NAV 2013 Service we already have installed by NAV DVD and now we want to have more
In both ways created services can be managed using Microsoft Dynamics NAV Administration Tools, so it is very easy modify services for any further needs. However if we try to remove service by using function “Remove”, then tools uninstall service and remove folder (including all binaries) and this can be problem if we have few services based on the same binaries folder.
Few Microsoft Dynamics NAV 2013 services can share the same TCP communication ports (Attention: do not mix it with NAV 2009). However, here are few tricks need to do before we use port sharing:
These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.
Gedas BusniauskasMicrosoft LithuaniaMicrosoft Customer Service and Support (CSS) EMEA
Thanks for this useful post. Is it possible to control which version is used to create a new instance when using the Administration Tool? For exmaple I've got a few services running 7.0.33995 and I now want to create a new one running 7.0.34194. That fine, I can create a new service using sc create.
If I want to then add another 7.0.34194 instance, can I create one using the admin tool? Failing that can I manually add config files to the instances folder for my 7.0.34194 service or do I have to create more services using sc create?
Hi, does the different services really use different build versions?
I understand that the executable binaries are used from the directory they are started from but what about the dlls? Aren't they registered to the registry during install. So when C:\AnotherBuild\Microsoft.Dynamics.Nav.Server.exe is runnning and needs some functionality from a Nav dll it calls from registry that where the particular dll is installed. Doesn't the registry then point out the dll from the first install directory (probably C:\Program Files\Microsoft Dynamics NAV\70\Service)? And because there are multiple builds running on the same server isn't this firstly installed dll from a different build than the executable itself?
This is the main reason I'm hesitant to run different build version on the same server. Am I just nitpicking or have I misunderstood the way dlls work in Windows?
very useful post
All dlls related to new build has to be in new folder (for example C:\Program Files\Microsoft Dynamics NAV\70\Service Latest) and of course RTC client needs own folder with the new build too. Then it works.
In this case I have only one issue - debugger, by running it there is en error message:
The client version does not match the server version. You can only connect to a server with a matching version.
Client version: 7.0.33781.0
Server version: 7.0.34902.0
Of course running from 7.0.34902 client. Any idea what to change?
Whenever I do step 2 part b (using powershell to create the service), My service is created but when I look in the Administration Tool, the service is called (Default). I have changed the service instance in the config file. Any ideas?
@Chris, you need to escape the $TestNAV70, by adding a ` before the $sign; it would look like this
-BinaryPathName '"D:\NAV 7\Service\Microsoft.Dynamics.Nav.Server.exe" `$TestNAV70
Then the service is properly created.
Another tip: if you, like me, download the files from PartnerSource and don't get the service running (this was caused by MS Filescreen, blocking the executables and dll's) go in to the service (and if you also create a role tailored client folder, do the same there) and run the following powershell command (you need PS 3.0 or higher):
get-childitem -recurse | unblock-file
Try running your service again, and it ought to work.