How do you handle version updates?

johnjeffers

First off, apologies in advance if this is a newbie question, but...I'm a newbie. I started a new job where we use NAV, but there isn't much NAV systems expertise on staff. So, I'm attempting to figure it out as I go.

I'm trying to come up with a plan to upgrade from NAV 2013 R2 CU8 to CU11. However, I quickly discovered that this is going to be a lot more complicated than I thought due to the fact that the RTC client version and Service Tier versions must match exactly. It seems that I can't stage a rollout of the upgraded client, and will have to do it all in one shot.

This seems very bad. And very weird. I've never run into anything like this before, where the client and server can't be upgraded separately. Am I missing something obvious, or is NAV really that strict about versions having to match exactly? And if that is the case, what's the best practice for doing these incremental updates?

Marijn

To my knowledge, the versions must indeed match. But these kind of upgrades are usually very rare. Only done once a year or every two years at maximum or so. Updates of the business logic, is a very different thing. These updates are very frequently needed for bugfixing and new functionality. These updates, with the fob extension, are backwards compatible most of the time and do not give you too much trouble.

johnjeffers

People in larger environments, how do you do this?

I have to touch well over 100 machines, many in remote locations. Is there a better option than simply saying "we've upgraded the server, and sorry, but your NAV client won't work until we get to your computer"? Of course I'm looking at automated rollout via GPO, but that's never 100% successful. And how are you supposed to test before you roll out?

One approach we thought of was to have multiple service tiers pointing at the same database. In other words, we have the existing CU8 service tier, and then we spin up another service tier, upgraded to CU11. But, for reasons too complex to go into here, our front end web server that interfaces with NAV won't work properly if we have clients attaching to multiple service tiers. So, that's out.

It really looks like my only option is to upgrade everything at once, with no opportunity to test. Any other advice would be GREATLY appreciated.

Cyberghost

Hi John

I think ClickOnce will do what you are after. ClickOnce holds the software on the server. When you login to NAV, it checks your version against the current server version and if necessary, it will download the latest version to you as the client.

If is also possible to have two (or more) clickonce clients, connecting to two different NAV services, so that you can update one without updating the other. It is something I have been playing about with recently and whilst a little bit of a pain, not the end of the world.

If you have any questions, please ask.

Cheers

Chris

johnjeffers

Thank you, Chris. I will look into ClickOnce. Cheers!

Kowa

For future updates it should be easier because a version check parameter has been introduced in CU 14 last month:
http://blogs.msdn.com/b/nav/archive/2014/12/05/introducing-a-build-version-check-between-nst-and-windows-and-web-clients.aspx
Most large scale environments use terminal servers like Citrix so there is no need to update any local NAV clients separately as everything can be done on the server.
But for your current update, ClickOnce seems to be the best bet.

johnjeffers

Kowa wrote:

For future updates it should be easier because a version check parameter has been introduced in CU 14 last month:
http://blogs.msdn.com/b/nav/archive/2014/12/05/introducing-a-build-version-check-between-nst-and-windows-and-web-clients.aspx

That article confuses me even more. From the article:

Have you ever wonder what 'The client version does not match the server version. You can only connect to a server with a matching version.' error message really means? Since the error message shows the file (build) versions of the client and server it has been speculated that only clients and servers of the same build can connect, which is not the case.

This bit implies that you can get around the client/server mismatch error. True?

So, people has asked us why we don't change this version every time we deliver a Cumulative Update. Well, there is really no reason, as this would force all the installation to be changed simultaneously and also would snatch the opportunity to just update one side of the installation

This is the exact problem I'm running into. Because the version changed, I'm now getting the error, even though he's saying that doesn't happen with Cumulative Updates.

TrippyZ

You should deploy your new client version using Group Policy. Lookup "SIS - Software Installation Services".