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 DVD\Prerequisite Components\Microsoft Report Viewer 2008\ ReportViewer2008.exe and select install or repair depending on if Report Viewer 2008 was already installed.

SQL Server option

CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

After click on the open config link on the error report page I located this key part for the problem

Configuring MSI package. Id = ‘SQLDemoDatabase’

Error 26204. Error -2147217900: failed to execute SQL string, error detail: CREATE DATABASE failed. Some file names listed could not be created. Check related errors., SQL key: CreateDemoDatabase SQL string: CREATE DATABASE [Demo Database NAV (6-0)]

The problem here is data files with the same name as the one we are trying to install already exist in the instance. To fix this problem we need to delete those already existing data files. On SQL server 2008 go to C:\Program Files\Microsoft SQL Server\MSSQL10.(instance name)\MSSQL\DATA and delete Demo Database NAV (6-0).mdf and Demo Database NAV (6-0)_log.LDF. After this start main installer again and execute repair.

My blog posts http://blogs.msdn.com/nav/archive/tags/peterwib/default.aspx
All blog post http://blogs.msdn.com/nav/default.aspx

If you get this error when trying to start the RTC, it normally means it’s something wrong with the licenses.
Ensure that the license you are using have permission to run RTC and service tier (correct granule). Granule needed for RTC.
• 9,000 Role Centers
• 9,100 Dynamics NAV Server

Ensure also that the license is uploaded.
1. Start classic client
2. Open the database used by RTC
3. Click Tools->License information
4. Click upload and pick the license file to be uploaded to SQL server

Ensure also that the license is saved in the database.
1. Start classic client
2. Open the database used by RTC
3. Click File->Database->Alter
4. Click on integration tab
5. Put a check mark on “Save license in database”

If it works in the classic client make database login synchronization.
1. Start “classic client with SQL” and connect to the database as above
2. Click Tools->Security->Synchronize all logins
3. Answer yes to the question if you would like to synchronize

If it doesn’t to connect to the database start SQL server manager and verify that the windows user have permission to login and use the NAV database

Intro
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.

Find the whale blog here: http://blogs.msdn.com/nav_developer/archive/2009/08/17/troubleshooting-multi-machine-installations-of-nav-2009.aspx