Microsoft Dynamics NAV 6.0 is making my head hurt

So, several things have been “bugging” me while working with this.
First of all, if you are running a 3 tier setup (and you probably are) then NAV server will need to monitor changes in the database. It can do this in one of two ways. Pooling or using notifications, though the service broker. If using pooling it will do a series of SQL queries against the database every few seconds to see if they have been any changes, this is even if you only have one NAV Server service running and all chances are bound to happen though that service anyway. The other way is is though the service broker, where each NAV service can “subscribe” to changes in certain parts of the database and get notified by the SQL server when ever changes occurs. This will ofc lower the “stress” on the SQL, especially if you are running several NAV services for one or more databases.

Pooling works out of the box, no problem. But using Service broker seems more appealing to me. Service broker works out of the box if your running the NAV Server as Local System/Network Service. When running as a domain account it needs a bit more “tweaking”, explained when following this guide.
http://msdn.microsoft.com/en-us/library/dd568739.aspx

As always, Kerberos was giving me a hard time and while troubleshooting one of the errors I noticed I was getting a ton of these errors on the SQL server.
(The activated proc '[$ndo$navlistener].[SqlQueryNotificationStoredProcedure-cf5de25d-f6a3-457e-928f-cfd42a83f241]' running on queue 'NAV6_NAVI0101.$ndo$navlistener.SqlQueryNotificationService-cf5de25d-f6a3-457e-928f-cfd42a83f241' output the following:  'Could not obtain information about Windows NT group/user 'int\NAVI01_NAV601_NAVI01', error code 0x534.')

If you search Google for this error you wont get a lot of hits, most tell you to do some stuff that, to me, didn’t make a lot of sense. From what I can understand basically this error comes when the SQL server cannot resolve the user. This can happen if the account your running the SQL Server Agent as, doesn't have read access to the account mentioned in the error, or the account doesn’t exists.
I got the error while backing up and restoring various NAV databases and hadn't cleaned up the database between the restore.  If you backed up a database and restored it, and get this error just, stop the Navision server, delete the Queue and associated service, then start the Navision service again.

When testing Navision from the Role Based client, its worth mentioning that the Navision Client will save all user configuration in the LOCAL profile and not the roaming directory. ( this is mentioned on page 31 in Microsoft Dynamics NAV - Hosting Guide too. You get around this by placing the config file somewhere else, and pointing to that file by adding settings:{path} … the guide suggest copying the file to %APPDATA%\ClientUserSettings.config but it could be anywhere that makes sense in your environment.

If you get this error from the client, when tested on a “remote” machine, but everything is working when called locally on the Navision Server
(The login failed when connecting to SQL Server [FQDN] )

you probably got the delegation on the Navision account wrong (or if running as local system, delegation on the computer account for the Navision server ) The account need access to pass on the user’s credentials to the SQL Server. IF the SQL server is running as local system, it needs delegation permissions to the SQL computer account, else to the account that SQL Server is running as.

Either of the 3 options here will work. Trusting user for delegation to any service (Kerberos only) is not considered safe or secure and should never be used (but will work for Navision too)
Trusting for delegation to the SQL account/server for the Service type MSSQLSvc for Kerberos only is the recommended and most secure way. If you want to support NTLM authentication too, you will need to set this to “any authentication protocol” but this is considered less secure.

One way to check if Kerberos is configured correctly would be to set above to “any authentication protocol” and then in ClientUserSettings.config set AllowNtlm=True. If this works, then change ServicePrincipalNameRequired=True and AllowNtlm=False. If you get the below error

The remote server did not satisfy the mutual authentication requirement

Something in the Kerberos authentication went wrong. Looking though the Security Event log will be extremely helpful. Don’t just give up and set AllowNtlm to True. That is for losers

And remember. If something is running as Local System or Network Service, it is running as the computer account. If you mess with SPN or delegation on that computer account, you need to restart the server for the changes to take effect. If you are running as a domain account and make chances to that, you need to restart all services running as that account for the chances to take effect.