Convergence 2010 - 3-Tiered Deployment

Last session of the convention for me ... one about the deployment of the 3-tiers of NAV 2009. Now, besides all jokes ... I always wondered, how on earth do you pronounce "tier". I always say it like you would say "teer" in English, but I'm sure as hell not sure it should be done this way ... But anyway ... Let's learn something.

2-tier vs 3-tier.

(Damn, there are lots of drawings on his slides, so this is going to be difficult to explain) Claus Busk Andersen explained the difference, which is quite clear, isn't it? The difference is the extra service (service layer) that is handling the business logic (or should I say: most business logic).


They wanted a more secure deployment model ... Business logic is executed on a secure application tier, and the database is only exposed to the application. On performance and scaleability level, the impact of the client is minimized... . And off course, this architecure is much more scaleable. Last but not least, this architecture gives us lots more exciting deployment benefits:

  • Maintenance
  • Hosting
  • Web services
  • New types of clients (web based, mobile, ... )

So, the future looks promising...

Let's talk about some deployment scenario's... .

1. Demo installation

Also called "the next next next" installation. It will install all you want to be able to give a demo .. also SQL Server (Express)...

2. Database and Dynmaics NAV Server on same hardware

This is the easiest "customer" installation. This is a common entry level scenario. Many implementations will run this way. But hold on, it is also the least scaleable option ... So keep that in mind.

3. Database and Dynamics NAV Server on seperate hardware

This is much better scaleable due to the seperated components, but it's more complex to configure from an infrastructure point of view

4. Database and multiple Dynamics NAV Servers on seperate hardware

It comes down on one database server and multiple service servers that hosts the middle tier.

So, what's the process now?

  1. Client logs in: Look up spn of nav server
  2. Nav server validates user and calls sql server: Looks up spn of sql server and calls sql server with user's security context (delegation)
  3. Sql server performs requested action: Validates user's token and sends the requested data
  4. Nav server executes business logic if any
  5. Nav server passes results back to client
  6. Client renders UI

To smoothen the installation process, there is the "Best Practices Analyzer for NAV 2009 SP1". I talked about this before in one of my previous posts. What it does is it verifies:

  • appropriate versions of nav is installed
  • Connection strings are correct
  • Relevant services are running
  • Correct service principal names are applied
  • Delegation is configured

The last two seem to be the most interesting .. and indeed they are .. . I can only recommend using it! Be aware, it does not take into account the server config file... .

After clicking through a lot of slides (hard to keep up), Claus showed the analyzer by showing two virtual pc's: one with AD and the NAV client, and one with the service tier. It was a real 3-tier set up, being the service tier on a completely seperate box. When running the analyzer, there were (off course) many mistakes.

First thing he fixed was adding a user in SQL Server (user that starts the service tier), and gave it "select" access to the table "Object Tracking" on the right database.

Second, he created the SPN's on the service tier box. It's the popular "setspn" command that you can look up in the documentation... (in other words, I had no time to write them down). Two have to be created: one for the service tier, and one for the database.

Next, in Active Directory, he set up delegation. There are two options: Trust everything and Trust something. Off course, the second was chosen: and he set up the delegation only for the SQL Server machine.

That was it, he started a new scan in the analyzer, and you could see that the errors for the NAV Server were gone (there were only errors for the business web services ... which should be fixed the same way). Now, NAV2009 started succesfully in the demo.

Now, if this wasn't advance enough ... Let's go more advanced. Mike took over.

How to get other machines on NAV 2009? Like a machine at home, which is not part of the domain of the company. Mike started talking about Application Virtualization. It allows you to not having to install a second operation system for only running one application (like NAV). So, you could set up a virtualizationbox, install NAV, and go from there. Good to know, the app is really running on your machine, so you have everything you want: disks, printers, ... . On the desktop, the app runs in a virtualized environment. So, it virtualized the dll's and all it needs to be able to run.

Mike showed this on his machine as well. He showed a windows 7 with NAV 2009 installed .. or at least it looked that way, because it was a virtualized NAV2009. He launched the application, you could see the virtualization mechanism to work, and it beautifully worked ... seemlessly.

Next: RTC over the internet .. still when client is not in the same domain. Not through virtualisation, but just a full blown client. Is this possible? Seems like it.. . The set up is like you know as Claus demonstrated. Just a 3 tier implementation, but then with a firewall, that 's going to be configurated.

What are the configuration changes? Well, in active directory, you should change the delegation again (that Claus did), to not only allow Kerberos, but you allow any authentication protocol. Next, in the control panel on the client, you go to the credential manager and add a windows credential and set up the network address, user and password, and off you go.. . He showed it, and it worked. The pc is not in the domain, but the pc IS running NAV.

Boy, I'm learning new stuff here. :-)

Is it supported stuff? I don't know ... but I still don't think that it's a good idea to use the NAV client over the internet all day. It's good (and fast enough) to do ad hoc stuff, but it's not good enough (again, in my opinion) to have this set up for your daily job... If you know what I mean.

OK, that was it ... good job, guys. You simplified the instal l process, and even added new stuff. Good session!

Comment List