Zarządzanie zmianą w przypadku przejścia na usługi Software as a Service takie jak Office 365 może wymagać adaptacji tego procesu po stronie klienta. Celem tego artykułu jest przedstawienie, jakiego typu zmiany występują w Office 365 oraz w jaki sposób informujemy naszych klientów o planowanych zmianach. Dzięki tym informacjom klienci będą mogli zintegrować, gdzie jest to potrzebne, własny proces kontroli zmiany w organizacji ze zmianami wykonywanymi w platformie.

Pryncypia Office 365

„Office 365 is Evergreen” takie sformułowanie można często znaleźć na obcojęzycznych stronach dotyczących Office 365. Co to w praktyce oznacza? Pracując z Office 365 korzystamy zawsze z najnowszej wersji platformy. Office 365 jest każdego dnia uaktualniany o usprawnienia w działaniu lub nowe funkcjonalności.

Office 365 jest agnostyczny, jeśli chodzi o wersję. Pracując np. z Exchange Online możemy uzyskać informację o wersji organizacji, jednakże nie udostępniamy publicznie informacji, jakie usprawnienia oraz nowe funkcjonalności wprowadza dana wersja. Ponadto wersje organizacji Exchange Online mogą być różne dla każdej instancji (tenanta) Office 365.

Rodzaje zmian:

Zmiany wprowadzane w Office 365 możemy podzielić na 5 kategorii:

• Nowe funkcjonalności

• Zmiany w istniejących funkcjonalnościach

• Zmiany powodujące zakłócenia w działaniu usługi

• Zmiany konfiguracyjne

• Usprawnienia w platformie

Nowe funkcjonalności to zmiany wprowadzające nowe możliwości w usłudze np.: Data Loss Prevention w Sharepoint Online, czy MAPI/http w Exchange Online.

Zmiany w istniejącej funkcjonalności to rozszerzenia i rozbudowa istniejących parametrów usługi np.: zwiększenie quoty (limitów) dla OneDrive for Business, zwiększenie quoty (limitów) dla skrzynek współdzielonych w Exchange Online

Zmiany powodujące zakłócenia w działaniu usługi to bardziej znaczące zmiany, które wymagają dłuższego zaplanowania i wymagają podjęcia akcji po stronie klienta. Przykładem tego typu zmiany może być ograniczenie we wsparciu dla produktów, np.: wspieranie tylko najnowszej wersji przeglądarki dostępnej dla systemu operacyjnego od 12 stycznia 2016.

Zmiany konfiguracyjne to zmiany, które wymagają zaangażowania po stronie klienta, ale nie wymagają dłuższego planowania. Dotyczą zazwyczaj usprawnień w działaniu platformy np. zmiany wprowadzane w zakresach adresów IP wykorzystywanych przez Office 365

Usprawnienia w platformie, które poprawiają jej działanie, zwiększają bezpieczeństwo, wprowadzają usprawnienia wydajnościowe lub usuwają znane problemy w działaniu Office 365. Tego typu zmiany są zazwyczaj niewidoczne dla klientów.

W jaki sposób informujemy o zmianach.

Informacje o zmianach w Office 365 dostępne są w następujących miejscach:

• Wymagania systemowe dla Office 365 - http://technet.microsoft.com/pl-pl/library/office-365-system-requirements.aspx. Przedstawia wymagania dla platformy Office 365 w tym długoterminowe plany związane z wymaganiami, np. informacje o tym, że podstawowe wsparcie dla Office 2010 kończy się 13 października 2015, co w kontekście Office 365 oznacza, że nowe funkcjonalności pojawiające się na platformie chmurowej mogą nie być dostępne w Office 2010 po tej dacie.

• Office 365 blog - http://blogs.office.com/. Strona, uaktualniana codziennie, zawierająca informacje o wprowadzonych nowych funkcjonalnościach lub zmianach w istniejących funkcjach platformy

• Strony Kondycji usługi (Service Health) i Planowanej konserwacji (Planned Maintenance) w Portalu Office 365. Strony informują o incydentach i wykonywanych pracach, aby przywrócić elementy usługi do działania po wykrytej awarii. Strona Planowanej konserwacji informuje o przewidzianych pracach utrzymaniowych i ich konsekwencjach dla dostępności usługi.

• Centrum Wiadomości (Message Center) w Portalu Office 365. Zawiera m.in. notyfikacje o planowanych zmianach, które mogą powodować zakłócenia w działaniu usługi np.: wyłączenie wsparcia dla protokołu SSL 3.0.

• Publiczna mapa drogowa -  http://office.com/roadmap. Strona ta przedstawia wysoko poziomowe informacje o zmianach w funkcjonalności i nowych funkcjonalnościach. Nie umieszczamy na tej stronie wszystkich informacji o nowych funkcjonalnościach czy zmianach w konfiguracji, które planujemy wprowadzić do Office 365.

Rodzaje zmian, a kanały informacyjne

Gdzie szukać informacji o wybranym rodzaju zmian. Poniższa tabela powinna ułatwić poszukiwania informacji o zmianach.

Czy mogę wstrzymać wprowadzanie zmiany w Office 365?

Platforma Software as a Service, jaką jest Office 365 nie umożliwia wstrzymania na żądanie klienta wprowadzenia zmiany. Office 365 jest globalną usługą. Na raz z tych samych serwerów fizycznych korzysta wiele instancji Office 365. Ponad to, z uwagi na zobowiązania związane z prywatnością danych nie rejestrujemy, na których serwerach znajdują się w danej chwili skrzynki użytkowników należące do klienta, czy na których serwerach znajdują się strony Sharepoint. W związku z powyższym nie ma technicznych możliwości wstrzymania wprowadzania zmiany na prośbę klienta.

First Release

First Release jest programem, który umożliwia klientom uzyskanie wcześniej dostępu do niektórych nowych znaczących funkcjonalności niż zostaną one zainstalowane w środowiskach korzystających ze standardowego cyklu dystrybucji zmiany. Dołączenie do programu wykonywane jest dla całej instancji Office 365, a więc dotyczy zarówno Exchange Online, jaki Sharepoint Online.

First Release nie jest „Beta” programem. Klienci korzystający z First Release otrzymują takie samo wsparcie jak korzystających ze standardowego cyklu.

First Release nie jest narzędziem, które umożliwia opóźnianie instalacji nowych funkcjonalności. Jest programem, który umożliwia otrzymaniem nowych cech usługi w pierwszej kolejności.

Zmiany w First Release są wprowadzana minimum 2 tygodnie wcześniej niż w standardowych środowiskach. W przypadku wyłączenia trybu First Release w instancji Office 365 przez klienta, funkcjonalności, które nie są jeszcze dostępne w standardowych „tenantach” zostaną wycofane.

Podsumowanie

Istnieje kilka miejsc gdzie publikujemy informacje o zmianach planowanych w Office 365. Zalecam regularne śledzenie Centrum Wiadomości w portalu Office 365, aby być na bieżąco z wprowadzanymi zmianami, zwłaszcza tymi, które mają wpływ na dostępność usługi lub wymagają akcji administratora. Ta funkcjonalność będzie podlegała dalszym usprawnieniom. Informacji o zmianach w Centrum Wiadomości szukajcie na Mapie Drogowej Office 365.

Dział Microsoft Customer Service and Support (CSS) rozpoczął rekrutację na stanowisko SharePoint / Windows Core Support Engineer. Do głównych zadań pracownika będzie należeć m.in.:

• Zdalne rozwiązywanie technicznych problemów klientów Premier Support;

• Zapewnienie wysokiej jakości obsługi zgłoszeń oraz porad technicznych;

• Współpraca z innymi inżynierami pracującymi reaktywnie w obrębie danej technologii.

To stanowisko, to przede wszystkim szansa pracy w unikalnym środowisku, dostęp do bardzo głębokiej wiedzy technicznej oraz współpraca z ekspertami technologii Microsoft w Europie i na świecie. Genialna praca dla osób szanujących stacjonarny tryb pracy w Warszawie oraz preferujących specjalizowanie się w wybranych produktach Microsoft.

Więcej informacji na temat wymagań można znaleźć na: SharePoint / Windows Core Support Engineer, Warsaw, Poland @ careers.microsoft.com.

Natomiast specyfika prac wykonywanych dla klientów Premier Support oraz działu CSS została opisana w artykule: Microsoft Premier Support w Polsce.

Dotychczas za pomocą narzędzia synchronizacyjnego DirSync możliwe było synchronizowanie haseł z lokalnego Acitve Directory do Azure AD. (Opisałem ten proces w artykule Synchronizacja haseł do Office 365 deep dive). Co jednak, jeśli użytkownik zapomniał swoje hasło? Potrzebna była wtedy interwencja administratora, ponieważ użytkownik nie miał możliwości zresetowania hasła. Administrator resetował hasło, a DirSync synchronizował je do Office 365. Wsteczna synchronizacja haseł oraz portal Self-Service Password Reset rozwiązują ten problem. Postaram się obie funkcjonalności przybliżyć w poniższym artykule.

Jak to działa?

Aby móc skorzystać z opcji resetowania hasła użytkownik musi mieć przypisaną licencję Azure AD Premium. Po przypisaniu licencji, użytkownik może za pomocą strony (1) http://aka.ms/SSPRSetup skonfigurować, w jaki sposób chce potwierdzić swoją tożsamość w momencie resetowania hasła. Dostępne opcje to:

• odebrania połączenia telefonicznego (także w języku polskim),
• wpisanie kodu z wiadomości sms,
• wpisanie kodu z wiadomości email otrzymanej na alternatywny adres pocztowy.

Użytkownik po otworzeniu strony do resetowania hasła (2) (https://passwordreset.microsoftonline.com/) będzie musiał podać swój login oraz uwierzytelnić się za pomocą jednej z wcześniej skonfigurowanych metod. Po zakończonym powodzeniem uwierzytelnieniu, użytkownik będzie mógł wprowadzić nowe hasło (3), które zostanie zapisane w Azure AD. Następnie narzędzie synchronizacyjne Azure AD Sync skonfigurowane do synchronizacji wstecznej haseł, zreplikuje (4) hasło to lokalnego AD.

Nowe hasło, które wprowadzi użytkownik musi być zgodne z regułami złożoności zaimplementowanymi w lokalnym Active Directory.

Co musi zrobić administrator, aby wdrożyć tę funkcjonalność?

Proces uruchamiania funkcjonalności Self-Service Password Reset został bardzo dobrze opisany na poniższej stronie: http://msdn.microsoft.com/en-us/library/azure/dn683881.aspx

Ważne, aby konto administratora włączającego portal Self-Service Password Reset:

• posiadało przypisaną licencję Azure AD Premium,
• było kontem chmurowym (założonym w Azure AD), a nie kontem sfederowanym z lokalnego AD (konto typu Microsoft Account używane do zarządzania tenantem Azure również nie jest odpowiednie).

Warto pamiętać, że narzędzie Azure AD Sync synchronizuje również hasła z lokalnego AD do Azure AD, a więc zapewnia funkcjonalność dostępną dotąd dzięki DirSync.

Jak działa proces synchronizacji wstecznej haseł?

Synchronizacja wsteczna haseł korzysta z technologii Azure Service Bus. Silnik synchronizacyjny wbudowany w narzędzie Azure AD Sync podtrzymuje komunikację z Azure AD. Z punktu widzenia firewall’a, połączenie jest nawiązywane z serwera Azure AD Sync do Azure AD. Do komunikacji wykorzystywane są porty 9350-9353. Jednakże, gdy są zamknięte, synchronizacja odbywa się na porcie 80. Po zresetowaniu przez użytkownika hasła jest ono przesyłane w postaci jawnej do lokalnego AD, aby sprawdzić czy spełnia wymagania, co do złożoności. Jeśli hasło jest zgodne z wymaganiami, zostanie zapisane w lokalnym AD. Mimo, że komunikacja odbywa się na porcie 80, jest ona zaszyfrowana mechanizmami, które dostarcza Azure Service Bus.

Po wykonaniu kilku testów mogę stwierdzić, że po zresetowaniu, hasło jest synchronizowane do lokalnego AD w przeciągu około 1 minuty.

Podsumowanie

Azure AD Premium otwiera nowe możliwości związane z zarządzaniem AD „w chmurze”. Ponadto dzięki nowemu narzędziu synchronizacyjnemu: Azure AD Sync, integracja między lokalną infrastrukturą AD, a Azure AD jest jeszcze pełniejsza. Wkrótce Azure AD Sync będzie dostarczał kolejnych nowych funkcjonalności. Stay tuned!

Kilka dni temu, dział Microsoft Customer Service and Support (CSS) rozpoczął w Polsce rekrutację na stanowisko Premier Field Engineer (PFE). Osoba pracująca w tej roli będzie zajmowała się głównie świadczeniem wsparcia dotyczącego produktów SharePoint Server oraz usługi SharePoint Online w Office 365. Więcej o tym, jak wygląda praca inżyniera PFE można znaleźć w artykule: Microsoft Premier Support w Polsce.

Osoby mające duże doświadczenie w pracy z: SharePoint, IIS oraz ASP.NET, zachęcamy do aplikowania. Mile widziana jest praktyczna wiedza z zakresu budowy rozwiązań i programowania na platformie SharePoint.

Więcej informacji na temat otwartej rekrutacji można przeczytać na Microsoft Careers pod tym adresem: https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=1&jid=163939&jlang=en&pp=ss

Zapraszamy!

Czy chciałbyś, aby Microsoft za darmo pomógł Ci wykonać migrację do Office’a 365? Od 1 września 2014 możesz skorzystać z nowych programów, które znacznie ułatwią ten proces:

• FastTrack – usługa polegająca na przygotowaniu środowiska do migracji bądź integracji środowiska lokalnego z chmurą Microsoft
• oraz ograniczona czasowo (do końca marca 2015) Adoption Offer polegająca na pomocy we wdrożeniu i rozpoczęciu pracy w nowym środowisku

FastTrack

Od 1 września klient ma możliwość skorzystania z usługi o nazwie „FastTrack” kupując minimum 150 licencji Office 365 z poniższych planów:

• Office 365 Enterprise plans (E1, E3, E4, G1, G3, G4),
• Exchange Online standalone (P1 i P2),
• O365 ProPlus SKU,
• SharePoint Online standalone SKUs,
• Lync Online standalone SKUs,
• OneDrive Standalone SKUs.

„FastTrack” polega na bezpłatnej, zdalnej pomocy wykwalifikowanych inżynierów Microsoft w przygotowaniu Office’a 365, a także środowiska lokalnego do migracji do chmury. Sama migracja danych nie jest częścią „FastTracka”.

Office 365 Adoption Offer

Oprócz asysty w przygotowaniu środowiska, Microsoft oferuje od 1 września „Office 365 Adoption Offer”. Jest to oferta skierowana do nowych klientów kupujących przynajmniej 150 licencji w planach:

• Office 365 Enterprise plans (E1, E3, E4),
• Płatnych planach edukacyjnych Office 365 Education plans (A3, A4),
• Office 365 Government plans (G1, G3, G4),
• Exchange Online standalone (P1, P2).

“Office 365 Adoption Offer” umożliwia migrację skrzynek pocztowych do Exchange Online w jednej z dwóch opcji:

1. Opcja 1. Wykonanie migracji poczty elektronicznej do Exchange Online przez specjalistów z Microsoft Onboarding Center (MOC). Migracja może być wykonana zarówno z Exchange On-Premises, Lotus Notes, a także z systemów pocztowych firmy trzeciej. Microsoft Onboarding Center nie tylko wspomaga klienta przy migracji zawartości skrzynek, ale także przy stworzeniu konfiguracji Hybrydowej dla Exchange. Migrowanych jest tyle skrzynek, ile klient zakupił licencji.  Skrzynki muszą znajdować się w jednym lesie AD.

Migracja nie obejmuje migracji folderów publicznych i archiwów. W przypadku migracji z Lotus Notes migrowane są wiadomości z ostatnich 30 dni oraz wpisy z kalendarza z ostatnich 14 dni.

1. Opcja 2. Zamiast wsparcia ze strony MOC, klient może otrzymać voucher na sfinansowanie czynności migracyjnych do Exchange Online, a także OneDrive i Sharepoint w wysokości:

• $15 per licencja dla 150 – 1000 licencji,
• $5 per licencja dla powyżej 1000 licencji (maksymalna kwota wsparcia dla jednego klienta to $60k).

Przykład: kupując 3000 licencji E1, klient otrzyma 15000$+(5$*2000)=25000$ wsparcia!

Klient może wykorzystać voucher na sfinansowanie działań wykonanych przez Partnera, MCS (Microsoft Consulting Services) lub Premier Support związanych z migracją.  Otrzymane wsparcie może być przeznaczone na migrację danych, rozwiązania problemów post-migracyjnych, a także rozszerzenie funkcjonalności.

Oferta Office 365 Adoption Offer jest ograniczona czasowo. W przypadku posiadania umowy wsparcia Premier, zachęcamy do kontaktu z Technical Account Managerem, aby porozmawiać na temat naszych usług zapewniających szybką i bezproblemową migrację do Office’a 365.

Jak zainstalować Office 365 ProPlus Click-to-Run na komputerze używanym przez wielu użytkowników? To pytanie zadawali sobie administratorzy w wielu przedsiębiorstwach. Ostatnio pojawiło się rozwiązanie tego problemu.

Od 1 września istnieje możliwość aktywowania Office 365 ProPlus Click-to-Run na komputerach współdzielonych np. na serwerze terminalowym. Dzięki tej funkcjonalności każdy z użytkowników logujących się na takiej stacji będzie mógł aktywować pakiet Office używając własnej licencji.

Aby zainstalować Office 365 ProPlus w trybie współdzielonym należy do pliku konfiguracyjnego (wywoływanego przy uruchomieniu Office Deployment Tool) dodać wpis:

<Property Name="SharedComputerLicensing" Value="1" />

Gdy Office 365 ProPlus zostanie zainstalowany w trybie współdzielonym, każdy logujący się na stacji użytkownik będzie musiał podać swoje poświadczenia, aby aktywować dla siebie pakiet Office. W przypadku, gdy organizacja korzysta z serwerów AD FS, uwierzytelnianie na platformie aktywacyjnej odbędzie się w sposób zintegrowanym. Przy następnym logowaniu na tej samej stacji przez tego użytkownika, podanie poświadczeń nie będzie potrzebne nawet, jeśli w między czasie na stacji logował się inny użytkownik i aktywował pakiet Office używając swojego konta. Ponadto aktywacja Office 365 ProPlus na stacji współdzielonej nie będzie zużywać jednej z 5 aktywacji, jakie posiada użytkownik z przypisaną licencją na Office 365 ProPlus.

Jeśli użytkownik przez kilka dni nie będzie logował się na stacji, to jego token użyty do aktywacji pakietu Office wygaśnie. W związku z tym, gdy użytkownik zaloguje się na stacji po kilku dniach przerwy i uruchomi aplikację pakietu Office, będzie musiał ponownie podać poświadczenia, aby aktywować pakiet Office (w przypadku wykorzystanie AD FS uwierzytelnianie będzie zintegrowane). Nie jest dokładnie określone po ilu dniach token wygaśnie, gdyż okres ten może być różny dla każdego z użytkowników.

Dodatkowe informacje o instalacji Office 365 ProPlus Click-to-Run w trybie współdzielonym dostępne są tutaj: http://technet.microsoft.com/en-us/library/dn782860(v=office.15).aspx

Parafrazując Fredrę czasami wśród naszych klientów zdarza się ciekawe łączenie technologii. Jedną z ciekawszych i coraz szerzej stosowanych jest FSRM - File Server Resource Manager.  Pozwala on na zaawansowane zarządzanie serwerami plików. M.in. limity folderów (quota) oraz filtrowanie plików (File Screening)

W Server 2003R2 oprócz FSRM pojawił się nowy mechanizm replikacji plikowej DFSR (Distributed File System Replication). Daje on szybki, odporny na awarie, oszczędzający łącze sposób synchronizacji plików pomiędzy serwerami.

Szybka powtórka z mechaniki działania DFSR:

• Usługa wykrywa, że plik lub folder w replikowanej ścieżce się zmienił (poprzez subskrypcje NTFS USN Journal)
• Rozpoczyna proces nazywany marshalling (liczenie sumy kontrolnej i ewentualne dzielenie na kawałki wielkości 64k)
• Plik trafia do staging folder i tam czeka aż partnerzy replikacyjni go pobiorą
• Zachodzi replikacja właściwa pomiędzy staging folderami
• Na drugim serwerze plik zostaje „wyciągnięty” ze staging folderu i „złożony” w całość w tymczasowym folderze „Installing”
• Z „Installing” zostaje wkopiowany do docelowej ścieżki

Interesująca rzecz pojawią się, gdy połączymy DFSR i FSRM ze sobą. Kilka lat temu pojawił się artykuł KB w trybie „rapid publishing”, którey odrobinę omawia ten scenariusz http://support.microsoft.com/kb/959210 DFSR may not operate correctly when used in conjunction with FSRM file screens

I teraz mamy dwa przypadki:

1. Quoty na folderach
2. File screening

Oba mogą powodować problem tylko w przypadku, gdy ustawienia FSRM na węzłach replikacyjnych są niespójne. Mianowicie:

Ad. 1. Na węźle źródłowym folder może zajmować 2GB. Na docelowym 1GB. Plik przechodzący po linku replikacyjnym może bez problemu istnieć na pierwszym serwerze, ale przechodząc z Installing do ścieżki docelowej NTFS (a właściwie filter driver FSRM pod NTFS) zwróci błąd o niewystarczającej ilości miejsca na dysku.

Najgorsze w całej sytuacji jest to, że jeśli takich plików/zadań replikacyjnych będzie więcej niż 16, to może nam to „zakorkować” replikację całkowicie (UpdateWorkerThreadCount), ponieważ usługa będzie stale ponawiała próby przesłania danych.

Ad. 2. Podobnie ma się sytuacja z Filtrowaniem plików. Na serwerze źródłowym pozwalamy na pliki konkretnego typu (na przykład *.mp3) z kolei na docelowym już niekoniecznie. Tu plik wychodząc z „installing” dostanie od NTFS „Access Denied (5)”.

Podsumowując. DFSR i FSRM mogą działać wspólnie. Ale wtedy i tylko wtedy, gdy ustawienia FSRM są spójne na WSZYSTKICH węzłach replikacyjnych. W przeciwnym przypadku DFSR może przestać działać całkowicie.

PS. Na czas początkowej synchronizacji (InitSync) zalecamy wyłączenie FSRM całkowicie i zastosowanie ustawień dopiero po ustabilizowaniu się infrastruktury.

Śledzenie wiadomości, weryfikowanie czy dotarła ona do adresata oraz upewnienie się czy wiadomość była przesłana drogą taką, jaką się spodziewamy może okazać się niełatwym zadaniem. Gdy wiadomość dotrze już do adresata, z nagłówka wiadomości możemy dowiedzieć się, jaką drogę przebyła. Często są jednak sytuacje, że nie mamy możliwości odczytać wiadomości dostarczonej do adresata i chcemy „wyśledzić” naszą wiadomość.

W systemie Microsoft Exchange 2013 możemy posłużyć się poleceniami Exchange Management Shell (EMS) i uzyskać informacje dotyczące trasy naszej wiadomości. W artykule tym opiszę jak odczytywać logi transportowe za pomocą EMS w systemie Microsoft Exchange 2013 oraz przedstawię krótko alternatywne sposoby odczytywania trasy naszej wiadomości. Przesyłanie wiadomości w systemie Microsoft Exchange 2013 zostało zmodyfikowane i jak wiadomo nie ma już serwera z rolą HUB Transport (jak w przypadku Microsoft Exchange 2007/2010). Odpowiedzialność za przesyłanie wiadomości znajduje się w usługach znajdujących się na serwerze z rolą Mailbox: Transport Service, Mailbox Transport Submission Service oraz Mailbox Transport Delivery Service. Więcej informacji o przesyłaniu wiadomości w systemie Microsoft Exchange 2013 można znaleźć tutaj: Mail Flow

Pobieranie danych z logów transportowych

Pierwszym krokiem jest wykonanie odpowiedniego zapytania w EMS. Jeśli wiemy, kto był nadawcą wiadomości, a kto odbiorcą wykonujemy poniższe zapytanie:

Get-TransportService | Get-MessageTrackingLog -Sender user.01@fcit.pl -Recipients user.21@fcit.pl | Sort TimeStamp | ft EventId,Source,serverHostName,clientHostname,timestamp -AutoSize

 W wyniku tego zapytania otrzymujemy wynik:

Na pierwszy rzut oka widać, iż nasza wiadomość była na trzech serwerach. Jednak to, co się z nią działo na poszczególnych serwerach, przez jakie usługi transportowe na nich przechodziła, możemy odczytać za pomocą dwóch kolumn: EventID (Zdarzenie) oraz Source (Źródło). Aby ułatwić odczytanie tych informacji, poniżej przedstawiam opis najczęstszych zdarzeń oraz źródeł tych zdarzeń. Na tej podstawie możemy dowiedzieć się o trasie naszej wiadomości.

Odczytywanie informacji o przepływie wiadomości

Teraz omówimy sobie zdarzenia, jakie dotyczyły przesłanej przykładowej wiadomości. Prześledźmy, zatem wynik naszego zapytania i posługując się powyższymi tabelkami omówimy, co się działo w każdym z wierszy. Dla czytelności dodałem nr wierszy do naszego logu.

• W wierszu nr 1 mamy zdarzenie RECEIVE, a źródłem jest STOREDRIVER. To nam mówi, iż wiadomość została dostarczona ze skrzynki pocztowej do usługi Mailbox Transport Submission Service znajdującej się na serwerze DortmundEXA01. Komunikacja ta odbyła się w obrębie tego samego serwera.
• W wierszu nr 2 mamy zdarzenie HAREDIRECTFAIL, co oznacza, iż nastąpiła próba wygenerowania wiadomości redundantnej na serwerze MilanEXM01 zakończona niepowodzeniem.
• W wierszu nr 3 mamy zdarzenie RECEIVE, a źródłem jest SMTP. Oznacza to, iż wiadomość została odebrana przez komponent SMTP Receive usługi Transport Service.  Serwerem wysyłającym (klient) był serwer DortmundEXA01, a serwerem odbierającym (serwer) był serwer MilanEXM01.
• Wiersz nr 4 posiada zdarzenie SUBMIT, a jego źródłem jest STOREDRIVER. Z tabel zawierających opisy zdarzeń odczytujemy, iż usługa Mailbox Transport Submission Service dostarczyła z sukcesem wiadomość do usługi Transport Service. Serwerem wysyłającym (klient) był serwer DortmundEXA01, a serwerem odbierającym (serwer) był serwer MilanEXM01.

Zatrzymajmy się tutaj na chwilę. Wiersz nr 3 i wiersz nr 4, tak naprawdę opisuje nam to samo zdarzenie, jednakże zarejestrowane przez dwie usługi (wysyłającą i odbierającą) na dwóch różnych serwerach. Oba mówią nam o dostarczeniu wiadomości od usługi Mailbox Transport Submission Service na serwerze DortmundEXA01 do usługi Transport Service na serwerze MilanEXM01.

• Wiersz nr 5 zawiera zdarzenie AGENTINFO, co może wskazywać na procesowanie reguł transportowych dla tej wiadomości lub skanowanie przez Malware Filter Agent na serwerze MilanEXM01.
• W wierszu nr 6 mamy zdarzenie HAREDIRECTFAIL, co oznacza, iż nastąpiła próba wygenerowania wiadomości redundantnej na serwerze LondonEXA01 zakończona niepowodzeniem.
• Wiersz nr 7 zawiera zdarzenie RECEIVE, a źródłem jest SMTP. Oznacza to, iż wiadomość została odebrana przez komponent SMTP Receive usługi Transport Service.  Serwerem wysyłającym (klient) był serwer MilanEXM01, a serwerem odbierającym (serwer) był serwer LondonEXA01.
• Wiersz nr 8 zawiera zdarzenie SEND, a źródłem jest SMTP. To z kolei oznacza, że wiadomość została wysłana za pomocą protokołu SMTP pomiędzy usługami transportowymi. Serwerem wysyłającym (klient) był serwer MilanEXM01, a serwerem odbierającym (serwer) był serwer LondonEXA01.

Znów zatrzymajmy się na chwilę. Wiersz nr 7 i 8 opisuje nam to samo zdarzenie zarejestrowane przez dwie różne usługi transportowe na dwóch różnych serwerach. Jedna mówi o wysłaniu wiadomości (wiersz nr 8), a druga o odebraniu tej samej wiadomości (wiersz nr 7). Ponieważ z poprzednich zdarzeń wiedzieliśmy, iż wiadomość znajdowała się w usłudze Transport Service na serwerze MilanEXM01, to wiersz nr 7 i 8 mówi nam o przesłaniu wiadomości pomiędzy usługą Transport Service na serwerze MilanEXM01, a usługą Transport Service na serwerze LondonEXA01.

• Wiersz nr 9 zawiera zdarzenie AGENTINFO, co może wskazywać na skanowanie wiadomości przez Malware Filter Agent na serwerze LondonEXA01.
• Wiersz nr 10 zawiera zdarzenie DELIVER, a źródłem jest STOREDRIVER. Z naszych tabel wynika, że w takim przypadku wiadomość została dostarczona do skrzynki pocztowej odbiorcy. Usługą odpowiedzialną za dostarczenie wiadomości do skrzynki jest usługa Mailbox Transport Delivery Service.
• Wierz nr 11 posiada zdarzenie SEND, a źródłem jest SMTP. To oznacza, że wiadomość została wysłana za pomocą protokołu SMTP pomiędzy usługami transportowymi. Serwerem wysyłającym (klient) był serwer LondonEXA01, a serwerem odbierającym (serwer) był także serwer LondonEXA01. Z poprzednich zdarzeń wiedzieliśmy, ze wiadomość została dostarczona do usługi Transport Service na serwerze LondonEXA01, wiec zdarzenie SEND w tym przypadku mówi nam o wysłaniu wiadomości od usługi Transport Service do usługi Mailbox Transport Delivery Service.

Poniżej znajduje się zobrazowanie trasy wiadomości, gdzie cyfry odpowiadają nr wierszy z naszego zapytania pobrane z logów na odpowiednich serwerach. 

Podsumujmy, zatem gdzie po kolei znajdowała się nasza wiadomość.:

1. Wiadomość została wysłana ze skrzynki znajdującej się na serwerze DortmundEXA01

2. Wiadomość znajdowała się w usłudze Mailbox Transport Submission Service na serwerze DortmundEXA01

3. Następnie wiadomość znajdowała się w usłudze Transport Service na serwerze MilanEXM01.

4. Potem wiadomość znajdowała się w usłudze Transport Service na serwerze LondonEXA01.

5. Później wiadomość znajdowała się w usłudze Mailbox Transport Delivery Service na serwerze LondonEXA01.

6. Następnie wiadomość została dostarczona do skrzynki na serwerze LondonEXA01.

Korzystanie z Delivery Reports

Szybszym i łatwiejszym sposobem do śledzenia naszej wiadomości jest skorzystanie z Delivery Reports (Raporty doręczeń). Jest to narzędzie śledzenia wiadomości znajdujące się w konsoli Exchange Administration Center (EAC). Można go użyć do wyszukiwania i śledzenia statusu przepływu wiadomości e-mail wysyłanych do lub od użytkowników znajdujących się w GAL, z pewnym zastrzeżeniem. Można śledzić informacje dotyczące wiadomości wysyłanych przez lub otrzymanych od konkretnej skrzynki pocztowej w organizacji. Więcej informacji na temat Delivery Reports znajdziesz tutaj: Track messages with delivery reports.

Korzystając Delivery Reports dla naszej wiadomości dostajemy poniższą informację:

Delivery Report for User 21

Submitted

1/3/2014 2:45 PM DORTMUNDEXA01

The message was submitted to dortmundexa01.fc.local.

1/3/2014 2:45 PM dortmundexa01.fc.local

The message has been transferred from dortmundexa01.fc.local to MILANEXA01.fc.local.

1/3/2014 2:45 PM milanexa01.fc.local

Message was received by milanexa01.fc.local from DORTMUNDEXA01.fc.local.

1/3/2014 2:45 PM milanexa01.fc.local

The message has been transferred from milanexa01.fc.local to LONDONEXA01.fc.local.

1/3/2014 2:45 PM londonexa01.fc.local

Message was received by londonexa01.fc.local from MILANEXA01.fc.local.

1/3/2014 2:45 PM londonexa01.fc.local

The message has been transferred from londonexa01.fc.local to LONDONEXA01.fc.local.

Delivered

1/3/2014 2:45 PM londonexa01.fc.local

The message was successfully delivered.

Odczytanie trasy wiadomości z nagłówka

Informację, przez jakie serwery przechodziła nasza wiadomość można także odczytać z nagłówka odebranej wiadomości oraz analizatora wiadomości znajdującego się na stronie https://testconnectivity.microsoft.com/. Analizując nagłówek tej samej wiadomości dostajemy wynik:

Przeskok nr 4 mówi nam o przesłaniu wiadomości pomiędzy usługą Transport Service a usługą Mailbox Transport Delivery Service znajdujących się na tym samym serwerze.

Podsumowanie

Jak widać mamy kilka sposobów na sprawdzenie, w jaki sposób nasza wiadomości dotarła od nadawcy do adresata. Najszybszym i chyba najłatwiejszym sposobem jest wykorzystanie funkcjonalności Delivery Report zawartej w konsoli Exchange Admin Center. Jednakże, jeśli chcemy uzyskać szczegółowe informacje dotyczące wszelkich zdarzeń, jakie miały miejsce podczas przesyłania wiadomości (np. użycie Agentów Transportowych, poprawne lub niepoprawne wygenerowanie wiadomości redundantnych), wówczas należy skorzystać z Exchange Management Shell. Dodatkowo, jeśli chcemy prześledzić lub znaleźć informacje o wiadomościach wysyłanych od/do naszej organizacji gdzie nadawcą lub odbiorcą była osoba z poza GAL wówczas także będziemy zmuszeni do skorzystania z Exchange Management Shell.

Jesteś specjalistą zajmującym się bezpieczeństwem systemów informatycznych i szukasz nowych wyzwań? Rekrutujemy!

Dział Microsoft Global Business Support (GBS) poszukuje kandydatów na stanowisko Premier Field Engineer – Security. Wymagana jest wiedza i doświadczenie w zakresie bezpieczeństwa systemów IT opartych o technologie oraz produkty Microsoft. Gwarantujemy bardzo ciekawą i pełną wyzwań pracę dla największych firm w Polsce oraz Europie.

Więcej o usługach dostarczanych przez inżynierów naszego działu można znaleźć tutaj: Microsoft Premier Support w Polsce.

Szczegóły dotyczące oferty opublikowano na Microsoft Careers: PFE Security.

W pierwszej części artykułu opisałem najważniejsze cechy pakietu Office 365 ProPlus oraz sposoby przeprowadzania instalacji. W drugiej części przedstawię warianty uaktualniania Office 365 ProPlus. Artykuł ten jest istotny, ponieważ proces aktualizacji różni się od tych dostępnych dla klasycznego Office 2013 Professional Plus.

Jakie są sposoby aktualizacji pakietu Office 365 ProPlus? Dostępne są 3 warianty instalowania update’ów:

1. Automatycznie z „chmury”.

2. Automatycznie z lokalnej sieci.

3. Reinstalacja pakietu Office z centrum dystrybucji paczek.

Zanim przyjrzymy się dokładniej każdej z możliwości, należy zauważyć, że decyzję o sposobie uaktualniania pakietu Office należy podjąć podczas instalacji Office 365 ProPlus odpowiednio konfigurując plik Configuration.xml

Automatycznie z „chmury”

To jest domyślny sposób uaktualniania w przypadku, gdy użytkownik sam pobrał i zainstalował pakiet Office 365 ProPlus przez portal Office 365. Uaktualnienia do pakietu Office 365 ProPlus, będą pobierane przez Internet, z punktu dystrybucyjnego znajdującego się w Office 365 zwanego: Content Delivery Network (CDN).

Tę opcję uaktualniania można też wdrożyć, dodając w pliku Conifguration.xml następujący klucz:

<Updates Enabled="TRUE"  />

Lub

<Updates Enabled="TRUE" UpdatePath="" />

Automatycznie z sieci lokalnej

W tym wariancie pobierania update’ów, poprawki będą pobrane przez klientów ze zdefiniowanego lokalnego punktu dystrybucyjnego zamiast z Internetu.  Administrator musi wcześniej pobrać uaktualnienia, za pomocą narzędzia Office Deployment Tool (ODT) i umieścić je w lokalnym punkcie dystrybucji.

Miejsce, z którego klienci będą pobierać update’y wskazujemy za pomocą ścieżki UNC lub HTTP, w pliku konfiguracyjnym użytym przy instalacji.

Tę możliwość uaktualniania można wdrożyć konfigurując plik Conifguration.xml z następującym kluczem:

<Updates Enabled="TRUE" UpdatePath="\\Server01\Office\" />

Reinstalacja pakietu Office z centrum dystrybucji paczek.

W przypadku tej opcji, poprawki nie będą automatycznie pobierane przez pakiet Office. Aby uruchomić proces aktualizacji, należy ponownie uruchomić narzędzie ODT (setup.exe /CONFIGURE Configuration.xml), które wymusi reinstalację pakietu Office. Nie spowoduje to jednak pobrania pełnego pakietu Office na stację kliencką. Proces wykryje, jakie pliki wymagają uaktualnienia i pobierze tylko te niezbędne do aktualizacji Office’a.

Wariant aktualizacji poprzez reinstalację, jako jedyny, integruje się z oprogramowaniem do zarządzenia aplikacjami, np. System Center Configuration Manager. Ponadto tylko w tym wariancie, to administrator decyduje, kiedy będą instalowane uaktualnienia. Jednakże minusem tej opcji, jest to, że reinstalacja nie rozpocznie się, jeśli użytkownik ma otwarte aplikacje pakietu Office i nie zamknie ich, gdy pojawi się proszący o to komunikat. Obejściem tego problemu jest ustawienie w pliku Configuration.xml klucza FORCEAPPSHUTDOWN="TRUE" jednakże spowoduje on wymuszenie zamknięcia aplikacji Office bez możliwości zapisania danych.

Aby wdrożyć tę opcję uaktualniania w pliku Conifguration.xml należy stworzyć następujący wpis:

<Updates Enabled="FALSE" />

Jak działa proces uaktualniania?

Poniższy opis ma zastosowanie, gdy opcja automatycznego pobierania uaktualnień jest włączona (Updates Enabled="TRUE"). Proces update’owania jest inicjowany przez Scheduled Task, utworzony podczas instalacji Office 365 ProPlus o nazwie: „Office Automatic Updates”

To zaplanowane zadanie pracuje w kontekście konta Local System. Uruchamia się o 3:00 rano + random offset w niedzielę, wtorek i piątek oraz po zalogowaniu użytkownika co 30 minut przez okres 1 godziny. Następnie proces wygląda tak:

1. Proces sprawdza, czy w zdefiniowanym miejscu (w chmurze lub lokalnym punkcie) dostępne są nowe poprawki, porównując je z bieżącą wersją pakietu Office

2. Jeśli nie ma nowych poprawek, proces sprawdza czy na stacji są już pobane poprawki, które czekają na zaaplikowanie. Sprawdzony zostanie, czy klucz rejestru istnieje i czy ma inną wartość niż „0”: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\propertyBag\

   UpdatesReadyToApply.

   
   

3. Jeśli w miejscu dystrybucji poprawek znajdują się nowe uaktualnienia, są one pobierane w wersji skompresowanej do: folderu: C:\Program Files\Microsoft Office 15\Data\Updates\Download

   W tym momencie użytkownicy zobaczą następujący komunikat na pasku:

   

   Wymaganie jest, aby konto Local System miało uprawnienia read to zasobu, z którego należy pobrać uaktualnienie. 

4. Po zakończeniu pobierania pliki zostaną rozpakowane w C:\Program Files\Microsoft Office 15\Data\Updates\Apply oraz zostanie utworzony klucz rejestru: UpdatesReadyToApply.

5. Następnie użytkownikowi pojawi się komunikat proszący o zamknięcie aplikacji pakietu Office, aby zmiany mogły zostać zaaplikowane

   
   

   Wybranie opcji “Close Programs” spowoduje zamknięcie aplikacji oraz ich ponowne uruchomienie z zachowaniem niezapisanych danych!

   Jeśli użytkownik wybierze opcje „Cancel”, poprawki nie zostaną zastosowane.

6. Jeśli procesy pakietu Office będą włączone przez 3 kolejne dni, blokując możliwość zaaplikowania uaktualnień, użytkownikowi pojawi się kolejna notyfikacja prosząca o zamknięcie pakietu Office, aby poprawki mogły być zastosowane. Jednakże użytkownik będzie miał możliwość odrzucenia i tej notyfikacji.

7. Jeśli jednak użytkownik zamknie aplikacje pakietu Office po pojawieniu się notyfikacji to poprawki zostaną zainstalowane. W momencie instalacji poprawek, korzystanie z pakietu Office nie jest możliwe.

Poniżej znajduje się opisany wyżej proces:

Jak działa proces uaktualniania poprzez reinstalację pakietu Office?

Aby rozpocząć proces uaktualniania w tym wariancie, należy ponownie uruchomić narzędzie ODT z przełącznikiem CONFIGURE z odpowiednio zmodyfikowanym plikiem .xml. Plik musi wskazywać wersję Office, którą chcemy zainstalować oraz może wymusić zamknięcie wszystkich aplikacji Office lub poprosić użytkownika o ich zamknięcie.

Przykładowy plik .xml, który może być wykorzystany do uaktualnienia Office do wersji: 15.0.4569.1508

<Configuration>

<Add SourcePath="\\serwer\dp" OfficeClientEdition="32" Version="15.0.4569.1508">

<Product ID="O365ProPlusRetail">

<Language ID="pl-pl" />

</Product>

</Add>

               <Updates Enabled="FALSE">

<Display Level="FULL" AcceptEULA="TRUE" />

<Logging Name="OfficeSetup.txt" Path="%temp%" />

<Property Name="AUTOACTIVATE" Value="1" />

</Configuration>

Często pojawiającym się pytaniem jest: Jak duży jest update, który został pobrany na stację kliencką?

Aby odpowiedzieć na to pytanie, wystarczy skompresować zawartość folderu C:\Program Files\Microsoft Office 15\Data\Updates\Apply, ponieważ ten folder zawiera pobrane, ale rozpakowane uaktualnienia.

Mam nadzieje, że ta dwuczęściowa seria artykułów o Office 365 ProPlus pozwoliła przybliżyć ten wciąż mało znany komponent Office 365. W razie dodatkowym pytań zachęcam do kontaktu z działem wsparcia Premier.

Exchange 2013 Service Pack 1

Jak większość z Was już pewnie zauważyła, kilka dni temu wydany został dodatek Service Pack 1 dla Exchange Server 2013. Wprowadza on wiele nowości, o których możecie poczytać na blogu grupy produktowej http://blogs.technet.com/b/exchange/archive/2014/02/25/exchange-server-2013-service-pack-1-available.aspx.

Jedną z nowości, która się pojawiła jest nowy sposób komunikacji pomiędzy programem Outlook i serwerami Exchange – MAPI over HTTP (lub często nazywany po prostu MAPI/HTTP).

Co to jest MAPI/HTTP?

Zadaniem MAPI/HTTP jest zastąpienie protokołu RCP over HTTP (zwanego także Outlook Anywhere). Jest to bardzo prosty protokół, zgodny z HTTP/1.1, w którym komendy MAPI wysyłane są do serwerów Exchange, bezpośrednio z wykorzystaniem metody POST. W porównaniu do protokołu RPC over HTTP znacząco upraszcza komunikację z Exchange. Żeby nie pozostać gołosłownym, spróbujmy sobie przeanalizować, jak wygląda połączenie RPC over HTTP.

Gdy Outlook chce komunikować się z serwerami Exchange, musi otworzyć dwa niezależne połączenia.

• Pierwsze do komunikacji do serwera
• Drugie, jako kanał zwrotny.

Połączenia mogą przechodzić przez niezależne serwery CAS, ale zawsze muszą ostatecznie trafić do tego samego serwera Mailbox (Back-End). Każde zapytanie MAPI, opakowywane jest w protokół RPC a następnie dodatkowo w protokół HTTP, aby zostać przesłanym do serwera CAS. Tam komponent Proxy weryfikuje gdzie docelowo powinno trafić połączenie i przekazuje je do właściwego serwera Mailbox. Połączenie trafia docelowo na komponent RPC Proxy, który odczytuje komunikat RPC i nawiązuje lokalne połączenie RPC. Dopiero na tym etapie komponenty Back-End są w stanie przeczytać instrukcje MAPI wysłane przez klienta. Odpowiedź na te żądania zostanie odesłana analogicznie kanałem zwrotnym.

Jak widać na powyższym przykładzie, architektura komunikacji obejmuje dużą ilość protokołów i komponentów, z których każdy jest kolejnym punktem do analizy, gdy Outlook nie może nawiązać połączenia z serwerem Exchange.

Co zmienia protokół MAPI/HTTP.

Najlepiej będzie znów prześledzić to na przykładzie.

Outlook chcąc wysłać instrukcje MAPI, komunikuje się bezpośrednie z serwerem docelowym. Komendy przesyłane są bezpośrednio, jako zapytania HTTP, które transparentnie przechodzą przez serwer CAS, tak jak wszystkie pozostałe protokoły jak OWA czy EWS.

Jakie zalety ma komunikacja MAPI/HTTP?

Z punktu widzenia użytkownika zmiana jest dość istotna. Outlook znacznie szybciej nawiązuję połączenie z serwerem, w szczególności, gdy klient przełącza się miedzy sieciami (np. przechodzi z sieci korporacyjnej na połączenie GSM). Różnica jest także odczuwalna przy wybudzaniu komputera ze stanu hibernacji.

Z punktu widzenia administratora, prostsza architektura oznacza mniej komponentów, które mogą ulec awarii oraz dużo prostszą analizę, gdy Outlook nie może nawiązać połączenia.

Jak uruchomić MAPI/HTTP

MAPI/HTTP jest domyślnie wyłączony, ale po włączeniu może pracować równolegle do protokołu Outlook Anywhere. Zanim zostanie uruchomiony, musimy zweryfikować:

• Czy użytkownicy posiadają oprogramowanie w wersji, która obsługuje nowy sposób komunikacji. W chwili obecnej wymagany jest Outlook 2013 z zainstalowany dodatkiem Service Pack 1.
• Czy wszystkie serwery w ramach Database Availability Group oraz wszystkie serwery Client Access zostały zaktualizowane do wersji Exchange 2013 Service Pack 1.

Jeśli powyższe są spełnione, możemy przejść do konfiguracji:

• Konfigurujemy adresy oraz protokół, który będzie używany do weryfikacji poświadczeń użytkowników:

Set-MapiVirtualDirectory -Identity "Contoso\mapi (Default Web Site)" -InternalUrl https://Contoso.com/mapi -IISAuthenticationMethods Negotiate

• Upewniamy się, że certyfikat przypisany na serwerze zawiera FQDN, które skonfigurowaliśmy w poprzednim kroku. Jeśli nie, instalujemy właściwy certyfikat.
• Jeśli przed serwerami CAS znajduje się load/balancer lub srwery proxy, upewnijmy się, że ich konfiguracja obejmuje adresy, które skonfigurowaliśmy w pierwszym kroku.
• Jeśli wszystko jest gotowe, to uruchamiamy funkcjonalność MAPI/HTTP

Set-OrganizationConfig -MapiHttpEnabled $true

Jeśli wszystko zostało poprawnie skonfigurowane i korzystamy z programu Outlook we właściwej wersji, powinniśmy po pewnym czasie dostać komunikat z prośbą o wykonanie restartu klienta pocztowego. Po restarcie nawiązane zostanie połączenie MAPI over HTTP.

Co jeśli w swojej organizacji nadal mamy Exchange 2010?

Użytkownicy łączący się do skrzynek przechowywanych na Exchange 2013 będą w pełni wykorzystywali MAPI over HTTP. Jeśli jednak będą chcieli uzyskać połączenie do udostępnionej skrzynki znajdującej się na Exchange 2010 lub od folderów publicznych przechowywanych na starszej wersji Exchange, ich program pocztowy otworzy niezależne połączenia z wykorzystaniem standardowego RPC over HTTP.

W powyższym przykładzie:

• Połączenie do książki adresowej: Protokół HTTP, typ Exchange Directory
• Połączenie do skrzynki na Exchange 2013: Protokół HTTP, typ Exchange Mail
• Połączenie do skrzynki na Exchange 2010: Protokół RCP/HTTP, typ Exchange Mail
• Połączenie do folderów publicznych na Exchange 2010: Protokół RPC/HTTP, typ Exchange Public Folders

Jeśli chcielibyście dowiedzieć się więcej na ten temat, zapraszam do lektury i oglądania materiałów dostępnych na naszych stronach:

MAPI over HTTP
http://technet.microsoft.com/en-us/library/dn635177(v=exchg.150).aspx

Exchange 2013 and MapiHttp
http://channel9.msdn.com/Events/Open-Specifications-Plugfests/Redmond-Interoperability-Protocols-Plugfest-2013/Exchange-2013-and-MapiHttp

Outlook 2013 Client Protocols
http://channel9.msdn.com/Events/Open-Specifications-Plugfests/Redmond-Interoperability-Protocols-Plugfest-2013/Outlook-2013-Client-Protocols

Jakiś czas temu temu zostały opublikowane pakiety SP1 do produktów SharePoint, Project Server, Office Web Apps oraz pakietu Office System 2013. Historia jest dość zawiła, ale ze wzlgędu na błędy w nim odkryte SP1 został cofnięty i ponownie opublikowany. Zaktualizowałem ten post, aby odzwierciedlał aktualne zalecenia.

Artykuły oraz odnośniki do źródeł instalacji można znaleźć tutaj:

Jest kilka zaprzeczających sobie informacji pojawiających się w Internecie. W takim razie zamieszczam kilka faktów na temat tego pakietu zbiorczego aktualizacji:

• Jeżeli zainstalowana została pierwotna (błędna) aktualizacja SP1, to należy ponownie pobrać poprawioną (ostatnio opublikowaną) paczkę instalacyjną SP1. Po instalacji na wszystkich serwerach, należy również uruchomić narzędzie PSConfig w wersji graficznej lub z linni poleceń.
• SP1 dla SharePoint Server 2013 zawiera w sobie SP1 dla SharePoint Foundation 2013 (nie trzeba go instalować niezależnie)
• SP1 do SharePoint Server 2013 nie zawiera w sobie aktualizacji kumulacyjnej z lutego 2014 r.
• SP1 dla SharePoint 2013 zawiera aktualizację zbiorczą z marca 2013 r (March 2013 PU). Nie trzeba jej instalować niezależnie. Zatem rekomendowany zestaw aktualizacji to SharePoint 2013 RTM + SP1 + (ew. Feb CU 2014)
• Instalacja produktu SharePoint Server 2013 wraz z SP1 (wersja slipstream) nie została jeszcze opublikowana. Musimy jeszcze chwilę (mam nadzieję niedługą) poczekać z instalacją SharePoint Server 2013 na Windows Server 2012 R2.
• Gdy instalujemy SP1 dla SharePoint 2013 w polskiej wersji językowej, to nie musimy oddzielnie instalować SP1 do pakietu językowego polskiego. Ale musimy zainstalować SP1 dla wszystkich innych pakietów językowych, które zostały wcześniej zainstalowane na serwerze SharePoint. Tzn. SP1 jest zlokalizowany, ale zawiera aktualizacje tylko dla języka, dla którego go pobieramy.
• SP1 nie zawiera aktualizacji do App Fabric. Ten komponent należy aktualizować niezależnie.

Wersja slipstream, zarówno dla SharePoint Server 2013, jak i SharePoint Foundation 2013, jest już dostępna. Pakiety instalacyjne można pobrać z MSDN lub VLSC (SharePoint Server) lub z Microsoft Download Center (SharePoint Foundation).

Więcej informacji:

Announcing the release of Service Pack 1 for Office 2013 and SharePoint 2013

Service Pack for SharePoint Server 2013 1 Recalled [Updated]

SP1 for SharePoint 2013 has been rereleased

Service Pack 1 for SharePoint 2013 is now available for download (updated)

SharePoint 2013 SP1 FAQ

Wydany 25 lutego Service Pack 1 do Exchange 2013 wprowadza wiele nowych funkcjonalności. Między innymi rozszerza możliwości mechanizmu Data Loss Prevention o nowe reguły obejmujące polskie wymagania.

Możemy teraz stworzyć regułę DLP, która będzie wyzwalana, gdy w treści wiadomości będzie znajdował się

• numer PESEL

• numer dowodu osobistego

• numer paszportu

Umożliwia to tworzenie reguł DLP, chroniących przed przesłaniem tego typu danych w wiadomościach email przez użytkowników. Funkcjonalność ta jest już także dostępna w większości środowisk Exchange Online.

Więcej informacji o nowych funkcjonalnościach związanych z DLP, które wprowadza Service Pack 1 dostępne jest na blogu grupy produktowej Exchange: http://blogs.technet.com/b/exchange/archive/2014/02/25/data-loss-prevention-in-exchange-just-got-better.aspx

Od ponad 10 lat, Premier Support jest najwyższym poziomem wsparcia technicznego świadczonym przez Microsoft. Głównym celem usługi jest zwiększenie niezawodności systemów oraz podniesienie produktywności zespołów IT. W ramach kontraktu oferowane jest również wsparcie przy rozwiązywaniu problemów technicznych związanych z produktami Microsoft.

Jest kilka oficjalnych miejsc w sieci, na podstawie których można dowiedzieć się, czym jest i do kogo jest skierowana usługa Microsoft Premier Support. W tym poście chciałem Wam przybliżyć, jak wygląda ta forma kontraktu “od kuchni”.

Historia Premier Support zaczyna się dawno, dawno temu…

gdy produkty serwerowe Microsoft rozprzestrzeniały się po przedsiębiorstwach w coraz większej skali i były już używane przez krytyczne systemy, na których opierał się biznes. Microsoft do swojej oferty zdalnego wsparcia 24/7 wprowadził grupę inżynierów, wspierających rozwiązywanie problemów na miejscu u klienta. Taki specjalny „oddział” był wstanie dotrzeć w dowolne miejsce na ziemi (dosłownie) i współpracując z grupą wspierającą klienta zdalnie, rozwiązać jego problem. Tego typu wsparcie dotyczyło głównie poważniejszych reaktywnych zgłoszeń (ważny system nie działa, trzeba go jak najszybciej naprawić).

Nie ma produktów idealnych, zdarza się, że zawodzi producent oprogramowania. Błąd w produkcie powoduje problem, który może negatywnie wpłynąć na działanie kluczowych systemów informatycznych firmy. W takich sytuacjach tworzone są poprawki naprawiające niewłaściwie działające oprogramowanie. Wbrew pozorom, zarówno teraz, jak i kiedyś, stosunkowo rzadko dochodziło do takiej sytuacji.

Większość problemów, nad którymi pracowali inżynierowie rozwiązując zgłoszenia reaktywne, wynikało z błędów ludzkich lub procesowych (niewłaściwa konfiguracja, niewiedza, brak procesu zarządzania IT, brak kopii zapasowych, brak procedur odzyskiwania systemu, itp.). Zespół pracujący dotychczas reaktywnie, przekształcił się dość szybko w grupę specjalistów blisko współpracujących z zespołem IT klienta i zajmujących się wybranymi produktami Microsoft z każdej możliwej perspektywy. Zespół zapewniał transfery wiedzy, wspierał przy wdrożeniu i konfiguracji, proaktywnie weryfikował środowiska IT, aby zapewnić ich właściwe działanie. Tak wykształcił się zespół Premier Field Engineers (PFE), który jest właścicielem tego bloga.

Dygresja z historią w tle, doprowadziła nas do teraźniejszości… ;-)

Oferta Premier Support

Obecnie lista usług, do których klienci Premier Support mają dostęp, jest naprawdę olbrzymia. Dzielą się one na dwie kluczowe kategorie: usługi proaktywne oraz reaktywne.

Usługi proaktywne

To np. kilkaset warsztatów, na bardzo wysokim poziomie. Są tworzone przez osoby pracujące z dużymi systemami na całym świecie i mających olbrzymie doświadczenie w danej technologii. Do przykładów należą:

• PowerShell Scripting for the IT Administrator

• SQL Server 2012 Performance Tuning Design Internals and Architecture

• System Center Service Manager 2012 Administration and Configuration

• Windows Server 2012 DirectAccess Deployment and Troubleshooting

• SharePoint 2013 Upgrade and Deployment

• Office 365 Online Administration and Configuration

• SharePoint 2010 Backup Recovery and Availability

• Advanced .NET Debugging

• Visual Studio 2010 ALM Team Foundation Server Administration

• Lync Server 2010 Advanced Voice

• IIS Best Practices

• Netmon for Enterprise Troubleshooting

• Active Directory Backup and Disaster Recovery

• ASP.NET MVC

• itd.

Wiele usług proaktywnych Premier Support to rozbudowane platformy tworzone latami przez kilkudziesięciu ekspertów z danej dziedziny. Należą do nich programy takie jak: Risk Assessment Program as a Service (RAP as a Service), Code Review, Migration Readiness Assessment. Przykładowo, RAP as a Service jest dostępny dla wszystkich kluczowych produktów serwerowych, np.: Active Directory, SharePoint, Exchange, SQL Server, IIS, itd. Program ten służy do automatycznej weryfikacji zdrowia krytycznego środowiska przedsiębiorstwa pod kątem występowania problemów konfiguracyjnych, błędów, zagrożeń, które mogą mieć wpływ na stabilność działania usługi w przyszłości. Np. SharePoint Server RAP as a Service to około tysiąc testów badających „zdrowie” farmy SharePoint Server na żądanie klienta.  Polecam prosty filmik, jako wprowadzenie do usługi RaaS:

Przykładową listę usług proaktywnych, które aktualnie znajdują się w ofercie Premier Support, można znaleźć w katalogu usług na rok 2013: 

Premier Proactive Services Catalogue, Central and Eastern Europe - 2013

Oferta jest aktualizowana i rozszerzana na bieżąco, bo zależy nam na dostosowaniu jej do potrzeb naszych klientów. Polecam zerknięcie do tego pliku, bo zakres usług robi wrażenie. 

Usługi reaktywne

Usług reaktywnych nie należy kojarzyć ze standardową pierwszą linią wsparcia do rozwiązywania problemów. Zaraz po otwarciu, zgłoszenie trafia do grupy ekspertów z naszego kraju. W razie konieczności jest eskalowane do konkretnych grup produktowych za granicą, które specjalizują się w konkretnej dziedzinie np.: .NET lub SCCM. Nad najbardziej złożonymi problemami pracują inżynierowie eskalacyjni przy współpracy z członkami grupy produktowej (np. konkretnym programistą danej funkcjonalności w produkcie Microsoft). To tutaj również jest podejmowana decyzja, czy zostanie stworzona poprawka do produktu. W przypadku krytycznych zgłoszeń, zdarza się, że do pomocy inżynierowi zdalnemu, wysyłany jest inżynier wsparcia na miejscu u klienta (właśnie inżynier PFE). A jego praca wygląda mniej więcej tak: :)

Ale Premier Support to nie tylko wysokiej klasy profesjonaliści IT oraz wsparcie techniczne…

Zaufany doradca techniczny

W ramach kontraktu, klient otrzymuje doradcę technicznego po stronie Microsoft (Technical Account Manager). TAM jest interfejsem, dzięki któremu klient może komunikować się z Microsoft. Jego główną rolą jest zrozumienie biznesu klienta, analiza wymagań oraz właściwe dobranie i zaplanowanie usług Premier Support. TAM jest również koordynatorem różnego typu eskalacji oraz zapytań ze strony klienta i skierowanych do Microsoft.

Wsparcie w obszarze operacyjnym

Pewnie wiecie, że nie błędy technologiczne są główną przyczyną awarii systemów informatycznych. Przeważająca większość z nich, jest spowodowana czynnikiem siedzącym pomiędzy fotelem, a klawiaturą ( :-) ), lub też wynika z zaniedbań procesowych. Właśnie w obszarze Operation Consulting można wdrożyć wiele usprawnień w funkcjonowaniu działu oraz systemów IT. Premier Support to wsparcie w budowie i optymalizacji procesów zarządzania IT, kompleksowe usługi doradcze, szkolenia i gry symulacyjne.

Polecam ciekawy artykuł rozszerzający tematykę: Reactive IT and Fighting Fires Costs More Money Than You Think.

Premier Support for Developers

Na początku istnienia, Premier Support koncentrował się głównie na obszarze infrastruktury i kształcił kompetencje wśród Profesjonalistów IT. Obecnie Premier Support to bardzo szeroki wachlarz usług przeznaczonych dla architektów rozwiązań oraz programistów.  

Oferta dotyczy m.in.:

• Podniesienia kompetencji przedsiębiorstwa w zakresie planowania, doboru architektury oraz budowy rozwiązań

• Zwiększenia produktywności zespołów programistów.

• Wdrożenia procesów walidacji rozwiązań.

• Diagnozowania problemów związanych z rozwiązaniami (np. zła wydajność, błędy), walidacji architektury oraz sposobu implementacji rozwiązań.

 Dla zainteresowanych tematem, polecam następujący odnośnik: Premier Support for Developers.

Bujamy się w chmurze

Do tego dochodzi bardzo rozbudowana oferta dotycząca usług w chmurze publicznej oraz prywatnej. Przykładem jest „Premier Support for Windows Azure”, czyli dedykowana oferta dla przedsiębiorstw  hostujących swoje krytyczne systemy w Windows Azure. Albo np. liczne usługi dotyczące Office 365 z każdej możliwej perspektywy technologicznej (Exchange, Active Directory, SharePoint, Lync, zarządzanie, planowanie środowisk hybrydowych, itp.).

Do kogo jest skierowana oferta

Oferta jest naprawdę olbrzymia i spełnia wymagania zarówno bardzo dużych przedsiębiorstw, jak i średnich firm. Nie będę się rozpisywał, bo i tak nie w swoim stylu popłynąłem w marketingowe wywody. Ale jeżeli firma korzysta z produktów Microsoft, i na ich bazie działają usługi krytyczne z perspektywy prowadzonego biznesu (np. zarządzanie tożsamością, poczta, portal internetowy, systemy CRM, aplikacja LOB, itp.) to proponuję zapoznać się z ofertą. Gwarantuję, że w obszarze produktów Microsoft, oferta wsparcia jest bezkonkurencyjna. Tak mówią klienci: :)

Więcej informacji (już nieco bardziej formalnych) oraz dane kontaktowe można znaleźć na oficjalnej stronie Microsoft Premier Support Polska.

Kilka tygodni temu Microsoft udostępnił darmową usługę Windows Azure Virtual Machine Readiness Assessment. Dzięki niej możliwa jest weryfikacja prywatnej infrastruktury (obecnie: Active Directory, SQL Server oraz SharePoint) pod kątem migracji serwerów do Windows Azure. Narzędzie testuje wybrane środowisko, w wyniku czego powstaje szczegółowy raport. Znajdziecie w nim ew. obszary, w których wymagane są zmiany przed migracją (np. w konfiguracji lub architekturze usługi). Dane dotyczące środowiska są zbierane zarówno na podstawie ankiety wypełnianej manualnie, jak również (a może przede wszystkim) automatycznie wykonanych testów.

Narzędzie możecie pobrać stąd: Windows Azure Virtual Machine Readiness Assessment (http://www.microsoft.com/en-us/download/details.aspx?id=40898)

Moda na co dzień determinuje wiele z naszych zachowań – kupujemy „wypasione” telefony, szybkie (lub duże) samochody, modne ciuchy, piszemy na blogach, itd. W chwili refleksji dotarło do mnie, że nie nadążam za modą – wszak nie prowadzę bloga… Czas więc to nadrobić i dołączyć do bardziej nowoczesnej części społeczeństwa. Nie dość więc, że na blogu, to zajmiemy się jeszcze modnymi technologiami – Windows Azure i PowerShellem. Zapraszam…

Windows Azure oferuje całkiem przyjemny portal do zarządzania naszą „chmurką” nie mniej jednak w niektórych sytuacjach przydałaby się nam automatyzacja wybranych czynności. Z pomocą przychodzi oczywiście PowerShell i dedykowany moduł do Windows Azure. Aby rozpocząć naszą przygodę, będziemy potrzebowali PowerShell w wersji minimum 3.0 oraz moduł, który można pobrać z witryny Microsoft: http://go.microsoft.com/fwlink/?LinkID=279888.

Po pobraniu i instalacji modułu uruchamiamy konsolę PowerShell i tu czeka na nas mała niespodzianka – funkcja automatycznego ładowania modułów, do której tak już się zdążyliśmy przyzwyczaić nie zadziałała… Spieszę jednak aby Was uspokoić – to nie błąd, moduł domyślnie instaluje się w katalogu C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure, który nie jest brany pod uwagę przez mechanizm importujący moduły. Jak zwykle mamy kilka sposobów na zmianę tego zachowania, jednym z nich może być dodanie do naszego profilu PowerShell następującej linii:

$env:PSModulePath = $env:PSModulePath + ";C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure"

Przy ponownym uruchomieniu PowerShella możemy już korzystać z poleceń dostępnych w module Azure.

Czas więc podłączyć się do naszej subskrypcji Windows Azure. Do wyboru mamy dwie możliwości.

W przypadku pierwszej opcji możemy skorzystać z polecenia Add-AzureAccount, niestety zostaniemy poproszeni o zalogowanie się w dodatkowym oknie. O ile metoda ta sprawdzi się podczas prac ad hoc, o tyle przy próbie automatyzacji zadań będzie to problem.

Drugi sposób wykorzystuje certyfikat, który można pobrać z portalu Windows Azure. Po uruchomieniu polecenia Get-AzurePublishSettingsFile zostanie uruchomiona przeglądarka internetowa na stronie udostępniającej plik z certyfikatem. Plik o rozszerzeniu .publishsettings należy zapisać w bezpiecznym miejscu (wszak jest to klucz do zarządzania naszym środowiskiem!). Tak przygotowani, uruchamiamy polecenie Import-AzurePublishSettingsFile, jako parametr podając ścieżkę do pobranego przed chwilą pliku i możemy zarządzać środowiskiem.

Import-AzurePublishSettingsFile azure.publishsettings

Polecenie powoduje import certyfikatu do naszego magazynu oraz utworzenie pliku konfiguracyjnego w ścieżce C:\Users\Nazwa_Użytkownika\AppData\Roaming\Windows Azure PowerShell.

Za pomocą polecenia Get-AzureSubscription możemy sprawdzić jak długo ważny jest nasz certyfikat umożliwiający połączenie - [Not After].

Pora wykonać jakieś prawdziwe zadanie. Na początek sprawdźmy, jakie maszyny wirtualne mamy już utworzone w naszym środowisku – wykorzystamy polecenie Get-AzureVM:

W celu uruchomienia jednej z maszyn wydamy polecenie Start-AzureVM, np.:

Start-AzureVM -ServiceName gblab -Name dc2

Analogicznie wyglądałoby zatrzymanie maszyny:

Stop-AzureVM -ServiceName gblab -Name dc2 -Force

Parametr Force będzie potrzebny, gdy zatrzymujemy ostatnią maszynę w ramach naszej usługi (gblab w tym przypadku). Uważajcie jednak, efektem zatrzymania ostatniej maszyny będzie zmiana adresu IP (zarówno VIP, jaki i DIP). Więcej na ten temat znajdziecie tutaj: http://blogs.technet.com/b/keithmayer/archive/2013/06/19/windows-azure-virtual-machines-there-s-more-than-1-way-to-shutdown-a-vm.aspx

Stwórzmy zatem przykładową funkcję, która spowoduje uruchomienie całego naszego środowiska (ograniczamy klikanie na portalu!):

function Start-AzureLAB
{
    $x = 1
    Write-Progress -Activity "Getting VMs" -Status "Please wait..."
    $VMs = Get-AzureVM | where {$_.Status -ne "ReadyRole"}
    foreach ($VM in $VMs)
    {
        Write-Progress -Activity "Starting VMs" -Status $VM.Name `
             -PercentComplete ($x * 100 / $VMs.Count)
        Start-AzureVM -ServiceName $VM.ServiceName -Name $VM.Name
        do
        {
            Start-Sleep -Milliseconds 250
        }
        while ((Get-AzureVM -ServiceName $VM.ServiceName `
            -Name $VM.Name).PowerState -ne "Started")
        $x++
    }
}

Po dodaniu funkcji do profilu mamy gotowy mechanizm – proste polecenie PowerShell zamiast serii „kliknięć”…

Pierwsze zadanie wykonane. Jeśli uważacie, że czasami warto podążać za modą – niewykluczone, że ciąg dalszy nastąpi…

Więcej informacji o aspektach praktycznego wykorzystania Windows Azure znaleźć można w artykule Piotra - Wirtualna maszyna “w chmurze”– czyli środowisko testowe lub produkcyjne, w Windows Azure.

Szybka notka z pola walki z ADMT. Żeby wyciągnąć dane na temat przeszłych migracji z Active Directory Migration Toolkit można użyć Management Studio i poniższego zapytania SQL:

use admt
SELECT sourceObject.SamName as 'SourceSAMAccountName'
  , sourceDomain.DnsName as 'SourceDomain'
  , '' + sourceDomain.[sid] + '-' + convert(nvarchar,sourceObject.[rid]) as 'SourceSID'
  , targetObject.samname as 'targetSAMAccountName'
  , targetDomain.dnsname as 'TargetDomain'
  , '' + targetDomain.[sid] + '-' + convert(nvarchar,targetObject.[rid]) as 'TargetSID'
  , sourceObject.[Type] as objectType
  
  FROM [ADMT].[dbo].[MigratedObjects]
  join dbo.[Objects] as sourceObject on [MigratedObjects].[SourceObjectId] = sourceObject.ObjectId
  join dbo.[Domains] as sourceDomain on sourceObject.DomainId = sourceDomain.DomainId
  join dbo.[Objects] as targetObject on [MigratedObjects].[targetObjectId] = targetObject.ObjectId
  join dbo.[Domains] as targetDomain on targetObject.DomainId = targetDomain.DomainId

Dla wielu przedsiębiorstw wdrożenie nowej wersji pakietu Office jest sporym problemem, mimo, że firmy te chciałyby wykorzystywać zalety najnowszego Office’a jak najszybciej. W dużych organizacjach takie wdrożenie jest długotrwałe i może oznaczać przerwę w dostępie do pakietu Office dla użytkowników. W mniejszych organizacjach instalowanie najnowszych wersji Office może być niemożliwe ze względu na koszty.

Celem dwuczęściowej serii artykułów jest przedstawienie Office 365 ProPlus Click-to-Run, który może rozwiązać powyższe problemy. W pierwszej części przedstawię najważniejsze cechy pakietu Office oraz możliwości związane z przeprowadzeniem instalacji. W drugiej części artykułu, zaprezentuję możliwości dystrybucji uaktualnień do tej wersj pakietu Office.

Office 365 ProPlus – cechy ogólne

Office 365 ProPlus to aplikacja instalowana na dysku twardym komputer działająca również w przypadku braku posiadania łączności z Internetem. Pakiet oferuje ten sam „user experience”, co tradycyjny Office. Jednakże, Office 365 ProPlus różni się od tradycyjnej instalacji opartej o pliki .msi następującymi cechami:

• Licencja przypisana jest do użytkownika, nie do komputera.

• Użytkownik posiadający licencję może zainstalować Office 365 ProPlus na 5 komputerach

• Użytkownik musi uwierzytelnić się w Office 365, aby aktywować oprogramowanie na urządzeniu. Użytkownik może użyć “chmurowych” lub sfederowanych poświadczeń.

• Office jest strumieniowany na lokalnych komputer i można go używać zanim zostanie w pełni pobrany, co znacząco przyśpiesza proces instalacji.

• Usługi aktywacji licencji takie jak KMS lub MAK nie są potrzebne

• Możliwa jest instalacja side-by-side z tradycyjną wersją Office (konieczna zgodność wersji 32, 64-bitowa)

• Poprawki wydawane w przewidywalnym czasie (raz na miesiąc, drugi wtorek miesiąca)

• Komputer musi połączyć się z Internetem (konkretnie z https://ols.officeapps.live.com/olsc/OlsClient.svc) przynajmniej raz na 30 dni, aby Office 365 Click-to-Run pozostał aktywowany. W przeciwnym wypadku Office przejdzie w tryb ograniczonej funkcjonalności.

Office 365 ProPlus nie jest wymagany, aby połączyć się do usług Office 365 takich, jaki Exchange Online. Możemy do tego celu korzystać również z wersji Office’a instalowanej z plików .msi. Ponadto, Office w wersji Click-to-Run może być wykorzystany do połączenia z usługami znajdującymi się on-premises.

Pobranie pakietu Office 365 ProPlus nie wymaga licencji, ale aktywowanie kopii już tak. Po zainstalowaniu aplikacji, użytkownik ma przyznany 5-dniowy „grace-period” na aktywację Office 365 ProPlus. Domyślnie Office zostanie automatycznie aktywowany podczas instalacji, jeśli użytkownik ma przyznaną licencję. Jeśli skonfigurowano federację pomiędzy lokalnym Active Directory a Office 365 to proces aktywacji nie będzie wymagał podania nazwy użytkownika i hasła, aby aktywować Office 365 ProPlus, o ile oprogramowanie będzie instalowane na komputerze mającym łączność z serwerem ADFS oraz będącym członkiem domeny.

Każdy użytkownik posiadający licencję na Office 365 ProPlus może zainstalować tę wersję Office na maksymalnie 5 komputerach. W przypadku próby instalacji na szóstym urządzeniu, użytkownik zostanie poproszony od odinstalowanie Office 365 ProPlus z jednej z maszyn i zwolnienie licencji. Pliki instalacyjne Office’a 365 ProPlus mogą być pobrane z punktu dystrybucyjnego znajdującego się w Office 365 zwanego: Content Delivery Network (CDN) lub ze zdefiniowanego przez administratora wewnętrznego punktu dystrybucji.

Proces Instalacyjny

Office 365 ProPlus tak samo jak Office instalowany z plików .msi wymaga posiadania uprawnień administracyjnych na komputerze. Jednakże proces instalacyjny można zainicjować oprogramowaniem do zarządzenia aplikacjami, np. System Center Configuration Manager, które posiada uprawnienia instalowania software’u na stacji roboczej.

Office 365 ProPlus jest dostarczany z własnym, dedykowanym agentem App-V, umieszczanym domyślnie w folderze: C:\Program Files\Microsoft Office 15\Clientx64 (agent znajduje się w tym folderze niezależnie czy instalujemy wersję 32 czy 64 bitową Office).

Po rozpoczęciu instalacji Proces instalacyjny o nazwie integratedoffice.exe, będzie przeprowadzał instalację w kontekście lokalnego użytkownika. Jednakże po wykonaniu około 10% zadania, proces zmieni kontekst i będzie kontynuował instalację i pobieranie danych w kontekście konta Local System. Jest to ważne, jeśli pakiet Office’a jest pobierany przez serwer proxy z Internetu i jeśli serwer proxy wymaga uwierzytelnienia. W takim przypadku konta komputerów, na których będzie instalowani Office 365 ProPlus, muszą mieć uprawnienia na serwerze proxy do łączenia się z Internetem.

Po około 15-20% procesu instalacyjnego, czyli zazwyczaj po około 2 minutach Office 365 ProPlus, będzie gotowy do pracy. Zostaną utworzone ikony Office’a, a pliki typu: .docx, .xlsx etc. skojarzone z pakietem Office. Gdy użytkownik uruchomi w tym momencie np. Worda, zostanie on natychmiast pobrany, aby można było rozpocząć korzystanie z tej aplikacji.

Zarządzenia dystrybucją Office 365 ProPlus

Możemy wyróżnić dwa sposoby dystrybucji Office 365 ProPlus

1. Self-service. Użytkownik sam inicjuje proces pobierania i instalowania Office 365 ProPlus

2. Automated. Administratorzy zarządzają i inicjują instalację. W tym przypadku Office 365 ProPlus może być pobrany do lokalnej punktu dystrybucji lub być pobierany z Internetu.

Self-Service

Użytkownik logując się do Portalu Office 365 (portal.microsoftonline.com) może pobrać binarki Office 365 ProPlus o ile posiada przypisaną licencję. Inicjując w ten sposób proces instalacyjny pliki są pobierane z CDN (http://officecdn.microsoft.com/). Po zainstalowaniu oprogramowania, konfiguracja Office’a jest możliwa za pomocą Group Policy Object.

W przypadku indywidualnej instalacji każdy użytkownik pobiera pełną instalację Office 365 ProPlus.  Może to mocno obciążyć łącze do Internetu w firmie.

W Portalu Office 365 administrator może wyłączyć możliwość samodzielnego pobierania pakietu Office 365 ProPlus przez użytkowników.

Automated

Aby ograniczyć wykorzystanie linku Internetowego, pliki instalacyjne można pobrać raz, umieścić w punkcie dystrybucyjnym w sieci lokalnej i użyć narzędzia do dystrybucji oprogramowania (np. System Center Configuration Manager) w celu zainicjowania instalacji. Zrealizowanie powyższych kroków jest możliwe dzięki aplikacji: Office Deployment Tool for Click-to-Run (ODT). Jest to narzędzie wiersza poleceń, pozwalające pobrać pliki instalacyjne, a także rozpocząć instalację w modelu dystrybucji centralnej. Cały proces jest zarządzany przez pliki konfiguracyjne. Pełen opis tego jak stworzyć plik konfiguracyjny, znajduje się w tym artykule: http://technet.microsoft.com/en-us/library/jj219426.aspx

Należy zwrócić uwagę, że tworząc plik konfiguracyjny nie mamy możliwości wskazania ścieżki instalacyjnej dla Office 365 ProPlus. Office będzie zawsze instalowany w folderze: C:\Program Files\Microsoft Office 15\ (nie zależnie czy instalujemy wersję 32 czy 64 bitową).

W następnym artykule przedstawię, w jaki sposób zarządzać uaktualnieniami do Office 365 ProPlus.

Wiele firm obawia się, że wdrożenie Office 365 to skomplikowany proces, który wymaga instalacji wielu serwerów w lokalnej infrastrukturze.  Zwłaszcza instalacja i konfiguracja serwerów ADFS, aby zapewnić logowanie za pomocą tych samych poświadczeń do aplikacji hostowanych lokalnie oraz aplikacji znajdujących się w Office 365 może być trudne dla niektórych organizacji. Brak powyższej funkcjonalności może być poważną przeszkodą przed rozpoczęciem korzystania z Office 365. W tym artykule przedstawię funkcjonalność synchronizacji haseł (Password Sync), która umożliwia uproszczenie konfiguracji oraz zmniejszenie ilości serwerów potrzebnych do wdrożenia Office 365.

Funkcjonalność synchronizacji haseł jest realizowana przez narzędzie DirSync, wykorzystywane także do synchronizacji obiektów z lokalnego Active Directory do Windows Azure Active Directory (WAAD). (Więcej informacji na temat WAAD, znajduje się tutaj: http://technet.microsoft.com/en-us/library/hh967611.aspx).  DirSync jest to darmowy appliance Forefront Identity Manager 2010 R2 przeznaczony jednokierunkowego (z małymi wyjątkami) synchronizowania obiektów takich jak konta użytkowników, grupy, kontakty itp., z lokalnego Active Directory do Windows Azure Active Directory. Proces odpowiedzialny za synchronizację haseł uruchamiany jest automatycznie, co 2 minuty i wykonuje następujące czynności:

• Sprawdza atrybut pwdLastSet na każdym koncie użytkownika, aby ustalić czy nastąpiła zmiana hasła.
• Jeśli zostanie stwierdzona zmiana hasła, proces pobiera hash hasła z Active Directory.
• Hash hasła zostaje ponownie zahash’owany i w takie postaci wysłany do Windows Azure Active Directory za pomocą szyfrowanego kanału.

Jak widać same hasła nie są przesyłane do Office 365. Synchronizowane są ich hashe, które są dodatkowo zabezpieczone.

DirSync w procesie synchronizacji, wysyła do WAAD, także nazwę użytkownika (UserPrincipalName). W związku z tym, konto użytkownika w WAAD, ma taki sam login i hasło jak konto użytkownika w lokalnym AD. Dzięki temu użytkownik może używać tych samych poświadczeń do logowania do usług znajdujących się w Office, 365 jaki w lokalnym Active Directory.

Główny proces synchronizowania obiektów i ich atrybutów, który uruchamia się, co 3 godziny jest niezależny od procesu synchronizacji haseł. Oznacza to, że wymuszenie zwykłego procesu synchronizacji nie wymusza synchronizacji haseł. Aby wymusić synchronizację haseł należy wykonać następujące polecenie w Powershellu konfiguracyjnym DirSync: Set-FullPasswordSync oraz zrestartować usługę FIMSynchronizationService.

DirSync, który jest niezbędny do synchronizacji haseł, może być instalowany na serwerach Windows Server 2008 R2 lub nowszych. Ponadto 22 listopada 2013 została wydana wersja DirSync (6567.0018), która pozwala na instalowanie tej aplikacji na kontrolerach domeny. Inną możliwością jest zainstalowanie serwera DirSync na serwerze wirtualnym znajdującym się Windows Azure.

Synchronizacja obiektów za pomocą DirSync zmienia „source of authority” dla obiektów w Office 365. Oznacza to, że wszelkie zmiany na obiektach utworzonych w WAAD za pomocą DirSync, muszą być wykonywane w lokalnym AD, a następnie zsynchronizowane do WAAD. Dotyczy to również haseł. Użytkownik chcąc zmienić hasło, musi to zrobić w lokalnym AD i poczekać (maksymalnie 2 minuty), aż nowe hasło zostanie synchronizowane do chmury.

Warto nadmienić, że zarówno korzystając z ADFS, jaki i Password Sync, polisy dotyczące haseł konfigurowane są w lokalnym Active Directory.

Jakie są różnice między używaniem DirSync z Password Sync, a wykorzystaniem ADFS do uwierzytelniania do Office 365:

• ADFS umożliwia wykorzystanie Client Access filtering policy (konieczne posiadanie ADFS Proxy), które mogą na przykład zablokować dostęp do Office 365 w wybranych godzinach, wybranym grupom użytkownikom do wybranych usług.
• ADFS w niektórych przypadkach może zapewnić Single Sign-On (logowanie do Lync’a, logowanie do OWA w LANie). W przypadku DirSync z Password Sync, użytkownik musi podawać poświadczenia aby zalogować się poczty, Lynca  Online czy Sharepointa Online
• W przypadku ADFS uwierzytelnianie użytkownika odbywa się w lokalnym Active Directory. Jeśli chodzi o DirSync Password Sync, użytkownik uwierzytelniany jest przez WAAD.

Jeśli powyższe funkcjonalności nie są wymagane, DirSync z Password Sync jest wspaniałą alternatywą dla wdrażania ADFS dla potrzeb logowania do Office 365, która ogranicza koszty wdrożenie usług w chmurze.

Każdy pracujący na co dzień z Windows Management Instrumentation powinien zaznajomić się z pewnym narzędziem. Mianowicie z WMI CIM Studio (do pobrania stąd: http://www.microsoft.com/en-us/download/details.aspx?id=24045). Niestety wraz z pojawianiem się nowych wersji systemów operacyjnych, a co za tym idzie wersji przeglądarki Internet Explorer, CIMStudio przestało działać. Formatki ActiveX na których jest ono oparte są uznawane za niebezpieczne. Owocuje to pustymi oknami dialogowymi:

Na szczęście jest obejście tego problemu, które działa również w Windows 8.1/2012R2 jest względnie proste – uruchomienie studio.htm z zaufanej ścieżki sieciowej. Z tym, że tą ścieżką sieciową może też być nasza stacja robocza :) Więc do pracy:

Po instalacji WMI tools przechodzimy do katalogu z jego instalacją (domyślnie C:\Program Files (x86)\WMI Tools). Następnie share-ujemy go pod jakąś nazwą. W moim przypadku jest to WMI$:

Po zaaplikowaniu zmian przechodzimy do katalogu sieciowego i otwieramy studio.htm za pomocą Internet Explorera. Pierwsze otwarcie będzie miało taki sam efekt, jak próba korzystania z CIM Studio bezpośrednio z menu start – puste okna. Należy w opcjach zaawansowanych właściwości strefy Local Intranet dodać naszą ścieżkę do listy adresów (uwaga – nie może to być localhost, musi to być nazwa NetBios komputera):

Po zatwierdzeniu zmian zamykamy IE. Otwieramy ponownie studio.htm i jesteśmy powitani będem:

Na szczęście to fałszywy pozytyw. Po kliknięciu “OK” kilka razy możemy pracować z CIM Studio!

Dla zainteresowanych tematem WMI polecam zapoznanie się z serią moich artykułów na GeekClub.pl:

http://wss.geekclub.pl/baza-wiedzy/wmi-jako-obiektowa-baza-danych-wprowadzenie-16,1444

W tym roku, ponownie mamy zaszczyt poprowadzić kilka sesji na konferencji Microsoft Technology Summit. Jeżeli jeszcze nie wiesz czy się wybierasz, to zapraszamy do zapoznania się z tegoroczną ofertą na stronie: www.mtskonferencja.pl.

Jeżeli będziesz na konferencji, to oczywiście zapraszamy na nasze sesje oraz kontakt z nami. Obiecujemy trzymać poziom!

29 lipca został wycofany z Download Center, Exchange 2013 Cumulative Update 2 (15.0.712.22) i zastąpiony jego nową wersją (15.0.712.24). Można go pobrać z Download Center . Ma to związek z problemem, który wystąpił w ostatnim CU, dotyczącym możliwej utraty uprawnień na folderach publicznych w przypadku przeniesienia skrzynki Public Folder (http://blogs.technet.com/b/exchange/archive/2013/07/12/e2013-rtm-cu2-issue-public-folder-permissions-loss-after-pf-mailbox-move.aspx). Nowy Cumulative Update 2 jest pełną instalacją serwera Exchange 2013, która nie zawiera już powyższego problemu.

Cumulative Update 2 (wersja: 15.0.712.24) może być zainstalowany na serwerze Exchange 2013 RTM, CU1 i CU2 w wersji 15.0.712.22. Uwaga: przed instalacją nowego CU2 nie należy odinstalowywać istniejącego Cumulative Update, ponieważ spowoduje to odinstalowanie całego serwera Exchange.

Ostatnio trafiają do mnie zapytania dotyczące błędów, które są obserwowane w środowiskach SharePoint Server 2010 / SharePoint Foundation 2010 po zainstalowaniu na platformie Windows Server 2008 R2 krytycznej aktualizacji zbiorczej MS13-052 (Vulnerabilities in .NET Framework and Silverlight could allow remote code execution). Częścią tego pakietu jest problematyczna aktualizacja: KB2844286.

Po zainstalowaniu poprawki, możecie zaobserwować błędy typu „Unable to display this Web Part”, które mają związek ze zmianą w platformie .NET 3.5.1 wpływającą na kontrolkę DataFormWebPart wyświetlającą dostosowany widok listy SharePoint.

Rekomendowanym rozwiązaniem tego błędu jest zainstalowanie aktualizacji KB2872441.

Często zdarza się, że chcemy usunąć zbędne dane z Active Directory. Jednak ze względu na model replikacyjny, obiekty z bazy danych AD są usuwane dopiero po upłynięciu Tombstone Lifetime (TSL – więcej szczegółów na temat procesu replikacji nagrobków można znależć tutaj: http://technet.microsoft.com/en-us/library/cc772726(v=ws.10).aspx#w2k3tr_repup_how_okdq)

Jednak zanim obiekt w Active Directory może zostać zamieniony w nagrobek (celowo unikam określenia “usunięty”), czynnośc ta musi przejść wielostopniowy proces weryfikacji, czy ta czynność jest naprawdę bezpieczna. Zgodnie z tym artykułem: http://technet.microsoft.com/pl-pl/magazine/2007.09.tombstones(en-us).aspx; sprawdzane są następujące rzeczy:

• czy kasowany obiekt nie ma już ustawionej flagi isDeleted na true (nie da się usunąć nagrobka)
• Security Descriptor obiektu (jego część zawierająca uprawnienia) nie określa go jako obiektu prywatnego (efektywnie sprawia, że nikt inny poza AD nie może go modyfikować)
• atrybut systemFlags nie przecyzuje wartości 1 na bicie DISALLOW_DELETE 0x80000000
• isCriticalSystemObject nie jest true (nie chcemy usuwać obiektów o krytycznym znaczeniu dla systemu – na przykład obiektu NTDS Settings dla działającego kontrolera domeny)
• użytkownik wykonujący próbę kasowania ma uprawnienia do danej czynności
• obiekt nie jest wskaźnikiem typu crossRef (cross-reference) dla istniejącej partycji AD (nie chcemy pozwolić na usunięcie wskaźnika do istniejącej domeny lub partycji aplikacyjnej)

Wystarczy, że którykolwiek z powyższych nie zostanie spełniony, to próba skasowania obiektu zakończy się niepowodzeniem.

Taki właśnie przypadek ostatnio przytrafił się mi osobiście. W ADSIEdit w kontenerze z użytkownikami miałem obiekt o nazwie CORP$. Co ciekawe, to CORP było starą domeną z której nasz klient się zmigrował. Co jeszcze ciekawsze, obiekt ten nie był widoczny w konsoli AD Users & Computers. Niestety porządek musi być, więc rozpoczęliśmy wraz z koleżankami i kolegami z działu wsparcia proces rozwiązywania problemu. W tym celu przedsięwzięliśmy m.in. następujące kroki:

• Wiedzieliśmy, że próba jego usunięcia daje nam następujący komunikat:
  
• Weryfikacja, czy relacja zaufania na cele migracji, ciągle istnieje;
  Tu stwierdziliśmy, migracja została przeprowadzona prawidłowo i po jej zakończeniu trust został usunięty
• Zrzut atrybutów obiektu, żeby się dokładnie dowiedzieć czym on jest;
  Okazało się, że był on klasy user (dziwne, bo zazwyczaj konta komputerów mają znak dolara na końcu)
  Miał ustawioną flagę isCriticalSystemObject na true
  SAMAccountType był ustawiony na wartość: 0x30000002. zgodnie z MSDN oznacz to, że jest to konta użytkownika relacji zaufania (SAM_TRUST_ACCOUNT http://msdn.microsoft.com/en-us/library/cc228417.aspx); potrzebne są one do zestawiania secure channel pomiędzy kontrolerami z róznych domen: http://support.microsoft.com/kb/128489 
• Ponowna weryfikacja braku trust-u;
  Nie ma go. Nie pojawia się w konsoli AD Domains & Trusts oraz nie istnieje jego TDO w kontenerze system (http://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx)
• SAMAccountName konta był wyglądał następująco:
  

No i dzięki temu wiedzieliśmy, co się stało (taka zmiana sAMAccountName następuje dla obiektów skonfliktowanych w czasie replikacji). Wynik analizy był następujący:
Niekasowalny obiekt jest wynikiem stworzenia konfliktowej relacji zaufania (na dwóch serwerach jednocześnie). najprawdopodobniej relacja zaufania jeszcze się nie zreplikowała do któregoś z kontrolerów domeny i PDC Emulator (który jest odpowiedzialny za utrzymanie relacji zaufania) był wyłączony. Więc rola FSMO została przejęta, relacja zaufania została stworzona ponownie na innym DC. Po wznowieniu łączności ze starym PDC, sytuacja się sama rozwiązała, ale powstały obiekty CNF (zgodnie z http://technet.microsoft.com/library/Cc961782). Na szczęście taki obiekt nikomu nie wadzi, więc nie trzeba go kasować. Na zawsze pozostanie w bazie danych. Jedyny problem, jaki może się pojawić w przyszłości, to próba zestawienia trust-u z inna domeną o nazwie CORP. Żeby temu zapobiec, wystarczy zmienić DN felernego obiektu.

PS. Inną opcją stworzenia takich obiektów jest… odzyskanie ich z AD Recycle Bin. Ale jednakowo nie będą one usuwalne.

Miło mi poinformować, że właśnie otwarto rekrutację do naszego zespołu na stanowisko

  
               Premier Field Engineer – SharePoint

Jeżeli…

• jesteś ekspertem w technologii SharePoint,
• masz doświadczenie zdobyte podczas pracy na dużych środowiskach,
• preferujesz bezpośredni kontakt z klientem,
• nudzi Cię monotonia,
• masz pasję i chcesz się nią dzielić…

… gratuluję! Właśnie znalazłeś wymarzoną pracę!!! ;-)

Więcej szczegółów na temat stanowiska można znaleźć tutaj:
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=1&jid=117827&jlang=EN&pp=SS

W razie pytań zapraszamy do komentowania.