Polski TechNet Blog https://docs.microsoft.com/archive/blogs/plitpro/feed.xml Thu, 21 Jun 2018 14:08:59 GMT en-US hourly 1 Bliżej chmury publicznej - Zarządzanie urządzeniami mobilnymi w Office 365 https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-zarzadzanie-urzadzeniami-mobilnymi-w-office-365 Thu, 21 Jun 2018 16:08:58 GMT https://blogs.technet.microsoft.com/plitpro/?p=14445 Sposoby zarządzania urządzeniami Firma Microsoft oferuje kilka sposobów zarządzania urządzeniami mobilnymi, które dostępne są w usłudze Office 365. Mamy tutaj dostępne 3 opcje:
  • ActiveSync
  • Mobile Device Management for Office 365
  • Microsoft Intune

ActiveSync

Klasyczna metoda dostępu do poczty korporacyjnej za pomocą ActiveSync znana głównie z rozwiązań On-Premises w Exchange Server. Z poziomu urządzenia mobilnego uzyskujemy dostęp do poczty korporacyjnej za pomocą klienta pocztowego uruchomionego na urządzeniu mobilnym. Podczas pierwszej próby podłączenia urządzenia do systemu urządzenie mobilne otrzymuje polityki, które zostały skonfigurowane przez administratora systemu pocztowego Exchange Online w Office 365. Za pomocą polityk administrator może wymusić na użytkowniku wprowadzenie blokady hasła, zaszyfrować urządzenie lub wymusić politykę haseł. W celu konfiguracji polityk ActiveSync należy zalogować się do Exchange Online za pomocą przeglądarki na adres: https://outlook.office.com/ecp. Następnie przejść do zakładki mobile -> mobile device mailbox policies i za pomocą ikony „plusa” z menu utworzyć nową politykę lub edytować domyślną - Default (Rys. 1)

Rys. 1. Konfiguracja polityk ActiveSync w Exchange Online

Zarządzanie urządzeniami mobilnymi za pomocą polityk ActiveSync sprowadza się tylko i wyłącznie do konfiguracji polityk, które opisałem powyżej. Nie ma centralnego miejsca z poziomu którego można wyświetlić wszystkie urządzenia i przeprowadzić dodatkową konfigurację.

Mobile Device Management for Office 365

Narzędzie MDM for Office 365 pozwala na zarządzanie urządzeniami mobilnymi w ramach Organizacji w Office 365. Konfiguracja odbywa się z poziomu „ubogiej” konsoli dostępnej z poziomu Office 365 Security & Compliance. Jest bezpłatnym narzędziem do zarządzania urządzeniami mobilnymi w Office 365. Wspiera platformy z systemem: iOS, Android oraz Windows Phone. W celu uruchomienia konsoli Device Management należy zalogować się do swojej subskrypcji w Office 365 przy użyciu adresu https://protection.office.com przejść do Data loss prevention -> Device managemnt. W nowym oknie pojawi się konsola z poziomu, której można zobaczyć podłączone urządzenia mobilne do systemu (Rys. 2).

Rys. 2. Konsola – Mobile Device Management for Office 365

Konfigurację polityk wykonuje się z poziomu konsoli https://protection.office.com, gdzie należy przejść do sekcji Data loss prevention -> Device security policies (Rys. 3). Za pomocą przycisku +Create a policy tworzymy politykę i przypisujemy ją do grupy użytkowników korzystających z Office 365.

Rys. 3. Listing polityki w MDM for Office 365

Do uruchomienia funkcji MDM for Office 365 należy wykonać poniższe kroki:
  • Konfiguracja rekordów DNS dla obsługiwanej domeny w Office 365
  • Konfiguracja APN dla urządzeń iOS (w przypadku wykorzystywania urządzeń Apple)
  • Konfiguracja MFA (opcjonalnie)
  • Konfiguracja i dostosowanie polityk do wymogów bezpieczeństwa
Szczegółowy opis konfiguracji oraz wymaganych kroków do uruchomienia usługi MDM for Office 365 znajduje się w poniższym linku: https://support.office.com/en-us/article/set-up-mobile-device-management-mdm-in-office-365-dd892318-bc44-4eb1-af00-9db5430be3cd

Microsoft Intune

Usługa Microsoft Intune jest dodatkowo płatnym produktem do zarządzania urządzeniami mobilnymi, który można uruchomić w ramach pojedynczej licencji  InTune lub w pakietach Enterprise Mobility + Security (E3, E5), Microsoft 365 (E3,E5), Microsoft 365 Business lub Microsoft 365 Education (A1, A3,A5). Microsoft Intune jest „kombajnem” z poziomu, którego można zarządzać urządzeniami z systemem iOS, Android, Windows czy macOS. Zarządzanie urządzeniami mobilnymi wykonuje się w poziomu konsoli (Rys. 4) która jest dostępna pod adresem https://portal.azure.com.

Rys. 4. Konsola do zarządzania urządzeniami mobilnymi - Microsoft Intune

Z poziomu konsoli konfigurujemy urządzenie, które na początku musi spełnić szereg wymagań (sekcja - Device compliance) przez podłączeniem do zasobów firmowych, gdzie następnie za pomocą polityk konfiguracyjnych (sekcja - Device Configuration) zarządzamy urządzeniami mobilnymi. Na koniec z poziomu konsoli Microsoft InTune można wykonywać deployment aplikacji (sekcja - Mobile apps) oraz skonfigurować dostęp (sekcja Conditional access). Polityki zgodności (Device compliance) konfiguruje się per platforma mamy tutaj do dyspozycji: Android, Android for Work, iOS, macOS, Windows Phone 8.1, Windows 8.1 and later oraz Windows 10 and later. Przykładowo przy wyborze platformy Android for Work można sprawdzać stan zdrowia urządzenia (np. czy nie jest rooted), wprowadzić dla jakiej wersji OS dana polityka działa i na końcu sprawdzić takie elementy jak hasło do urządzenia, szyfrowanie czy blokowanie aplikacji z nieznanych źródeł. Tryb Android for Work (Rys. 5) jest bardzo ciekawą funkcją, która tworzy dedykowaną „przestrzeń” na urządzaniu mobilnym w której instalowane są aplikacje zarządzane z poziomu systemu Microsoft Intune. W celu podłączenia urządzenia do systemu Microsoft Intune (oraz MDM for Office 365) z systemem Android wymagana jest instalacja aplikacji Intune – portal firmy ze sklepu Google Play.

Rys. 5. Android for Work

Polityki konfiguracyjne (Device Configuration) tak jak w przypadku polityk zgodności konfiguruje się per platforma. Z tego poziomu wprowadzamy ograniczenia na urządzeniach mobilnych oraz wymuszamy pewne zasady. Przykładowo dla platformy Android for Work możemy wymusić politykę haseł, która będzie wymagana podczas próby uruchomienia aplikacji z poziomu „przestrzeni” Android for Work (Rys. 6)

Rys. 6. Device Configuration – Android for Work

Co wybrać?

Opcje mamy trzy 😊 tradycyjna odpowiedź to zależy… głównie od tego czy chcemy dopłacać do Microsoft Intune i wykorzystywać opcje takie jak deployment aplikacji, posiadać dobrą konsole z perspektywy administratora do zarządzania, czy z perspektywy użytkownika końcowego mieć możliwość zmiany/resetu hasła passcode na urządzeniu mobilnym w przypadku zapomnienia hasła – co w przypadku wykorzystania ActiveSync lub MDM for Office 365 wiązałoby się z wyczyszczeniem urządzenia do ustawień fabrycznych.

Podsumowanie

Systemy do zarządzanie urządzeniami mobilnymi stają się coraz bardziej popularne w związku z tym organizacje coraz częściej się zastanawiają nad ich wykorzystaniem. Powyższy artykuł opisywał produkty do zarządzania  urządzeniami mobilnymi z perspektywy firmy Microsoft. Natomiast jakiś czas temu robiłem szerszy przegląd rynku pod kątem produktów MDM. W związku z tym myślę, że dodatkowo warto sprawdzić co konkurencja w tym temacie do powiedzenia. /Bartłomiej Prokocki]]> Bliżej chmury publicznej - Podpisywanie i szyfrowanie wiadomości z wykorzystaniem S/MIME w Office 365 https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-podpisywanie-i-szyfrowanie-wiadomosci-z-wykorzystaniem-smime-w-office-365 Sat, 05 May 2018 09:18:42 GMT https://blogs.technet.microsoft.com/plitpro/?p=14315 Certyfikaty… Do podpisywania i szyfrowania wiadomości przy użyciu S/MIME zostanie wykorzystany certyfikat użytkownika, który został wygenerowany w lokalnym Centrum Autoryzacji (Rys. 1). W związku z tym, że certyfikat pochodzi z lokalnego CA: FarbeniRootCA certyfikat ten jest zaufany tylko w obrębie organizacji. Na zewnątrz organizacji certyfikat ten jest niezaufany, ponieważ jego Root CA nie został potwierdzony przez zaufanego dostawcę certyfikatów, który znajduje się w storze certyfikatów Zaufane główne urzędy certyfikacji.

Rys.1. Certyfikat użytkownika z lokalnego CA

W przypadku wykorzystania certyfikatów do podpisywania i szyfrowania wiadomości wysyłanych poprzez Exchange Online z Office 365 wymagany jest upload certyfikatu FarbeniRootCA do Office 365 w formacie SST. Przed rozpoczęciem prac za pomocą poniższych poleceń (Rys. 2) wykonamy listing oraz eksport certyfikatu z lokalnego stora z Zaufane główne urzędy certyfikacji do formatu SST. 
Get-ChildItem – Patch Cert:\LocalMachine\Root
$cert = Get-ChildItem – Patch Cert:\LocalMachine\Root\{GUID_CERTYFIKATU}
Export-Certificate -Cert $cert -FilePath C:\FarbeniRootCA.sst -Type SST

Rys. 2. Listing certyfikatów

Następnie łączymy się do Exchange Online za pomocą PowerShella i umieszczamy certyfikat FarbeniRootCA w Office 365 (Rys. 3). Przed wgraniem certyfikatu warto upewnić się czy ktoś wcześniej nie umieścił tam innego certyfikatu. Weryfikację oraz wgranie certyfikatu wykonujemy za pomocą poniższych poleceń: 
Get-SmimeConfig | select SMIM* | fl
$sst = Get-Content C:\FarbeniRootCA.sst -Encoding Byte
Set-SmimeConfig -SMIMECertificateIssuingCA $sst

Rys. 3. Upload certyfikatu do Exchange Online w Office 365

Po poprawnie przeprowadzonych krokach certyfikat z lokalnego Centrum Autoryzacji znajduje się już w Exchange Online.

Konfiguracja Outlooka

Gdy certyfikat z lokalnego Root CA znajduje się już w Exchange Online, a użytkownik w naszym przypadku Zygmunt Nowak wygenerował swój imienny certyfikat z FarbeniRootCA to oznacza , że można już przejść do następnego etapu: procesu konfiguracji Outlooka.Z poziomu Outlooka 365 Pro Plus / Outlook 2016 należy przejść odpowiednio do lokalizacji Plik -> Opcje -> Centrum zaufania -> Ustawienia Centrum zaufania. W oknie Centrum zaufania (Rys. 4) przechodzimy do zakładki Zabezpieczenia poczty e-mail i wybieramy opcję Ustawienia.

Rys. 4. Office 365 ProPlus – Centrum zaufania

W oknie Zmienianie ustawień zabezpieczeń w polu Certyfikat podpisujący klikamy w Wybierz i wybieramy certyfikat użytkownika w moim przypadku jest to Zygmunt Nowak. Taką samą czynność wykonujemy w polu Certyfikat szyfrowania (Rys. 5) i klikamy OK.

Rys. 5. Office 365 Pro Plus – Konfiguracja S/MIME do podpisywania i szyfrowania wiadomości

Po wyborze certyfikatu w oknie Centrum zaufania dodatkowo należy opublikować certyfikat w GLA. W tym celu klikamy w przycisk Publikuj w GLA. Po poprawnie przeprowadzonych krokach możemy wysłać podpisaną wiadomość.

Podpisywanie i szyfrowanie wiadomości

Pierwszą czynnością, którą należy wykonać w przypadku gdy chcielibyśmy wysyłać zaszyfrowaną wiadomość jest wysyłka podpisanej wiadomości przez nadawcę do swojego odbiorcy i następnie odpisanie odbiorcy na przesłanego maila przez nadawcę – jest to tzw. wymiana kluczy. Podczas wysyłki takiego maila w moim przypadku nadawcą będzie Zygmunt Nowak (zygmunt.nowak@farbeni.pl), a odbiorcą będzie Zofia Jankowska (zofia.jankowska@farbeni.pl). Nadawca w opcjach wiadomości musi zaznaczyć opcję Podpis (Rys. 6 – A) i wysłać wiadomość do Odbiorcy. W skrzynce Odbiorcy pojawi się wiadomość od Nadawcy (Rys. 6 – B) wiadomość taka będzie zawierała ikonę „kłódki” i „orderu”. Gdzie po kliknięciu w „order” będzie można wyświetlić właściwości podpisu cyfrowego (Rys. 6 – C)

Rys. 6. Przesyłanie podpisanej wiadomości – w ramach organizacji

Powyżej opisane czynności mają zastosowanie w przypadku gdy adresat i nadawca pracują w ramach jednej organizacji. W przypadku gdy chcielibyśmy wysyłać podpisane wiadomości pomiędzy różnymi organizacjami wykonujemy dokładnie takie same czynności oraz dodatkowo w przesłanym mailu przez Nadawcę pojawi się informacja, że wystąpiły problemy w podpisem (Rys. 7 – A). Należy kliknąć w ikonę wykrzyknika i za pomocą przycisku Ufaj - zaufać nadawcy (Rys. 7 – B). Oczywiście należy sprawić pola, kto wystawiał certyfikat oraz do kiedy dany certyfikat jest ważny.

Rys. 7. Przesyłanie podpisanej wiadomości – poza organizacją

W momencie gdy użytkownicy przesłali pomiędzy sobą podpisane wiadomości i wymienili się swoimi certyfikatami mogą szyfrować korespondencję z wykorzystaniem S/MIME. Podczas redagowania nowej wiadomości Nadawca w opcjach musi zaznaczyć Szyfruj oraz Podpisz (Rys. 8 - A). W skrzynce odbiorczej Odbiorcy pojawi się wiadomość z ikonką „kłódki” – która oznacza że wiadomość jest zaszyfrowana oraz z ikoną „orderu” który oznacza, że wiadomość jest również podpisana (Rys. 8 – B). Dodatkowo użytkownik może sprawdzić poprawność podpisania i zaszyfrowania wiadomości klikając w „kłódkę” wyświetlając właściwości zabezpieczeń wiadomości (Rys. 8 – C).

Rys. 8. Szyfrowanie wiadomości

Po wykonaniu opisanych powyżej czynności użytkownicy systemu pocztowego mogą wymieniać pomiędzy sobą szyfrowaną korespondencję.

Potencjalne problemy

Czasami zdarza się, że pomimo tego że użytkownicy wymienili się kluczami wysyłając do siebie podpisane wiadomości to i tak występują problemy z wymianą szyfrowanych maili. Najczęstszym rozwiązaniem problemu jest dodanie odbiorcy do lokalnej książki adresowej użytkownika oraz podczas wysyłki wiadomości korzystanie z podpowiedzi w Outlooku. UWAGA! Utrata certyfikatu użytkownika może spowodować problemy w odczytem zaszyfrowanych wiadomości. W związku z tym należy pamiętać o backupie certyfikatu użytkownika z kluczem prywatnym.

Podsumowanie

W dzisiejszych czasach coraz częściej można spotkać się z podszywaniem pod czyjąś tożsamość lub próbę wyłudzenia kluczowych danych z organizacji. Wykorzystanie podpisu elektronicznego oraz szyfrowania to kolejny element układanki z zakresu bezpieczeństwa o którym należy pamiętać i go wykorzystywać. /Bartłomiej Prokocki]]> Bliżej chmury publicznej - Azure Multi-Factor Authentication https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-azure-multi-factor-authentication Mon, 19 Mar 2018 11:49:30 GMT https://blogs.technet.microsoft.com/plitpro/?p=14245 Jak włączyć? W celu włączenia funkcji Azure Multi-Factor Authentication w Office 365 należy wykonać opisane poniżej kroki. Zalogować się do konsoli admin center za pomocą przeglądarki wpisując adres https://portal.office.com przejść do zakładki Users -> Active Users i z menu środkowego wybrać opcję More -> Setup Azure multi-factor auth (Rys. 1)

Rys. 1. Office 365 – panel administratora

W oknie multi-factor authentication (Rys .2) należy wskazać konto użytkownika dla którego chcemy włączyć uwierzytelnienie wieloskładnikowe zaznaczając go za pomocą „fajki” i następnie w oknie quick steps wybrać opcję Enable. Podczas włączania zostaniemy ponownie poproszeni o potwierdzenie próby włączenia MFA, gdzie następnie zostanie wyświetlona informacja, że dana funkcjonalność została poprawnie włączona. Voila 😊

Rys. 2. Włączanie funkcji Multi-Factor Authentication

Next step

Po włączeniu Multi-Factor Authentication, użytkownik podczas pierwszej próby zalogowania się do usługi Office 365 zostanie poproszony o skonfigurowanie dodatkowej weryfikacji dla swojego konta (Rys. 3). Mamy tutaj do wyboru cztery opcje:
  • Call to phone – użytkownik otrzymuje telefon z usługi Office 365,
  • Text message to phone – użytkownik otrzymuje smsa na wskazany numer telefonu,
  • Notification through mobile app – użytkownik otrzymuje powiadomienie w aplikacji Microsoft Authenticator, którą musi wcześniej pobrać na swoje urządzenie mobilne,
  • Verification code from mobile app - użytkownik otrzymuje kod weryfikacyjny w aplikacji Microsoft Authenticator, którą musi wcześnie pobrać na swoje urządzenie mobilne

Rys. 3. Konfiguracja dodatkowej weryfikacji w Multi-Factor Authenticator

W przypadku gdy w opcji Mobile app wskazaliśmy tryb weryfikacji jako Receive notifications for verification to z poziomu urządzenia mobilnego w aplikacji Microsoft Authenticato,r należy dodać konto które chcemy skonfigurować przy pomocy kodu QR. W następnym kroku należy podać swój numer telefonu na wypadek utraty dostępu do aplikacji Microsoft Authenticator. Po poprawnie wykonanych czynnościach funkcja MFA dla użytkownika została skonfigurowana. Od tego momentu użytkownik przy każdej próbie dostępu do zasobów w Office 365 będzie musiał dodatkowo potwierdzić próbę dostępu w aplikacji (Rys. 4)

Rys. 4. Dodatkowa weryfikacja w aplikacji Microsoft Authenticator.

Seamless SSO

Podczas codziennego korzystania z usługi Office 365 każdorazowa weryfikacja użytkownika może okazać się uciążliwa, a wykorzystanie usługi Office 365 stanie się problematyczne. Z pomocą przychodzi tutaj Seamless SSO. Za pomocą tej opcji w przypadku gdy użytkownik loguje się z zaufanej lokalizacji / strefy nie musi dodatkowo potwierdzać swojej tożsamości. Funkcję Seamless SSO włącza się z poziomu narzędzia Azure AD Connect -> Tasks -> Change user sign-in (Rys. 5). W kreatorze należy zaznaczyć opcję Enable single sign-on. Po włączeniu tej opcji w usłudze katalogowej Active Directory dla której włączyliśmy Seamless SSO pojawi się obiekt komputera o nazwie AZUREADSSOACC

Rys. 5. Włączenie opcji Seamless SSO z poziomu narzędzia Azure AD Connect

Dodatkowo musimy włączyć opcję conditional access w Azure. W tym celu należy zalogować się na portal Azure za pomocą przeglądarki wpisując adres https://portal.azure.com  przejść do zakładki Azure Active Directory -> Conditional access -> Named locations i za pomocą przycisku New location dodać nazwę oraz publiczny adres IP z którego będziemy logowali się do usługi Office 365 i chcemy włączyć funkcję Seamless SSO. Po poprawnie wykonanych czynnościach funkcja MFA z SSO została poprawnie włączona. /Bartłomiej Prokocki]]> Bliżej chmury publicznej - Kopia zapasowa środowiska Exchange Online https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-kopia-zapasowa-srodowiska-exchange-online Thu, 30 Nov 2017 13:58:00 GMT https://blogs.technet.microsoft.com/plitpro/?p=14225 artykule opisywałem w jaki sposób przeglądać oraz eksportować logi z Message Tracking do lokalnego środowiska. W niniejszym artykule przyjrzymy się backupie skrzynek pocztowych użytkowników w Exchange Online. Sprawa jest o tyle istotna ponieważ backup i jego odtwarzanie jest bardzo ważnym elementem, który może wpłynąć na stabilne działanie biznesu w przypadku pojawienia się nieoczekiwanej awarii. Co gorsze funkcjonalności jako takiej backupu w Exchange Online nie ma więc tym bardziej warto zgłębić temat.

Natywne mechanizmy odzyskiwania w Exchange Online

Exchange Online wykorzystuje natywne mechanizmy wysokiej dostępności znane jako Database Availability Groups. Mechanizmy te zostały zaimplementowane w system Exchange Server On-Premise od wersji 2013. Skrzynki pocztowe w Exchange Online są replikowane i synchronizowane pomiędzy Microsoftowymi Datacentrami. Co w rezultacie w przypadku awarii jednego Datacenter w dalszym ciągu zapewnia dostęp do aktualnych danych skrzynki pocztowej. Problem pojawia się gdy użytkownik przez przypadek lub celowo skasuje wiadomość i zechce ją ponownie odzyskać. W zależności od planów w usłudze Office 365 mamy nałożone odpowiednie ograniczenia, które mają wpływ na ilość przechowywanych danych i możliwości ich odzyskiwania w Office 365 są to takie elementy jak:
  • Storage Limit - limit podstawowej skrzynki pocztowej
  • Archive quota - limit archiwum skrzynki pocztowej
  • Recoverable Items folder quota - limit folderu dla elementów do odzyskania
  • In-Place Hold / Litigation Hold / eDiscovery Hold
  • Messaging Records Management Polices: Deleted Items, Recoverable items / Retention Tags / Polices
Limity skrzynek pocztowych różnią się w zależności od posiadanego planu w Office 365. W najbardziej popularnych planach limit taki wynosi 50GB per użytkownik oraz 50 GB per archiwum. Mówiąc o archiwum należy wspomnieć , że tak naprawdę prawdziwe archiwum dostępne jest tylko w planach Office 365 Enterprise E3 i E5 ponieważ w tych planach nie ma ograniczeń co do jego wielkości. Szczegółowe porównanie dla poszczególnych subskrypcji można znaleźć w poniższym linku: https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx W przypadku gdy wielkość skrzynki pocztowej użytkownika będzie wynosiła 40 GB pojawi się ostrzeżenie, które jest pierwszym sygnałem ostrzegawczym informującym użytkownika, że powinien wykonać porządki w swojej skrzynce pocztowej. Następne ostrzeżenie pojawi się gdy wielkość skrzynki wyniesie 49.5 GB – zostanie zablokowane wysyłanie. Gdy wielkość dojdzie do 50 GB przepływ wiadomości jest całkowicie blokowany: nie można wysyłać i odbierać wiadomości - należy skasować zbędne maile lub przenieść do archiwum. Gdy wiadomości zostaną skasowane zostają przenoszone do katalogu Elementy Usunięte (krok 1 - Rys 1) gdzie następnie zgodnie z politykami retencji są kasowane i przenoszone do katalogu Odzyskiwania elementów. Zgodnie z domyślną polityką maile z katalogu Odzyskiwania elementów przechowywane są przez 14 dni po tym okresie nie można ich już odzyskać. W przypadku gdy chcielibyśmy pominąć folder z katalogiem Odzyskiwania elementów maile należy skasować z kombinacją klawiszy Shift + Delete (krok 2 – Rys 1)

Rys. 1. Polityki retencji

In-Place Hold / Litigation Hold / eDiscovery Hold jest bardzo przydaną funkcjonalnością za pomocą której możemy „zatrzymać” wszystkie maile dla konkretnej skrzynki bądź wskazanych lub wszystkich skrzynek pocztowych przechowywanych w usłudze Office 365. Coraz częściej zdarzają się przypadki, że korespondencja pocztowa potrzebna jest na wypadek odejścia pracownika z firmy, który wraz ze sobą „zabiera” swoją korespondencję i kasuję ją ze swojej skrzynki pocztowej co gorsza wynosi na zewnątrz. Funkcja In-Place Hold pomoże nam „zatrzymać” takie wiadomości w naszej organizacji pomimo tego, że zostaną one skasowane lub przeniesione przez użytkownika. W konfiguracji takiej możemy wskazać by były przetrzymywane konkretne wiadomości np. od określonych nadawców, w określonym przedziale czasowym bądź z określonym słowem kluczowym. Następnie za pomocą eDiscovery Hold możemy wyszukać takie wiadomości i docelowo wyeksportować do pliku PST Polityki MRM / Retention Polices automatycznie przenoszą stare lub odpowiednio skategoryzowane wiadomości do archiwum lub pozwalają na odzyskiwanie skasowanych wiadomości zgodnie z domyślnymi lub skonfigurowanymi politykami. Porównanie oraz opis domyślnych polityk w systemie Exchange Online vs. Exchange On-Premise można znaleźć w poniższym linku: https://technet.microsoft.com/en-us/library/dn775046(v=exchg.150).aspx

Co dodatkowo robią admini…

Jedną z najprostszych metod zabezpieczenia się przez przypadkowym skasowaniem wiadomości przez użytkownika jest wykorzystanie mechanizmu Journal Rules poprzez utworzenie reguły, która zapisuje wszystkie wysyłane i odbierane wiadomości do Journala umieszczonego w Office 365 z którego w późniejszym czasie można odzyskać pojedyncze elementy. W przypadkach gdy pracownik odchodzi z firmy, a pozostali współpracownicy potrzebują mieć dostęp do korespondencji byłego pracownika zalecane jest wykonanie konwersji skrzynki użytkownika do Shared Mailbox. Dzięki takiej operacji, nasza organizacja zaoszczędzi na licencjach, a dla zainteresowanych pracowników skrzynka typu Shared Mailbox zostanie podłączona do osobistej skrzynki pocztowej. Opis sposobu wykonania konwersji skrzynki typu user mailbox do shared mailbox można znaleźć w poniższym linku: https://support.office.com/en-us/article/Convert-a-user-mailbox-to-a-shared-mailbox-2e122487-e1f5-4f26-ba41-5689249d93ba Co się dzieje ze skrzynkami starych pracowników? Najczęściej licencje są odpinane od skrzynek użytkowników, a skrzynki „archiwalne” pozostają w chmurze. Myślę, że to kwestia czasu kiedy Microsoft wprowadzi licencje dla tego typu „skrzynek”

Co jeszcze?

W przypadku gdy to co zostało opisane we wcześniejszych punktach to za mało, możemy użyć narzędzi firm trzecich lub samodzielnie napisać dedykowane skrypty do backupu pojedynczych skrzynek do pliku PST w lokalnym środowisku. Obecnie na rynku jest bardzo dużo rozwiązań firm trzecich za pomocą których można tradycyjnie wykonywać backup na wskazany zasób lub do „chmury” danego producenta. Według mojej analizy i oceny na szczególną uwagę zasługuje nasz lokalny producent firma CodeTwo, która specjalizuje się w produktach związanych z pocztą Exchange zarówno tej On-Premises jak i Online – w swoim portfolio posiada produkt CodeTwo Backup for Office 365 za pomocą którego można wykonywać backup skrzynek z Exchange Online w Office 365. Dodatkowo podczas samodzielnej analizy i poszukiwań produktów do backupu Exchange Online myślę, że warto zwrócić uwagę na poniższe produkty:
  • Veeam Backup for Microsoft Office 365
  • AvePoint Exchange Online Backup and Recovery
  • SysTools Office 365 Backup
  • SkyKick Office 365 Backup

Podsumowanie

W Exchange Online w Office 365 zaraz po tradycyjnych logach SMTP brakuje mechanizmu dla zapewnienia tradycyjnego backupu znanego ze środowisk Exchange On-Premises. Mam nadzieję, że w przyszłości pojawi się natywny mechanizm, za pomocą którego będzie można wykonywać taki backup i odzyskiwać granularnie pojedyncze elementy. A Wy jakich metod zabezpieczeń dla skrzynek pocztowych w Exchange Online używacie u siebie? Gorąco zachęcam do dzielenia się swoimi doświadczeniami w komentarzach. /Bartłomiej Prokocki]]> Webowe narzędzie do zarządzania serwerami Windows - Microsoft Project "Honolulu" https://docs.microsoft.com/archive/blogs/plitpro/webowe-narzedzie-do-zarzadzania-serwerami-windows-microsoft-project-honolulu Tue, 31 Oct 2017 10:00:09 GMT https://blogs.technet.microsoft.com/plitpro/?p=14137
  • Gateway server do zarządzania danymi – pobiera dane poprzez Remote PowerShell oraz WMI over WinRM. Nie potrzeba więc instalować żadnych agentów, co jest super.
  • Serwer Web’owy – interfejs dla admina
    • Czy to nie wygląda jakoś znajomo? Tak – to dokładnie to samo podejście które było w Server Management Tool (SMT) które działało w środowisku Azurowym – było w wersji preview do końca czerwca – SMT zostało jednak ubite zanim wyszła finalna wersja. Wygląda jednak na to, że Project Honolulu jest w pewnym sensie następcą SMT. Zobaczcie poniżej na wersje produktów pakietów instalacyjnych gateway’a dla obu narzędzi. Jak dla mnie wygląda to na kolejne build’y tego samego narzędzia - 1.0 jeszcze pod nazwą SMT, 1.1 już jako Honolulu. Z tą różnicą, że zamiast w Azure wszystko może działać z środowisku lokalnym. Instalacja jest dosyć prosta i nie powinna nastręczyć dużo problemów. Narzędzie możemy zainstalować na serwerach WS2016 i nowszych oraz na Windows 10. Pierwszym problemem na jaki możecie się natknąć jest przeglądarka. Jedyna wbudowana w Windows Server 2016 przeglądarka, Internet Explorer jest niewspierana. Trzeba doinstalować na serwerze inną przeglądarkę lub łączyć się do usługi z desktopa.   Po instalacji Project’u Honolulu możemy przejść do dodania zarządzanych serwerów. W Honolulu możemy zarządzać serwerami Windows od wersji WS2012 aż do najnowszej wersji WS2016 (1709). Pamiętajmy, że to narzędzie wciąż jest w fazie deweloperskiej, więc niektóre funkcjonalności podstawowego WS2016 mogą wciąż być jeszcze nie wspierane np. Storage Space Direct (S2D). Z powodu brakujących kilku komend PowerShellowych - Windows Server 2012 oraz 2012R2 wymaga dogrania WMF5.0 lub nowszego, aby można było nim zarządzać z Honolulu. Oczywiście, serwer gateway’a Honolulu powinien mieć odpowiednio skonfigurowane TrustedHosts – pewne prace mogą być więc wymagane w środowiskach grup roboczych. Do konsoli możemy dodać serwery typu Standalone, klastry Failover oraz klastry Hyper-Converged. Ok, “pokaż konsole” możecie powiedzieć. Więc, … proszę :)     Gdy otworzycie konsolę możecie wybrać którym komputerem chcecie zarządzać. Po wybraniu jednego z serwerów w panelu z lewej strony możecie znaleźć obszary/narzędzia, które można użyć. W panelu po prawej stronie, szczegółowe informacje dla wybranego narzędzia.   Przejdźmy teraz do opcji Hyper-V. Dla przypomnienia – do Honolulu możemy dodawać zarówno pojedyncze hosty Hyper-V oraz całe klastry. Nie ma potrzeby skakania pomiędzy Hyper-V Manager i Failover Cluster Manager. Można użyć tylko tego narzędzia, gdy wyjdzie już w wersji finalnej. W buildzie TechnicalPreview wciąż brakuje kilku ustawień, opcji, …. Widok maszyn wirtualnych ma 2 zakładki: Summary i Inventory. Widok Summary pokazuje ogólne informacje i statystyki dla naszych maszyn wirtualnych. W widoku Inventory możemy działać na konkretnych VMkach.   W opcjach ustawień dla Project’u Honolulu można znaleźć opcje wyboru języka w jakim konsola ma pracować (tylko angielski w fazie TP) oraz opcje związane z rozszerzeniami – które są bardzo ciekawe. Domyślnie jest już kilka rozszerzeń zainstalowanych. Aby dodać kolejne potrzebujemy nuget package uri. Można się więc spodziewać, że będą tu dodawane kolejne narzędzia z Microsoftu. Może to być również opcja na integrację z narzędziami firm trzecich. Nowe narzędzie Microsoftu może zastąpić wiele innych obecnie używanych przez administratorów Windows. Jest narzędziem webowym, może być więc użyte z dowolnej platformy. Mamy tu również rozszerzenia, dzięki którym w przyszłości można będzie zwiększyć jego możliwości. Jest jeszcze wiele pracy przed developerami Microsoftu przy tym narzędziu, ale trzeba to przyznać - Project Honolulu wygląda obiecująco i jest krokiem w dobrą stronę – czymś czego admini Windows od dawna oczekiwali. -- Mariusz Rybusiński]]>         Bliżej chmury publicznej - Przeglądanie oraz eksport logów Message Tracking z Exchange Online https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-przegladanie-oraz-eksport-logow-message-tracking-z-exchange-online Mon, 30 Oct 2017 10:00:22 GMT https://blogs.technet.microsoft.com/plitpro/?p=14106 Message Tracking Za pomocą narzędzia Message Tracking administrator systemu pocztowego może ustalić przyczynę problemów związanych z dostarczeniem poczty. W szczegółowych logach MT znajdują się informacje takie jak: adres nadawcy, adres odbiorcy, message id, status wiadomości oraz data. Dostęp do takich informacji można uzyskać za pomocą interfejsu Webowego lub za pomocą PowerShella.

    Message Tracking via Web

    W celu uzyskania dostępu do Message Tracking za pomocą interfejsu webowego należy zalogować się do systemu Exchange Online do konsoli zarządzającej za pomocą adresu https://outlook.office365.com/ecp/ przy użyciu poświadczeń administracyjnych. Następnie przejść do zakładki mail flow -> message trace. W zakładce message trace (Rys.1) należy wprowadzić odpowiednie parametry takie jak zakres czasowy (date range), status dostarczenia (delivery status), dodatkowo można wskazać konkretnego nadawcę (dender) lub odbiorcę (recipient)

    Rys. 1. Message Tracking – parametry

    Po wyborze odpowiednich parametrów przechodzimy do następnego etapu za pomocą przycisku search. Pojawi się nowe okno Message Trace Results w którym zostanie wyświetlona lista wyszukanych wiadomości (Rys. 2)

    Rys. 2. Message Tracking – listing wyszukanych wiadomości

    Po wyszukaniu odpowiedniej wiadomości można podejrzeć szczegółowy status danej wiadomości za pomocą przycisku „ołówka”. We właściwościach wiadomości zostanie wyświetlona szczegółowa informacja na temat zdarzeń dla danej wiadomości, które zostały przedstawione na Rysunku 3

    Rys. 3. Message Tracking – szczegóły dostarczenia wiadomości

    W przypadku gdy okres przeszukiwania wiadomości byłby starszy niż 7 ostatnich dni Message Tracking wykorzysta mechanizm historycznego wyszukiwania i prześle podsumowanie na wskazaną skrzynkę pocztową. Pojawią się tutaj dodatkowe opcje w których trzeba określić czy jest to wiadomość wychodząca czy przychodząca do naszego systemu (Direction), adres IP (Original client IP address), tytuł raportu (Report Title) oraz adres na który zostanie wysłany raport (Notification email address).

    Message Tracking via PowerShell

    Dokładnie takie same czynności jakie zostały omówione w sekcji Message Tracking via Web można wykonać za pomocą wiersza poleceń w PowerShellu. Mamy tutaj do dyspozycji dwa rodzaje komend:
    • Get-MessageTrace – komenda wyszukuje wiadomości z ostatnich 7 dni.
    • Start-HistoricalSearch – komenda uruchamia wyszukiwanie historycznych wiadomości do 90 ostatnich dni i przesyła raport na wskazany adres mailowy.
    W celu wyszukania wszystkich wiadomości z ostatnich 48 godzin należy użyć poniższego polecenia (Rys. 4) 
    Get-MessageTrace | Select SenderAddress,RecipientAddress,Received,Status,Subject

    Rys. 4. Wyszukiwanie wiadomości z ostatnich 48 godzin za pomocą PowerShella

    Skrypt

    Należy pamiętać o tym, że logi z Message Tracking w Exchange Online przechowywane są do 90 dni po tym okresie są automatycznie kasowane. Natomiast w Exchange On-Premise to administrator decyduje jak długo informacje z Message Tracking są przechowywane. Często spotykam się z sytuacją kiedy trzeba wrócić do historii wiadomości starczych niż 90 dni. W takim wypadku należy wdrożyć rozwiązanie, które przenosi bieżące logi z Message Tracking „na bok” i w każdym momencie możemy do nich wrócić. Poniższa część skryptu łączy się do naszej subskrypcji za pomocą wskazanych poświadczeń. Skrypt pobiera logi z Message Tracking z ostatniego dnia i je eksportuje, zapisując je do lokalnego środowiska. Dalej logi można przechowywać w dłuższym czasie niż 90 dni. Skrypt taki należy uruchamiać codziennie za pomocą zaplanowanych zadań. Do uruchamiania skryptów wymagana jest instalacja Windows Azure Active Directory for Windows Powershell. 
    $user = "login@nazwasubskrypcji.onmicrosoft.com"
$pass = "password" | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ($user,$pass)
Connect-MsolService -Credential $cred
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $session -AllowClobber
$from=(Get-Date -Hour 0 -Minute 0 -Second 0).AddDays(-1)
$to=(Get-Date -Hour 23 -Minute 59 -Second 59).AddDays(-1)
$logi=((Get-Date).AddDays(-1)).ToString("yyyy/MM/dd")
Get-MessageTrace -StartDate $from -EndDate $to | select SenderAddress, RecipientAddress, Received, Status, Subject | Out-File c:\Logs-$logi.txt
Get-PSSession | Remove-PSSession

    Podsumowanie

    W Exchange Online w Office 365 brakuje mechanizmu przeszukiwania logów z Message Tracking starszych niż 90 dni w związku z tym warto zastanowić się uruchomieniem skryptu eksportu logów „na bok” np. do lokalnego środowiska lub innego zasobu uruchomionego na Azure. Jest jeszcze jeden mankament o którym należy pamiętać: w Exchange Online nie ma typowych logów SMTP znanych z Exchange On-Premises, które były włączane na connectorach. Mam nadzieję, że w przyszłości również w Exchange Online mechanizm taki zostanie zaimplementowany /Bartłomiej Prokocki]]>         Migracja usługi katalogowej Active Directory do systemu Windows Server 2016 https://docs.microsoft.com/archive/blogs/plitpro/migracja-uslugi-katalogowej-active-directory-do-systemu-windows-server-2016 Thu, 28 Sep 2017 11:36:31 GMT https://blogs.technet.microsoft.com/plitpro/?p=14025 Promowanie nowego kontrolera domeny Prace związane z migracją usługi katalogowej Active Directory rozpoczniemy od instalacji systemu operacyjnego Windows Server 2016 Standard – proces instalacji jest bardzo prosty w związku z tym ten krok zostanie pominięty. Po wykonaniu instalacji należy upewnić się że zostały zainstalowane najnowsze aktualizacje, przypisany statyczny adres IP (w moim przypadku 192.168.0.101) oraz wprowadzona została poprawnie nazwa dla kontrolera domeny (w moim przypadku będzie to dc2016), serwer podpinamy do bieżącej domeny (w moim przypadku jest to farbenia.local). Gdy wykonaliśmy wszystkie wyżej opisane czynności możemy przejść do dodania roli. W tym celu w poziomu Server Managera wybieramy opcję Add Roles and Features. Następnie w oknie kreatora wybieramy rolę Active Directory Domain Services dodatkowo automatycznie zostaną zaznaczone narzędzia administracyjne do zarządzania AD DS. i DNS Server. Po przeprowadzeniu instalacji roli Active Directory Domain Services należy wypromować nasz serwer to kontrolera domeny. Z poziomu Server Managera po wykonaniu instalacji pojawi się opcja Post-deployment Configuration – Promote this server to a domain controler, którą należy wybrać (Rys. 1)

    Rys. 1. Promote this server to a domain controller

    W kreatorze Active Directory Domain Services Configuration Wizard w kroku Deployment Configuration wybieramy opcję Add a domain controller to an existing domain. W polu Domain upewniamy się, że widnieje nazwa naszej domeny: farbenia.local (Rys. 2)

    Rys. 2. Deployment Configuration

    W kroku Domain Controller Options zaznaczamy opcję Domain Name System (DNS) server oraz Global Catalog (GC). W polu Password i Confirm Password wprowadzamy hasło do odzyskiwania usług katalogowych Active Directory (Rys. 3)

    Rys. 3. Domain Controller Options

    Pozostałe kroki: DNS Options, Additional Options, Paths itd. zostawiamy domyślnie i na końcu kreatora akceptujemy konfigurację za pomocą przycisku Install, który rozpocznie proces promowania nowego kontrolera domeny w domenie farbenia.local. Po poprawnie przeprowadzonych czynnościach możemy uruchomić narzędzie Active Directory Users and Computers, przejść do jednostki organizacyjnej Domain Controllers i sprawdzić czy pojawił się nowy kontroler domeny dc2016 (Rys. 4)

    Rys. 4. Listing kontrolerów domeny

    Weryfikacja poprawności działania usługi katalogowej Active Directory

    Weryfikację poprawności działania domeny zaczniemy od kluczowego polecenia dcdiag, które sprawdza aktualny stan kontrolerów domeny i raportuje swoje wyniki w wierszu poleceń. Wynik komendy dcdiag został przedstawiony na Rysunku 5.

    Rys. 5. Weryfikacja kontrolera domeny za pomocą polecenia DCDiag

    Kolejnym przydatnym narzędziem do weryfikacji replikacji pomiędzy kontrolerami domeny jest polecenie repadmin z przełącznikami /synccall oraz/showreps Polecenie repadmin /synccall wymusza synchronizację pomiędzy wszystkimi kontrolerami w domenie. Polecenie repadmin /showrepl wyświetla topologię replikacji pomiędzy kontrolerami domeny oraz ich status.

    Przeniesienie ról FSMO na nowy kontroler domeny

    Przed przystąpieniem do przeniesienia ról FSMO (Flexible Single Master Operation) na nowy kontroler domeny z systemem Windows Server 2016 należy zaktualizować usługę katalogową Active Directory za pomocą poniższych poleceń: 
    adprep /forestprep
adprep /domainprep
    Narzędzie adprep znajduje się na nośniku instalacyjnym systemu Windows Server 2016 w katalogu support/adprep Następnie z poziomu wiersza poleceń za pomocą polecenia netdom query fsmo można sprawdzić na którym serwerze aktualnie przechowywane są role FSMO (Rys. 6). Zgodnie z Rysunkiem 6 wszystkie role znajdują się na kontrolerze domeny dc.farbenia.local.
    • Schema master
    • Domain naming master
    • PDC
    • RID pool manager
    • Infrastructure master

    Rys. 6. Listing ról FSMO przed przeniesieniem na nowy kontroler domeny

    Role FSMO można przenieść za pomocą interfejsu graficznego lub za pomocą narzędzia ntdsutil z poziomu wiersza poleceń. Ja osobiście od jakiegoś czasu jestem fanem wiersza poleceń między innymi z prostoty dokumentacji wykonywanych czynności. Z poziomu wiersza poleceń należy uruchomić narzędzie ntdsutil (Rys. 7) Gdzie następnie należy wpisać polecenie connection. Pojawi się informacja, że aktualnie znajdujemy się w opcji fsmo maintenance, gdzie następnie należy wpisać polecenie connections. W tym kroku podłączamy się do kontrolera domeny na który zostaną przeniesione role fsmo wpisujemy connect to server dc2016.farbenia.local. Zostanie wyświetlona informacja o nawiązaniu połączenia z serwerem dc2016. W następnym kroku należy wpisać quit, automatycznie wrócimy do kroku fsmo maintenance gdzie następnie zostanie przeprowadzona migracja ról fsmo. Kolejno należy wpisać:
    • transfer pdc
    • transfer naming master
    • transfer schema master
    • transfer rid master
    • transfer infrastructure master
    Na koniec wychodzimy z fsmo maintenance za pomocą polecenia quit i dalej z narzędzia ntdsutil również za pomocą polecenia quit.

    Rys. 7. Migracja ról FSMO za pomocą ntdsutil

    Deinstalacja starego kontrolera domeny

    Gdy role FSMO zostały przeniesione na nowy kontroler domeny można ponownie sprawdzić na którym kontrolerze domeny aktualnie znajdują się role FSMO (Rys.8)

    Rys. 8. Listing ról FSMO po migracji na nowy kontroler domeny z system Windows Server 2016

    Po poprawnym przeniesieniu ról FSMO można zdepromować stary kontroler domeny. W tym celu z poziomu starego kontrolera domeny dc.farbenia.pl z Server Managera wybieramy opcję Remove Roles and Features, następnie w kroku Server Roles odznaczamy Active Directory Domain Services i DNS Server. Pojawi się informacja, że jest to kontroler domeny i przez usunięciem wybranych elementów należy zdepromować kontroler domeny (Rys. 9) za pomocą przycisku Demote this domain controller.

    Rys. 9. Depromowanie kontrolera domeny

    Gdy aktualny kontroler domeny zostanie zdepromowany serwer można usunąć z domeny, jedynym i aktualnym kontrolerem domeny który przechowuje wszystkie role FSMO jest serwer dc2016.farbenia.pl UWAGA. Należy pamiętać że czasami może zdarzyć się sytuacja że na kontrolerze uruchomione są inne usługi które również należy przenieść przed skasowaniem starego kontrolera domeny. /Bartłomiej Prokocki]]>         Bliżej chmury publicznej - scenariusze migracji skrzynek pocztowych do Office 365 - Exchange Hybrid - część 4 https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-scenariusze-migracji-skrzynek-pocztowych-do-office-365-exchange-hybrid-czesc-4 Wed, 30 Aug 2017 08:10:42 GMT https://blogs.technet.microsoft.com/plitpro/?p=13975
  • długotrwałe wykorzystanie środowska lokalnego oraz środowiska w chmurze z możliwością przenoszenia skrzynek pocztowych i zasobów pomiędzy środowiskami
  • migracja do Office 365 i następnie wygaszenie środowiska lokalnego
    • Ja w tym przypadku skupię się na przełączeniu poczty na środowisko Exchange Online i wygaszeniu Hybrydy dla Exchange Server, która była wymagana na czas migracji zasobów z Exchange On-Premises do Exchange Online

    Przełączenie rekordów MX na Office 365

    Krokiem milowym związanym z wygaszeniem środowiska lokalnego Exchange i rezygnacją z połączenia Hybrydowego  jest przełączenie rekordów pocztowych MX na Exchange Online Protection w usłudze Office 365. Na chwilę obecną rekordy MX dla domeny farbeni.pl wskazują na mail.farbeni.pl które odwołują się do  środowiska lokalnego Exchange Server (Rys. 1).

    Rys. 1. Weryfikacja rekordów MX

    W celu wykonania przełączenia rekordów MX na środowisko Online należy z poziomu witryny Admin center w Office 365 zweryfikować jakie wpisy w publicznym DNSie należy wprowadzić by poprawnie działały z Office 365. W tym celu należy się zalogować do konsoli admin center za pomocą przeglądarki wpisując adres https://portal.office.com przejść do Admin -> Setup -> Domain i wybrać domenę, którą będziemy przełączać. W moim przypadku jest to domena farbeni.pl (Rys 2). W nowy oknie pojawią się rekordy dla Exchange Online, które należy wprowadzić w publicznym DNS.

    Rys. 2. Rekordy dla Exchange Online w publicznym DNS.

    Po poprawnym wprowadzeniu rekordów typu MX, TXT oraz CNAME w publicznym DNS dla domeny farbeni.pl możemy przejść do weryfikacji konfiguracji za pomocą przycisku Continue setup. W kroku Add a domain wybieramy opcję I’ll manage my on DNS records. Następnie w kroku Update DNS setting weryfikujemy listę wprowadzonych rekordów w publicznym DNS i przechodzimy dalej. W następnym kroku kreator zweryfikuje wpisy wymagane dla Exchange Online (Rys. 3). Jak widać wymagane elementy dla Exchange Online zostały dodane i zostały zaznaczone na zielono. Rekordy które świecą na czerwono dotyczą innych usług takich jak Lync czy MDM. Na koniec wybieramy opcję Save and close.

    Rys. 3. Weryfikacja rekordów DNS dla Exchange Online.

    Po poprawnie przeprowadzonych czynnościach poczta dla środowiska Hybrydowego Exchange Server wskazuje na środowisko Exchange Online. Od tego momentu wszystkie wiadomości przysyłane do naszej organizacji filtrowane są za pomocą Exchange Online Protection Po zmianie rekordów w publicznym DNS zalecane jest wykonanie weryfikacji i przepływu poczty wewnątrz jak i na zewnątrz naszej organizacji.

    bye bye Exchange Hybrid…

    Gdy już wszystkie zasoby pocztowe zostały przeniesione z lokalnego środowiska (skrzynki pocztowe użytkowników, skrzynki wspólne) a rekordy pocztowe wskazują już na Exchange Online możemy rozpocząć prace związane z wygaszeniem Hybrydy. W lokalnym środowisku Exchange Server za pomocą Exchange Management Shell i poniższego polecenia konfigurujemy usługę Autodiscover by wskazywała na Office 365. 
    Set-ClientAccessServer ex2016 –AutodiscoverserviceInternalUri https://autodiscover.outlook.com/Autodiscover/autodiscover.xml
    Z poziomu wiersza poleceń weryfikujemy OrganizationRelationShip (Rys. 4) lokalnego środowiska ze środowiskiem online za pomocą polecenia: 
    Get-OrganizationRelationship | select name, domainnames, enabled | fl

    Rys. 4. OrganizationRelationShip – Lokalne środowisko

    Następnie łączymy się do Exchange Online za pomocą Microsoft Azure Active Directory Module for Windows Powershell za pomocą poniższych komend: 
    $credential = Get-Credential
Connect-MsolService -Credential $credential
    i również wykonujemy weryfikacje OrganizationRelationship „z drugiej” strony

    Rys.5. OrganizationRelationShip – Środowisko Online

    Z poziomu lokalnego środowiska kasujemy OrganizationRelationship za pomocą polecenia 
    Remove-OrganizationRelationship -Identity „On-premises to O365 – {GUID}”
    Z poziomu środowiska online kasujemy OrganizationRelationship za pomocą polecenia 
    Remove-OrganizationRelationship -Identity „O365 to On-premises– {GUID}”
    Wszystkie opisane wyżej czynności związane z kasowaniem OrganizationRelationship można wykonać z poziomu konsoli Exchange Admin Center. Gdy już skasowaliśmy relacje pomiędzy Exchange On-Premises, a Exchange Online możemy przejść do skasowania hybrydy za pomocą polecenia Remove-HybridConfiguration (Rys. 6)

    Rys. 6. Remove Hybrid

    Po poprawnie przeprowadzonych czynnościach Hybryda lokalnego systemu pocztowego oraz online została skasowana. Od tego momentu poczta dla naszej organizacji przechowywana jest tylko i wyłącznie w Exchange Online poza naszą organizacją. Konta pocztowe pracowników są synchronizowane do chmury za pomocą narzędzia Azure AD Connect. Bazy z lokalnego środowiska Exchange On-Premises można skasować i odinstalować system Exchange Server, należy natomiast pamiętać że po deinstalacji programu Exchange Server z lokalnego środowiska nie będzie można zarządzać atrybutami dla Exchange z poziomu lokalnej konsoli Exchange Admin Center, która z niektórych przypadkach może być bardzo przydatna. /Bartłomiej Prokocki]]>         Bliżej chmury publicznej - scenariusze migracji skrzynek pocztowych do Office 365 - Exchange Hybrid - część 3 https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-scenariusze-migracji-skrzynek-pocztowych-do-office-365-exchange-hybrid-czesc-3 Thu, 27 Jul 2017 18:25:10 GMT https://blogs.technet.microsoft.com/plitpro/?p=13875 Migracja zasobów

    Skrzynki pocztowe użytkowników

    Główną zaletą środowiska Hybrydowego jest bezproblemowa migracja skrzynek pocztowych pomiędzy lokalnym środowiskiem Exchange Server, a Exchange Online bez wpływu na stabilność przepływu poczty w obrębie organizacji jak i na zewnątrz firmy. Migracja skrzynek pocztowych może być wykonywana w dowolnym czasie i tempie w zależności od preferencji i przyjętego harmonogramu. Po weryfikacji poprawności działania środowiska, możemy przejść do migracji skrzynki pocztowej użytkowników z Exchange On-Premise do Exchange Online. W celu przeniesienia skrzynki do Office 365 logujemy się do Exchange Online za pomocą przeglądarki na adres: https://outlook.office.com/ecp. Następnie przechodzimy do zakładki recipients -> migration i za pomocą ikony „plusa” z menu wybieramy Migrate to Exchange Online (Rys.1).

    Rys. 1. Migracja lokalnej skrzynki do Office 365

    W oknie new migration batch – Select a migrate type, wybieramy rodzaj migracji, którą chcemy przeprowadzić w naszym przypadku będzie to Remote move migration i przechodzimy do dalszego kroku za pomocą przycisku Next. Rodzaje poszczególnych migracji zostały w artykule Bliżej chmury publicznej - Scenariusze migracji skrzynek pocztowych do Office 365.

    Rys. 2. Wybór metody migracji skrzynki pocztowej

    W następnym kroku Select the users (Rys. 3) dodajemy konto użytkownika, które chcemy przenieść do Exchange Online, w moim przypadku będzie to konto Henryka Nowaka z adresem mailowym: Henryk.Nowak@farbeni.pl

    Rys. 3. Wybór użytkownika do migracji do Exchange Online

    W następnej kolejności zostaniemy poproszeni o poświadczenia Administratora do lokalnego środowiska Exchange i wskażemy adres Mailbox Replication Service (MRS) Proxy w moim przypadku będzie to adres farbeni.pl. W kroku Move Configuration (Rys. 4) należy uzupełnić pole New migration batch name oraz wybrać docelową subskrybcję Office 365 w moim przypadku jest to privatelabs.mail.onmicrosoft.com. W opcji Archive zaznaczamy Move the primary mailbox and archive mailbox if one exists, przechodzimy do dalszego kroku za pomocą przycisku Next.

    Rys. 4. Konfiguracja zadania migracji

    W kroku Start the batch należy wskazać skrzynkę pocztową, na którą zostanie przesłany raport z informacją na temat zmigrowanych zasobów. W polach start i complete job wybieramy opcję Automaticaly zgodnie z Rysunkiem 5. Konfigurację akceptujemy za pomocą przycisku new.

    Rys. 5. Konfiguracja zadania migracji

    Rys. 6. Migracja skrzynki pocztowej

    Po poprawnie przeprowadzonych krokach rozpocznie się proces migracji skrzynki pocztowej, który będzie trwał w zależności od ilości migrowanych skrzynek i elementów, ich wielkości oraz przepustowości łącza. Na Rysunku 6 można zobaczyć zadanie MoveToOffice365_1, które zmieniło swój status z Syncing na Completed co oznacza, że skrzynka pocztowa Henryka Nowaka została poprawnie przeniesiona do Office 365. W celu dokonania weryfikacji można przejść do recipients -> mailboxes i zweryfikować typ skrzynki Henryka Nowaka, po migracji powinna być widoczna jako Office 365 (Rys. 7)

    Rys. 7. Weryfikacja skrzynki

    Gdy skrzynka została już przeniesiona do Exchange Online należy pamiętać o przypisaniu licencji do Office 365. Czynności, które należy wykonać zostały opisane w artykule Bliżej chmury publicznej – Scenariusze migracji skrzynek pocztowych do Office 365 – Exchange Hybrid - część 2 w sekcji Tworzenie kont w Office 365. Przed produkcyjną migracją skrzynek pocztowych rekomenduję przeniesienie kilku testowych skrzynek z lokalnego środowiska do online oraz sprawdzić uprawnienia Send as i Send on behalf dla zasobów które będą migrowane.

    Skrzynki wspólne

    Oprócz dedykowanych skrzynek pocztowych użytkowników w środowisku pocztowym Exchange Serwer znajdują się również skrzynki wspólne użytkowników tzn. shared mailboxes, które są wykorzystywane do wspólnej pracy przez klika osób lub traktowane jako repozytorium lub centralne miejsce do przechowywania wiadomości dla poszczególnych działów, projektów, systemów czy innych elementów. Do skrzynek wspólnych nie można bezpośrednio się logować można je przeglądać bezpośrednio ze skrzynki pocztowej użytkownika. Migrację skrzynki wspólnej wykonuje się dokładnie w taki sam sposób jak migracja skrzynki użytkownika. Przed przystąpieniem do migracji skrzynki wspólnej zalecane jest weryfikacja uprawnień.

    Grupy dystrybucyjne

    Grupy dystrybucyjne w Office 365 są synchronizowane za pomocą narzędzia Azure AD Connect. Grupy dystrybucyjne (Distribution group – DL) muszą znajdować się w jednostce organizacyjnej, która jest synchronizowana do Office 365. Zsynchronizowane elementy można podejrzeć z poziomu Admin Center w Office 365 lub z poziom konsoli zarządzającej Exchange admin center (Rys. 8). Grupy dystrybucyjne mogą przekonwertowane do Office Groups.

    Rys. 8. Grupy dystrybucyjne

    Public Folders

    Foldery publiczne od jakiegoś czasu są „złym koszmarem” praktycznie każdego administratora systemu pocztowego, a użytkownicy lokalnych środowisk pocztowych niestety w dalszym ciągu ich używają. Ja za każdym razem gdy spotykam się z klientem próbuję go namówić na to by zrezygnował z folderów publicznych na rzecz nowszych i lepszych rozwiązań w Office 365. Natomiast jeśli padnie wymóg przeprowadzenia takiej migracji to odsyłam do oficjalnej dokumentacji Microsoft, gdzie została opisana procedura krok po kroku w jaki sposób należy przeprowadzić taka migrację: https://technet.microsoft.com/en-us/library/dn874017(v=exchg.150).aspx

    Podsumowanie

    W powyższym artykule opisałem w jaki sposób migrować zasoby z Exchange On-Premise do Exchange Online. W następnej i najprawdopodobniej ostatniej części opiszę wyłączenie lokalnego środowiska wraz z deinstalacją systemu Exchange Server.]]>         Bliżej chmury publicznej - scenariusze migracji skrzynek pocztowych do Office 365 - Exchange Hybrid - część 2 https://docs.microsoft.com/archive/blogs/plitpro/blizej-chmury-publicznej-scenariusze-migracji-skrzynek-pocztowych-do-office-365-exchange-hybrid-czesc-2 Fri, 30 Jun 2017 09:25:44 GMT https://blogs.technet.microsoft.com/plitpro/?p=13785 Aktualny stan Na chwilę obecną środowisko Hybrydowe Exchange Server posiada skrzynki pocztowe tylko i wyłącznie w lokalnej infrastrukturze Exchange 2016 On-Premise. Synchronizacja użytkowników do Azure Active Directory wykonywana jest za pomocą narzędzia Azure AD Connect. Rekordy pocztowe MX wskazują na lokalne środowisko On-Premise Exchange Server 2016.

    Weryfikacja środowiska

    Po zakończonych pracach związanych z konfiguracją połączenia Hybrydowego możemy przejść do weryfikacji i poprawności działania środowiska. Pierwszym elementem weryfikacyjnym jest komenda Get-HybridConfiguration (Rys. 1) którą wykonujemy z poziomu Exchange Management Shell.  Za pomocą tego polecenia wyświetlimy bieżącą konfigurację połączenia Hybrydowego oraz szczegółowe parametry takie jak: nazwa domeny obsługiwanej przez Hybrydę, włączone „Ficzery” takie jak FreeBusy, MoveMailbox, itd…  czy inne przydatne informacje dla Administratora.

    Rys. 1. Weryfikacja połączenie Hybrydowego – polecenie Get-HybridConfiguraion

    Następne polecenie, które wykorzystamy do weryfikacji bieżącej konfiguracji będzie komenda Get-OrganizationRelationShip . Za pomocą której wyświetlimy szczegółowe informacje na temat funkcji FreeBusy, MailboxMoveEnabled, adresu OWA i Autodiscover, nazwy połączenia czy innych przydatnych informacji.

    Rys. 2. Weryfikacja połączenie Hybrydowego – polecenie Get-OrganizationRelationship

    Dodatkowo z poziomu Exchange admin center można zweryfikować:
    • Mail flow -> Accepted domain – powinna pojawić się nowa autorytatywna domena z przedrostkiem, który składa się z nazwy zarejestrowanej domeny w Office 365 czyli nazwadomeny.mail.onmicrosoft.com w moim przypadku jest to privatelabs.mail.onmicrosoft.com
    • Mail flow -> Send Connector – nowy send connector, który wysyła maile do autorytatywnej domeny w Office 365. Od strony Exchange Online connector, który odbiera maile z On-Premise i wysyła do On-Premise
    • Organization -> Sharing – powinny pojawić się polisy udostępniania pomiędzy lokalnym środowiskiem, a chmurą i odwrotnie od strony Exchange Online
    Do weryfikacji środowiska zalecane jest wykorzystanie narzędzia Microsoft Remote Connectivity Analyzer, które jest dostępne z poziomu adresu: https://testconnectivity.microsoft.com

    Co jeszcze ?

    Tworzenie kont w Office w 365 Gdy zweryfikowaliśmy aktualną konfigurację połączenia hybrydowego za pomocą wiersza poleceń i interfejsu graficznego. Możemy sprawdzić przepływ wiadomości pomiędzy środowiskiem On-Premise, a Online. Prace rozpoczniemy od utworzenia skrzynki pocztowej w Exchange Online. W tym celu logujemy się do lokalnego środowiska Exchange Server 2016 za pomocą przeglądarki na adres: https://farbeni.pl/ecp. Następnie przechodzimy do zakładki recipients -> mailboxes i za pomocą ikony „plusa” z menu wybieramy Office 365 mailbox (Rys. 3) – funkcjonalność Office 365 mailbox pojawiła się po utworzeniu Hybrydy. Uzupełniamy wymagane pola, konto tworzymy w jednostce organizacyjnej, która jest synchronizowana do Office 365 i wybieramy opcję Save. W konsoli zarządzającej pojawi się konto Jakub.Trzeci@farbeni.pl jako mailbox type: Office 365.

    Rys. 3. Tworzenie konta pocztowego w Office 365

    Po utworzeniu konta z poziomu lokalnej konsoli Exchange automatycznie zostało utworzone konto użytkownika w usłudze katalogowej Active Directory, które należy dosynchronizować do Azure Active Directory. Z poziomu witryny Admin center w Office 365 na nowym użytkowniku należy włączyć licencję i wskazać lokalizację/region.  W tym celu należy się zalogować do konsoli admin center za pomocą przeglądarki wpisując adres https://portal.office.com przejść do Admin -> Users -> Active Users -> Jakub Trzeci -> Product licences i zaznaczyć opcje przedstawione na Rysunku 4.

    Rys. 4. Przypisanie licencji dla użytkownika w Office 365

    Po wykonaniu opisanych powyżej czynności konto pocztowe dla skrzynki jakub.trzeci@farbeni.pl zostanie założone w Exchange Online w Office 365. Dodatkowo można wykonać weryfikację i sprawdzić czy takie konto faktycznie znajduje się w Office 365. W tym celu z konsoli zarządzającej Exchange Server wybieramy w lewym górnym rogu Office 365 i przechodzimy do zakładki recipients. Jak widać na Rysunku 5 konto Jakub Trzeci jest już w Office 365 natomiast konta z lokalnego Exchange Server widoczne są w zakładce contacts jako Mail User.

    Rys. 5. Weryfikacja kont w Exchange On-Premise i Exchange Online od strony Office 365

    Weryfikacja przepływu poczty Weryfikację przepływu poczty pomiędzy lokalnym środowiskiem, a online przeprowadzimy za przy pomocy założonego konta chmurze Jakub.Trzeci@farbeni.pl. Sprawdzimy następujące scenariusze:
    • Wysyłka maila z lokalnego środowiska do chmury
    • Wysyłka maila z chmury do lokalnego środowiska.
    W celu przeprowadzenia testów należy zalogować się do lokalnego środowiska Exchange. Do tego celu wykorzystamy interfejs OWA, który jest dostępny z poziomu adresu: https://farbeni.pl/owa. Logujemy się na konto użytkownika w Exchange 2016, w moim przypadku będzie to konto z adresem Emil.Nieweglowski@farbeni.pl i wysyłamy maila do Jakuba. Następnie logujemy się na konto Jakuba za pomocą przeglądarki internetowej do adresu https://outook.office365.com (Rys. 6). Sprawdzamy czy otrzymaliśmy pocztę od Emila i odpowiadamy na maila. Gdzie następnie sprawdzamy konto Emila i weryfikujemy czy otrzymaliśmy wiadomość od Jakuba. Wiadomości zostały poprawnie odebrane zarówno przez użytkownika, który posiada skrzynkę pocztową w lokalnej infrastrukturze (Exchange Server 2016) oraz przez użytkownika, który posiada skrzynkę w chmurze (Exchange Online) co oznacza że przepływ poczty działa poprawnie.

    Rys. 6. Weryfikacja przepływu poczty: Exchange On-Premise <-> Exchange Online

    Weryfikacja Free / Busy  Przejdźmy teraz do kalendarza i planowania spotkań. Użytkownicy Emil Niewęgłowski i Jakub Trzeci mają już zaplanowane spotkania w swoich prywatnych kalendarzach (Rys. 7). Emil ma zajęte dwa terminy 27.06 g. 14-15 oraz 28.06 g. 8-10 natomiast Jakub jest zajęty 28.06 g. 9.00 – 9.30 oraz 29.06 w godzinach 10-12 oraz 13-15.

    Rys. 7. Widok kalendarzy

    Do utworzenia nowego spotkania użyjemy kalendarza Emila, który planuje spotkanie z Jakubem. Do utworzenia spotkania wykorzystamy asystenta planowania. Jak widać na Rysunku 8 Jakub 29.06. w okresie 10-11 ma status Away natomiast w godzinach 13-14 ma status Busy. Zgodnie z założeniami funkcja Free Busy działa poprawnie ponieważ wyświetla informacje o niedostępności użytkownika.

    Rys. 8. Asystent planowania

    Podsumowanie

    W następnej części przeprowadzimy migracje zasobów z lokalnego środowiska do Exchange Online, gdzie następnie „wygasimy lokalne środowisko”. /Bartłomiej Prokocki]]>