[Gelöst] - CRM über https

Hallo zusammen,

da bin ich wieder. :)

Ich habe derzeit folgendes Problem:
Wir versuchen nur über https unseren CRM 4.0 Server zu veröffentlichen (vorher hatten wir http). Klappt soweit auch ganz gut, ich komme über https://crm.domäne.de problemlos auf dem Server und alles funktioniert.
Versuche ich nun einen neuen Client zu installieren, findet der Konfigurationsassistent den Server nicht. Bei bestehenden Clients funktioniert es über den Konfigurationsassistenten ebenfalls nicht, wenn ich da allerdings in der Registrierung die entsprechenden Pfade änder, kann ich mich über Outlook mit dem CRM Server verbinden.

Ich habe bereits folgenden Microsoft Artikel angewandt: http://support.microsoft.com/kb/947423/en-us
Der funktioniert auch bei http Verbindungen, aber offensichtlich nicht bei https.

Ich hoffe mal nicht, dass der Konfigurationswizard ein Problem mit https hat - hat da schonmal jemand Erfahrungen gemacht?

Beste Grüße,
Christian

Zuletzt geändert von CK82 am 24. September 2009 08:19, insgesamt 1-mal geändert.

Hallo Christian,

schau dir einmal den Artikel an, der sollte deine Probleme beheben:
http://rc.crm.dynamics.com/rc/regcont/e ... _comm.aspx
und diesen Zusatz bitte beachten
http://blog.sonomapartners.com/2009/02/ ... ckbox.html

Hm ja, dass ist alles gemacht worden und das interessante ist ja auch, dass es bei bereits installieren Clients läuft, wenn man in der Registrierung die Pfade anpasst (überhaupt keine Probleme - läuft flott und stabil).
Das einzige Problem ist, dass ich keine neuen Clients dazu bekomme, da der Konfigurationwizard die Klamotten nicht anerkennt :|

Hallo Christian,

was hast du denn für eine Option bei der Konfiguration der Clients gewählt?
Verwende einmal die Option "Onlinediensteanbieter". Mit der sollte es funktionieren.

Wenn nicht, prüfe einmal mit folgendem SQL-Befehl die Einstellungen in der MSCRM_Config Datenbank:

SELECT ColumnName, NVarCHarColumn FROM DeploymentProperties
WHERE ColumnName in ('AsyncSdkRootDomain', 'ADWebApplicationRootDomain', 'ADSdkRootDomain')

Was steht in den Feldern?

Moin,

wenn ich es über den "Online Service Provider" versuche bekomme ich "Not authorized - 401". Versuche ich es über "My Company" bekomme ich den Fehler "Server unable to process request".
Der Server ist innerhalb des Firmennetzes wie außerhalb des Firmennetzes immer über die gleiche Adresse zu erreichen (https://crm4.domäne.net). Anleitungen sind genauso durchgearbeitet worden - das einzige was ich mir jetzt noch vorstellen könnte ist, dass es ein Problem mit dem ISA gibt wenn ich versuche über den Online Service Provider eine Verbindung aufzubauen. Aber das sollte eigentlich auch nicht sein, da der ISA Server íntern nicht mitspielt...

Ich setze jetzt nochmal mit meinem Netz-Admin auseinander, dass er mir Zugriff auf die DBs gibt, damit ich selber was machen kann.

Zuletzt geändert von CK82 am 23. September 2009 08:11, insgesamt 1-mal geändert.

So... jetzt konnte ich selber in die DB gucken und habe festgestellt, dass in den dbo.deploymentProperties die Row IFDRootDomainScheme fehlt.
Lasse ich das CRM4IFDTool über unsere Installation laufen, bekomme ich immer wieder die gleichen Einstellungen zurück "On Premise" anstatt "IFD & OnPremise" und die IFD Domain Scheme wird mit http angegeben...

Wenn ich deinen SQL Befehl ausführe steht in den Feldern:
ADSDK Root Domain: crm.domäne.net
AD WebApplikation Root Domain: crm.domäne.net:443
AsyncSdkRootDomain: leer (steht nichts drin)

Hallo Christian,

mit den von dir geschilderten Einträgen kann das auch nicht funktionieren.
In allen drei Feldern sollte das gleiche stehen, und zwar "crm.domäne.net:443"

Kannst du im IFD-Tool die Pickliste von OnPremise auf IFD&OnPromise umstellen?
Wenn ja, stelle dies einmal um und gibt in beiden Einträgen unten auf der Seite eure HTTPS Adresse ein.

Einträge habe ich entsprechend geändert - trotzdem funktioniert es nicht.

Bei dem IFD Tool kann ich das Ifd & On Promise auswählen, nur scheinbar übernimmt er nichts.

Hallo Christian,

wenn das IFD-Tool keine Einstellungen übernimmt, habt ihr noch keine IFD-Einstellungen gemacht. In diesem Fall einfach eine IFD-Konfiguration durchführen, und schon sollte es funktionieren.

Hm bekomme ich den jetzt noch IFD Enabled?
Laut dem hier (http://blogs.msdn.com/crm/archive/2008/ ... asics.aspx) muss das vor/während der Installation geschehen.

Hallo Christian,

IFD kannst du jederzeit ein und auch wieder ausschalten. Der Blogeintrag ist völlig veraltet und stimmt in dieser hinsicht nicht mehr.

IFD kannst du einfach dadurch "einschalten", das du über das IFD-Tool die entsprechenden Einstellungen vornimmst und abspeicherst. Das Tool setzt dann alle benötigten Einträge in der Datenbank und der Registry automatisch.
Ausgeschaltet wird IFD dann einfach dadurch, das du im IFD-Tool die Einstellung OnPromise auswählst und speicherst, dann werden alle Einträge wieder entfernt.

Ok dann ahb ich dich gerade falsch verstanden - wo nehme ich denn die IFD-Einstellungen vor, die dann scheinbar fehlen.

Hallo Christian,

die Einstellungen nimmst du im IFD-Tool vor.
Dort einfach IFD&OnPromise auswählen, den IP-Range für die AD-Authentifizierung angeben, und die Webadressen, das wars.

*g* ok erstmal danke, dass du solange durchhälst, aber ich seh den Wald vor lauten IFDs nicht mehr scheinbar (bin ja auch erst seit gestern dran...) :) Und irgendwie drehe ich mich im Kreis.

Also ich setzen ja im Tool
1. Authentication Strategy: IFD + OnPremise (dadurch Enable ich scheinbar IFD)
2. IP Adresse: die des Servers, die erste im Subnetz die letzte im Subnet
3. IFD Root Domain Scheme: HTTPS - crm.domain.net:443 - crm.domain.net:443
4. AD Domain Scheme: HTTPS - crm.domain.net:443 - crm.domain.net:443
5. Apply Changes

Passieren tut aber nichts (selbst wenn die Einträge jetzt falsch sind). Die Einträge in der Config Datenbank bleiben die selben und wenn ich das Tool schließe und wieder aufrufe habe ich keinerlei Änderungen.

Als ich eben gefragt habe, warum sich nichts ändert (keine Einstellungen übernommen werden), hast du mir gesagt das wir keine IFD Einstellungen gemacht hätten, was aber scheinbar über das Tool (IFD+OnPremise) passieren soll. Nur wie gesagt passiert da nichts und keine Einstellungen werden gespeichert. :(

Ich glaub ich geb gleich auf....

Hallo Christian,

immer mit der Ruhe, das bekommen wir schon hin

Du bist schon auf dem richtigen Weg. Jetzt zu den Einstellungen im IFD-Tool.
Nachdem du einmal EInstellungen mit dem IFD-Tool gespeichert hast, werden diese eim nächsten Start des Tools angezeigt, sobald du in der Pickliste wieder IFD&OnPromise ausgewählt hast. Nach der Auswahl sollten jetzt also die IP-Adresse und die Subnetmask und die beiden URLs wieder erscheinen.
Funktioniert dies nicht, habt ihr einen Grundsätzlichen Fehler im System, der erst einmal beseitigt werden muss.

DIe Einträge in der COnfig DB solltest du einmal von Hand korrigieren, damit dieser Fehler schon einmal beseitigt ist.

Jetzt zu der Funktion des Tools.
IFD bedeutet Internet Facing Deployment und stellt das CRM von der AD-Authentifizierung auf die Form basierte Authentifizierung um.
Die IP-Adresse und die SUbnetMAsk, die du in dem Tool eingibst, steuern, welche Computer mit AD-Authentifizierung und welche mit Forms basierter Authentifizierung arbeiten.
Gibt du zum Beispiel 192.168.12.12 und die Subnetmask 255.255.255.255 ein, bedeutet dies, das der Rechner mit der IP 192.168.12.12 mit der AD-Authentifizierung im CRM arbeitet, alle anderen mit der Forms basierten.

Dann musst du noch beachten, das die URL zur Anmeldung unter IFD eine andere ist, als ohne.
Beispiel:
Du hast die URL crm.domain.net unter IFD Root domain SChema eingegeben, https ausgewählt und euer Mandant nennt sich demo1.
Dann lautet die URL für die ANmeldung am CRM: https:\\demo1.crm.domain.net

Der Name demo1.crm.domain.net muss dabei vom Client in die richtige IP aufgelöst werden können. Entweder durch einen lokalen HOST-Eintrag oder besser durch einen entsprechenden Eintrag im zuständigen DNS-Server.

Der erste Test sollte sein, die obige URL im Webbrowser aufzurufen. WEnn das funktioniert, sollte auch der Rest funktionieren.

Dann haben wir scheinbar einen Fehler im System, denn die Änderungen die ich im Tool mache werden nicht gespeichert.

Mir fehlt in der Datenbank auch ein Eintrag IFDRootDomainScheme der halt definiert ob http oder https (wie halt beim OnPremise).

Der Host-Eintrag ist denke so noch nicht vorhanden, sondern maximal für crm.domäne.net

Danke erstmal, ich habe die Arbeitspakete empfangen. ;)

immer ein schritt weiter (wie mans nimmt... ;) )

Um deine Vorschläge zu testen (und weil unsere Admins nicht mehr da sind) habe ich in meiner lokalen Hosts-Datei den Server inkl. Mandanten aufgelöst, sprich:
ich kann nun über den IE - mandant.crm.domäne.net - auflösen und ich komme auch mit dem IE auf unsere CRM Installation (alles über http, da das Zertifikat scheinbar nicht für die mandanten FQDN funktioniert).

Bei der Konfiguration des Outlook-Addins bekomme ich so allerdings die gleichen Fehler, dass hat mich so also nicht weitergebracht oder? ...

Hallo Christian,

habt ihr eventuell einen Proxy-Server im Einsatz, oder verwendet den ISA-Server von MS?

Proxy soweit ich weiß nicht (habe auch keinen in den LAN Einstellungen).

Einen ISA haben wir, aber der sollte doch eigentlich nicht mitspielen intern oder? Der ISA Server soll auch schon eingerichtet sein, allerdings kann ich das noch nicht prüfen, da ich hier keinen Zugriff von aussen habe.

Hallo zusammen,

ich bin ein Kollege von Christian und würde gerne nochmal ein paar Dinge klarstellen.
Wir wollen intern unser CRM auf Dynamics neu aufsetzen und später via ISA für unsere Mitarbeiter auch von außen zugreifbar haben.

Die Adresse ist von Innen wie von aussen gleich https://crm.domain.com.

Authentifikation läuft prinzipiell nur über AD. Forms based Authentication ist eigentlich nicht vorgesehen.

Bei der ersten Installation und Konfiguration wurde der Server fälschlicherweise mit http://crm:5555 erstellt.
Da das nicht unsere Richtlinien für interne Systeme erfüllt muss das System auf HTTPS über Port 443 und FQDN umgestellt werden.

Die Umstellung hat auch für den Browserzugriff funktioniert. Nur die Outlook Clients wollen sich nicht mehr konfigurieren lassen.

Wir setzen intern keinen Proxy ein. Intern kann auch kein Routing über ISA hergestellt werden. Die Benutzer gehen intern immer direkt gegen den CRM Server. Extern kommen die User dann später über ISA rein mit den entsprechenden Listenern. Das funktioniert hier auch schon prima so für SharePoint, Groove und Exchange/Outlook.

Ist vielleicht eine Neuinstallation des CRM die einzig valide Lösung? Der Switch auf HTTPS, FQDN und Port 443 scheint dem CRM System irgendwie nicht bekommen zu sein.

Viele Grüße,

Andrej Doms

Hallo Andrej,

danke für die Zusammenfassung und klarstellung.

Die nachträgliche Änderung eines Ports im CRM ist ohne Probleme möglichm habe ich selbst schon mehrfach durchgeführt. Ihr müsst nur unbedingt alle Punkte des Artikels http://support.microsoft.com/kb/947423/en-us beachten.

Ich nehme an, ihr habt den Server dann auf Port 80 umgestellt, und verwendet dann SSL über den Port 443, richtig?
Es wäre falsch, den Server auf den Port 443 umzustellen, um dann SSL zu verwenden.

Der Servername lautet CRM und die Domäne domain.com, so das der FQN des Servers crm.domain.com lautet, richtig?
Dann müsst ihr keine Änderung an dieser KOnfiguration vornehmen, sie ist korekt.

Habt ihr vor der Installation des Outlook Clients die neue URL des CRM in den Intranetsites aufgenommen?
Habt ihr noch gespeicherte Kennwörter im IE für die alte Konfiguration? Die solltet ihr löschen.

Was steht nach einer Fehlgeschlagenen Installation im Error Log des Clients?

Hallo Michael,

https geht ja standardmäßig über 443. Warum also sollte ich das über Port 80 legen, zumal ich damit gegen die internen Regeln verstoße? Wir haben alle Artikel, die hier genannt wurden soweit vollständig umgesetzt und es hat bisher keine Besserung gegeben.

Ich tendiere dazu, das ganze nochmal aufzusetzen und dann von vornherein mit den richtigen Parametern zu installieren. Außer es hat noch jemand eine geniale Idee...

Viele Grüße, Andrej

Hallo Andrej,

dann gehen mir auch erst einmal die Ideen aus. Wenn eine Neuinstallation ok ist, würde ich diesen Weg gehen.

Hi Michael,

nach der Neuinstallation funktionierts auch mit den Clients. Da war wohl was verbogen. :)
Danke für die Hilfe!

MfG,
Christian

Hallo Christian,

schön, das jetzt alles wieder funktioniert.