Navision crashes with window authentication

themave

I just upgraded my Navision server and my separate terminal servers to windows 2003 enterprise edition, from windows 2000, they have all the latest service packs and updates. Also upgraded the domain controller from SBS2000 to SBS2003 R2 permium edition, all updates applied.

From terminal server when I start the Navison client I try to use windows authentication, it opens the database, and then immediately causes the server service on the Navision server to stop.

So, the whole Navision service stops and all users loose the connection, I have to restart the service. I installed the server service with TCP, not TCPS

I am using Navision 4.0 no service packs, US version. Navision database not sql server
There is no security to sync with the native database.

On my windows 2000 environment, everything works fine.

This is a completely separate network, all new machines, ect. All users were added to the new domain, the Navision software and client is new install. I used Hotcopy to get the database from one network to another, by copying files to a removable drive. The server starts and runs fine.

This is the startup parameter I am using, the services and host files are correct.

"C:\Program Files\Microsoft Business Solutions-Navision\Client\fin.exe" servername=10.0.0.6:2410, nettype=tcp, ntauthentication=yes, id=f:\%username%, company="Test Company - BTEC"

If I use database authentication, it works fine, the only thing I change is the “yes” to a “no, on the ntauthentication setting. No other software changes.

"C:\Program Files\Microsoft Business Solutions-Navision\Client\fin.exe" servername=10.0.0.6:2410, nettype=tcp, ntauthentication=no, id=f:\%username%, company="Test Company - BTEC"

I have all the users set up with a windows login, and I also setup a separate database login, since I couldn’t get the windows authentication to work.

Any ideas ?

davmac1

This may not be directly related to the problem, but are you running the latest Navision executables?
You don't have to upgrade the Navsion database to run on SP2 or SP3 executables, and you will get the latest bug fixes to the non-application area of Navision.

themave

davmac1 wrote:

This may not be directly related to the problem, but are you running the latest Navision executables?
You don't have to upgrade the Navsion database to run on SP2 or SP3 executables, and you will get the latest bug fixes to the non-application area of Navision.

I am not, what are the steps

stop the server, install the server program, install the client,
start the server, open the client, and answer yes to question about upgrading.

I do have the lastest service packs.

I haven't done that before, but figure this is probably the steps.

David_Singleton

themave wrote:

...
From terminal server when I start the Navison client I try to use windows authentication, it opens the database, and then immediately causes the server service on the Navision server to stop.

So, the whole Navision service stops and all users loose the connection, I have to restart the service. I installed the server service with TCP, not TCPS
...

I can think immediately of three things that can just cause the server service to stop.

1/ Is when a task tries to directly access the Navision database file. This is common with badly set up backup software that tries to lock the Navision Database whilst a user is attached to the database via the server. Navision Server service just shuts down in this case.

This could also happen if another user tries to connect to the database server directly, but is unlikely since they will normally just get a "You can not change the database whilst other users are accessing it". Though there is some possibility, especially if you were running that Navision Server Service on the Terminal Server, which I gather you are not.

2/ Bad network packets. If Navision detects bad packets being sent to it, it will shut down the server service. This is because bad packets can corrupt the database. (In fact most database corruptions I have seen and since fixing things is my job, I have seen a lot of these are due to a bad network card sending bad packets). So to prevent this, the server shuts it self down. But with new hardware, and the latest service packs, its unlikely for bad packets to get that far.

Still it would not hard to get a network sniffer to do some heavy traffic testing to see if there is a bad connection somewhere. You could even remove the 1gig link from Terminal Server to Navision, and temporarily try a normaly 100Meg switch.

3/ Port scanning. If Navision detects a task that is scanning ports and it scans the Navision port, then the Server will shut down. This is some sort of security thing, but I could never get a clear answer from Navision as to exactly what. This is possible in your case, if for example, the TS has some kind of task that when it looks for Printers and drives to share, it maybe scans some ports. Maybe some printer sharing software, something like a print booster for Citrix.

Anyway these three things come to mind, but they don't look to promising in your case. I guess more why I am writing this, is just to let you know that this does happen. Also I would really like to know what you eventually find out, since it may help me next time. I know how many hours/days it took me to work out these three. Especially figuring out that it was bad network cards that corrupt the database.

David_Singleton

Just rereading, you don't have a BDC remote somewhere san at another location, over a WAN, or somewhere that it could be generating bad packets.

Also, are you able to connect to the Server from a client directly using Windows Authentication, but without going through terminal server.

i.e. is this a terminal server issue, or an AD issue?

themave

David Singleton wrote:

Just rereading, you don't have a BDC remote somewhere san at another location, over a WAN, or somewhere that it could be generating bad packets.

Also, are you able to connect to the Server from a client directly using Windows Authentication, but without going through terminal server.

i.e. is this a terminal server issue, or an AD issue?

Right now it is all one local network, a single switch connecting

SBS2003 server (one nic to local network, one nic to external router)
Navision server
and two win2003 terminal servers

connecting to the terminal server via dsl line. able to authticate, and run other programs on the terminal server session, browse the network, send print jobs to a local and remote printers. Access network shares and run openoffice programs, running Outlook in TS session and use all it's functions for email and calendaring, ect.

From TS session, can connect to Navision, using the database authication and it runs fine, can access everything, post and print.


no local client hooked up, as everyone connects via a terminal server session, I will try to hook up a local client

David_Singleton

themave wrote:

...


no local client hooked up, as everyone connects via a terminal server session, I will try to hook up a local client

I think its important to try that, since if you get the same issue you can then eliminate TS as the issue, or identify it as the issue .

themave

David Singleton wrote:

themave wrote:

...


no local client hooked up, as everyone connects via a terminal server session, I will try to hook up a local client

I think its important to try that, since if you get the same issue you can then eliminate TS as the issue, or identify it as the issue .

Ok now we are getting somewhere although were I am not sure.

Added a windows login, for the administrator, then from the Navision server, started client with windows Authentication and was able to log onto the database. So, went back to terminal server session, logged in to new session as administrator, and was able to start the client using windows authentication. :P Which means it is related to permissions, but not exactly sure how.

David_Singleton

themave wrote:

David Singleton wrote:

themave wrote:

...


no local client hooked up, as everyone connects via a terminal server session, I will try to hook up a local client

I think its important to try that, since if you get the same issue you can then eliminate TS as the issue, or identify it as the issue .

Ok now we are getting somewhere although were I am not sure.

Added a windows login, for the administrator, then from the Navision server, started client with windows Authentication and was able to log onto the database. So, went back to terminal server session, logged in to new session as administrator, and was able to start the client using windows authentication. :P Which means it is related to permissions, but not exactly sure how.

What I think is happening then is that the existing windows logins in Navision are not authenticating properly. In that AD does not recognize them. Are you using the same AD?

Do they look correct - eg
CompanyDomain\THEMAVE or like

S-1-6-21-567418333-112024500-25651452-1011 ?

themave

They all appear correctly, Created all users on the small business server. and then went into Navision and added users windows logins, via the lookup box,

so they all appear in the correct format

CompanyDomain\THEMAVE

the administrator I just added appears in the same format

CompanyDomain\Administrator

right on the same window with the rest of the windows login users

David_Singleton

themave wrote:

They all appear correctly, Created all users on the small business server. and then went into Navision and added users windows logins, via the lookup box,...

Yes I noticed in the begining you said SBS, but I over looked that. So authentication is really done locally on that machine.


Can you try to just delete one user and then recreate it to see if it fixes the issue. I know it probably wont help, since if you see the qualified user name, its probably authenticating correctly. But worth a try.

kine

I am using Navision 4.0 no service packs, US version. Navision database not sql server

This is the source of problems. NAV 4.00w/o SP is not stable.

Example of problems solved by SP1:

P3) Navision Server Crash
Error
The cache for mapping DBM TableNo to a Table ID and Company Name combined a hash index and a fixed array; each hash node pointing into an element of the array. When the array increased its memory was deleted, making the hash index pointers invalid.
This has been corrected
fin.exe
dbm.dll
server.exe
slave.exe

VSA reference: 8019731
P4) Windows Authentication is Slow
Error
Enumeration of user groups with Windows Authentication was slowing down authentication.
This has been corrected
fin.exe
finsql.exe
nas.exe
nassql.exe
dbm.dll
xp_ndo.dll

themave

Thanks, I had asked our service provider, but they didn't have an explaination

so are these the step to do the executable upgrade ?

stop the server
install the newest release of the server program
install the client
start the server
open the client and answer yes to question about upgrading.

David_Singleton

themave wrote:

Thanks, I had asked our service provider, but they didn't have an explaination

so are these the step to do the executable upgrade ?

stop the server
install the newest release of the server program
install the client
start the server
open the client and answer yes to question about upgrading.

You will probably get a message that you must first uninstall the old version before installing the new one, other than that you have it right.

davmac1

It is considered the same release, so you have to uninstall the old, before installing the new.

kine

I am not sure, but I think that you need to open the DB first by the new client to convert it and after that you can connect and run the server over this converted DB.

David_Singleton

kine wrote:

I am not sure, but I think that you need to open the DB first by the new client to convert it and after that you can connect and run the server over this converted DB.

Hmm are you sure? It used to allow you to convert when the first client connected to the Server. Though I normally do it the way you suggest, I have definitely converted databases whilst connected to the server.

kine

It is why I wrote that I am not sure... :-) I did it in this way each time ;-)

David_Singleton

kine wrote:

I am not sure,...

David Singleton wrote:

Hmm are you sure? ...

:oops: #-o