Fehlersuche Microsoft Dynamics CRM Email Router

Es gibt eine ganze Reihe von Blogeinträgen von Microsoft, welche Möglichkeiten der Fehlersuche es für den Email Router für Microsoft Dynamics CRM gibt, anbei findet ihr eine Liste mit entsprechenden Links zu den Artikeln:

Email Router Demystified –Troubleshooting (Part 1)

Email Router Demystified –Troubleshooting (Part 2) -Troubleshooting Outgoing email issues

Email Router Demystified -Troubleshooting (Part 3) -Troubleshooting Incoming email issues

Email Router Demystified–Tools for Troubleshooting -Intro

Email Router Demystified–Tools for Troubleshooting -Email Router Logging

Email Router Demystified–Tools for Troubleshooting -Fiddler

Email Router Demystified–Tools for Troubleshooting -Message Analyzer

Email Router Demystified–Tools for Troubleshooting -WCF Tracing

 

 

 

CRM 2016 Probleme mit Vorname Nachname (Firstname Lastname)

Aktuell gibt es ein Problem mit CRM Online Version 8.0.1.90.

Der Benutzer, der diese Organisation anlegt wird im CRM korrekt mit seinem Vor- und Nachnamen angezeigt. Erstellt dieser Benutzer aber einen Datensatz, wird als Besitzer Firstname Lastname angezeigt und nicht der richtige Name des Benutzers. Dieses Problem betrifft nur den Benutzer, der die CRM Organisation angelegt hat.

Der Microsoft Support hat bestätigt, das es sich um ein bekanntes Problem handelt und dieses mit der Version 8.1 behoben wurde.

Als Workarround gibt es aktuell folgende Lösung.

Im Office 365 Portal muss der Vorname, Nachname und der Anzeigename einmal auf einen beliebigen anderen Wert geändert und gespeichert werden. Anschließend können wieder die ursprünglichen Werte für Vorname, Nachname und Anzeigename eingetragen werden. Dann wird der Besitzer auch mit seinem korrekten Vor- und Nachnamen im CRM beim Besitzer des Datensatzes angezeigt. Wichtig ist, auch den Anzeigenamen manuell zu ändern, da dieser nicht automatisch aktualisiert wird, wenn bereits ein Wert in dem Feld steht.

CRM 2013 – Probleme mit deutschem Dezimaltrennzeichen

Aktuell gibt es mit einem deutschen CRM 2013 System einen Bug mit Dezimalfeldern.
Wenn ihr in einem Dezimalfeld z.B. 1,6 eingebt, wird dies durch die GUI automatisch in 16 geändert, was nicht unbedingt der gewünschte Effekt ist.
Das Problem ist bei Microsoft bereits bekannt und es wird an eine Lösung gearbeitet. In de Zwischenzeit könnt ihr folgenden Workaround anwenden.

Geht in die persönlichen Optionen im CRM auf den Reiter Formate und dort auf Anpassungen. Dann ändert ihr auf dem ersten Reiter Zahl das Symbol für die Zifferngruppe in den dritten Wert, das ist ein Leerzeichen.

Nachdem ihr diese Änderung gespeichert habt könnt ihr wieder werte in die Dezimalfelder eingeben, ohne das diese von der GUI geändert werden. Sobald der Fix für diesen Bug bereitsteht, werde ich an dieser Stelle darüber berichten.

KB Artikel von Microsoft

Wie ihr ja alle wisst werden die KB Artikel von Microsoft bei der Anzeige im Internet Explorer automatisch in die Standardsprache des Explorers übersetzt, bei mir zum Beispiel in Deutsch.

Meistens schalte ich dann direkt auf die englische Version um, weil ich die einfacher lesen kann, die Übersetzungen sind mir zu holprig. Aber wie es dann immer so ist, habe ich da bei dem KB Artikel 968520 schon länger nicht mehr gemacht und immer mit der deutschen Version gearbeitet, da ich mir eigentlich nur die aktuellen SQL Scripte herauskopiere und dann verwende.

Heute musste ich dann feststellen das es eine gute Idee ist, auch KB Artikel auf die englische Sprache umzustellen, die man schon auswendig kennt. In den Übersetzungen sind nicht unbedingt alle Teile des KB Artikels enthalten. Und da Kb Artikel auch durchaus überarbeitet werden kann es euch passieren, das ihr selbst von bekannten Artikeln nicht alle Teile des Artikels zu sehen bekommt.

Als Beispiel sein der bereits angesprochene der KB Artikel kb968520 genommen, der von den Geschwindigkeitsproblemen im CRM handelt, wenn die AsyncOperationBase-Tabelle zu groß wird. 1000 mal gelesen, 1000 mal Scripte kopiert, die letzten 100 mal nicht mehr auf englisch umgeschaltet, man kennt den Artikel ja eh schon auswendig.

In der deutsche Übersetzung endet der Artikel mit dem SQL-Statement, um die Anzahl der Datensätze zu ermitteln, die durch das Hauptscript gelöscht werden können. Ändert ihr jetzt die Sprache auf englisch werdet ihr feststellen, das in der englischen Version noch ein möglicher Script Error und seine Lösung behandelt wird. Natürlich habe ich gerade ein paar Stunden damit verbracht diesen Fehler zu finden ohne den Teil in der deutschen Übersetzung zu finden.

Es zeigt sich also, immer gleich auf die englische Version umschalten lohnt sich, wenn man einen KB Artikel wirklich komplett lesen möchte oder muss.

CRM 2011 – 1 is not a valid Status Code

Heute bin ich über einen interessanten Fehler gestolpert, den ich euch nicht vorenthalten möchte.

Beim Speichern eines Auftrages habe ich folgende Fehlermeldung erhalten:

1 is not a valid status code for state code SalesOrderState.Submitted on salesorder.

Das ist insoweit ungewöhnlich, weil es sich um einen gültigen Statuscode für den Auftrag handelt. Merkwürdig war, das dieser Fehler nur bei einem Benutzer auftrat, dieser dafür aber auch an verschiedenen anderen Stellen merkwürdige Fehler hatte, z.B. wurden bei diesem Benutzer die Preise in einem Rechnungsprodukt nicht mehr addiert, so das eine Rechnung keine Summe mehr hatte.

Nach einiger Suche war die Lösung dann relativ einfach. Bei dem Benutzer war das Kennzeichen „Integrationsbenutzer“ in der Benutzerverwaltung von Nein auf Ja umgestellt. Nachdem ich dieses Kennzeichen wieder auf Nein gestellt habe, hat alles wieder so funktioniert wie bei den anderen Benutzern.

Nach ein bisschen Nachfragen ist auch herausgekommen, wie dieses Kennzeichen, das im Standard nicht auf dem Formular des Benutzers angezeigt wird, geändert wurde.

Der Benutzer hatte mit den CRM Connectoren zum verbinden des CRMs mit Navision experimentiert und dabei wurde das Kennzeichen durch den Connector umgestellt.

CRM 2011 – The located assembly’s manifest definition does not match the assembly reference

Hallo zusammen,

bei einem Kunden habe ich beim update einer CRM 4 Organisation den folgenden Fehler erhalten:

Action Microsoft.Crm.Tools.Admin.UpgradeWorkflowsAction failed.

Could not load file or assembly ‚Microsoft.Crm.Sdk, Version=4.0.0.0, Culture=neutral,

PublicKeyToken=31bf3856ad364e35‘ or one of its dependencies.

The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Ursache war, das ein paar PlugIns nicht in der Datenbank gespeichert waren sondern im Filesystem. Ich musste also nur die Daten aus dem Verzeichnis Server\bin\assembly des alten CRM 4.0 Servers auf den neuen CRM 2011 Server kopieren und konnte dann die Datenbank erfolgreich updaten.

Sollte das oben beschriebene Verfahren nicht ausreichen kann es helfen, die Microsoft.Crm.Sdk und SdkProxy Dlls der Version 4 in den Gac zu registrieren und dann das Update durchzuführen, danach können die Dlls wieder deregistriert werden.

 

Microsoft.Crm.Sdk and SdkProxy (v4)

CRM 2011 – Duplikaterkennung beim Import mit RU12 funktioniert nicht

Hallo zusammen,

wie ich gerade gelesen habe, soll es ein Problem mit dem RU12 und der Duplikaterkennung beim Import geben. Laut Microsoft Support ist dies erkannt worden und soll mit dem nächsten Major Release behoben werden.

Link zum Originalartikel siehe hier.

CRM 2011 – Bug mit Notizen im RU12

Es wird in den Foren vermehrt von einem Bug im RU12 berichtet, bei dem das Änderungsdatum und der Änderungsbenutzer einer Notiz geändert wurden, obwohl der Benutzer nur in die Notiz geklickt hat, um z.B. etwas in die Zwischenablage zu übernehmen, aber diese nicht von ihm geändert wurden.

Dies scheint ein Bug zu sein. Sobald ich weitere Infos dazu habe, werde ich diese hier berichten.

UPDATE 06.03.2013:
Auf CRM Online wurde dieses Problem mit dem letzten kleinen Update behoben, für alle anderen wird dies mit dem RU13 behoben werden.

CRM 2011 Dezember 2012 Service Update und Share Point List Komponente

Hallo,

wenn ihr die SharePoint List Komponente auf eurem CRM System einsetzt müsst ihr daran denken, nach dem Einspielen des RU12 auch diese List Komponente upzudaten. Die alte Komponente ist nicht kompatibel mit dem RU12 und wird  nicht mehr funktionieren.

Ihr findet die aktuelle List-Komponente hier:

http://www.microsoft.com/de-de/download/details.aspx?id=5283

RU11 kann nicht auf der Datenbank eingespielt werden

In der Version 2 des RU11 für Microsoft Dynamics CRM 2011 gibt es einen Fehler der dazu führt, das zwar das Serverupdate durchgeführt werden kann, das Update auf der CRM Datenbank aber nicht durchgeführt wird.

Ihr seht dann im Deployment Manager, das die Datenbank immer noch auf der vorher eingespielten Updateversion ist.

In der Log-Datei erscheint folgende Fehlermeldung:
„Ausnahmefehler beim Anwenden der Datenbankupdates auf die Organisation mit dem Namen = xxxx, ID=xxxxxxx-xxxx-xxxx-xxxxxxxxxxxx:
System.Data.SqlClient.SqlException (0x80131904): Bei der Konvertierung eines varchar-Datentyps in einem datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.“

Aktuell ist mir nur eine unsupportete Lösung für dieses Problem bekannt, das freundlicherweise von Christian.Mueller hier gepostet wurde.

Anbei die wichtigsten Teile aus seinem Post:

Konnte das Problem erfolgreich lösen: auch bei mir schlug das Update auf Rollup 11 per Installer fehl mit der Meldung, dass einige Organisationsdatenbanken nicht aktualisiert werden konnten. Ein Update der Org-DBs kann nachträglich noch einmal über den Deployment-Manager gestartet werden. Hierfür müssen alle DB-Connections geschlossen sein! D.h. auch die CRM Async-Services und andere Dienste, die evtl. auf die Org-DBs zugreifen, müssen beendet werden (wie bereits weiter oben beschrieben).

Die beiden letzten insert-Statements wurden bei mir versucht auszuführen, da die beiden TimeZoneRule-Datensätze nicht vorhanden waren. Hierbei fällt aber auf, dass die Notation der beiden „Datums-Werte“ (‚2012/07/20‘ bzw. ‚2012/08/19‘) nicht korrekt ist (YYYY/MM/DD). Diese müssten – laut ENU-Lokalosierung – ‚2012/20/07‘ bzw. ‚2012/19/08‘ lauten (YYYY/DD/MM). Das korrekte Statement lautet also folgendermaßen:

>>> START >>>

!!! KORRIGIERTES SQL STATEMENT !!!

— Morocco Standard Time:
— Morocco will switch to daylight saving time from 2012 onwards. The Moroccan government has changed the 2012 DST start date to occur on the last
— Sunday of April and end date to occur on the last Sunday of September. During the time of Ramadan, DST will be interrupted and from July 20 to
— August 19, 2012, time will be turned back to standard time.

IF EXISTS (SELECT * from TimeZoneDefinitionBase WHERE TimeZoneDefinitionId = ‚A57C8407-74AF-47f0-B1D8-86575C134EC0‘)
BEGIN
IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = ‚275515A8-F651-4C94-98EE-C04C63537D1B‘)
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, ‚2012/1/1‘, ‚A57C8407-74AF-47f0-B1D8-86575C134EC0‘, ‚275515A8-F651-4C94-98EE-C04C63537D1B‘, 0,
0, 0, 9, 5, 0, 3, 0, 0,
-60, 0, 4, 5, 0, 2, 0, 0)
END

IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = ‚546D7620-34E9-4565-AD10-72BA30486C37‘)
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, ‚2012/20/07‘, ‚A57C8407-74AF-47f0-B1D8-86575C134EC0‘, ‚546D7620-34E9-4565-AD10-72BA30486C37′, 0,
0, 0, 0, 0, 0, 0, 0, 0,
-60, 0, 0, 0, 0, 0, 0, 0)
END

IF NOT EXISTS (SELECT * from TimeZoneRuleBase WHERE TimeZoneRuleID = ’86F4ACFB-3E69-474E-AAAF-238419C38801‘)
BEGIN
insert into TimeZoneRuleBase(ModifiedOn, CreatedOn, TimeZoneRuleVersionNumber, EffectiveDateTime, TimeZoneDefinitionId, TimeZoneRuleId, Bias,
StandardBias, StandardYear, StandardMonth, StandardDay, StandardDayOfWeek, StandardHour, StandardMinute, StandardSecond,
DaylightBias, DaylightYear, DaylightMonth, DaylightDay, DaylightDayOfWeek, DaylightHour, DaylightMinute, DaylightSecond)
values ( getutcdate(), getutcdate(), 12, ‚2012/19/08‘, ‚A57C8407-74AF-47f0-B1D8-86575C134EC0′, ’86F4ACFB-3E69-474E-AAAF-238419C38801‘, 0,
0, 0, 9, 5, 0, 3, 0, 0,
-60, 0, 4, 5, 0, 2, 0, 0)
END
END

<<< END <<<

Führt man das korrekte Statement gegen ALLE Org-DB Datenbanken per SQL Management Studio aus, sind die beiden TimeZoneRule-Records vorhanden und man kann den Update-Prozess für die Organisation(en) über den Deployment-Manager noch einmal ausführen! Dabei sollte der Updateprozess erfolgreich durchlaufen (bei mir war es so!).