[Gelöst] - CRM Testsystem IFD

Hallo zusammen,

mal wieder ein Problem mit IFD.
Wir haben ein Testsystem aufgesetzt um Erweiterungen etc. zunächst dort zu testen (macht ja auch Sinn). Nun habe ich gestern IFD mit dem CRMIFDTool aktiviert und nun werden die Systemaufträge nicht mehr ausgeführt.

Mir ist klar, dass die Aufträge über den Asynchronen Verabreitungsdienst ausgeführt werden. Weiterhin habe ich bereits die Einträge in den DeploymentProperties geprüft:
ADRootDomainScheme: https
ADSdkRootDomain: testcrm.domäne.de:443
ADWebApplicationRootDomain: testcrm.domäne.de:443
AsyncSdkRootDomain: testcrm.domäne.de:443

IfdRootDomainScheme: https
IfdSdkRootDomain: testcrm.domäne.de:443
IfdWebApplicationRootDomain: testcrm.domäne.de:443

In der Registrierung sind die richtigen Werte eingetragen:
ServerURL: testcrm.domäne.de:443
LocalSdkPort: 443
ConfigSku: OnPremise (sollte da nicht "IFD+OnPremise" stehen?)

Der Asynchrone Verarbeitungsdienst läuft unter einem DomänenAccount, ebenso wie der CRM ApplicationPool im IIS. Das Domänenkonto hat Vollzugriff auf den Installationsordner von CRM (Domänenkonten sind vorgeschrieben).

Folgende Fehlermeldung wird bei den Systemjobs hinterlegt (Erweiterte Suche und ErrorMessage anzeigen lassen):
Fehlercode: -2.147.204.346
Meldung: System.Net.WebException: The request failed with HTTP Status 401: Unauthorized. at System.Web.Services.Protocols............................

Das die Systemjobs nicht mehr ausgeführt wurden, tritt zeitlich erst auf, nachdem IFD aktiviert wurde. :(

Hat da jemand Rat?

Beste Grüße,
Christian

Zuletzt geändert von CK82 am 10. November 2009 14:32, insgesamt 2-mal geändert.

Hallo Christian,

prüfe mal diesen Link

Der Registrykey ist korrekt eingetragen.

Ich habe gerade einmal spasseshalber IFD mit dem Tool rückgängig gemacht und dann funktionieren die Systemjobs wieder. Hat es eventuell etwas damit zu tun, dass mit dem IFD Config Tool "Anonymous = On" gesetzt wird und beim OnPremise "Anonymous = Off"?

Hallo Christian,

den Zugriff des Anonymous benötigst du im IFD, deshalb ist die Einstellung völlig korrekt.
Hast du nach der Konfiguration des IFD den Webserver neu gestartet und den Cache des IE auf dem Server gelöscht? Wenn nicht, bitte einmal den Cache löschen und den Webdienst und den AsyncService neu starten.

ich hab den IIS, den Async. Verarbeitungsdienst mehrmals neu gestartet, Cache geleert und Server rebootet trotzdem kein Erfolg.

Das Einzige was weiterhilft ist IFD auszuschalten... :D

Hallo Christian,

kannst du dich am CRM anmelden, wenn IFD eingeschaltet ist?

Welche IP-Adresse hat der Server und was hast du für eine IP-Adresse und Subnet-Mask in der IFD-Konfiguration angegeben?

der Server hat die IP Adresse: 192.168.10.220 Subnetz: 255.255.255.0
Ich habe als IP-Adresse im Config Tool eingegeben: 192.168.10.1 Subnetz: 255.255.255.0

Ich kann mich vom Clinet am CRM anmelden. Direkt am Server (über eine Remotedesktopverbindung) kann ich CRM nicht aufrufen

erm wenn mich nicht alles täuscht hätte ich mit den Konfigurationseinstellungen 192.168.10.220 Subnetz: 255.255.255.255 nur den Server drin...

Wie dem auch sei, wenn ich das im Tool eingebe funktioniert der Zufriff auf das Testsystem weder vom Client noch vom Server aus. ;)

Hallo Michael,
kein Problem, dass kommt bei mir öfters vor. ;)

Problem ist allerdings immernoch nicht gelöst. Ich komme, wenn ich direkt am Server angemeldet bin, nicht auf das CRM drauf und ich denke da liegt der Hase im Pfeffer. Ich bekomme als Fehlermeldung einfach nur "Internet Explorer cannot display webpage".

Ich habe gerade auch nochmal geprüft ob es eine "versteckte" IP-Adresse beim Server gibt (das ich eventuell doch in einem anderen Netz hänge ohne es zu wissen), gibt es aber nicht :|

Edit: Schalte ich IFD aus, komme ich am Server auch auf das CRM System.

okeeeeeeee..... jetzt bin ich verwirrt.

Eventuell liegt es an der Namensauflösung. ich habe gerade in der Hosts-Datei des Servers, manuell IP-Adresse und FQDN eingetragen. Danach laufen die Systemjobs wieder. Einloggen am server kann ich mich trotzdem nicht...

Vom Client läufts problemlos, auch die Namensauflösung...

Hallo Christian,

dann lass uns noch einmal anfangen:

Der Server hat die IP-Adresse 192.168.10.220.

Ohne IFD kannst du dich am Server anmelden. Wirst du dabei nach dem Benutzernamen und dem Kennwort gefragt?

Sobald du IFD-einschaltetst, kannst du dich nicht mehr am CRM anmelden, weder vom Client noch vom Server.

Wenn dem so ist, muss die Konfiguration des IFD falsch sein. Deshalb sollten wir diese erst einmal der Reihe nach überprüfen:
- Wie lautet der FQN des Servers?
- Wie lautet der Name der Organisationseinheit im CRM, an der du dich anmelden möchtest?
- Was gibst du im IFD für Einstellungen ein
-- IP-Adresse und Subnet-Mask
-- IFD Domain Schema
-- IFD App Root Domain
-- IFD SDK Root Domain
-- AD Domain SChema
-- AD App Root Domain
-- AD SDK Root Domain
- Was wird in dem Fenster unten links in grau angezeigt?

Wie rufst du das CRM vom Client auf, wenn IFD eingeschaltet ist und wie, wenn es nicht eingeschaltet ist?

Namensauflösung ist auch mein Verdacht, deshalb die ganzen Fragen.

Das kriegen wir schon ans laufen, ich betriebe über 20 Server im IFD, und es gab da noch nie Probleme

So... es liegt recht eindeutlig an der Namensauflösung, allerdings hat nur der Server ein Problem damit.

Nachdem ich den IE Cache gelöscht habe, kann ich mich auch am Server anmelden.

Folgendes ist das Szenario:
- Normale CRM Installation ohne IFD - alles funktioniert, ich kann mich überall anmelden (Server, Client, Systemjobs laufen)
- Sobald ich IFD anschalte, konnte ich mich am Server nicht mehr am CRM anmelden - an den Clients lief es aber wie gewohnt.
- gleichzeitig sind die Systemjobs nicht mehr durchgelaufen (wahrscheinlich ein Effekt der nicht mehr funktionierenden Anmeldung am Server)
- nachdem ich die hosts-datei auf dem Server angepasst habe (192.168.10.220 testcrm.domäne.de) und ich den IE Cache auf dem Server gelöscht habe, kann ich mich sowohl am CRM anmelden und die Systemjobs funktionieren auch wieder

- Schalte ich IFD wieder aus und entferne den Eintrag aus der hosts-Datei funktioniert auch wieder alles wie gehabt....


Alle Klarheiten beseitigt? :D

Edit:
- Server und Client erhalten beide die gleichen DNS Server
- einziger Unterschied in der Konfiguration: Server hat eine feste IP-Adresse (logisch) - Client bekommt DHCP

Zuletzt geändert von CK82 am 10. November 2009 13:59, insgesamt 1-mal geändert.

Gelöst:
Namensauflösung IPv6 funktioniert nicht.

In der etc\hosts Namensauflösung manuell auf IPv4 umgestellt.