Changing the clocks in Dynamics NAV or Dynamics 365 Business Central

Let's begin with a quote from a little-known band called Jukebox The Ghost:

Time and I don't see eye to eye

Try as I might, it ain't no friend of mine

Twice a year in Britain our clocks get moved forward or backwards as part of the thrill that is British Summer Time. Many nations in sunnier climes tend to joke about the term.

Growing up in the 80's, this meant going around the house twice a year to set all our clocks forward one hour in the Spring or one hour back in the Autumn. Nowadays, with so many clocks taking their time from the internet, it's a lot easier but there can still be a few problems. Here is one that appears frequently on our helpdesk whenever there is a clock change:

The client could not establish a connection to the Microsoft Dynamics NAV Server.
Fault Code – 'InvalidSecurity'
Reason = 'An error occurred when verifying security for the message.'

So what is that all about?

The InvalidSecurity error means the server and the client PC’s clocks don’t match up. A difference of less than 5 mins is okay but anything outside that makes the program go, “Great Scott!” and show the error above. The quick solution is to get the user to check their Windows clock and adjust the time.

But what if this error suddenly affects lots of users, especially when entering or leaving British Summer Time? Don't the clocks automatically change? The clients can't all be wrong can they? All good questions and the eye of suspicion should instead fall on the server.

On the middle-tier server, open the Administration Tool for NAV / BC. The server instances have a value called Services Default Time Zone that's shown in the General tab. It’s a good idea to set this to ‘Server Time Zone’ rather than the default value, which is ‘UTC’. The service needs a restart for the change to take effect so arrange a good time to do that as your users will be kicked off their clients if you restart in the middle of their work day. This ‘Server Time Zone’ setting helps the server and clients roll with the changes brought about by the wonders of British Summer Time.

An extra benefit is that this setting will ensure Job Queue Entries run on time rather than an hour later than expected.

Finally as an additional detail Services Default Time Zone can also be set to a specific time zone if for example you have staff based in multiple countries and they need their own instance to connect to.

So perhaps time on the server and the client can see eye to eye after all.