In a developer or test environment
1. Install Service, Database and Classic client on the server machine.
2. Create the needed windows users on the server machine
3. Add the newly created window users to NAV in classic client, under Tools->Security->Windows Logins
4. Now sync all new logins in classic client, under Tools->Security->Synchronize All Logins
5. Install RTC on client machine
6. Update ClientCredentialType in C:\ProgramData\Microsoft\Microsoft Dynamics NAV\ClientUserSettings.config (path is for Windows 7 and Windows 2008) to “UserName” on client machine. Also update the server key to server machine name. It’s important that you have never started RTC on this machine before to make this working.
7. If you have started RTC earlier on the client machine you also need to update ClientCredentialType in C:\Users\[user name]\AppData\Local\Microsoft\Microsoft Dynamics NAV\ClientUserSettings.config to “UserName” on client machine. Replace [user name] with your user name. Also update the server key to server machine name.
8. Start RTC and you will get a popup box asking for credential. For user name type “[server machine name]\[user name on server machine]“.

For an production environment I would recommend to use certificates to authorize the connection between RTC and server. Guides to setup certificates can be found under subject “Procedural Overview” on http://msdn.microsoft.com/en-us/library/gg502476.aspx

The event log explain the problem like bellow. So it obvious that we of some reason can’t connect to the database.
Type: System.Data.SqlClient.SqlException
Class: 14
LineNumber: 1
Number: 916
State: 1
Source: .Net SqlClient Data Provider
ErrorCode: -2146232060
Message: The server principal “XX\YY” is not able to access the database “ZZ” under the current security context.

When looking at the security for database “ZZ” I found the same problem as the event log was pointing at, no trace of user “XX\YY” with gives the NAV service access to the database. It turns out that when adding or deleting a NAV user all user privileges is re-synced, and any user not part of the new list is deleted. And if the NAV service account is not part of the user list, NAV service can’t longer connect to database.

The solution is very simple. You have to make sure that the service account is added as a user in NAV under Tools – Security – Windows Logins. Followed by syncing logins.

How to-do it?
It’s very simple. “setup.exe” does support some different parameters for this purpose:
/quiet <– will turn of the UI
/log [filename] <– create a log text file in the specified location
/config [filename]<– point to the configuration file to use during the installation
/uninstall <– will simple un install the product
/repair <– repairs a bad installation

The first thing that needs to be done is to create the configuration file that we will use.

1. Star “setup.exe”
2. Click “next”
3. Click “I accept”
4. Click “Choose an installation option”
5. Click “Custom Components”
6. Select the product that you want to install
7. Update destination folder if needed by clicking on the “destination folder” link
8. Click “next”
9. Click on the component that you have picked to setup the different parameters as “server name” and so on. When done apply your changes.
10. Click “save configuration”
11. Pick a good location, name and save the xml file

You can create as many configuration files as you want for different purposes. Now, you can run the silent install by simply doing start -> run -> [setupExepath] /quiet /config [configfilepath.xml]. Be sure to take a look to the log file, to ensure everything went OK.

Example D:\setup.exe /quiet /config C:\configfiles\config1.xml /log C:\log.txt

This error may happen when you are attaching the database manually, or if database and NAV service is on two different machines. A variation of this may also happen if you setup NAV server to user domain user account. Luckily the solution is the same for all problems

Enabling the Object Change Listener
1. Open “SQL Server Management Studio” and then connect to your SQL Server instance.
2. On the File menu, point to New, and then click Query with Current Connection.
3. Type the following SQL statements.

USE MASTER
CREATE LOGIN [ReplaceWithNAVServerAccount] FROM WINDOWS;
GO

4. Highlight the lines that you typed and, on the Query menu, click Execute.
5. Now type these lines below the existing lines.

USE [ReplaceWithYourDatabaseName]
CREATE USER [ReplaceWithNAVServerAccount] FOR LOGIN [ReplaceWithNAVServerAccount];

6. Highlight the lines that you just typed and, on the Query menu, click Execute.
7. Now type these lines below the existing lines.

CREATE SCHEMA [$ndo$navlistener] AUTHORIZATION [ReplaceWithNAVServerAccount];
GO

8. Highlight the lines that you just typed and, on the Query menu, click Execute.
It’s very possible that you will see an error stating that the schema in question already exists. This is not a problem.
9. Now type these lines below the existing lines.

ALTER USER [ReplaceWithNAVServerAccount] WITH DEFAULT_SCHEMA = [$ndo$navlistener];
GRANT SELECT ON [Object Tracking] TO [ReplaceWithNAVServerAccount];
GO

10. Highlight the lines that you just typed and, on the Query menu, click Execute.

This could probably be combined to a simple script.

And here is the list copied from Christopher.
1) Remember that your install is the very first impression the user gets of your application. If your install sucks or worse fails that will not want to use your software or your support desk will get flooded with calls. I can not understate this point. I have saved companies from the brink of bankruptcy by fixing their deployment problems and I’ve seen companies fail that were unwilling to take their problems seriously.

2) The install must be bullet proof. It must work on any kind of machine you throw at it. Keep It Simple and avoid anything that could be brittle. Know and follow all current windows platform best practices

3) Perform all of your checks, user inputs, validation up front. Prevent failures up front.

4) Have a clear point of no return. You should make no state changes prior to that point and there should be no user prompts after this point.

5) Avoid Reboots – e.g. Don’t settle for getting your service to start by performing a reboot

6) The installation should be transactional ; support rollback. We are all on or all off – no in between.

7) The installer must support silent installation including all settings that could be manipulated if running interactively.
 Keep the UI Simple. People don’t read; they just press next. Let the defaults represent the general case.

9) Don’t step on other peoples software. Take care with regards to DLL hell when installing shared components.

10) You must have a safe uninstall that doesn’t break the system or ask the user scary questions like “do you want to remove these shared dll’s?” Dll what? is what your use will think.

11) Think ahead about servicing your application. You must be able to upgrades and patching ( your choice )

12) Always avoid rolling your own. Learn to use Windows Installer and follow all of it’s best practices.

Finally I have a personal mantra that I follow:
It’s not my machine, it’s my customers machine. DO NO EVIL.
1) Don’t change system settings. I once had a developer ask me to change the regional settings to make a report look better with no concern of the broader implications.
2) Don’t change the security posture of the machine. Don’t open up ACLs on directories or create service accounts with fixed passwords.
3) Don’t install ad-ware / malware. Sorry but no, I don’t want your damn Google / Yahoo! toolbar and so on. If you must, make it an opt-in not an opt-out and by damn don’t intentionally break your UI so that when the user says no you do it anyways.
4) Don’t be annoying with autoupdates. Make it an opt-in not an opt-out.

Christopher Painter gives this example on his blog post to explain the problem:
So let’s start with a simple example. Let’s go back 10 years in time and pretend we are writing an x86 application and x86 installer with no concern for x64. Someone hands you a vb6 EXE and a regfile ( HKLM\SOFTWARE\Company\Product type entries ) and says this is what needs to be deployed. You go off and create an MSI that writes the registry values, deploys the EXE and creates a shortcut. Now let’s come back to present. You take that MSI and throw it on a modern Windows 7 x64 box and it works just fine.

But now let’s pretend that the EXE was a .NET application. If it was compiled as x86 it would behave the same way. But if that application was built at AnyCPU ( the default for all versions of Visual Studio prior to VS2010 ) we are going to land in one of those traps. Here’s why:

MSI is marked as an x86 package so it writes the registry data to the Wow6432Node of the registry so the expected x86 application can find it. While the EXE gets installed to ProgramFiles(x86) it will actually JIT as a 64 bit process. This process will fail to find it’s registry resource at runtime and crash. This is because the .NET BCL Win32.Registry class cares about bitness.

You can find his complete post here

The problem I did run into was that when starting the RTC client it could not connect to the service, since I had moved the service. Since the service had moved I did say “no” to the questions if RTC should try to connect again. In the address field in the “server selection window” I did type the new address into address field. The “OK” button was now greyed out, so I could not connect to the server.

After spending some time to try to figure it out how to un grey the “OK” button I found by simple press TAB in the address field make RTC to connect to the service and retrieve the companies on the service. Now the “OK” button was not greyed out anymore.

Probably cause:
You have installed the RTC client outside the setup chainer or you have uninstalled Report Viewer 2008. It may also be that Report Viewer 2008 installation is broken.

Solution:
Run DVDPrerequisite ComponentsMicrosoft Report Viewer 2008 ReportViewer2008.exe and select install or repair depending on if Report Viewer 2008 was already installed.