• monitoruje serwer web CRM, czyli:
  • czy pula aplikacji działa?
  • czy da się pingować stronę
  • czy pula aplikacji przerwała działanie?
  • jakie są wywołania SOAP’owe
  • czy i jak często renderowane są raporty
• monitoruje proces asynchroniczny (asynchronous process), m.in.:
  • czy proces działa?
  • czy może wstać po restarcie?
  • czy nie ma problemów z odczytaniem bazy MSCRM_CONFIG i bazy organizacji
  • czy i jak często proces „pada”
  • czy Deletion Service działa i mógł odczytać dane do skasowania
  • czy ostatnie iteracja Deletion Service’u się udała
  • jak dużo operacji musi robić proces asynchroniczny i jak dużo operacji się udaje/nie udaje
  • jak dużo jest żądań synchronizacji offline i czy się udają/nie udają
  • jak dużo jest żądań synchronizacji książki adresowej i czy się udają/nie udają
• monitoruje warstwę platformy i wywołania usług sieciowych (web services), m.in.:
  • sprawdza wywołania CRM Discovery Service i dostęp do organizacji
  • jak dużo jest wywołań CrmService i czy się udają/nie udają
  • jak dużo jest wywołań MetadataService i czy się udają/nie udają
• monitoruje komponenty Reporting Services wykorzystywane przez Dynamics CRM, m.in.:
  • czy możliwe jest połączenie ze źródłami danych?
  • czy działają usługi Reporting Services?
  • czy nie ma za dużo żądań, które mogą sugerować atak DoS?
  • czy wystąpił błąd podczas renderowania raportów?
• monitoruje pozostałe komponenty Dynamics CRM, w tym bezpieczeństwo środowiska, m.in.:
  • jak często dane są brane z cache’a i jak często cache jest czyszczony
  • jakie błędy wystąpiły w kodzie plugin’ów
  • liczbę i wynik żądań uwierzytelniania i logowań użytkowników per organizacja
  • liczbę błędnych prób logowań i uwierzytelniania
  • liczbę błędnych żądań HTTP POST wysłanych przeciwko CRM’owi
  • liczbę odwołań do pliku Trace i błędów odczytu

Jak widać po powyższej liście, jeśli tylko ktoś ma SCOM’a, nie ma się co zastanawiać przed instalacją MP dla CRM’a. Nie widziałem jeszcze lepszych narzędzi, które monitorowałyby środowisko Dynamics CRM 4.0 w tak kompleksowy sposób. Microsoft, dobra robota!
Dynamics CRM 4.0 Management Pack dla SCOM’a jest do ściągnięcia stąd: http://www.microsoft.com/downloads/details.aspx?FamilyID=c2c9c4b6-69d5-432a-9560-8e4a6e01573a&displaylang=en. Miłych obserwacji!

Co to jest IFD?
IFD (Internet Facing Deployment) to nowy (pojawił się w wersji 4.0) model instalacji i konfiguracji Dynamics CRM 4.0. W tym modelu nie jest używana domyślna autentykacja domenowa (Windows Integrated), ale autentykacja oparta o formularze (Forms authentication). Scenariusz IFD stosuje się wtedy, kiedy do CRM użytkownicy chcą dostawać się przez internet, bez połączeń VPN.

Czym różni się wdrożenie z IFD od tego bez IFD?
Przede wszystkim Dynamics CRM 4.0 skonfigurowany jako Internet Facing Deployment (IFD) dostępny będzie dla użytkowników, którzy są poza domeną, w której jest zainstalowany CRM. CRM skonfigurowany jako IFD cechuje się następującymi zmianami:

• plik web.config zawiera informację o rodzaju autentykacji typu ServiceProviderLicenseAgreement oraz informację o szyfrowaniu klucza (dla CrmTicket authentication)
• rejestr na serwerze jest zmieniony i aktualizowany jest klucz IfdInternalNetworkAddress mówiący o tym, dla których użytkowników ma być używany który rodzaj autentykacji (tak naprawdę dla jakich adresów)
• tabela DeploymentProperties ma uzupełnione 3 nowe wartości zawierające dane o zewnętrznym adresie CRM

Jak poprawnie skonfigurować IFD?
Jeszcze niecałe 2 lata temu konfiguracja IFD opierała się o dostarczanie instalatorowi albo CRM’owi odpowiednich plików XML. Teraz całą konfigurację IFD można wykonać za pomocą narzędzia z graficznym interfejsem. Narzędzie, o którym mowa to CRM 4 IFD Tool dostępne tutaj: http://download.microsoft.com/download/4/e/f/4ef5f568-7320-4861-a947-47baf0966537/crm40ifdtool.zip.

1. Po uruchomieniu CRM 4 IFD Tool na serwerze wybieramy typ autentykacji na IFD + On Premise:

   

2. Pod spodem wpisujemy adresy i maski podsiecie, z których użytkownicy mają logować się „wewnętrznie”, tzn poprzez „normalne” logowanie domenowe:
   
3. W okienkach dotyczących IFD wpisujemy zewnętrzny adres CRM’a. Wpisujemy tu tylko domenę i ewentualnie port, bez nazwy organizacji! CRM odpowiednio doda nazwę organizacji w ramach domeny, którą wpiszemy. Oczywiście nie muszę chyba dodawać, że zalecany jest HTTPS…

   

4. Uzupełniamy wewnętrzny adres CRM’a (adres zostanie automatycznie wczytany z ustawień CRM’a):

   

5. Aplikujemy zmiany w IFD Tool („File” / „Apply changes”) i od tej pory mamy CRM’a, do którego użytkownicy dostający się z wewnątrz sieci będą się autentykować domenowo, a pozostali użytkownicy poprzez Forms’y.

Pamiętajcie o DNS’ach, otwarciu odpowiednich portów, a w przypadku SSL’a także o certyfikatach, żeby nie wkurzać użytkowników monitami o niepoprawnych certyfikatach…

• 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.

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

• .NET Framework 2.0,
• Application Error Reporting,
• Reporting Services Viewer Control
• Visual C++ Redistributable Package.

Część z nich możemy zainstalować samemu, uprzedzając tym samym instalatora. .NET Framework i Reporting Services Viewer Redistributable dostępne są tu: (odpowiednio: http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en i http://www.microsoft.com/downloads/details.aspx?FamilyID=8a166cac-758d-45c8-b637-dd7726e61367&DisplayLang=en). Application Error Reporting znajduje się na płycie z serwerem Dynamics CRM 4.0.

Problem jest natomiast z Visual C++ Redistributable Package. Niestety ten komponent nie „może”, ale „musi” być instalowany za każdym razem, kiedy jest uruchamiany instalator. Sytuacja ta jest o tyle dziwna, że instalator nie jest w stanie wykryć zainstalowanego wcześniej Visual C++ Redistributable Package, więc na nic nie przyda się instalowanie tego pakietu samemu.

Schody zaczynają się, kiedy komputer, na którym instalujemy CRM nie jest podłączony do internetu. Instalator zwyczajnie zatrzymuje się z błędem, bo nie jest w stanie ściągnąć pakietu. Czemu tak jest, nikt nie wie . Pewne jest tylko, że każdemu może się przecież zdarzyć instalacja bez dostępu do internetu.

Aby przeprowadzić instalację bez dostępu do internetu, powinniśmy ściągnąć pakiet stąd: http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&DisplayLang=en. Później zamiast go instalować, umieszczamy pliki w odpowiedniej strukturze folderów w głównym folderze instalacyjnym Dynamics CRM. Philip Richardson opisał ten proces na swoim blogu dokładniej, ja tylko pokażę gdzie jest miejsce dla plików instalacyjnych problemowego pakietu:

• \Redist\i386\VCRedist\vcredist_x86.exe
• \Redist\i386\VCRedist\vcredist_x64.exe
• \Redist\amd64\VCRedist\vcredist_x64.exe

(„Redist” na tym samym poziomie co foldery „Server” i „Client”)

Mam nadzieję, że przyda się komuś ta wiedza i dzięki temu uniknie kilkugodzinnej frustracji z każdorazowym ściąganiem Visual C++ Redistributable Package .