Falls Sie Perfomance-Probleme mit Ihrer Dynamics CRM / 365-Instanz haben, können Sie mit den folgenden Schritten etwas mehr ins Detail gehen, um zu sehen, an welcher Stelle es tatsächlich hängt.

Rufen Sie als erstes bitte ein Formular auf, von dem Sie denken, dass es wirklich langsam lädt. In unserem Beispiel verwenden wir das Firmenformular:

Der nächste Schritt ist Browserabhängig:
Internet Explorer: Drücken Sie [Strg] + [Shift] + [Q] zum Aufruf des Performance Centers
Chrome: Drücken Sie [Strg] + [D] und drücken Sie dann auf [Mehr …]. Als URL geben Sie folgende Zeichenfolge ein (ohne Anführungszeichen): „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ und als Namen beispielsweise „Performance Center“. Dadurch haben Sie oben nun einen Knopf in der Lesezeichenleiste, den Sie nun drücken um das Performance Center aufzurufen.
Firefox: Drücken Sie [Strg] + [B] um die Lesezeichenleiste aufzurufen. Fügen Sie hier ein neues Lesezeichen mit der URL „javascript:Mscrm.Performance.PerformanceCenter.get_instance().TogglePerformanceResultsVisibility()“ (ohne Anführungszeichen) ein und benennen Sie es treffend. Klicken Sie dieses danach an, während Sie das betroffene Formular im aktiven Tab geöffnet haben.

In allen Fällen sollten Sie nun ein Performance Center sehen. Hier drücken Sie nun nacheinander [Enable] (1) und dann [Close] (2):

Lösen Sie nun einen Reload der Seite aus. Dies kann durch drücken von [F5] oder des „Aktualisieren“-Knopfes erfolgen.

Rufen Sie anschließend wieder das Performance Center auf. Sie sehen nun den Ablauf des Seitenaufbaus (3). Mit dem Knopf [Copy All] (4) können Sie nun die Wartezeiten auch nochmal als Text herauskopieren.

Sollten Sie für unser Hosted Dynamics 365 einen Performance-Auszug machen, so würden wir Sie zum einen um den Text bitten, den Sie über den [Copy All]-Knopf heraus bekommen und zum anderen könnten Sie uns noch einen Screenshot von der Balkendiagramm-Darstellung schicken.

Möchte man eine Instanz in eine andere Infrastruktur migrieren (möglicherweise aufgrund einer Aktualisierung), sollten folgende Schritte beachtet werden.

  • Bevor die Instanz in der „alten Umgebung“ abgeschaltet wird, sollte der aktuelle Schlüssel für die Datenverschlüsselung kopiert werden. Diesen finden Sie ab Dynamics CRM 2011 unter Einstellungen > Datenverwaltung > Datenverschlüsselung > [X] Schlüssel anzeigen. Sie benötigen diesen nach der Migration, um die Datenverschlüsselung wieder zu aktivieren.
  • Stellen Sie zudem sicher, dass es einen CRM-User gibt, der alle der folgenden Eigenschaften besitzt.
    • Zugriffsmodus: Lesen-Schreiben (NICHT Administrator und erst recht nicht Lesezugriff)
    • Rolle: Mindestens Systemadministrator
  • Anschließend können Sie auf dem Anwendungsserver die Instanz deaktivieren und löschen. Hierbei wird die Datenbank nicht gelöscht.
  • Besagte Datenbank können Sie anschließend auf dem SQL-Server entweder im Rahmen eines Backups sichern, oder aber die Datenbank einfach aushängen.
  • In beiden Fällen können Sie die Datenbank entweder durch simples Wiedereinhängen oder durch das Wiederherstellen der Sicherung im neuen SQL-Server einhängen.
  • Auf dem neuen CRM- / Dynamics 365-Server können Sie dann die Organisation importieren. Nach der erneuten Eingabe der Namen sowie der Auswahl des Report-Servers kommen wir hier zum Benutzermapping. Dies können Sie automatisiert durchlaufen lassen, sofern die Domäne gleich bleibt. Anderenfalls müssen Sie die CRM-Benutzer manuell den AD-Benutzern zuweisen.
  • Im Falle des Fehlers „You must map your Active Directory user account to at least one enabled Microsoft Dynamics CRM user who has the System Administrator role before the organization can be imported“ sind folgende Ursachen möglich:
    • Sie führen den Import mit einem Benutzer durch, den Sie nicht gemappt haben > Sie müssen sich entweder den Import mit dem Benutzer durchführen, auf den die Anforderungen aus Schritt 2 passen, oder Ihren aktuellen Benutzer auf den besagten CRM-User mappen.
    • Sie führen den Import mit einem Benutzer durch, dessen CRM-User nur administrativen Zugriff auf das CRM hat > Führen Sie folgende Query in der Datenbank Ihrer Instanz aus:
      UPDATE SystemUserBase
      SET AccessMode = 0
      WHERE DomainName = 'DOMAIN\User'
    • Sie führen den Import mit einem Benutzer durch, dessen CRM-User deaktiviert ist > Führen Sie folgende Query in der Datenbank Ihrer Instanz aus:
      UPDATE SystemUserBase
      SET IsDisabled = 0
      WHERE DomainName = 'DOMAIN\User'

      Es kann sein, dass Sie davor einen anderen Benutzer deaktivieren müssen, um die maximale Anzahl von Benutzern nicht zu überschreiten:

      UPDATE SystemUserBase
      SET IsDisabled = 1
      WHERE DomainName = 'DOMAIN\OtherUser'
  • Danach wird der Import durchgeführt. Dies lief bei uns fehlerfrei durch. Sollten uns bei kommenden Migrationen noch gängige Fehler auffallen, werden wir diese an der Stelle ebenfalls festhalten.
  • Nach dem erfolgreichen Umzug müssen Sie bei der Verwendung von ADFS spätestens jetzt die alte Instanz löschen. Aktualisieren Sie anschließend beide Relying Party Trusts (mangels deutscher Server fehlt mir hier die Übersetzung) – die der alten Instanz und die der neuen.
  • Der A-Record muss ebenfalls auf die neue Infrastruktur zeigen.
  • Tragen Sie nach dem erfolgten Zugriff auf das neue CRM den in Schritt 1 gespeicherten Verschlüsselungskey wieder unter Einstellungen > Datenverwaltung > Datenverschlüsselung ein. Danach ist das CRM / Dynamics 365 wieder voll benutzbar.

Sofern Sie folgenden Fehler bei der Ausführung eines Reports bekommen:

Berichtfehler

Berichte können nicht ausgeführt werden, da der Konnektor für Microsoft
SQL Server Reporting Services, eine erforderliche Komponente für die
Berichterstellung, auf dem Server mit Microsoft SQL Server Reporting
Services nicht installiert ist.

… sollten Sie mal einen Blick auf diesen Artikel von Bhavesh Shastri werfen.

Ohne weitere Konfiguration ist der Timeout eines beliebigen Relying Party Trusts sehr knapp bemessen. Man muss sich gefühlt ständig erneut anmelden. Um das zu verhindern, kann man die Lifetime des Tokens per PowerShell erhöhen. Dazu geht man wie folgt vor:

Über das ADFS Management holen wir uns den Anzeigenamen (Display Name) des Relying Party Trusts.

Anschließend führen wir mit Hilfe der PowerShell-Konsole folgenden Befehl aus:

Get-ADFSRelyingPartyTrust -Name "[Anzeigename]" | Set-ADFSRelyingPartyTrust -TokenLifetime 720

Wobei wir mit dem Parameter „-TokenLifetime“ die Lifetime in Minuten setzen. In unserem Fall wären wir dann bei 12 Stunden.

Die Änderung wird sofort übernommen und gilt dann für alle neu ausgestellten Tokens.

Betroffene Systeme:
Microsoft Dynamics CRM Server 2011, 2013, 2015

Genaue Beschreibung:
Bei der Ausführung eines selbsterstellten FetchXML-Reports wird einem anstatt des Reports nur folgender Fehler angezeigt:

The report cannot be displayed. (rsProcessing Aborted)

Geht man nun auf den Reporting-Server und schaut in die Logs (Standardpfad: C:\Program Files\Microsoft SQL Server\\Reporting Services\LogFiles), so wird man unter anderem folgende Meldungen finden:

System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception.
System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception.
System.ComponentModel.Win32Exception: The target principal name is incorrect

Ursache:
Die FetchXML-Abfrage muss einen hierfür zuständigen HTTP SPN abfragen können, um korrekt mit dem Reporting-Server kommunizieren zu können. Läuft der CRM Application Pool unter einem Domain-Account, so wird diese Abfrage fehlschlagen, da der SPN nicht von Haus aus gesetzt wird.

Behebung:
Um diesen Fehler zu beheben, sind folgende Schritte notwendig:

  • Im IIS gehen wir auf die CRM-Seite, klicken auf Authentication, highlighten „Windows Authentication“ und aktivieren dann unter Advanced Settings den Haken für „Enable Kernel-mode authentication“.
  • Anschließend setzen wir folgende Befehle in der Kommandozeile ab:
    PS> setspn -a „HTTP/<CRM-Srv – Hostname>“ „<Application Service User>“
    PS> setspn -a „HTTP/<CRM-Srv – FQDN>“ „<Application Service User>“

Damit sollten die FetchXML-Reports wieder laufen.

Fehler: 

Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 26.01.2015 09:16:59 
Event time (UTC): 26.01.2015 08:16:59 
Event ID: 7c097f8cb25c47eaaee0b06824c52971 
Event sequence: 861 
Event occurrence: 109 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/1/ROOT-1-130666738292352050 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\ 
    Machine name: XXXXXXXX
 
Process information: 
    Process ID: 6392 
    Process name: w3wp.exe 
    Account name: XXXX\XXXXXXXXXX 
 
Exception information: 
    Exception type: SecurityTokenException 
    Exception message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

 
 
Request information: 
    Request URL: https://XXXXXXXXX.XXXXXXXXX.XXXX:443/default.aspx 
    Request path: /default.aspx 
    User host address: XXX.XXX.XXX.XXX
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: XXXX\XXXXXXXXXX 
 
Thread information: 
    Thread ID: 24 
    Thread account name: XXXX\XXXXXXXXXX 
    Is impersonating: True 
    Stack trace:    at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 
 
Custom event details: 

Ursache:
Wenn das selbsterstellte Zertifikat zur Kommunikation zwischen CRM und ADFS kurz vorm auslaufen ist (~1 Woche), stellt das ADFS ein neues Zertifikat aus und verwendet dieses auch sofort. Die eigentlichen CRM-Server bekommen davon allerdings wenig mit, haben immer noch den Thumbprint vom alten Zertifikat gespeichert und können mit dem nun verwendeten neuen gar nichts anfangen. Dies versucht uns diese Fehlermeldung zu übermitteln.

Behebung:
Zuerst führen wir auf dem ADFS-Server folgende Powershell-Befehle aus: 

Set-AdfsProperties -AutoCertificateRollover $true
Update-AdfsCertificate -Urgent
Im Anschluss daran öffnen wir den CRM Deployment Manager auf dem CRM-Server und führen diese beiden Assistenten nochmals aus:

  • Configure Claims-Based Authentication
  • Configure Internet-Facing Deployment

Diese müssen einfach nur durchgeklickt werden, sprich „Next“, „Next“, […], Apply.
Zurück auf dem ADFS-Server muss nun der ADFS-Dienst neugestartet werden („Active Directory Federation Services“).
Jetzt gehts wieder zum CRM-Server, wo der „Microsoft Dynamics CRM Asynchronous Processing Service“ neugestartet werden muss. Als letzter Schritt muss noch ein iisreset ausgeführt werden. Nun sollte alles wieder gehen.

Beim Anlegen von Benutzern kann es nach dem Klick auf „Speichern“ zu einem Fehler kommen. Im Eventlog kann man zu diesem Moment einen Fehler mit der Event-ID 18176 sehen. Durch was genau der Fehler entsteht, ist nicht bekannt – auf jeden Fall scheinen dem CRM bei dem Fehler Einträge in Feldern zu fehlen, welche standardmäßig vom System schon gesetzt werden.

Beheben lässt sich der Fehler ziemlich simpel:

  1. Gehen Sie im CRM als Administrator auf EINSTELLUNGEN -> VERWALTUNG -> Systemeinstellungen.
  2. Stellen Sie im Reiter Formate das aktuelle Format um, z.B. auf „Deutsch (Liechtenstein). Bestätigen Sie dies mit Klick auf „OK“
  3. Jetzt öffnen Sie die Einstellung nochmal und setzen das Format wieder zurück. Wieder mit „OK“ bestätigen.

Damit sollte das Problem schon behoben sein. Wir haben durch das temporäre Umstellen der Sprache bewirkt, dass die weiter oben genannten Felder wieder befüllt sind.