Najgorsze w wypadku UR6 jest to, że nie może być odinstalowany. Nie sądzę, żeby Klienci na wersję on-premise instalowali poprawki na swoich systemach produkcyjnych kilka godzin po ich publikacji. Problem mają użytkownicy CRM Online, na których środowiskach pojawił się już UR6. Nie będą mogli synchronizować danych offline do najbliższej poprawki. Ot, cloud computing .

Update Rollup 6 to oczywiście ponownie zbiór kumulatywny wszystkich poprawek. Całkiem spory zbiór, który wreszcie poprawia kilka wkurzających błędów (np. niemożność usunięcia emaila w widoku skojarzonym). Jest jednak jedna ogromna zmiana – Rollup 6 nie będzie mógł być odinstalowany (podobnie do UR5), bo zawiera istotne zmiany w strukturze bazy i platformy Dynamics CRM optymalizujące odczyt danych. Jakie to zmiany? Jedna z nich to niezła niespodzianka – na razie tylko napiszę tyle: “nowy rodzaj formatek” . Więcej nie mogę, bo blog jest monitorowany, a to jest funkcjonalność “not public” do czasu publikacji Rollup’a 7. Najważniejsze to pamiętać, że UR6 wprowadza zmiany, które są nieodwracalne w CRM 2011.
Oczywiście Microsoft opublikował już tzw. slipstream image, czyli pliki instalacyjne z uwzględnionym Rollup’em 6.

Co nowego naprawia Update Rollup 6?

• podczas migracji z CRM 4.0 do 2011 z UR5 kreator importu zatrzymywał się z błędem wynikającym podczas za dużego zbioru zależności obiektów
• błąd z poprawnym wyświetlaniem formatki, w której osadzony jest zasób z aplikacją Silverlight
• mała, ale uciążliwa rzecz z wyświetlaniem kontaktów bez imienia w postaci “Nazwisko,,”
• wyświetlanie znaczników HTML w widoku emaili z kolumną Opis dodaną do widoku
• błędy JScript podczas próby uruchomienia planowania usługi serwisowej z IE9
• duży błąd, przez który usuwanie rekordów udostępnionych (z wpisem do POA) nie usuwało rekordu powiazanego z tabeli POA (wpisu) przez co usunięcie udostepnionych rekordów nie gwarantowało zmniejszenia liczby wpisów w POA
• popularny błąd podczas próby usunięcia emaili z widoków skojarzonych “Rekord jest niedostępny” / “Record is unavailable“
• brak możliwości nazwania listy rabotowej dwuliterowym skrótem – ktokolwiek używa list rabatowych ?
• błąd z eksportowaniem pola typu “partylist” do Excel, kiedy w polu było więcej niż jeden rekordów
• błąd z niezapisywaniem danych w polu “checkbox” na formatce terminu edytowanej z klienta Outlook
• błąd, który powodował niewyświetlanie tekstu wyjątku w plugin’ie zarejestrowanym do zdarzenia “Przypisz” / ““Assign“
• w niektórych przypadkach widoki zapisane nie zwracały danych do dynamicznych list marketingowych
• błąd przy imporcie zarządzanego rozwiązania zawierającego nową relację między encjami systemowymi, jeśli w systemie istniała już własna, nowa relacja między tymi samymi encjami
• wszystkie poprawki, które były osobno opublikowane jako “fast publish” od Rollup’a 5, a więc np. problem z LDAP, albo niemożność uruchomienia raportów w środowisku, w którym był zainstalowany Claims Authentication

Ufff, dużo tego .

Standardowo Update Rollup 6 możecie ściągnąć stąd: http://www.microsoft.com/downloads/pl-pl/details.aspx?familyid=e35f3e66-42ea-46af-9e79-4b4f7fa55cfe&displaylang=pl, a poczytać więcej na temat UR6 można tutaj: http://support.microsoft.com/kb/2600640.

KB2645912, zwany też LDAP Fast-Publish Fix’em, to poprawka z rodzaju hotfix naprawiająca problem z połączeniem klienta CRM dla Outlook po zainstalowaniu Update Rollup 5. Otóż okazało się, że jeśli na serwerze skonfigurowany jest Internet Facing Deployment (IFD), a podczas konfiguracji klienta CRM dla Outlook zabraknie połączenia do kontrolera domeny (z różnych przyczyn), klient CRM próbuje pobrać dane o uwierzytenlnieniu użytkownika z LDAP’a. I oczywiście ich nie znajduje. I generuje błąd, który spędził sen z powiek w kilku sporych firmach .

Na szczęście Microsoft zareagował dość szybko i nie czekał z tą poprawką do Rollup’a 6. KB2645912 możecie ściągnąć automatycznie z Windows Update na komputery, gdzie jest zainstalowany klient CRM dla Outlook.

Cannot configure the organization for Microsoft Dynamics CRM for Outlook. Try to configure the organization again. If the problem persists, contact your system administrator.

Trochę mnie ten błąd wkurzał, bo nie do końca wiadomo o co chodzi. Zajrzenie wgłąb logów i trace’ów odkrywa 2 błędy, które są przyczyną wystąpienia tego wyjątku:
Microsoft.Crm.CrmException: Logon failed due to missing credentials

Error| Exception : Culture is not supported. Parameter name: culture 0 (0×0000) is an invalid culture identifier. at Microsoft.Crm.MapiStore.DataStore.WaitInitialized()

“Culture is not supported” wskazuje na rozbieżności w pakiecie językowym. Pójście daleje dalej pozwala dojść do realnego problemu – mianowicie użytkownik podczas pierwszej synchronizacji z organizacją ma jako domyślny ustawiony język, który nie został włączony (lub został odinstalowany) w CRM. A Kreator Konfiguracji próbuje zapisać ustawienia użytkownika. I tu pojawia się ten problem, bo do tej pory nie trzeba było mieć ustawionych uprawnień do zapisywania użytkowników.

ROZWIĄZANIE:
Należy sprawdzić czy użytkownik, dla którego konfigurujemy klienta CRM dla Outlook, ma prawa do zapisu ustawień użytkownika (w jakiejkolwiek roli przypisanej do siebie). Jeśli nie ma, dodać uprawnienia “ZAPIS” dla “USTAWIENIA UŻYTKOWNIKA”:

Później wystarczy uruchomić ponownie Kreatora Konfiguracji i wszystko powinno działać!

W tle generuje się błąd:
“Appointment With Id=GUID Does Not Exist”

Problem w tym, że to nie termin (appointment) chcemy usuwać. A tu podczas próby usunięcia dowolnego zamkniętego działania z widoku, niezależnie od typu działania, CRM próbuje usuwać termin o danym GUID. Oczywiście go nie znajduje w bazie i pojawia się problem.

Microsoft na razie nie podał przyczyny takiego zachowania CRM 2011 po migracji, ale błąd jest już znany.

SPOSÓB NAPRAWY
Możemy próbować się pozbyć tego błędu poprzez:
1. Eksport dostosowań, w których znajduje się widok, w którym próbujemy usuwać działanie.
2. Edycję dostosowań w XML poprzez dodanie następującej linijki po wszystkich innych linijkach opisujących “komórki” widoku:

<cell name="instancetypecode" width="100" ishidden="1" />

Chodzi o to, żeby CRM wiedział z instancją jakiego działania ma do czynienie, kiedy próbuje je kasować.
3. Ponowny import i publikację dostosowań

To rozwiązanie, nie wiedzieć czemu, nie działa jednak na wszyskich widokach. Ale jest miła niepodzianka – Microsoft świadomy tego błędu, obiecał przygotować poprawkę w jutro wydanym Update Rollup 4. Czekam z niecierpliwością, bo wkurzam się coraz bardziej, że “standardowa” migracja niby działa, ale nie do końca. Nigdy nie wiadomo po jakim czasie i co się zepsuje.

To niezwykle popularne okienko może mieć bardzo różne przyczyny. Przyczyny oznaczone są na powyższym obrazku na limonkowo w nawiasach . Te poszczególne problemy rozwiązuje się w następujące sposoby:

“Please select an account that is a member of the PrivUserGroup security group and try again.”:

To najprostszy przykład. Błąd ten jasno daje do zrozumienia co się dzieje – konto, na którym działa “Deployment” w Email Router’ze uruchamiany jest na koncie, które w Active Directory nie jest w grupie PrivUserGroup. Aby naprawić ten problem, sprawdź na jakim koncie skonfigurowany jest “Deployment” i dodaj to konto do grupy PrivUserGroup.

“The descryption key could not be obtained because HTTPS protocol is enforced, but not enabled. Enable HTTPS protocol, and try again.”:

Tu mamy do czynienia z trochę trudniejszym do naprawienia błędem. Rozwiązanie tego problemu może oprzeć się o 3 poniższe sposoby:

1. Sprawdź w IIS, czy rzeczywiście strona wymaga SSL. Jeśli tak, podaj właściwy adres w Email Router (z uwzględnieniem HTTPS).
   Jeśli 1) nie pomoże, przejdź do 2:
2. Email Router jeszcze w wersji RC miał dziwną przypadłość polegającą na sprawdzaniu “na siłę” CRM Online. Aby to wyłączyć (i przy okazji wyłączyć sprawdzanie SSL, wejdź na serwer, na którym zainstalowany jest Email Router. Na serwerze przejdź do katalogu: “C:\Program Files\Microsoft CRM Email\service” i otwórz plik Microsoft.Crm.Tools.Email.Management.config. Znajdź w tym pliku linijkę:
   <add key="DiscoveryUrl" value="https://dev.crm.dynamics.com" />

   i… zakomentuj ją! Wprowadza ona bowiem w błąd EMail Router i każe mu szukać Discovery Service’u w CRM Online…

   Jeśli 1) i 2) nie pomogły, to:

3. Email Router wymusza na siłę ustawienie SSL, ponieważ tak ma ustawione w rejestrze. Aby to zmienić, wejdź na serwer, na którym zainstalowany jest Email Router, otwórz rejestr i wejdź do gałęzi: HKLM -> Software -> Microsoft -> MSCRM i dodaj nową wartość DWORD o nazwie “DisableSecurityDecryptionKey” i ustaw jej wartość na 1. Zrestartuj serwer i odpal Email Router ponownie. Wszystko powinno działać.

Powyższe sposoby pozwalają na rozwiązanie wszystkich problemów, jakie do tej pory pojawiły się z Email Router’em. Część wywołałem specjalnie w oczekiwaniu na to, co się stanie. Email Router 2011 zachowuje się bardzo fajnie, podając dokładne opisy problemu, a więc zdał moje testy na 90%. Byłoby 100%, gdyby nie miał w ogóle błędów i pokazywałby instrukcje jak te błędy naprawić .

UWAGA: Hotfix bezpieczeństwa ASP.NET dla Dynamics CRM 4.0 wymaga Update Rollup 13!

Tymczasowe obejście:
Jeśli nie macie Update Rollup 13, albo musicie czekać na politykę aktualizacji w swojej firmie, zastosujcie tymczasową poprawkę poprzez edycję pliku web.config CRM’a. Trzeba tam dodać ustawienie “Custom errors” i wymusić pokazywanie zawsze jednej i tej samej strony błędów, a nie pozwalać serwerowi generować i pokazywać realnego błędu. Można to zrobic tak:

1. Stwórzcie prostą stronkę o tytule np. error2.aspx (dla zmyłki), może być pusta.
2. Edytujcie web.config jak poniżej:

<configuration>       

AssemblyName: Microsoft.Crm.ObjectModel.MultiCurrencyPlugin, Microsoft.Crm.ObjectModel
i
Microsoft.Crm.Sdk.InvalidPluginExecutionException: Object reference not set to an instance of an object.

…to padliście ofiarą nienaprawionego do tej pory przez Microsoft błędu. Błąd ten pojawia się, kiedy utworzycie jakiekolwiek pole typu money na dowolnym obiekcie. CRM automatycznie dodaje wtedy atrybut systemowy exchangerate i od tej pory dołącza do obiektu plugin przeliczający wartość z pola walutowego do waluty bazowej.
Problem zaczyna się, kiedy usunięte zostanie pole walutowe i w obiekcie nie ma już pól typu money. CRM zapomina bowiem… odrejestrować plug-in’a i nie usuwa atrybutu exchangerate, a nadal próbuje liczyć wartość w walucie bazowej, oczekując wartości z chociaż jednego pola walutowego. I… NullPointerException gotowy .

Rozwiązanie:
W obiekcie, na którym pojawia się ten błąd, dodajcie jakiekolwiek pole typu money. Pole nie musi być widoczne na formatce, ważne, żeby było atrybutem tego obiektu.

PRZYCZYNA PROBLEMU:
Takie zachowanie spowodowane jest faktem, że Internet Explorer utracił znaczenie powiązania z plikami typu aspx lub inaczej – Internet Explorer nie wie, co zrobić z plikiem takiego typu. Dlaczego? Wszystkiemu winna jest poprawka do IE, którą większość użytkowników zainstalowało z Windows Update (KB953838 dostępna tutaj).

ROZWIĄZANIE PROBLEMU:
Najprostsze rozwiązanie to przywrócić IE wiedzę jak interpretować pliki aspx . W tym celu w okienku, które się pojawia (“Czy chcesz zapisać plik Blank.aspx?”) wybieramy “OK” i zapisujemy w jakimś łatwo dostępnym miejscu. Później otwieramy plik prawym guzikiem i wybieramy “Otwórz za pomocą…”. W okienku, które się pojawi wybieramy Internet Explorer i zaznaczamy, żeby IE zawsze otwierał pliki aspx:

Problem rozwiązany.

Otóż, ten błąd nie wynika wcale z tego, że któreś pole ma źle ustawioną precyzję. Wynika raczej z faktu, że produkt, który został dodany do oferty lub szansy sprzedaży nie jest obecny w cenniku wykorzystanym przez tę szansę sprzedaży/ofertę. Rozwiązaniem jest dodanie produktu do cennika, który jest użyty w danej szansie lub ofercie. I już. Tyle