28. Februar 2011 11:23
Hallo,
inzwischen ist das Problem gelöst.
Allerdings weiß ich nicht 100%tig wie.
Zunächst: wenn ihr das Debugging mit der in einem anderen Link vorgeschlagenen Methode nicht ans Laufen bekommt (wie es mir ergangen ist), dann benutzt das Werkzeug
CRM Trace Log Viewer.exe. Darin via
Tools, configure Tracing den lokalen Servernamen eingeben, dann geht das Konfigurationsfenster auf:
Häkchen bei Trace Enabled, Directory fürs log, Level: verbose etc. alles eingeben; das setzt automatisch die Registry-Einträge richtig und dann bekommt ihr eine Logdatei.
Eine der Logdateien war nach folgendem Muster benamt:
- Code:
SERVERNAME-w3wp-CRMWeb-YYYMMDD-xx.log
wobei DOMAIN Euer eigener Domänenname ist, ACCOUNT ist das Konto, mit dem der AppPoolName läuft (im IIS),
SERVERNAME is Dein Servername, YYYMMDD ist das Datum and xx ist eine zweistellige Zahl.
In diesem Typ Logdatei gab es zuhauf Einträge nach folgendem Muster:
- Code:
>Checking Token Membership for WindowsIdentity DOMAIN\ACCOUNT for groupSID S-1-5….
bla bla — noch ein Haufen Zeug
>SetupMode: False
Ein Lead-Eintrag wird offensichtlich immer durch ein >-Zeichen angeführt.
Und das SetupMode deutete auf eine nicht erfolge Authentifizierung.
Hinter GroupSID S-1-5… stand eine AD-Gruppe, und zwar die PrivUserGroup. Und das angemahnte Konto war definitiv darin enthalten.
Ich habe es allerdings wegen der Fehlermeldung nochmal entfernt und wieder hinzugefügt und m.E. war das der Grund.
Der angemahnte Benutzer war auch genau der mit dem der CRMAppPool im IIS lief.
Und jemand anderes meinte, dieser müsse unter NetworkService betrieben werden (weil sonst die „Impersonation der angemeldeten AD-User gegenüber der CRM-Plattform“ nicht funktionieren würde), also haben wir das Konto für den CRMAppPool auf NetworkService umgestellt. Hinterher hatte ich es wieder auf den User zurückgestellt, den Server neu gestartet und es lief nach wie vor noch alles gut.
Zudem hatte ich noch die neuesten Patches auf den Server gespielt.
Sucht Euch aus, woran es lag…