[gelöst] Fehler beim Starten des Web Service Dienstes?

[dr]

hi. in einer testumgebung läuft bei uns auf einem server ein navision 2009 mit sql-server. soweit funktioniert auch alles.
classic client und rtc kann ich von meinem rechner aus einwandfrei benutzen.

jetzt wollte ich ein wenig mit den webservices rumspielen und hierbei das tutoriel aus diesem blog durchgehen.

leider scheitere ich schon ziemlich früh...
a) der webservice dienst muss mit dem gleichen konto gestartet werden wie der nav server dienst, sonst gibts direkt nen fehler
b) für den navserver wurde ein extra benutzer angelegt, diesen verwende ich nun also auch für den webservice dienst.

wenn ich nun aber den webservice dienst auf dem server starten will kommt eine fehlermeldung:

Fehler beim Starten des Diensts MicrosoftDynamicsNavWS. Der Grund hierfür ist möglicherweise ein Konfigurationsfehler. Ausführliche Fehlerinformationen: HTTP konnte URL "http://+:7047/MicrosoftDynamicsNavServer/" nicht registrieren. Der Prozess weist keine Zugriffsrechte für diesen Namespace auf (Details finden Sie unter hhttp://go.microsoft.com/fwlink/?LinkId=70353)

kennt das jemand bzw hat jemand genug administratorwissen um mir zu sagen, was die ursache hierfür sein kann? der begriff namespace ist mir bisher noch nicht in bezug auf dienste über den weg gelaufen..!?


daniel

Zuletzt geändert von dr am 17. April 2009 09:15, insgesamt 1-mal geändert.

Du hast die Antwort schon selbst in der Fehlermeldung und deiner Einleitung mit gepostet.

a) Der Standarduser für beide Services ist der NETWORK SERVICE, den habt ihr geändert
b) Der Link in der Fehlermeldung zeigt genau auf die Lösung

Also entweder setzt ihr den Service Benutzer wieder zurück auf NETWORK (dem ist es nämlich erlaubt, über die angegebene URL/Namespace einen Listener zu erzeugen) oder ihr erlaubt dem jetzigen Benutzer die Erzeugung eines Listeners an angegebener URL/Namespace (Link).

hi silverx,
die antwort war mir leider nicht wirklich offensichtlich, da ich von administrativen dingen nicht so viel ahnung habe. wenns mal was anderes außer navision ist dann "richtiges" programmieren

zu a) ich weiß gar nicht mehr wieso genau, aber unser admin wollte damals einen eigenen user dafür haben. daher die änderung, hat es irgendwelche vor- bzw nachteile den standard network service zu nehmen?

zu b) http namespace configuration hat mir zunächst einfach gar nichts gesagt und ich konnte auch mit dem begriff acl nichts anfangen. inzwischen ist das ganze aber gelöst, bei meiner rechereche bin ich noch auf folgende links gestoßen, die auch für andere nützlich sein könnten:
- Httpcfg Overview - dieses tool ist nach der navision installation unter [...]\Microsoft Dynamics NAV\60\Service enthalten und wird benötigt, um die rechte freizuschalten
- Parsing SDDL Strings - einen sogenannten sddl string benötigt man als parameter für das httpcfg tool

daniel

Hallo dr,

ich habe grade genau das selbe Problem, weiß aber absolut nicht, welche Rechte ich über die ACL setzen muss/darf/kann...
Kannst du mir deinen Aufruf der httpcfg.exe mal posten?

httpcfg.exe -u http://host:7047/ -a ???

für User mit der SID: S-1-5-21-1310868914-19736067-1800150966-23839 (SID hab ich aus der NAV Windows Logins Tabelle).

Grüße

Ich bin einen Schritt weiter gekommen. Durch folgende Lösung bin ich nun in der Lage, die Dienste über den technischen User zu starten:

Create a Service Principal Name
1. On any server computer in the domain, download the Windows Server 2003 Service Pack 2 32-bit Support Tools.
2. Create the SPN by running the setspn utility. The required syntax is:

setspn –A ServerName_InstanceName/FullyQualifiedDomainNameOfServer:Port Domain \User

3. Using DYNNAV-SERVER (the server that runs Microsoft Dynamics NAV Server in this walkthrough) and DynamicsNAV (the default instance name for Microsoft Dynamics NAV Server), the full command should look like this:

setspn -A DYNNAV-SERVER_DynamicsNAV/DYNNAV-SERVER.yourDomain.yourCompany.com:7046 yourdomain\yourUser

Jetzt ist es leider so, dass dieWebservices nicht mehr über das Netzwerk ansprechbar sind, weil die Windows-Authentifizierung fehlschlägt. Lokal auf dem Server hingegen sind die Services ansprechbar.
Jemand eine Idee?

Grüße

Für alle die auch hier hängen:
http://msdn.microsoft.com/en-us/library/ee414212.aspx