Po co nam SCOM Management Pack dla Dynamics CRM 4.0?

Jak pewnie wiecie, Microsoft wreszcie jakiś czas temu (niezbyt dawno) opublikował Dynamics CRM 4.0 Management Pack dla SCOM (System Center Operations Manager 2007). Dla tych szczęśliwców, którzy mają SCOM’a w firmie, może okazać się, że pack ten stanie się niezastąpiony odkąd przyjrzycie się bliżej, co nam daje.
I tak, Management Pack dla CRM’a oczywiście monitoruje serwer i ogólnie środowisko, w którym zainstalowany jest Dynamics CRM 4.0. Po instalacji okazuje się, że MP pilnuje naprawdę sporej liczby zdarzeń. Ten post opisuje znaczną część z nich. W szczególności Management Pack:

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

Internet Facing Deployment (IFD) – co to jest i jak skonfigurować CRM pod IFD?

Tak dużo osób ma problem z poprawną konfiguracją IFD, że postanowiłem ją wreszcie opisać. Dodatkowo postaram się wytłumaczyć w tym poście co jest czym w konfiguracji CRM’a przez internet. Mam nadzieję, że się przyda.

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…

Nowa wersja dokumentu o optymalizacji i wydajności Dynamics CRM

Wiem, wiem – powinienem już napisać o Rollup 5 (dziękuję za przypomnienie ;) ). Będzie o nim później, teraz bowiem czas napisać o czymś, co ukazało się jeszcze przed Update Rollup 5…
Kilka dni temu Sustaining Engineering Team (E2) wydał nową wersję Optimizing and Maintaining Microsoft Dynamics CRM 4.0. Dokument opisuje najlepsze praktyki mające na celu zwiększenie wydajności systemu Dynamics CRM w sporych środowiskach. Dodatkowo warto się czasem z nim zapoznać, bo zawiera informacje o optymalizacji rzeczy rzekomo niezwiązanych z CRM’em – poprawne ustawienia autentykacji w IIS, informacje o układzie dysków w serwerach CRM itd. White paper jest do ściągnięcia tutaj: https://www.microsoft.com/downloads/details.aspx?FamilyID=ba826cee-eddf-4d6e-842d-27fd654ed893&displayLang=en.

CRM 4.0 Implementation Guide v4.4.1

Coprawda minęło już trochę czasu od ukazania się najnowszej wersji Implementation Guide (4.4.1), ale warto o niej wspomnieć chociażby teraz. A to dlatego, że w najnowszym Implementation Guide mamy sporo nowości, m.in.:

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

    Microsoft Dynamics CRM 4.0 Implementation Guide
    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.

MTS 2008 ze strefy eksperta CRM, czyli jak zrobić migrację Dynamics CRM

Długo oczekiwana konferencja Microsoft Technology Summit 2008 już za nami… Moje wrażenia opiszę w innym poście. Póki co skupię się na roli, która pełniłem podczas MTS’u. Przez 2 dni miałem przyjemność pełnić rolę eksperta, a podsumowanie pierwszego dnia w poście niżej. Podobnie jak pierwszego dnia, drugi dzień obfitował w pytania o migrację z Dynamics CRM 3.0 do 4.0. Dlatego, wychodząc na przeciw zapotrzebowaniu, zdecydowałem się poniżej zebrać kilka odpowiedzi na pytania dotyczące migracji Dynamics CRM. Mam nadzieję, że się przydadzą :) .

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

HTTP 401: Brak autoryzacji podczas przeglądania raportów

Jeśli podczas próby generowania dowolnego raportu w Dynamics CRM zdarzy Wam się natrafić na błąd „Nie wykonano żądania ze stanem HTTP 401: Brak autoryzacji” nie wpadajcie w panikę! :) W CRM 3.0 seria kroków do naprawienia problemu była całkiem długa i wymagała sporo wiedzy (np. ustawienie delegacji na serwerach, ustawienie SPN itd). W CRM 4.0 natomiast, mamy Dynamics CRM Data Connector for Microsoft SQL Server Reporting Services! :) . Narzędzie to niweluje potrzebę podwójnej autentykacji (tzw. Kerberos double-hop) między serwerami.

Narzędzie znajduje się na płycie z Dynamics CRM 4.0. i musi być zainstalowane tuż po instalacji serwera CRM. Jego instalacja wprowadza kilka zmian w sposobie łączenia się z Reporting Services, dzięki czemu nie musimy już ręcznie ustawiać serwera CRM jako „zaufany dla delegacji”. Aby upewnić się, że CRM Data Connector for SSRS został poprawnie zainstalowany, należy na serwerze z Reporting Services otworzyć Report Managera (http://serwer/reports) i otworzyć folder z raportami systemu CRM – zazwyczaj „v4.0″. W tym folderze trzeba znaleźć źródło danych raportów CRM – zazwyczaj „MSCRM_DataSource”. Jeśli raporty są skonfigurowane prawidłowo po instalacji konektora, źródło danych będzie wyglądać jak poniżej:

Jeśli po instalacji konektora, dalej pojawia się błąd „Nie wykonano żądania ze stanem HTTP 401: Brak autoryzacji” („The request failed with HTTP status 401: Unauthorized”), nie zapomnijcie zrestartować serwera IIS, na którym zainstalowany jest CRM – to pomaga!!! :)

Instalacja Dynamics CRM offline i Visual C++ Redistributable Package

Instalator serwera Dynamics CRM 4.0 i klientów Dynamics CRM dla Outlook wymaga do swojego uruchomienia pewnych komponentów. Część z nich musi być zainstalowana i uruchomiona wcześniej (jak np. Usługa indeksująca – Indexing Service). Pozostała część może być zainstalowana przez instalator. Do tych drugich należą:

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