As IT people we like to be in control. We can have disparate systems, spread across various geographic locations, yet still rest assured that there is very little that we cannot administrate from the comfort of our own office.
For this reason, we are none too keen on how users connect to the Microsoft Dynamics NAV database using the RoleTailored Client. Users have to enter the correct combination of [Server]:[Port]/[Instance] to get to the correct database.
It is true that the settings are retained and the user will not have to enter them subsequently. It is also true that these settings can be specified during the client install – in which case they may never have to enter them. However, these settings are stored in a config file on the local machine.
What if the server address for RTC changed for any reason? Sure, you could send an email round – but you can probably guarantee you’ll get some confused phone calls. You might even, perish the thought, have to embark upon a desk by desk tour of all the PC’s in your company.
Another consideration is load sharing. If you have more than 20 to 25 users running RTC you’ll probably want to consider having more than one middle tier server available to spread the load. With the middle tier connection saved on each client, trying to manage which users connect to which server could easily become something of a headache.
We feel your pain. So, we’ve developed some load sharing capability for NAV. Within NAV you can enter the details for the middle tiers that you have available. For each user you can specify the middle tier that you want them to connect to – or you can leave NAV to spread new connections equally between the servers.
When the users run the client, they first pass their domain SID to a NAV web service, which decides on the middle tier to connect them to and returns the server, port and instance details. The client is then launched with these details and the user connects to the correct server.
If you need to make a middle tier unavailable e.g. if you are doing some work that will require a reboot of the server, you can disable it in NAV, and users will not be directed to it.
Even if you only have one middle tier, it is nice to know that you can control and change the connection details centrally and with that bring this rogue aspect of NAV back under our remote control. We can direct and monitor connections to the middle tiers without leaving our chair – and let’s face it, as IT admins, that’s the way we like it.
If you’re interested, drop us a line at the usual address.