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

Znaleźliśmy już błędy w Dynamics CRM 2011

Ponieważ od pewnego czasu pracujemy już z Dynamics CRM 2011 (ja jako MVP bezpośrednio z Grupą Produktową, a Netwise jako członek programu Metro) mieliśmy już okazję “przeklikać” większość nowych funkcjonalności i nie raz użyliśmy już plugin’ów i rozszerzeń. Miło mi się pochwalić, że nasz zespół do tej pory w samej tylko wersji BETA znalazł już 6 błędów, z których 3 po naszych wskazówkach będzie naprawione w kolejnych wersjach CRM 2011 (następne build’y). Tutaj akurat największe uznanie należy się nie mi (1 błąd), ale Tomkowi Filipowiczowi (http://www.xrmconsulting.pl), który zgłosił już 5 błędów i co tydzień przynosi nowy :) .

Ja osobiście bardzo się cieszę, bo realnie przyczyniamy się do tego, żeby Dynamics CRM 2011 był w momencie premiery naprawdę dojrzały, bezbłędny i rewelacyjny! :) . Cieszę się też dlatego, bo z punktu widzenia Microsoft Corporation i grupy odpowiedzialnej za rozwój CRM “jacyś goście” z nikomu nieznanej w Redmond Polski pomogli znaleźć i rozwiązać błędy w kluczowym biznesowym systemie Microsoft.

Tomek, jesteś wielki ziom! :-)

Follow

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