Client Start hängt im Splashscreen

Hallo Community,

Wir möchten einen weiteren Standort unserer Firma an das NAV 2013 CU 58 anbinden.
Einer der PCs am neuen Standort wurde testweise bereits per OpenVPN mit dem NAV verbunden und lief.

Nun wurde ein fester VPN Tunnel zwischen den Firewalls der Standorte aufgebaut.
Beim Start des NAV Clients erfolgt die Anmeldung per "NAV Username Password"
danach hängt der Client beim Splash Screen und baut das eigentliche Clientfenster nicht auf.

In Wireshark sehe ich das der TLS Handshake zw Client und Service erfolgreich verläuft und dann kein weiterer Traffic erfolgt.
Auch sehe ich keine Anfragen an andere Server die unbeantwortet bleiben. Ich denke die Verbindung zum Middle-tier-Server sollte auch reichen.
IPSEC VPN Tunnel steht und ist Testweise in beide Richtungen komplett offen.
Routen sind gesetzt und ich kann in beide Richtungen pingen.

An einem anderem Standort mit ähnlicher Anbindung läuft es problemlos.

Bei einer späteren NAV Version verhinderte ein Excel/Office update Prozess den Start. Diese habe ich schon geprüft.

Mir gehen die Ideen aus nach was ich noch suchen könnte. Hat Jemand eine Idee?

Hallo,

das könnte auch am Profil bzw. an der Startseite des Benutzers liegen. Ist da evtl. noch das Outlook- Addin aktiv bei dem Anwender?

Gruß Fiddi

Die Idee ein ganz einfaches Rollencenter/Profil zu verwenden ohne Add-ins macht Sinn. Ansonsten mal in das Ereignisprotokoll auf Client oder eher Server schauen.

Vielen Dank für die Vorschläge.

Im Ereignisprotokoll finden sich keine relevanten Einträge, weder am Client noch auf dem Server.
Das Outlook Addin wurde schonmal von der Startseite entfernt, aber ich werde es nochmal ohne alle Addins probieren.
Ich denke im laufe des Tages kann ich nochmal auf den Rechner zugreifen.

Ich habe mittlerweile das DNS im Verdacht.
Am funktionierenden externen Standort besteht eine Vertrauensstellung zu unserer Domäne, was an diesem Standort nicht möglich ist.
Ich habe daher am Client die IPs vom Middletier und versuchsweise auch DB Server sowie Domänencontroller in der hosts Datei aufgelöst (sowohl FQDN als auch nur Hostname).

Müssen noch andere Namen am Client bekannt sein?

Hallo,

DNS- Auflösung könnte ein Problem sein.
Ein anderes könnte eine abweichende MTU der TCP/IP- Pakete im Netzwerk sein.
Das kann schon mal dazu führen, das man glaubt, dass das Ganze hängt, es dauert dann nur halt eine halbe Stunde, bis etwas passiert.
Habe gerade letzte Woche ein paar Stunden nach so einem Fehler gesucht, weil eine Anwendung scheinbar hing.
Als ich das Programm versehentlich eine halbe Stunde habe laufen lassen, kam es dann plötzlich.

Gruß Fiddi

Profil ohne Addins habe ich getestet, leider erfolglos.
DNS würde ich jetzt auch ausschließen da ich testweise unseren Dnsserver mal dort eingerichtet habe, leider auch erfolglos.
Im Wireshark sah ich auch keine weiteren DNS Anfragen.

Die abgebuchte Lizenz wird lustigerweise in den Active Sessions in der DB eingetragen. Verbindung steht also prinzipiell.

MTU ist ne Idee, begebe ich mich mal auf die Suche und lass es mal laufen.
...
Und tatsächlich nach etwa 20 Minuten kommt die Meldung das die Verbindung zum Server getrennt wurde.
Und man findet einen Ereignislogeintrag.

Vielleicht ist aber auch bloß der Tunnel gerade nicht verfügbar gewesen, denn für mich sieht das aus als wenn er keinen mehr erreicht hat.
(Edit: der Tunnel steht stabil und der Abbruch lässt sich reproduzieren, der Verbindungsabbruch kommt also woanders her)

Type: Microsoft.Dynamics.Nav.Client.NavClientClosingException
Fatal: True
ShowError: True
Message: Die Verbindung zum Server wurde getrennt. Die Anwendung wird beendet.
StackTrace:
bei Microsoft.Dynamics.Nav.Client.ConnectionStateManager.HandleCommunicationFailure[T](CallServerMethod`1 callServerMethod, ServerCallOptions options, Exception e, Int32 messageNumber, String sessionId)
bei Microsoft.Dynamics.Nav.Client.ConnectionStateManager.CallServer[T](CallServerMethod`1 callServerMethod, ServerCallOptions options)
bei Microsoft.Dynamics.Nav.Client.ConnectionStateManager.CallServer[T](CallServerMethod`1 callServerMethod)
bei Microsoft.Dynamics.Nav.Client.ServerInvocationHandler.CallServer[T](CallServerMethod`1 callServerMethod)
bei Microsoft.Dynamics.Nav.Client.ServiceConnection.CallServer[T](CallServerMethod`1 callServerMethod)
bei Microsoft.Dynamics.Nav.Client.ServiceConnectionBase.GetPage(PageRequestDefinition pageRequestDefinition, NavRecordState& state)
bei Microsoft.Dynamics.Nav.Client.ServiceConnection.Microsoft.Dynamics.Nav.Client.IService.GetPage(PageRequestDefinition , NavRecordState& )
bei Microsoft.Dynamics.Nav.Client.DataBinder.NavDataAccessHelper.GetDataSet(Int32 tableId, NavFilterGroup[] filterGroupList)
bei Microsoft.Dynamics.Nav.Client.DataBinder.NavDataAccessHelper.GetRows(Int32 tableId)
bei Microsoft.Dynamics.Nav.Client.ProfileAttributes.FindProfileRow()
bei Microsoft.Dynamics.Nav.Client.ProfileAttributes.Initialize()
bei Microsoft.Dynamics.Nav.Client.Builder.ProfileCacheInitializer.Initialize()
bei Microsoft.Dynamics.Nav.Client.Builder.CompanyInitializer.OpenCompany(String companyName)
bei Microsoft.Dynamics.Nav.Client.FormBuilder.BuilderSession.OpenCompany(String companyName)
bei Microsoft.Dynamics.Nav.Client.FormBuilder.BuilderSessionInitializer.InitializeCore()
bei Microsoft.Dynamics.Nav.Client.FormBuilder.BuilderSessionInitializer.Initialize()
bei Microsoft.Dynamics.Framework.UI.Builder.Initialize()
bei Microsoft.Dynamics.Framework.UI.UISession.Initialize()
bei Microsoft.Dynamics.Nav.Client.WinClient.NavWinFormsClientSession.InitializeUISession()
bei Microsoft.Dynamics.Framework.UI.Windows.ClientSessionBase.SetupSessions()
bei Microsoft.Dynamics.Framework.UI.Windows.ClientSessionBase.InitCore()
bei Microsoft.Dynamics.Nav.Client.WinClient.NavWinFormsClientSession.InitCore()
bei Microsoft.Dynamics.Framework.UI.ClientSessionCore.Init()
bei Microsoft.Dynamics.Framework.UI.Windows.ClientSessionBase.Run()
bei Microsoft.Dynamics.Nav.Client.WinClient.NavClientErrorHandler.ExecuteAndCatchExceptions(Func`1 execute)
Source: Microsoft.Dynamics.Nav.Client.ServiceConnection
HResult: -2146233088


Tipps zur Paketlänge sind willkommen. Da bin ich erfahrungslos.

Es ist ein IPSec Tunnel der über einen VPN Router hinter einer Teledat/Speedport über eine DSL Leitung aufgebaut wird. Hinter dem Tunnel jeweils ein Ethernet Netz.
Das müsste heißen da die kleinste MTU aus der PPPoE Leitung kommt, könnte es helfen am Client die MTU der Netzwerkkarte auf PPPoE Niveau zu senken (1492 statt 1500).
Ist das Korrekt?

Wenn das hilft kann ich die MTU Änderung der Firewall in Auftrag geben und setze die am Client zurück.

Edit:
ich habe mittels ping die größte nicht fragmentierte Paketgröße ermittelt und diese +28 als MTU auf der Netzwerkkarte des Client eingetragen.
Der Ping läuft jetzt scheinbar noch etwas stabiler aber der Client zickt weiter.

Bin weiter für Vorschläge offen.

Zertifizierungsstelle, Exchange Server hatte ich auch mal in der Hosts nachgetragen.
ebenso mal das Addin Verzeichnis des Clients umbenannt um irgendwelche Dritthersteller DLLs außen vor zu lassen.
Leider alles ohne Erfolg.

Kennt sich jemand in der Startroutine des Clients aus damit ich Schritt für Schritt prüfen kann an welcher Stelle es scheitert?

Wie kommt man mit dem Debugger auf einen Dienst der für NAVUserPassword konfiguriert ist.
Vielleicht sehe ich ja schon die Session und kann etwas debuggen?
Die Lizenz wird ja schließlich belegt, da liegt die Vermutung/Hoffnung nahe das auch eine Session da ist.

Gibt es auf dem SQL Server in den Ereignisprotokollen Einträge? Es könnte sein, dass die Verbindung zum Service funktioiniert, die Delegierung zum SQL Server jedoch hakt.

Nein, auch auf dem SQL Server sind keine relevanten Einträge im Eventlog.

Kannst du mir erklären was der Client beim Start direkt auf der DB macht?
Eigentlich sollte doch nur der Dienst mit der DB kommunizieren, oder?

Prinzipiell erreicht er auch den SQL-Server, aber der Client/User hat natürlich keine Rechte auf der Datenbank

Client/User hat natürlich keine Rechte auf der Datenbank

implizit schon, wenn der Benutzer sich bei NAV anmeldet, muss er auch auf den SQL-Server zugreifen dürfen, sonst kann er nicht arbeiten.
Damit er das darf, muss der Servicetierbenutzer die entsprechenden Rechte weiterreichen, und auch selbst die Berechtigung haben ein SetSPN durchzuführen. (Die Benutzereinrichtung dafür findest du in der Doku für den Betrieb von Servicetier und SQL-Server auf unterschiedlichen Rechnern)

Gruß Fiddi

Hallo Fiddi,

bei der beschriebenen Prozedur kommuniziert der Client doch aber nicht direkt mit der DB, und da der Client auf dem selben Rechner, mit der selben Anmeldung als OpenVPN-Roadwarrior funktioniert, kann ich davon ausgehen das in diesem Bereich alles ok ist. Oder hab ich etwas falsch verstanden?

Hallo,

such doch mal in der "Entwickler und IT- Hilfe" des Entwicklungsclients nach 'SPN'.

Hast du das alles berücksichtigt?

Gruß Fiddi

Ich hab es überprüft und sehe keine Probleme.
Trotzdem Danke.

Ich hoffe auf weitere Ideen.

Ich hatte noch einmal die Möglichkeit mich auf den Client aufzuschalten und zu testen.

Mit noch weiter abgesenkter MTU auf der Netzwerkkarte funktionierte der Client.
Dann gilt es nun die optimale Abstimmung des Tunnels zu finden, aber das Thema hier ist gelöst und durch.

Vielen Dank an Fiddi für den Hinweis und an alle Andreren fürs Kopf zerbrechen.