Microsoft Dynamics CRM | showModalDialog

Seit der Chrome Version 37 hat Google den Support für die showModalDialog Methode eingestellt. Dies hatte bei einigen CRM Kunden gravierende Auswirkungen auf den Betrieb von CRM2011 und CRM2013. Was bislang durch eine Security-Einstellung temporär wieder aktiviert werden konnte, wird nunmehr offiziell zum April hin endgültig abgeschaltet. Mehr Details hierzu findet Ihr unter http://blog.chromium.org/2014/07/disabling-showmodaldialog.html.

Wichtig in diesem Zusammenhang ist, dass das CRM Produkt-Team bereits reagiert hat und in den kommenden Updates eine finale Lösung hierfür anbieten wird. Konkret sind dies:

                – CRM 2011 UR18 (On Premise only)

                – CRM 2013 UR3 (On Premise only)

               –  CRM 2013 SP1 – Fix will be included in CRM 2013 SP1 UR3 (Online & On Premise)

                – CRM 2015 – Fix will be included in CRM 2015 UR1 (Online & On Premise)

Die Veröffentlichung ist für den Monat April vorgesehen, so dass sich Kunden keine großen Sorgen über den Betrieb der vorhandenen Lösungen machen sollten.

In diesem Zusammenhang sei jedoch gesagt, dass die Fixes nur für das jeweils letzte Update Rollup zur Verfügung gestellt werden können. Da einige Kunden bislang noch nicht auf diesem Update Rollup Stand sind, heißt es in den kommenden Tagen also noch einmal sich mit einem Update auseinanderzusetzen und ggfs. auch seinen Quellcode (bei Anpassungen) zuvor zu prüfen.

Werbeanzeigen

Microsoft Dynamics CRM 2011 | Update Rollup 17

Es ist soweit, seit letzter Woche steht Update Rollup 17 für Microsoft Dynamics CRM 2011 zum Download bereit und damit für Windows 8.1 bzw. Windows 7 auch das Zeitalter der Unterstützung von IE11 eingeführt.

Update Rollup 17 enthält einen Hotfix, der manuell aktiviert werden muss. Dieser betriff den E-Mail Router und Exchange 2010.

  1. On the Email Router machine, you must create a new String value Key named „CASServerName“ in the path HKEY_Local_Machine\Software\Microsoft\MSCRMEmail.
  2. Enter the NetBIOS name of one of the Exchange CAS servers.

Deshalb habe ich auch wieder mein Registry Key Artikel aktualisiert, so dass alle Änderungen zentral zusammengefasst eingesehen werden können.

Natürlich stehen auch wieder zentrale Punkte im Fokus des Update Rollup 17. Sprich uns erwarten Verbesserungen im Outlook-Client (Ladeverhalten), wie auch im Web-Client.

Einen hervorragenden Überblick gewinnt Ihr im Podcast.

Technorati Tags:

Microsoft Dynamics CRM 2011 | Update Rollup 16

So viele Neuigkeiten rund um CRM 2013, da wollen wir doch nicht vergessen, dass es auch noch Neuigkeiten zum Vorgänger gibt. In der letzten Woche wurde das Update Rollup 16 veröffentlicht.

Mit diesem Update Rollup müssen keine Schritte manuell durch Änderungen / Ergänzungen von Registrierungsschlüsseln aktiviert werden. Das Update Rollup 16 kann deinstalliert werden und die Liste der beinhalteten Fixe liest sich wie das “Who-is-who”…

Es sind wirklich zahlreiche Fehlerbehebungen, die es einzeln hervorzuheben in einer weiteren scheinbar endlosen Liste münden würde.

Ich habe das Update Rollup 16 bereits seit einigen Wochen in meiner Entwicklungsumgebung installiert und getestet und kann nur positiv über dieses Update Rollup sprechen.

Technorati Tags:

Microsoft Dynamics CRM 2011 | Update Rollup 15 verfügbar

Microsoft hat gestern das Update Rollup 15 für Microsoft Dynamics CRM 2011 zum Download zur Verfügung gestellt. Leider fehlen derzeit noch die deutschen Bits & Bytes. Auf Nachfrage wurde mir zugesagt, dass die Dateien in den kommenden Tagen nachgeschoben werden sollen – auf jeden Fall aber pünktlich zum Roll-Out über den Windows Update Service zur Verfügung stehen werden.

Ein Grund für die Rückstellung des deutschen Paketes wurde nicht genannt.

Warum das Rollup 15 lohnt? Vor allem wegen dem neuen Outlook Client, der mit deutlich mehr Stabilität glänzt und somit bereits für die CRM 2011 Nutzer veröffentlicht wurde.

Alle weiteren Fakten sind von den PFE Dynamics CRM Kollegen im Blog (englisch) wunderbar aufbereitet worden. Hört Euch auch den entsprechenden Podcast mit weiteren Informationen hierzu an.

Update 10.10.13: Die Dateien stehen nunmehr auch in der deutschen Version zum Download zur Verfügung.

Technorati Tags:

Microsoft Dynamics CRM 2013 | Action required before Upgrade

Notification

Jüngst sollten einige CRM Online Kunden von Euch Post von Microsoft erhalten haben. In dieser E-Mail informiert das CRM Online Team über einen durchgeführten Test mit Eurer/(n) CRM 2011 Organisation/(en) bzgl. eingesetzter JavaScript Ressourcen. Anlage ist eine .txt-Datei in denen weitere Details entnommen werden können. So heißt es hier in etwa:

Output for Organization Your Organizationname:
==========================================================================
Solution Name: Solutionname            Publisher Name: Default Publisher                                    Version: 1.0        IsManaged:False
———————————————————————————————————————————-
 
Web Resource Name : jQuery_min.js            Web Resource Type: 3
 
Match found: .ParseXml
Match found: .Clear
Match found: .DefaultValue
Match found: .Disabled

Danach folgt der komplette gefundene Quelltext und dann eine wichtige Zeile:

The organization Organizationname has X potential issues with their Web Resources for Microsoft Dynamics CRM 2013

In der E-Mail findet Ihr weitere Hinweise mit Links zu Seiten, die Euch weiterhelfen können. Aus der Praxis möchte ich Euch heute einige Tipps geben, wie mit dem Prüfungsergebnis umzugehen ist.

Zunächst gilt es folgende Punkte zu verifizieren:

a) es handelt sich um eine Lösung, die von einem ISV Anbieter bezogen wurde (meist zu erkennen an dem Publisher Name oder an IsManaged = true)

b) es handelt sich um eine eigene Lösung, die von mir oder einem Programmierer realisiert wurde

c) es handelt sich um eine Individual-Lösung von meinem Implementierungspartner, die ich im Rahmen der Implementierung oder Nachpflege erhalten habe (auch hier meist zu erkennen an dem Publisher)

Im Fall A stellt sich die Frage, ob man die Lösung selbst bei dem ISV Partner eingekauft hat oder diese über seinen Implementierungspartner erhalten hat. Im Zweifel kann eigentlich immer der ISV Partner direkt angeschrieben oder angerufen werden, so dass dieser eine Aussage zu der Kompatibilität mit CRM 2013 treffen kann.

Im Fall B ist man selbst gefragt, hierzu gleich noch ein paar Tipps, während im Fall C direkt der Implementierungspartner zu fragen ist. Sollte dieser nicht mehr existieren (Insolvenz), so gibt es in der Regel die Möglichkeit Microsoft direkt anzusprechen und an einen geeigneten Nachfolge-Partner vermittelt zu werden, der einem mit dem Quellcode bzw. dessen Analyse weiterhelfen kann. Falls nicht, fragt Eure MVPs, wir helfen Euch gerne weiter.

———-

Was ist konkret im Fall B ein geeignetes Vorgehen. Ihr findet in dem Satz eine Anzahl (X) potenzieller Fehlerquellen, die einen Umstieg auf CRM 2013 gefährden. Um diese Anzahl zu verifizieren und die Ursachen zu erfahren holt Euch idealerweise das Microsoft Dynamics CRM 2013 Custom Code Validation Tool. Dieses installiert Ihr in Eurer CRM 2011 Instanz und lasst Euren Quellcode analysieren.

Ihr solltet auf eine vergleichbare bzw. gleiche Anzahl an Treffern kommen, die Euch von dem CRM Online Team zur Verfügung gestellt wurde. Das Tool ist jedoch kein “Allheilmittel”.

Ausgewiesen wird z.B. auch ein auskommentierter Code:

// crmForm.all.SOME_FIELD_ID

Ihr solltet also sehr genau prüfen, ob Eure Webressourcen tatsächlich noch v4.0 Code-Zeilen enthalten oder nicht doch etwa schon umgestellt wurden auf CRM 2011 (Xrm.Page.).

Weiterhin gilt: Es werden alle Webressourcen untersucht, unabhängig davon, ob Sie in einer Form eingebunden sind oder nur in Eurer Lösung hinzugefügt wurden. Wird gar eine Webressource als vermeintliche Fehlerquelle ausgewiesen, diese wird jedoch nicht von einer Form aus angesprochen, so wird es hier im Einsatz von CRM 2013 auch keine Fehler geben. Die Ressource wurde wohl eher vergessen zu löschen (vielleicht weil man Sie irgendwann doch wieder benötigen könnte Zwinkerndes Smiley .

Ein weiterer Fall kann die Verwendung von jQuery als Bibliothek sein. Auch diese Webressource wird gescannt und nach potenziellen Gefahren untersucht. Und was soll ich Euch sagen. Natürlich enthält diese Ressource potenziell nicht mehr unterstützte Methoden, wie etwa .Disabled oder .ParseXml.

Leider erkennt das Tool hier jedoch nicht, dass jQuery auf Grund von Cross-Browser-Plattform hier verschiedene Funktionen anbietet und je nach Unterstützung des Browser Methode A, B oder C zum Einsatz bringt. In der Praxis kommt es daher in der Regel auch nicht zu irgendwelchen Fehlern.

In der Praxis hat sich daher bewährt eine Quellcode-Dokumentation einzusetzen. Wer eine solche nicht hat, dem empfehle ich den Einsatz von Snapshot.

Auf Basis der Quellcode-Dokumentation lassen sich erheblich bessere Aussagen treffen, ob Eure Systeme potenzielle Fehlerquellen enthalten, die bei einem Upgrade zu Fehlern führen.

Aus der Praxis heraus empfehle ich daher folgende Reihenfolge bei der Ursachenforschung:

      • Ermittlung eingesetzter ISV Lösungen. Wer ist der Anbieter, welche Version habe ich Einsatz?
        • Ermittlung von crmForm. / v4.0 Code-Zeilen die auf Xrm.Page. hin umgestellt werden müssen
                   Hier empfiehlt sich zunächst erst einmal nur die Anzahl zu ermitteln, um je nach Aufwand zu entscheiden,
                   externe Ressourcen mit heranzuziehen, die bei der Migration unterstützen.
  • Werden 2007er Endpunkte im Quellcode angesprochen ( zu identifizieren anhand der URL                                   “…MSCRMServices/2007/…”
  • Kann ich den/die Entwickler ausfindig machen (wenn ich es nicht selbst gewesen bin)?
  • Kenne ich mich selbst in JavaScript Code aus oder muss ich eine Ressource in Anspruch nehmen?

Und dann noch ein Tipp: Nicht nur JavaScript-Code kann zu Problemen führen, auch einige Plug-Ins können im Einsatz mit CRM 2013 ärger bereiten, da die neue Funktion “auto save” eingeführt wird und dies unter Umständen durch den Plug-In-Code nicht berücksichtigt wird. Auch könnte im Plug-In der 2007er Endpunkt angesprochen werden, der ebenfalls nicht mehr unterstützt wird.

Daher gilt auf jeden Fall: Auch die Plug-Ins untersuchen !!!

Diese Aufgabe übernimmt das Custom Code Validation Tool nicht.

———

Fazit: Wer gut vorbereitet sein will, der sollte sich seine Quellcode-Dokumentation unmittelbar zur Hand nehmen und Schritt für Schritt die Analyse durchführen. Ihr könnt – sofern Ihr bereits einen Migrationstermin erhalten habt – diesen noch um einige Tage verschieben und somit die notwendige Sorgfalt wahren, um auch mit der neuen Version Eure Nutzer zu begeistern.

 

Technorati Tags:

Microsoft Dynamics CRM 2011 | Update Rollup 15

Bald ist es soweit und Update Rollup 15 steht zum Download für alle CRM On-Premise Kunden zur Verfügung. Da heißt es einmal mehr: Vorbereitung auf das Update Rollup und Beurteilung, ob ein Update sinnvoll in der eigenen Umgebung erscheint oder nicht.

Microsoft stellt dazu erneut einen Knowledge-Base-Artikel vorab zur Verfügung, der alle notwendigen Informationen beinhaltet. Diesmal ist mir die deutsche Übersetzung besonders übel “aufgestoßen”, weshalb ich dringend die englische Originalfassung empfehle. Als CRM Administrator ist man eh mit den Fachbegriffen vertraut.

Viele Outlook CRM Nutzer unter Euch dürften sich bereits über das erschienene Critical Update Rollup 11 gefreut haben, welches zahlreiche Stabilitätsverbesserungen des Outlook-Clients mit sich brachte, jedoch den Nachteil hatte, dass spätere Update Rollups nicht “drüber” installiert werden konnten, ohne die Änderungen rückgängig zu machen.

Mit Update Rollup 15 bestreitet das Team nun einen neuen Weg und bringt eine Verbesserung des Outlook-Clients heraus, die eigentlich einem neuen Outlook-Client gleichkommt. Dies merkt man zwar nicht von der optischen Seite her, aber der technische Unterbau wurde neu konzipiert und extrem verbessert. Ausführliche Informationen hierzu findet Ihr im Support-Artikel.

Ebenso herausheben möchte ich eine Anpassung des Ladeverhaltens von Scripten in Webressourcen nach Update Rollup 12, welches einen Workaround erforderlich machte, um die Ladereihenfolge oder besser Code-Initialisierung zu garantieren. Update Rollup 15 wird hierfür einen Fix beinhalten, so dass die Reihenfolge Eurer Webressourcen innerhalb einer Maske auch wieder in Einklang zu der Initialisierung steht – die eigentliche Verarbeitung und damit Zeit einmal ausgenommen.

So ist es wohl auch kaum mehr verwunderlich, dass ich allen das Update Rollup 15 nahe legen möchte und eine Installation empfehle.

 

Technorati Tags:

Microsoft Dynamics CRM 2011 | Verwendung lokaler Zeitzonencode

In Microsoft Dynamics CRM gibt es zahlreiche Anwendungsbeispiele, in denen auf Basis von DateTime-Attributen verschiedene Berechnungen durchgeführt werden sollen – so z.B. in den Offset-Berechnungen für den Arbeitszeitenkalender. Offset beschreibt die Dauer in Minuten seit Mitternacht.

In Installationsumgebungen, die in mehreren Zeitzonen operieren ergeben sich dadurch für Plug-Ins oder Workflow-Activities spezielle Herausforderungen.

Können wir über eine Abfrage noch sehr einfach an die Zeitzone eines ausgewählten Benutzers herankommen, so stellt sich die Frage, wie dies in der Praxis in eine Berechnung / Konvertierung zur aktuellen Zeit münden kann?

Stellen wir uns also vor, wir haben in einer unserer Entitäten ein Suchfeld zu einem Benutzer integriert. Gleichfalls finden wir ein DateTime-Attribut in unserer Entität. Nun wissen wir bereits, dass CRM die Datum/Zeit-Felder immer in UTC Zeit speichert.

Lesen wir daher einen Feldinhalt z.B. in einem Plug-In mit

var DateField = entity.GetAttributeValue<DateTime>(„prefix_yourfieldname“);

aus, so finden wir anstelle von 02.09.2013 08:00 Uhr lokaler Zeit (deutsche Zeitzone) den Wert 02.09.2012 06:00.

Aus einem Beispielcode im SDK wissen wir aber auch, dass wir den Zeitzonencode eines Benutzers einfach abfragen können.

var currentUserSettings = service.RetrieveMultiple(
                         new QueryExpression(UserSettings.EntityLogicalName)
                         {
                             ColumnSet = new ColumnSet(„localeid“, „timezonecode“),
                             Criteria = new FilterExpression
                             {
                                 Conditions =
                                 {
                                    new ConditionExpression(„systemuserid“, ConditionOperator.Equal, SystemUserId.Id )
                                 }
                             }
                         }).Entities[0].ToEntity<UserSettings>();

                   _timeZoneCode = currentUserSettings.TimeZoneCode;

Wenn wir diese Abfrage starten erhalten wir für o.g. Beispiel die 110 zurück. Was jedoch können wir mit diesem Zeitzonencode anstellen?

In .NET findet sich eine DateTime Konvertierung auf Basis einer TimeZoneInfo.

TimeZoneInfo localZone = TimeZoneInfo.FindSystemTimeZoneById(ID);

Leider entspricht die ID in diesem Fall jedoch nicht der 110, sondern dem String “W. Europe Standard Time”. Wir müssen uns also eine Hilfe schaffen, um von dem ermittelten Code-Wert auf den korrekten String-Wert schließen zu können.

In diesem Fall hilft uns ein Dictionary:

Dictionary<int, string> TimeZoneNames = new Dictionary<int, string>();

                    TimeZoneNames.Add(110, „W. Europe Standard Time“);
                    TimeZoneNames.Add(000, „Dateline Standard Time“);
                    TimeZoneNames.Add(001, „Samoa Standard Time“);
                    TimeZoneNames.Add(002, „Hawaiian Standard Time“);
                    TimeZoneNames.Add(003, „Alaskan Standard Time“);
                    TimeZoneNames.Add(004, „Pacific Standard Time“);
                    TimeZoneNames.Add(010, „Mountain Standard Time“);
                    TimeZoneNames.Add(013, „Mexico Standard Time 2“);
                    TimeZoneNames.Add(015, „U.S. Mountain Standard Time“);
                    TimeZoneNames.Add(020, „Central Standard Time“);
                    TimeZoneNames.Add(025, „Canada Central Standard Time“);
                    TimeZoneNames.Add(030, „Mexico Standard Time“);
                    TimeZoneNames.Add(033, „Central America Standard Time“);
                    TimeZoneNames.Add(035, „Eastern Standard Time“);
                    TimeZoneNames.Add(040, „U.S. Eastern Standard Time“);
                    TimeZoneNames.Add(045, „S.A. Pacific Standard Time“);
                    TimeZoneNames.Add(050, „Atlantic Standard Time“);
                    TimeZoneNames.Add(055, „S.A. Western Standard Time“);
                    TimeZoneNames.Add(056, „Pacific S.A. Standard Time“);
                    TimeZoneNames.Add(060, „Newfoundland and Labrador Standard Time“);
                    TimeZoneNames.Add(065, „E. South America Standard Time“);
                    TimeZoneNames.Add(070, „S.A. Eastern Standard Time“);
                    TimeZoneNames.Add(073, „Greenland Standard Time“);
                    TimeZoneNames.Add(075, „Mid-Atlantic Standard Time“);
                    TimeZoneNames.Add(080, „Azores Standard Time“);
                    TimeZoneNames.Add(083, „Cape Verde Standard Time“);
                    TimeZoneNames.Add(085, „GMT Standard Time“);
                    TimeZoneNames.Add(090, „Greenwich Standard Time“);
                    TimeZoneNames.Add(095, „Central Europe Standard Time“);
                    TimeZoneNames.Add(100, „Central European Standard Time“);
                    TimeZoneNames.Add(105, „Romance Standard Time“);
                    TimeZoneNames.Add(113, „W. Central Africa Standard Time“);
                    TimeZoneNames.Add(115, „E. Europe Standard Time“);
                    TimeZoneNames.Add(120, „Egypt Standard Time“);
                    TimeZoneNames.Add(125, „FLE Standard Time“);
                    TimeZoneNames.Add(130, „GTB Standard Time“);
                    TimeZoneNames.Add(135, „Israel Standard Time“);
                    TimeZoneNames.Add(140, „South Africa Standard Time“);
                    TimeZoneNames.Add(145, „Russian Standard Time“);
                    TimeZoneNames.Add(150, „Arab Standard Time“);
                    TimeZoneNames.Add(155, „E. Africa Standard Time“);
                    TimeZoneNames.Add(158, „Arabic Standard Time“);
                    TimeZoneNames.Add(160, „Iran Standard Time“);
                    TimeZoneNames.Add(165, „Arabian Standard Time“);
                    TimeZoneNames.Add(170, „Caucasus Standard Time“);
                    TimeZoneNames.Add(175, „Transitional Islamic State of Afghanistan Standard Time“);
                    TimeZoneNames.Add(180, „Ekaterinburg Standard Time“);
                    TimeZoneNames.Add(185, „West Asia Standard Time“);
                    TimeZoneNames.Add(190, „India Standard Time“);
                    TimeZoneNames.Add(193, „Nepal Standard Time“);
                    TimeZoneNames.Add(195, „Central Asia Standard Time“);
                    TimeZoneNames.Add(200, „Sri Lanka Standard Time“);
                    TimeZoneNames.Add(201, „N. Central Asia Standard Time“);
                    TimeZoneNames.Add(203, „Myanmar Standard Time“);
                    TimeZoneNames.Add(205, „S.E. Asia Standard Time“);
                    TimeZoneNames.Add(207, „North Asia Standard Time“);
                    TimeZoneNames.Add(210, „China Standard Time“);
                    TimeZoneNames.Add(215, „Singapore Standard Time“);
                    TimeZoneNames.Add(220, „Taipei Standard Time“);
                    TimeZoneNames.Add(225, „W. Australia Standard Time“);
                    TimeZoneNames.Add(227, „North Asia East Standard Time“);
                    TimeZoneNames.Add(230, „Korea Standard Time“);
                    TimeZoneNames.Add(235, „Tokyo Standard Time“);
                    TimeZoneNames.Add(240, „Yakutsk Standard Time“);
                    TimeZoneNames.Add(245, „A.U.S. Central Standard Time“);
                    TimeZoneNames.Add(250, „Cen. Australia Standard Time“);
                    TimeZoneNames.Add(255, „A.U.S. Eastern Standard Time“);
                    TimeZoneNames.Add(260, „E. Australia Standard Time“);
                    TimeZoneNames.Add(265, „Tasmania Standard Time“);
                    TimeZoneNames.Add(270, „Vladivostok Standard Time“);
                    TimeZoneNames.Add(275, „West Pacific Standard Time“);
                    TimeZoneNames.Add(280, „Central Pacific Standard Time“);
                    TimeZoneNames.Add(285, „Fiji Islands Standard Time“);
                    TimeZoneNames.Add(290, „New Zealand Standard Time“);
                    TimeZoneNames.Add(300, „Tonga Standard Time“);

Wenn wir diese Hilfe in unseren Programmcode integriert haben, können wir mit Hilfe von:

int tzc = Convert.ToInt32(_timeZoneCode);

                    if (TimeZoneNames.ContainsKey(tzc))
                    {
                        tzn = TimeZoneNames[tzc];
                    }

auf den korrekten Zeitzonennamen schließen. Dieser befindet sich nunmehr in der tzn-Variablen. Und unsere Konvertierung sieht dann wie folgt aus:

TimeZoneInfo localZone = TimeZoneInfo.FindSystemTimeZoneById(tzn);

DateTime localDateTime = TimeZoneInfo.ConvertTimeFromUtc(DateField, localZone);

Mit dieser einfachen Hilfe können wir fortan zu jedem Feld die gewünschte Uhrzeit in dem Format eines zugehörigen Benutzers ausgeben und damit Berechnungen, wie Beispielsweise eine Offset-Berechnung anstellen.

Wer von Euch nunmehr noch etwas mehr Informationen zu .GetAttributeValue<T> haben möchte, dem sei der Blog Artikel meines MVP Kollegen David Barry empfohlen. In dieser sehr schönen Zusammenfassung bekommt Ihr Wertvolle Hinweise und Tipps zu Integration in Eure Projekte.

Damit wünsche ich Euch viel Spaß in der Verwirklichung / Umsetzung Eurer Projekte und bis zum nächsten Mal.

 

Technorati Tags: