Troubleshooting multi-machine installations of NAV 2009
The NAV 2009 documentation walkthroughs provide step-by-step instructions for installing NAV 2009 on 2 or 3 machines. However, we have found that some of the same configuration issues come up time after time after installation.
When on calls with partners and customers, it seemed to me that this information was spread out all over the place, so I wanted to organize it in a different way for troubleshooting purposes so that I would have most everything in one place. Hopefully this will be helpful to others as well.
The intention of this post is to provide a checklist of sorts for troubleshooting some of the areas where we frequently find errors or omissions in configuration after NAV 2009 has been installed.
Errors on the RTC resulting from configuration problems include but are not limited to...
Login failed for user...
A Server was not found at...
The User ID and password are invalid
*************************************
Before anything else, check to see what accounts are running the NAV and SQL services. Make note of domain account names, machine names, and FQDN (Fully qualified domain name)
Check for Incorrect SPN’s
When the NAV Server and the database are on separate machines AND the NAV Service is running under a Domain Acct:
2 SPN’s have to be set up for the NAV Service. SERVER will be different depending on your server name.
i.e. Server_DynamicsNAV/Server.FQDN:7046
Examples…
SERVER_DynamicsNAV/SERVER.NAV2009DC.LAB:7046
SERVER_DynamicsNAV/SERVER:7046
SPN for SQL Service is not needed IF SQL is running under NetworkService.
SPN for SQL IS needed if SQL is running under a Domain account – see "SQL SPN" at the end of this post
When the NAV Server and the database are on separate machines, AND the NAV Service is running under NetworkService account:
No SPN is needed for the NAV Service.
SPN for SQL Service is not needed IF SQL is running under NetworkService.
SPN for SQL IS needed if SQL is running under a Domain account – see "SQL SPN" at the end of this post
Tools
Tools are normally installed on Win 2008 by default (depending on features selected). For 2003, install the Windows Support Tools
- Windows 2003 Support Tools
o ADSIEdit.msc
o SETSPN.exe
Setting the SPN :
o Run the ADSI Edit tool on any server computer in the domain. To do this, click Start, click Run, type Adsiedit.msc, and then click OK.
In the ADSI Edit window, expand Domain, expand DC, expand CN=Users, right-click CN= AccountName, and then click Properties.
Note: The AccountName placeholder represents the domain account you are using to start the NAV Server (and/or SQL) service.
In the Properties dialog box, double-click the servicePrincipalName attribute to open the Multi-valued String Editor dialog box. (There are a few shortcuts to find the servicePrincipalName, you can check the ‘Show only attributes that have values’ to shorten the list or click in the Attributes box and type ‘ser’ to jump close to the attribute.)
In the Value to add box, add a SPN for the NAV Server (or SQL Server), and then click Add, keeping in mind that the SERVER will be different depending on your server name. For SQL SPN see Appendix A.
SERVER_DynamicsNAV/FQDN:7046
Note: Replace “SERVER” with the name of your server, and “FQDN” with the fully qualified domain name, such as “SERVER.MICROSOFT.COM”.
In the Value to add box, add a SPN for the NAV Server, and then click Add. Keeping in mind that the SERVER will be different depending on your server name.
SERVER_DynamicsNAV/SERVER:7046
Note: Here for the “SERVER” value, only specify the name of the server.
Click OK two times.
Close the ADSI Edit window.
Check Delegation
When running the NAV Service under a Domain Account:
Delegation has to be set up for the account running the NAV service.
Note: The Delegation tab will only be present after adding the SPN to the domain user account.
o Click Start, then click Run.
o Type in dsa.msc and click OK.
o Expand the Domain and then click on Users.
o Locate the domain user account you are using , right click and select Properties.
o Under that Delegation tab, select the ‘Trust this user for delegation to any service (Kerberos only)’, then click OK. (This is not constrained delegation as mentioned in the Walkthrough, but this makes it a little easier to setup delegation. You can always come back after it is setup and working to implement constrained delegation.)
o Close the Active Directory Users and Computers window.
o Note: for Constrained delegation, select Trust this user for delegation to specified services only and then select MSSQLSvc.
When running the NAV Service under NetworkService Account:
Delegation has to be set up for the machine running the NAV service.
o Click Start, and then click Run.
o Type in dsa.msc and click OK.
o Expand the Domain and then click on Computers.
o Locate the computer name, right click and select Properties.
o Under that Delegation tab, select the ‘Trust this user for delegation to any service (Kerberos only)’, then click OK.
o Close the Active Directory Users and Computers window
Check SQL Logins and OCL
Adding the login(s) to SQL and setting up the Object Change Listener (OCL):
OCL is NOT required if the NAV Server and SQL Server are on the same machine AND the NAV service is running under Network Service.
If using a Domain User to run services, make sure the login has been added to both SQL and NAV. Also check that user has Full Control to the server folder.
o The account may already exist in SQL but the permissions must be manually set correctly):
Open Microsoft SQL Server Management Studio.
Click Security to expand the tree-view, right-click Logins, and then select New Login.
This opens the Login - New dialog box.
Add the domain user account in the Login name field, using the following format:
domain\domainUser
Click OK to exit the Login - New dialog box.
Click Databases, Demo Database NAV (6-0) or other database name, and then click Security to expand the tree view.
Under Security, right-click Users, and then select New User.
This opens the Database User - New dialog box.
Add the domain user account in the User name and Login name field, using the following format:
domain\domainUser
o Add $ndo$navlistener in the Default schema field.
Click the Securables page.
Click Add, click OK, click Object Types, check Tables and then click OK. Click Browse, check the [dbo].[Object Tracking], click OK, click OK again.
In the Explicit permissions check Grant on the Select permission.
Click OK to exit the Database User - New dialog box.
Close Microsoft SQL Server Management Studio.
If the NAV server and SQL Server are on different machines AND the Network Service Account is running the NAV Service, then the Login and OCL must be set up using the same steps but for the machine account rather than the domain user…
Use the above steps, but replace the domain account with the machine account, i.e. <domain>\<computername>$
Check the configuration of Delegation for the RTC
Change the ClientUserSettings.config on the computer running the RTC, under the current user's profile, to define that a domain user account is to be used when connecting to the NAV Service tier.
On Windows Vista or Windows Server 2008, the default location is:
X:\Users\\AppData\Local\Microsoft\Microsoft Dynamics NAV
On Windows XP or Windows Server 2003, the default location is:
X:\Documents and Settings\\Local Settings\Application Data\Microsoft\Microsoft Dynamics NAV
Add the following key to the file:
<add key="DelegationInfo" value="DomainUser"></add>
There are two possible values: NetworkService and DomainUser. To enable delegation, set the parameter to DomainUser.
This will need to be repeated for all workstations that will be using the RTC.
After confirming all items above and making any changes, be sure to stop and start the NAV Server service before you attempt to re-connect using the RTC. If you still encounter the error message, remember that Kerberos tickets last for 10 hours, so if you add/change the SPN, you may either have to wait for any existing tickets to expire or download KerbTray and attempt to expire any existing tickets. This is found in the Windows Server 2003 Resource Kit, which can be downloaded from:
https://www.microsoft.com/Downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en
Check the SQL SPN (if applicable)
SPN must be added for SQL Server when running under a domain account.
There are errors in the documentation walkthrough regarding how to create the SPN for SQL. The easiest way to check for the correct SPN syntax is to look at how it automatically generates the SPN when running with network service (switch the account running the SQL service to NetworkService, check the SPN and use that to set up the SPN for a Domain Acct.
An example might be...
MSSQLSvc/LALA1719334.NAV2009DC.LAB:1433
where
SQL Service = MSSQLSvc
Server = LALA1719334
Domain = NAV2009DC.LAB
Port = 1433
Laura K. Lake
Microsoft Dynamics NA
Microsoft Customer Service and Support (CSS) North America
These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.
Comments
Anonymous
August 20, 2009
Beware of KB968189 and the impact on the App Server SPNs.Anonymous
August 21, 2009
The comment has been removedAnonymous
July 10, 2014
Hi, Thanks for this post very helpful. i have a problem with calling nav webservice in 3 tiers architecture from a remote session. My nav web service is under domain account. when i try to call nav web service with soapui i have this message Fri Jul 11 12:37:06 CEST 2014:INFO:frcp00vpp1322:7047 requires authentication with the realm 'null' RTC work fine in 3 tiers architecture. i use proxy fiddler and it work , because fiddler can read kerberos tickets without problem. i must call my webservice with soapui. Have you any idea please? Thanks