Update Rollup 6 wycofany na co najmniej 5 dni!

Oj, dzieje się. Kilkanaście godzin po publikacji Update Rollup 6, Microsoft wycofał go ze swoich stron. Powodem jest problem, który uniemożliwia użytkownikom synchronizację z klientem offline dla Outlook, jeśli mają co najmniej jeden termin cykliczny. Przewidywana data przywrócenia Rollup’a do internetu to 2012-01-17.

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 :) .

Microsoft Dynamics CRM 2011 Update Rollup 6 – podwaliny pod nową funkcjonalność

Dziś wieczorem Microsoft zgodnie z harmonogramem opublikował Update Rollup 6 dla Dynamics CRM 2011 z numerkiem, o którym pisałem we wcześniejszym poście. Nie mogłem się doczekać, żeby go opisać wcześniej, ale NDA zabrania nam pisania przed oficjalną publikacją :( .

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.

Co to za dziwna poprawka, ten KB 2645912?

Nie, to jeszcze nie Update Rollup 6. UR6 ukaże się na rynku dopiero 12 stycznia 2012 i będzie miał numerek KB 2600640 (nikomu nie mówcie :) ). Czym jest więc ten KB 2645912, który chce się instalować na maszynach z klientem CRM?

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.

Dziwny problem z konfiguracją CRM dla Outlook po instalacji Update Rollup 5

Wszyscy powoli przyzwyczajają się do nowych funkcji i lepszego działania CRM 2011 z Update Rollup 5. Ale nie wszyscy mają szansę używać CRM po instalacji tego Rollup’a :) . Niestety ostatnio bardzo popularny stał się błąd przerywający konfigurację organizacji w kliencie CRM dla Outlook. Objawia się tym, że można uruchomić Kreatora Kongifuracji i rozpocząć konfigurację organizacji dla klienta CRM dla Outlook, ale ta konfiguracja jest przerwana z błędem:

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ć! :)

Problem z usuwaniem działań po migracji do CRM 2011

Od jakiegoś czasu miałem nieprzyjemność zmagać się z błędem uniemożliwiającym usunięcie zamkniętych działań z widoków w CRM, po migracji z CRM 4.0 do CRM 2011. Problem występuje tylko i wyłącznie podczas usuwania rekordów z widoków, nie z formatek. I tylko i wyłącznie po migracji z CRM 4.0 i to nie na każdym środowisku. Nie ma jednak wytycznych, co powoduje występowanie tego błędu na części środowisk.
Informacja, jaką generuje CRM brzmi:
“Żądany rekord nie został znaleziony lub nie masz wystarczających uprawnień, aby go wyświetlić.”

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.

Rozwiązywanie problemów z Email Router dla CRM 2011

Konfiguracja Email Router’a dla Dynamics CRM 2011 przebiega całkiem podobnie do konfiguracji Router’a dla CRM 4.0. Całkiem podobnie, a w niektórych przypadkach nawet tak samo. Mimo tego, Email Router dla CRM 2011 czasem po prostu nie działa. Nie potrafi odczytać danych o użytkownikach. Ten post zawiera 3 propozycje rozwiązania Waszych problemów z Email Router’em, które pomogły mi z 3 błędami o różnych przyczynach.
Najbardziej popularny błąd, jaki zobaczycie podczas konfiguracji Email Router’a to błąd podczas pobierania użytkowników i kolejek z CRM (“The E-mail Router Configuration Manager was unable to retrieve user and queue information from the Microsoft Dynamics CRM server. This may indicate that the Microsoft Dynamics CRM server is busy. Verify the URL ‘…’ is correct. Additionally, this problem can occur if specified access credentials are insufficient. To try again, click Load Data. I TUTAJ WŁAŚCIWY PROBLEM”):

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ć :) .

Ważna poprawka bezpieczeństwa dla Dynamics CRM i ASP.NET

Jak pewnie wiecie, ostatnio w ASP.NET została odkryta poważna dziura umożiwiająca ściąganie plików z serwera, na którym stoi aplikacja. Dziura dotyczy wszystkich wersji ASP.NET. Więcej o dziurze tutaj: http://www.microsoft.com/technet/security/advisory/2416728.mspx.
Oczywiście wszystkie wersje CRM’a w jakiś sposób wykorzystują ASP.NET i niestety są podatne na tę dziurę. Nawet CRM 2011! Microsoft dziś wypuści(ł) bardzo ważny hotfix do CRM. Poprawka jest tutaj: http://support.microsoft.com/default.aspx?kbid=2421203. Absolutnie warto ją zainstalować jak najszybciej!!! Szczególnie jak macie CRM wystawionego przez IFD na zewnątrz…

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>       

    <system.web>

       <customErrors mode="On" defaultRedirect="~/error2.aspx" />

    </system.web>       

 </configuration>

Błąd “Object reference not set to an instance of an object”

Błąd “Object reference not set to an instance of an object” może pojawiać się w wielu kontekstach w przypadku pisanych przez nas plug-in’ów. Wtedy jednak możemy sami poprawić napisany przez siebie kod. Niestety… błąd ten pojawia się również w plug-in’ie napisanym przez Microsoft, który jest częścią normalnego “execution flow” w szczególnych przypadkach.
Jeśli podczas zapisywania rekordu macie błąd “Object reference not set to an instance of an object“, a w pliku śledzenia (trace) znajdziecie następujące fragmenty:

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.

Problem z Blank.aspx i Dynamics CRM 4.0

Wiele osób ma ostatnio problem z dziwnym zachowaniem CRM’a, mianowicie próbą “zachowania” pliku Blank.aspx. Gdzieś na blogach ignoranci zaczęli nawet szerzyć bzdurę, że to błąd Dynamics CRM 4.0 powoduje takie zachowanie. Wszystko wygląda tak:

Dynamics CRM 4.0 Blank.aspx

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:

Dynamics CRM 4.0 Blank.aspx - Otworz

Problem rozwiązany.

Błąd “Precision must be an integer within the allowed range: 0 for integers, 0 to 4 for money, 0 to 10 for decimal, and 0 to 5 for float fields”

Ostatnio na forum CRM pojawiło się pytanie co w Dynamics CRM znaczy błąd “Precision must be an integer within the allowed range: 0 for integers, 0 to 4 for money, 0 to 10 for decimal, and 0 to 5 for float fields” podczas oglądania w CRM szans sprzedaży, ofert lub produktów na szansach sprzedaży i ofertach. Jeśli też trafiłaś/eś na taki błąd i nigdzie nie możesz znaleźć o co chodzi (google wiele na ten temat nie mówi poza linkami do pytań pozostawionych bez odpowiedzi…), odpowiedź znajdziesz poniżej. A Maciek dostał odpowiedż już wcześniej tutaj: http://social.microsoft.com/Forums/en-US/crmdevelopment/thread/8e02cea2-bef8-45d8-b67a-6cb360ad8f2c :) .

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 :)

Follow

Otrzymuj każdy nowy wpis na swoją skrzynkę e-mail.