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.

• od tej wersji dokument dostarczany jest też w formacie CHM (skompilowane w jeden Planning Guide, Installing Guide i Operating and Maintining Guide. Wygląda to tak:

  
  Nawigacja i wyszukiwanie w nowym Implementation Guide jest znacznie łatwiejsza niż w poprzedniej, niedopracowanej wersji w Word

• pojawiła się sekcja o szyfrowaniu danych w SQL Server 2008
• pojawiła się sekcja o ustawianiu częstotliwości DeletionService
• pojawiła się sekcja o licznikach wydajności (performance counters), które mogą przydać się przy pracy z Microsoft Dynamics CRM

Implementation Guide jest do ściągnięcia tutaj: http://www.microsoft.com/downloads/details.aspx?FamilyID=1ceb5e01-de9f-48c0-8ce2-51633ebf4714&displaylang=en. Pośród kilku wersji językowych brakuje jednak polskiej.

W interfejsie Dynamics CRM, w opcjach, możemy wybrać wyświetlanie w widoku maksymalnie 250 rekordów. Usunięcie 10000 testowo utworzonych klientów nadal będzie żmudne = będzie wymagało od nas 40 razy zaznaczenia wszystkich rekordów i kliknięcia “Usuń”. Można zrobić to sprytniej!

Sposób 1 – usuwanie z pomocą kodu:

Jeśli lubisz kod i nie boisz się skompilować już gotowego kodu, Microsoft Dynamics CRM 4.0 udostępnia w SDK jeden przydatny request – BulkDeleteRequest. Jeszcze w Dynamics CRM 3.0 nie było możliwości usuwania wielu rekordów na raz przez wywołania web service’ów. W 4.0 to jest możliwe! Wystarczy zbudować kwerendę (QueryExpression), podać ją jako atrybut to obiektu typu BulkDeleteRequest, uzupełnić resztę właściwości i wywołać metodę Execute() w CrmService. Więcej informacji na ten temat znajduje się tutaj: http://msdn.microsoft.com/en-us/library/cc155955.aspx

Sposób 2 – unikaj cudownych płatnych narzędzi:

Jest pewna (niepolska) firma, która potrafiła zbić kapitał na niewiedzy użytkowników i… oferuje narzędzie, które wywołuje powyższy kod za opłatą! Ja sam zwalczam takie praktyki, dlatego nie polecam korzystania z takich narzędzi. Raczej lepiej poczytać SDK i samemu skopiować kod.

Sposób 3 – magiczny trick z dostosowaniami:

To jest niestety obejście, którego minusów trzebe być świadomym. Na szczęście nie ma ich wiele. Otóż, można usunąć dowolną liczbę rekordów dowolnego typu poza obiektami typów systemowych w bardzo prosty sposób – usuwając obiekt danego typu z systemu . Przy tym rozwiązaniu robimy backup naszych dostosowań, usuwamy obiekt, którego rekordy chcemy usunąć i… importujemy ten obiekt z powrotem . Do plusów tego rozwiązania należy niewątpliwie fakt, że usuniemy dowolną liczbę rekordów w super-krótkim czasie. Do minusów należy zaliczyć fakt, że obiekty custom mają tzw. ObjectTypeCode nadawany każdemu nowotworzonem obiektowi sekwencyjnie od 10000. Nasz nowy import nada naszemu obiektowi nowy numer i lepiej, żebyśmy byli świadomi w których skryptach używamy starego ObjectTypeCode =)

Mam nadzieję, że te wskazówki pomogą Wam usuwać mnóstwo danych z Waszego CRM’a! Jest jeszcze jeden sposób, który pozwala na wyświetlanie 5000 rekordów w widokach. Ale o nim nie napiszę – zbyt to “niesupportowalne”

Podczas importu organizacji Import Organization Wizard’em (uruchamia się go z “Deployment Manager’a”) przenoszone zostają wszystkie dane zgromadzone w naszym systemie CRM. Jednym z kroków importu jest mapowanie użytkowników. Po co mapować użytowników nie muszę mówić – wyobraźcie sobie sytuację, że właścicielem 1000 zadań w poprzednim środowisku był użytkownik, którego nie ma w nowej domenie – już wiadomo po co mapować . Mapować można na kilka sposobów – kreator oferuje też możliwość auto-mapowania. I ten post jest właśnie omówieniem tych sposobów , które jak się okazuje wprowadziły w błąd niejednego administratora. Poniżej lista możliwych wyborów i ich wyjaśnienie:

Opcja 1 – Active Directory account name
Kreator zmapuje użytkowników na podstawie nazw kont w AD. Lepiej więc, żeby nazwy się zgadzały

Opcja 2 – Microsoft Dynamics CRM full name to Active Directory full name
Nazwy kont w ogóle nie muszą się zgadzać pomiędzy domenami. Wystarczy, że kreator będzie w stanie zmapować pełne nazwy użytowników w CRM to pełnych nazw w AD.

Opcja 3 – Prefix
Najdziwniejsza opcja – kreator zmapuje PO KOLEI użytkowników do JUŻ ISTNIEJĄCYCH w nowym środowisku kont o odpowiednio wybranej nazwie (np. “uzytkownik_”) i automatycznie inkrementowanym sufiksie. Jeśli więc chcemy, żeby właściciele rekordów np. Ala i Jaś zmienili się w “uzytkownik_01″ i “uzytkownik_02″, to wybierzmy tę opję. Wybranie tej opcji nie spowoduje, że kreator stworzy konta użytkowników w AD!

Opcja 4 – Use existing mapping file
ta opcja pozwoli nam użyć wcześniej stworzonego pliku XML z odpowiednimi mapowaniami użytkowników

Ważne:
1. Import Organization Wizard nigdy nie tworzy kont w Active Directory. Narzędzie pozwala jedynie mapować stare konta do nowych

2. Jeśli któreś konto nie da się automatycznie zmapować, nie ma strachu – kreator w następnym kroku pokaże błąd i da nam możliwość zmapowania pozostałych użytkowników.

Miłego przenoszenia!

- upgrade do wersji 4.0 jest możliwy tylko z wersji 3.0

- upgrade jest możliwy tylko w tym samym języku, tzn. jeśli Dynamics CRM 3.0 był po polsku, Base Language wersji 4.0 musi być polski

- upgrade należy rozpocząć od postawienia nowego środowiska, tzn. SQL Server 2005, wspierana wersja Windows 2003 lub 2008 itd.

- przed upgrade’m wskazane jest zrobienie kopii zapasowej baz Dynamics CRM, dostosowań i (koniecznie!) raportów!

- proces upgrade’u nie daje możliwości rollback’u, co w skrócie oznacza, że w przypadku niepowodzenia trzeba od nowa zainstalować Dynamics CRM 3.0 i przywrócić bazy danych i dostosowania.

- podczas upgrade’u nadpisane (czytaj “zniszczone”) zostaną wszystkie niewspierane dostosowania, czyli np. zmiany w plikach *.aspx, *.js

- upgrade serwera Dynamics CRM przeprowadza się, uruchamiając setup Dynamics CRM 4.0 na maszynie, na której zainstalowany jest Dynamics CRM 3.0

- upgrade klienta przeprowadza się, uruchamiając na każdej maszynie klienckiej setup klienta Dynamics CRM 4.0. Z mojego doświadczenia wynika, że lepiej jest odinstalować klienta Dynamics CRM 3.0 i dopiero później zainstalować od nowa klienta dla Dynamics CRM 4.0. Dzięki temu można proces zautomatyzować np. poprzez GPO

- przed upgrade’m klientów lepiej zsynchronizować dane posiadane offline

- upgrade klienta dla Outlook’a spowoduje zainstalowanie SQL Server 2005 Express Edition

- podczas upgrade’u setup utworzy nowy widok dla raportów Dynamics CRM 4.0 i zmieni wszystkie raporty z wersji 3.0 tak, żeby współpracowały z SSRS Data Connector’em

- podczas upgrade’u usunięte zostaną wszystkie nieopublikowane dostosowania

- oficjalnie, podczas upgrade’u instalator zaktualizuje wszystkie workflow’y do wersji 4.0 (poza tymi, które używają akcji “Post URL”

- jeśli używasz klienta mobilnego Dynamics CRM 3.0 (Dynamics CRM 3.0 Mobile Client), nie upgrade’uj systemu! W wersji 4.0 nie ma oficjalnego klienta na urządzenia mobilne, a stary klient nie będzie działał

Uff, sporo tego. Mam nadzieję, że powyższa lista przyda się Wam, jeśli planujecie przeprowadzić migrację Dynamics CRM 3.0 do 4.0. Oczywiście w życiu nie wszystko jest tak pięknie i może się zdarzyć, że większość Waszych przepływów pracy trzeba będzie przepisać, raporty nie będą działać, a użytkownicy po prostu nie będą mogli się logować .

Z doświadczenia wiem, że lepiej “postawić” cały system od nowa, niż przeprowadzać upgrade, który poprawnie zmigruje 80% funkcjonalności, a na pozostałe 20% spędzimy więcej czasu niż na instalację zupełnie nowego systemu.