Help migrating NAV 5.0 to new server

Thorsteenster

I've been tasked with configuring a virtual server with Server 2008 R2, SQL Server 2008 and the lastest version of NAV 5.0.

Currently we have NAV 5.0 on an old server with 2003 and SQL 2005 with a document approval on another server that has been virtualized due to failed hardware.

Within the next year we're replacing or upgrading Navision and isn't very cost effective to put money into it currently that our consultant says it'll cost.

Migrating to the new server is 2 fold, the document approval hasn't been working, and the hardware it lives on is six years old.

I've tried looking on our current servers to see what components of Navision are installed, but it keeps asking for the install media, which of course I don't have.

I've been playing around with installing C-Side client, App Server, and DB server but am having issues.

If someone can help and/or provide links to installing, upgrading, migrating Navision 5.0 I'd greatly appreciate it.

Thanks!
(sorry if it's lengthy, but I'm not really a software guy, especially involving SQL!)

Alex_Chow

Here's the media for version 5.0.
http://www.mibuso.com/dlinfo.asp?FileID=825

You don't know how to do the migration, it may be worthwhile to pay your partner to do this for you.

ppavuk

Technical migration is simple enough, but something inside me tell me that better if you pay partner for this

stryk

Here you'll find some "walkthroughs": http://msdn.microsoft.com/en-us/library/dd568710.aspx
Well, that's actually about NAV 2009, but for the "classic" architecture at least parts of that apply to NAV 5.0 SP1, as well.

But have in mind that "Mainstream Support" fro NAV 5.0 SP1 endet several monthes ago; so if you are going to establish a completely new Server, why not considering a NAV upgrade, too?!

ppavuk

Another question - how to make full migration without partner licence? Did you got application designer granule?

Obviously, you can't edit system tables & codeunits with customer licence.

Sorry did not realized that this is just technical migration.

Thorsteenster

Our partner hasn't been very helpful at all which is why I'm turning to other sources.
Currently we are planning an upgrade to or replacing NAV, but completion is at least 1 year away.
We need to have NAV working just for this long, without spending a lot of money that can be towards our transition.
I'm not on that project, but we may go with Dynamics NAV, or another vendor.

I do have access to MS Dynamics NAV Customer Source, we must have software assurance because it shows NAV 2009 is available.

I think if I am to take this on, 2009 would be better than 5.0?

I didn't know there was a partner license and a customer license, is there a way to tell?

Obviousley I'm not doing it on our live server, other than to make a backup of the database to import to the new.

Another approach I can take is use Disk2VHD to create a virtual server, then upgrade from there, Server, NAV, and SQL. If this works I just need to setup a document approval system.
Perhaps this is a better solution?

I greatly appreciate help with this, our accountants and project managers do too!

ppavuk

Build a new server. Install SQL (2008 r2 if you want to use 2009 r2 NAV). 2005 is fine for 5.0. Install a new client on new server. Create database (same size as live one). Make a NAV backup of live DB. Restore it in new one.

Should be quite simple. Actually, you can refer to Installation Guide on you software CD, it is quite good.

You also need to install new client on each user machine.

I would say that technical upgrade to 2009 should not have any issue, there is more or less full backward compatibility.

If you are familiar with SQL - maybe better do a SQL backup, restore it on new server, and on first connect with new client, system will ask you to convert database. This will take a while, but will lead to same results as installation from backup. Install a client on server computer, as this will decrease network overhead.

Hope this helps.

Thorsteenster

Ok, I have SQL 2008 installed, NAV 2009 installed, imported the databse from old server, opened Classic with MS SQL server, and when I connect to the database it tells me it needs to be converted but then gives a error: "the object table has no primary key constraint in the sql server table description".
The only way I can find to set the primary key is from in the CSide client, but the Object Designer is greyed out, probably because I have no database open.
Is there a way to fix this in Managment Studio, or do I have to do something to the current database before exporting it to the new instance?

Alex_Chow

The easiest way is to do a backup in your old database in Navision (tools --> Backup). Then do a Tools --> Restore in the new database.

stryk

To fix the PK error in SSMS:

ALTER TABLE [dbo].[Object] ADD  CONSTRAINT [Object$0] PRIMARY KEY CLUSTERED 
(
	[Type] ASC,
	[Company Name] ASC,
	[ID] ASC
)
GO

But still the question remains WHY this error happened - this is not expected or normal :shock:
So a native FBK backup/restore to rebuild the database from the scratch might be feasible, but first you should make sure your db is not using any "SQL stuff" like custom views and "Lnked Objects" or maybe some SQL-site-added indexes, Procedures etc. - all this cannot be backed up by a native FBK!

Once your db is successfully restored make sure the "Database COmpatibility Level" is set to 100 (SQL 2008) - this is important with NAV 2009 as then it'll use the OPTIMZE FOR UNKNOWN hint (which is benefitial regarding performance).

If I understood you right, the VM machine is just used for testing?! If that was supposed to be your new live server I had to make some remarks regarding performance (e.g. assigne CPU fixed, not dynamically; don't use virtual drives or logical drives, etc.).

Thorsteenster

Ahh, I'll try a backup/restore from Navision, I was doing it in SQL management studio.

If all goes well with the VM (using Hyper-V), it will replace our current navision server, which I'll make a VHD of in case we need to bring it back online in a hurry.
For testing I want to get it working, have our accounting team test it for functionality and then do a fresh backup/restore and bring the VM live.

How can I check for "SQL stuff"?

Also, our current Navision server is partitioned to three drives, C, E, & T.
The VM is alotted a dynamic 160gb C drive, do I need to partition a E & T also or is all on C fine?
I think the E is for install location, and T for backups and logs.

Thanks all for your time and patience!

stryk

Thorsteenster wrote:

How can I check for "SQL stuff"?

Uhm, I'm afraid you can't ... actually you have to know what's implemented ...
Sure: in Management Studio you could manually check if there are Vies in the db which are not NAV system views or VSIFT, you could also check if there are any Stored Procedures or Functions, with querying sys.triggers you could check for Triggers ... but it's going to be tricky to find custom/non-NAV indexes ...

NAV itself does not have any of this; so it would have been added according to customize your system, or in progress of troubleshooting ... Thus, I guess your NAV partner should know about this ...

Thorsteenster wrote:

Also, our current Navision server is partitioned to three drives, C, E, & T.
The VM is alotted a dynamic 160gb C drive, do I need to partition a E & T also or is all on C fine?
I think the E is for install location, and T for backups and logs.

In a SQL Server environment you should NEVER use logical partitions. WIth SQL Server it is all about physical drives, thus real RAID volumes, directly attached; even in VM you need to have raw devices. LUN on a real SAN might be an exception.
This needs to be investigated & discussed more thoroughly ...

Thorsteenster

As you may have noticed, I'm not very familiar with NAV or SQL.
Is the "SQL stuff" things our NAV users would notice?

Glad you mentioned that about SQL, I'm re-evaluating the VM for it.
The host has a raid 5 for storage with 500gb of free space currently.
What I'm thinking is to backup and delete the current array, create two virtual disks, one for the host, the other for the NAV VM.
Create a 64gb IDE for boot/OS, then connect the RAID virtual disk as a physical disk via SCSI controller for NAV and SQL.

Alex_Chow

Yes, SQL is fun. SQL is interesting.

Again, do a backup and restore IN NAVISION, don't mess with the SQL stuff. One thing WILL lead to another.

stryk

Alex Chow wrote:

Yes, SQL is fun. SQL is interesting.

Again, do a backup and restore IN NAVISION, don't mess with the SQL stuff. One thing WILL lead to another.

Well, more and more NAV partners integrate SQL features with NAV; the simpliest of all things would be just "Linked Objects", but there could also be more complex stuff. I think it is important to find out if there is something like that, else the FBK restore would screw up, or the application would not work - in this case "One thing WILL NOT lead to another"

But then again; if something like that has been implemented in NAV, I guess the "customer" should have been informed; so probaly it's not rather likely that this system contains that "SQL stuff". I just find it worth asking about it.

Also have in mind, that a FBK backup/restore could "take forever", depending on the database size. Migrating from SQL to SQL is - IMHO - a SQL task, the old/native/proprietary FBK is outdated. How else would the rest of the non-NAV-SQL-world migrate their databases?!

stryk

Thorsteenster wrote:

As you may have noticed, I'm not very familiar with NAV or SQL.
Is the "SQL stuff" things our NAV users would notice?

Glad you mentioned that about SQL, I'm re-evaluating the VM for it.
The host has a raid 5 for storage with 500gb of free space currently.
What I'm thinking is to backup and delete the current array, create two virtual disks, one for the host, the other for the NAV VM.
Create a 64gb IDE for boot/OS, then connect the RAID virtual disk as a physical disk via SCSI controller for NAV and SQL.

For a test-environment where you don't care about performance at all, tis might do. For a live system, this is a "No Go".
RAID 5 sucks terribly, especially the write performance is degraded. So the questions is how many disks, and what kind of it, you have available. Are you using HDD or SSD? Or are we talking about LUN on a SAN? What are the SAN specs then?

A typical SQL disk-layout could be like this (again: this needs to be discussed in detail!!!):

C:\ RAID1 (2 x HDD) OS, Prgograms, PF, SQL (master, moderl, msdb)
\ RAID1 (2 x HDD) tempdb (multiple data files depending on number of CPU, 1 log)
E:\ RAID10 (4 - ? HDD) NAV (mdf/ndf) - number of HDD dependeing on db size & transaction volume
F:\ RAID1[0] (2-4 HDD) NAV (ldf) - number of HDD dependeing on db size & transaction volume
?:\ RAID? (? x HDD) local backups, misc
?:\ ...

With SSD the striping in the RAID volumes coule be reduced, depending on the db size).
With SAN this all might be a totally different story.

The disks are all physical drives/raw devices - no virtual drives or logical partitions. This is really important to handle the I/O properly and to grant good performance!

Thorsteenster

I am glad I read you reply before doing anything, I'll just leave things as they are for testing.

Nothing fancy, all HDD and DAS

Our current Navision server has two SAS 73GB HDD's RAID 1 (C: & E:), and two SAS 146GB HDD's RAID 1 (T:)
If testing goes well, the host for the test VM is lightly used and most likely be re-allocated.
It has two 73GB and six 146GB drives.
After I get the testing going, I'll ask a little more about physical server configuration.

I had one of our Navision admins run a backup for me this morning, it looks like it made two files, fin.fbk, and fin2.fbk.
fin.fbk is 2GB, and fin2.fbk is 1.2GB.

I am restoring fin.fbk now to the test VM, but not sure about this fin2.fbk if it needs to be restored also.
Edit: With help from Google I found after 2GB Nav creates a new fbk file.

Are we fine using the classic client, or do we need to use the role tailored?
We only have four constant users, and two periodic users.

stryk

Thorsteenster wrote:

Are we fine using the classic client, or do we need to use the role tailored?
We only have four constant users, and two periodic users.

Well, I guess this is a question only you could answer. If CC is OK so far, it's surely not a "must" to go for RTC.
But as RTC will be "The Future" - no more CC since NAV 2013 - it might be an idea to get familiar with it ...

Thorsteenster

Thanks, we'll discuss CC vs. RTC and likeliness of migrating to the latest NAV vs. another product.
We're also looking to combine several other programs we use into one solution.

I'm creating a share on the VM now for the CC to try some testing today.

Is there anything I should have the testers look at specifically?
Is there anything I am missing?
It almost seems a little too easy.....

Next step is looking at congifuring document approval.

Thanks!