Jak odinstalować IE8 Beta 2… kiedy sposoby ze stron zawodzą

Jak zwykle ciekawość skusiła mnie dziś do eksperymentu z IE8 Beta 2 :) . Ściągnąłem i przekonałem się, że rzeczywiście IE8 to spory krok do przodu (czyt. pojawiły się funkcje znane w Operze i Firefox’ie). Przeglądarka działa dużo szybciej, lepiej obsługuje CSS’y i ma sporo „bajerów”, które jeszcze nie raz będą reklamowane. Więc nie o tym będzie ten post… Będzie o tym, jak odinstalować IE8 Beta 2.
Spędziłem sporo czasu, żeby znaleźć sposób deinstalacji. Nie ma po prostu „uninstall IE8″. Jak się okazuje są 2 drogi pozbycia się Bety 2 z systemu. Od razu napiszę, że ta pierwsza „podstawowa”, o której piszą prawie wszyscy, nie działa na wszystkich maszynach – mi nie zadziałała na żadnym komputerze ;)

SPOSÓB 1 (popularny, niedziałający na 3 maszynach):

1. Wchodzimy do „Panelu sterowania”
2. Otwieramy „Programy i funkcje”
3. W zadaniach Wybieramy „Wyświetl zainstalowane aktualizacje”

4. Na liście znajdujemy Internet Explorer 8 i spokojnie klikamy „Odinstaluj”

SPOSÓB 2 (mniej popularny, ale działający):

1. Jeśli na liście aktualizacji nie ma Internet Explorer 8, to deinstalacja zaczyna się robić trudniejsza
2. Musimy za pomocą managera pakietów odinstalować pakiety instalacyjne IE8. W przypadku Visty, system przywróci nam po prostu IE7. Pakiety instalacyjne znajdują się w katalogu z Windows (u mnie C:\WINDOWS) w folderze „servicing\Packages”
3. Aby odinstalować pakiety za pomocą Managera Pakietów, musimy w linii poleceń wpisać:

FORFILES /P C:\WINDOWS\servicing\Packages /M Microsoft-Windows-InternetExplorer-8*.mum /c „cmd /c start /w pkgmgr /up:@fname /norestart”

Ostatni przełącznik „/norestart” jest opcjonalny, ale bez niego system będzie chciał się zrestartować po usunięciu pakietów. Ukończenie deinstalacji odbędzie się dopiero przy restarcie systemu.

PS. Nie odinstalowałem IE8 Beta 2 dlatego, że jest zły! Póki co nie działają niestety wszystkie add-on’y, których używam w codziennej pracy i dlatego ciągle wolę „siódemkę”. Ale IE8 zapowiada się naprawdę super!

Błędy w SDK 4.0.5

Aktualna wersja SDK dla Dynamics CRM to 4.0.5 z 30 maja 2008. Jest to wersja poprawiona, ale jak się okazuje – zawiera jeszcze sporo błędów :) . Mam na myśli błędy, które denerwują szczególnie, czyli fragmenty kodu, które rzekomo mają działać i dostarczają jakąś funkcjonalność, a najzwyczajniej w świecie nie działają…

Najwięcej błędów znajduje się we fragmentach kodu związanych jest z częścią systemu, która uległa zmianiom w wersji 4.0. W szczególności chodzi o obsługę DynamicEntity i różnych sposobów budowania kwerend do wywołania poszczególnych metod web service’u CrmService.asmx (np. ColumnSet, FilterExpression).

Jednym z przykładów błędnego kodu w SDK jest próba odwoływania się do właściwości obiektu klasy DynamicEntity poprzez Properties. W SDK mamy:

DynamicEntity entity = (DynamicEntity)retrieved.BusinessEntity;
string fullname;

for (int i = 0; i < entity.Properties.Length; i++)
{
if (entity.Properties[i].Name.ToLower() == „fullname”)

}

Ten kod w CRM 4.0 po prostu nie zadziała! Wynika to z faktu, że właściwość Properties jest teraz obiektem typu PropertyBag, więc np. nie ma właściwości Length, a Count. Dodatkowo nie można oczywiście odwoływać się do poszczególnych wartości w tej kolekcji poprzez indeksy liczbowe w pętli. Aby pobrać konkretne pole z encji, powinniśmy napisać:

if (entity.Properties.Contains(„fullname”))
{
fullName = entity.Properties["fullname"]; // a nie Properties[int i] !!!
}

Kolejne błędy znajdują się we fragmentach kodu opisujących np. dodawanie kolumn do zapytania, które chcemy wysłać web service’owi. SDK pokazuje w jednym z przykładów:

// Create a column set that holds the names of the columns to be retrieved
ColumnSet colsOrganization = new ColumnSet();
colsOrganization.Attributes = new string [] {„fullname”};

i znowu! Ten kod działał w CRM 3.0, ale nie zadziała w 4.0, jeśli użyjemy tak jak powinniśmy referencji do Microsoft.Crm.Sdk.dll :) Chyba, że „namieszamy” sobie w kodzie i dodamy „web reference” do web service’u oprócz referencji do wspomnianej DLL (czyniąc kod zupełnie nie-generycznym). Nie zadziała z tej prostej przyczyny, że w CRM 4.0 właściwość Attributes jest tylko do odczytu i zwraca listę ArrayList.
Prawidłowy kod dla CRM 4.0 to:

ColumnSet colsOrganization = new ColumnSet();
colsOrganization.AddColumn(„fullname”);



Niestety takich „nieścisłości” w SDK jest całkiem sporo… Jedyny sposób sprawdzenia, czy fragmenty kodu działają to ich uruchomienie. Nawet doświadczenie z wcześniejszymi wersjami CRM tu nie pomagają, a nawet chyba trochę szkodzą :) .

Dokument o synchronizacji Dynamics CRM z Outlook i pracy offline

Grupa Microsoft Dynamics CRM Engineering for Enterprise (E2) przygotowała dokument doskonale opisujący co dzieje się podczas synchronizacji danych między CRM’em i Outlook’iem. Dokument omawia proces replikacji podczas brania danych offline, pracy offline oraz synchronizacji powrotnej do serwera. White paper o tytule „Offline and Online Synchronization in Microsoft Dynamics CRM” można ściągnąć za darmo stąd: http://www.microsoft.com/downloads/details.aspx?FamilyID=c14ca8de-a452-4c9e-b4c9-1c0a51974528&displaylang=en

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

Instalacja Dynamics CRM for Outlook Client w domenie różnej od domeny serwera CRM

Dynamics CRM for Outlook Client to osobna aplikacja pozwalająca na integrację Dynamics CRM 4.0 z Microsoft Outlook. Pozwala ona na synchronizację wybranych danych z CRM’em oraz umożliwia pracę w CRM bez wychodzenia z Outlook’a. Istnieją dwie wersje klienta dla Outlook, tak jak opisane w tym poście: http://www.crmblog.pl/2008/07/dynamics-crm-for-outlook-online-vs.html.

Bardzo często zdarza się, że serwer CRM znajduje się w innej domenie niż użytkownicy uruchamiający Outlook’a. Wtedy, po zainstalowaniu Dynamics CRM for Outlook Client, próba konfiguracji tego narzędzia zakończy się błędem:
Dzieję się tak, ponieważ poświadczenia wysyłane do serwera, na którym znajduje się serwer CRM nie są zgodne z tymi, których potrzebne są do autoryzacji na serwerze CRM (prawidłowego użytkownika CRM). Ten błąd świadczy o tym, że w domenie, w której jest serwer CRM nie istnieje odpowiedni użytkownik. Nie zaś o tym, że nie ma go w systemie CRM!!! (CRM używa AD do autentykacji).
Ten błąd spowodował powstanie błędnej opinii, że Dynamics CRM for Outlook Client nie da się zainstalować, jeśli serwer z CRM’em jest w innej domenie niż komputery z Outlook’iem.
Jak się okazuje, nie jest to prawda. W tym poście pokażę trick, który pozwoli zainstalować klienta CRM dla Outlook nawet będąc w innej domenie. Należy pamiętać, że jeśli użytkownicy Outlook będą się łączyć z CRM przez internet (nie w intranecie), trzeba wybrać opcję „Dostawca usług online” w pierwszym kroku Kreatora Konfiguracji.
Kroki potrzebne do instalacji klienta dla Outlook w innej domenie:
1. Ponieważ Kreator Konfiguracji podczas próby połączenia z serwerem CRM wysyła poświadczenia osoby, która go uruchomiła, musimy mieć pewność, że istnieje w domenie serwera i systemie CRM konto o takiej samej nazwie. W tym celu (zakładając, że takiego konta nie ma), musimy dodać w domenie serwera CRM odpowiednie konto:

2. Następnie musimy mieć pewność, że utworzony użytkownik znajduje się w CRM’ie:

3. Teraz z dowolnego komputera spoza domeny, na którym chcemy zainstalować Klienta Dynamics CRM for Outlook, możemy uruchomić Kreator Konfiguracji. Pamiętać należy, że musimy być zalogowani na konto o takiej nazwie, którą ma użytkownik w systemie CRM (domena jest nieważna). Po spełnieniu tych warunków, Kreator Konfiguracji poprawnie łączy się do podanego serwera CRM (w innej domenie) i kończy konfigurację z sukcesem:

Błąd "Only items in the default Microsoft Outlook store can be promoted to Microsoft Dynamics CRM"

Ostatnio podczas próby śledzenia emaila przychodzącego w Outlook za pomocą funkcji „Śledź w programie CRM”, natknąłem się na błąd „Tylko elementy z domyślnego magazynu programu Microsoft Outlook mogą być awansowane do programu Microsoft Dynamics CRM” („Only items in the default Microsoft Outlook store can be promoted to Microsoft Dynamics CRM„):

Komunikat błędu jest dość oczywisty – informuje o tym, że email nie może być śledzony w CRM, ponieważ nie znajduje się w jednym z folderów podstawowych Outlook’a. Zacząłem się zastanawiać, co wobec tego zrobić, skoro używam konta pocztowego skonfigurowanego z IMAP, a nie POP3. Okazuje się, że jedyna opcja to ręcznie skopiować konkretny email do folderu z magazynu podstawowego, tj. np. „Skrzynka odbiorcza”:


…i dopiero z tego folderu można awansować (promować) email do CRM. To znaczy, że jest jedna super zaleta i jedna dość spora wada mechanizmu promocji emaili:

ZALETA: pozwala promować do CRM nawet emaile pochodzące z kont pocztowych obsługujących IMAP
WADA: niestety aby promować email trzeba zawsze ręcznie przenieść go do jednego z domyślnych folderów Outlook’a

Nie wiem jak Wy, ale ja to traktuje jednak w kategorii super zalety :) . Do emaili wychodzących używam CRM Email Router’a, a przychodzące śledzę za pomocą Dynamics CRM for Outlook. To umożliwia mi nie tylko wybieranie emaili do śledzenia, ale śledzenie również tych emaili, które pochodzą z innych kont (po przeniesieniu ich do odpowiedniego folderu…)

Egzamin MB2-632 – Microsoft Dynamics CRM 4.0 Applications

Zdałem :)
Ten post powinien jednak mieć tytuł „Beta egzaminu MB2-632″… O ile przy poprzednim egzaminie dziwił mnie fakt, iż niektórzy mówili, że egzamin jest niedopracowany, w przypadku egzaminu Microsoft Dynamics CRM 4.0 Applications można napisać otwarcie – egzamin nie tylko jest niedopracowany, ale jest czasami po prostu „żałośnie niedopracowany”.

Egzamin wyróżnia się spośród innych egzaminów dotyczących CRM 4.0. Nie tym, że jako jedyny obejmuje funkcjonalność Dynamics CRM. Raczej tym, że był pisany przez kogoś kto 1) nie zna systemu 2) nie zna angielskiego. Egzamin zaskakuje brakiem poprawnych odpowiedzi, pytaniami z jednym wyborem, które mają więcej niż jedną odpowiedź oraz błędami gramatycznymi.

Udało mi się zdać ten egzamin za pierwszym razem, ale mogę potwierdzić zdanie innych (spoza Polski), że egzamin jest po prostu nieporozumieniem. Pytanie o to „jak wysłać email z kampanii marketingowej”, które nie zawiera odpowiedzi, w której tworzymy campaign activity jest jednym z przykładów tego, że egzamin w ogóle chyba nie został sprawdzony przed udostępnieniem go w Prometric’u.

Nie zdziwcie się też, jak zobaczycie pytania, w których oczekiwane są 2 odpowiedzi, a są 3 prawidłowe… Albo jak zobaczycie pytanie z powtórzoną odpowiedzią… Albo jak zobaczycie odpowiedzi, które nijak się mają do funkcjonalności oferowanej przez system i realizacja zadania w pytaniu za pomocą podanych odpowiedzi jest „daleka od życia” i wskazuje na totalny brak doświadczenia osoby piszącej odpowiedzi…
Dodatkowo śmieszą błędy typu „you want to recording” (pisownia oryginalna) ;) , nie pozwalając się skupić na treści pytania.

Ogólnie, jak napisałem w komentarzach do egzaminu na jego końcu, ten egzamin to totalna porażka. Trochę boję się tego napisać… Ale mam nadzieję, że ten egzamin nie jest dowodem na to, że Microsoft zdecydował się na outsourcing tworzenia egzaminów do Indii…