Microsoft Dynamics CRM 4.0 | Installation unter w2k8 R2 / SQL 2008

Allen von Euch, denen eine Installation unter Windows 2008 (R2) (32/64bit) und SQL 2008 (R2) bevorsteht, sei mit diesem Artikel (Lessons learned) eine Hilfestellung gegeben. Zur Ausgangslage: Die CRM-Installation erfolgt auf einem Windows 2008 R2 (64bit) System. Als Service-Account wird der Netzwerkdienst verwendet – gleiches gilt jedoch auch, sofern ein Domain-Benutzer-Konto als Service Konto genutzt werden soll.Der SQL Server 2008 ist auf einem Windows 2008 R2 (64bit) System installiert. Neben der Default-Instanz wurde eine benannte (named) Instanz für CRM angelegt.

  

Szenario 1: Der Setup Konfigurationsassistent von CRM meldet bei der Überprüfung des SQL Servers einen Fehler, dass keine Verbindung zum SQL Server hergestellt werden kann bzw. auf die benannte Instanz kein Zugriff möglich ist.

Nach Überprüfung des SQL-Servers unter Sicherheit – Anmeldungen wurde festgestellt, dass das Netzwerkdienst-Konto ‘NT-AUTORITÄT\NETZWERKDIENST’ als SQL Benutzer nicht angelegt wurde. Die Anlage des Kontos ist ja schnell geschehen – so dachte man. Doch bei der Anlage über den Assistenten (Neuen Benutzer anlegen) kommt es zu einer Fehlermeldung.

Error 15401: Windows NT user or group ‘username’ not found. Check the name again.

Dazu gibt Microsoft unter dem Support-Artikel 324321 Hilfestellung. Es stellte sich heraus, dass ich die Maschinen in der Virtuellen Umgebung tatsächlich geclont hatte. Doch entgegen der Hilfestellungen aus diesem Artikel musste ich feststellen, dass es mit R2 und der Routine LookupAccountName offenbar ein Problem gibt, der mit Support-Artikel 976494 und einem Hotfix gelöst wird.

Szenario 2: Nach erneuter Überprüfung durch den CRM Konfigurations-Assistenten und den zuvor vorgenommenen Endstörungen (Szenario 1), kommt erneut eine Fehlermeldung bei der Überprüfung des SQL Servers. Diesmal ein Hinweis auf ein TimeOut (wie sich aus dem Event-Log entnehmen lässt).

Hier spielt uns die Windows Firewall einen Streich, da wir die Installation nicht auf der Default-Instanz, sondern auf einer benannten weiteren Instanz vornehmen wollen. Obwohl, wie im Artikel beschrieben der SQL-Server konfiguriert und die Port-Regeln in der Firewall (UDP 1433, 1434) eingerichtet wurden, erhalten wir dennoch den Fehler. Abhilfe schafft in diesem Fall der Support-Artikel 823938. Dieser beschreibt, wo in der Registry der TCP-IP-Port der Instanz zu entnehmen ist. Diesen Port in der Firewall freigegeben und den Konfigurations-Assistenten erneut gestartet, erhalten wir nunmehr einen erfolgreichen Durchlauf aller Tests (alles ist mit einem weißen Haken auf grünem Grund quittiert).

Voller Freude über die derartige Quittierung setzt sich die Installation nunmehr fort.

Szenario 3: Nach Überprüfung der Installation durch Aufruf der URL im Browser auf dem Server stellen wir fest, dass bei Aufruf mit http://localhost:5555 der CRM Server tatsächlich antwortet, es erscheint Microsoft Dynamics CRM. Doch wollen wir den Test auch von einem Client aus durchführen. Dort ist der Aufruf mit http://<servername>:5555 durchzuführen. Es erscheint eine 401.1 Fehlermeldung. Okay: Ich habe unterschlagen, dass auf dem CRM Server noch eine Firewall-Regel für den Port 5555 eingerichtet werden muss. Dies geschehen, erscheint dennoch bei Aufruf eine 401.1 Fehlermeldung. Hingegen ist der Aufruf über http://<ip-Adresse-des-CRM-Servers>:5555 möglich. Es erscheint ein Anmelde-Fenster und nach Eingabe der Konto-Informationen ist die Anmeldung möglich.

Um den Aufruf über den Servernamen zu ermöglichen, schnell noch den Support-Artikel 896861 befolgt, sollte anschließend auch der Aufruf über den Servername möglich sein. Und ja, es erscheint ein Authentifizierungs-Fenster. Doch warum? Schließlich haben wir im Internet-Explorer mittlerweile die Adresse als Lokale Site hinzugefügt und haben eingestellt, dass die automatische Anmeldung im Intranet erfolgen soll. Warum also dennoch das Anmeldefenster?

Prüft in diesem Fall mit dem setspn.exe-Tool doch einfach mal auch Service-Principal-Names auf dem CRM Server. Sofern Ihr dort keinen Eintrag HOST/[url] [machine-name] vorfindet, dann setzt mit dem Befehl SETSPN -A HOST/[url] [machine-name] diesen Eintrag. Eine anschließende Prüfung des Aufrufs der URL am Client ergibt eine fehlerfreie sofortige Anmeldung am CRM mit dem aktuellen Benutzerkonto (Zugegeben: Auch dieses wurde natürlich zuvor durch den Systemadministrator im CRM angelegt)

Fazit: Trotzdem der Implementierungsleitfaden besser und besser wird, sind doch noch signifikante Passagen durch unterschiedliche Installationsvoraussetzungen zu ergänzen. Ich hoffe, dass Euch dieser Artikel bei Euren Installationen weiterhilft, lese und beantworte ich doch beinahe tagtäglich ähnliche Fragestellungen in der CRM – Community.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s