Virtual Study

21 września 2016

Wrześniowe poprawki dla serwerów Exchange

Wczoraj Microsoft wydał kolejne paczki aktualizacji dla serwerów Exchange 2013 i 2016. Odpowiednio:
Pakiety te oczywiście zawierają poprawki do większości wykrytych po poprzednim pakiecie problemów oraz luk bezpieczeństwa, nie wprowadzają rewolucyjnych zmian, jednakże warto wspomnieć o kilku ciekawych cenach, które wprowadza CU3 dla Exchange 2016. Przede wszystkim, pozwala on na instalację Exchange na Windows Server 2016, który w sierpniu uzyskał status RTM, a po oficjalnej premierze na konferencji Ignite w przyszłym tygodniu będzie dostępny do pobrania. W Windows Server 2016 zawarty jest pakiet .Net Framework 4.6.2, więc CU3 wspiera ten pakiet, ale tylko na platformie Windows Server 2016, wsparcie dla starczych wersji systemu operacyjnego, również dla Exchange Server 2013 ma się pojawić w pakietach CU w dwóch kolejnych kwartałach.
Została również po raz kolejny zoptymalizowana replikacja w ramach DAG, co zaowocowało aktualizacja kalkulatora Exchange Server Role Requirements Calculator. Zaktualizowany został również widok kontaktów i statusu dostępności w kliencie webowa Outlook on the Web.

14 sierpnia 2016

.Net Framework 4.6.1 raz jeszcze

Jakiś czas temu pisałem o problemach we współpracy .Net Framework 4.6.1 z serwerami Exchange. W kolejnych paczkach aktualizacji grupa produktowa Exchange usunęła te problemy dla najnowszych edycji Exchange - 2013 i 2016, o czym również pisałem, przy okazji wydania tych poprawek. Po wydaniu CU2 dla Exchange 2016 i CU13 dla Exchange 2013 została zaktualizowana matryca zgodności serwerów Exchange, warto do niej zaglądać nie tylko przed instalacją nowych wersji Frameworka (wersje nowsze niż 4.6.1 nie są wspierane). Jednak na forach dyskusyjnych i listach mailowych widzę, że temat ten nie do końca jest jasno opisany, więc chciałem dodać jeszcze kilka słów wyjaśnienia.

.NET Framework 4.6.1 do poprawnej współpracy z Exchange wymaga dodatkowych poprawek, zgodnie z poniższą listą:
W przypadku aktualizacji systemu, należy zainstalować najpierw pakiet poprawek do Exchange (odpowiednio CU2 dla Exchange 2016 lub CU13 dla Exchange 2013), a dopiero wtedy .Net Framework 4.6.1 i odpowiedni dodatek.
W przypadku czystej instalacji serwera Exchange, możemy zainstalować najpierw poprawki systemowe i .Net Framework 4.6.1 z odpowiednimi poprawkami, a  następnie binaria Exchange - na szczęście możemy instalować od razu najnowszą wersję z pakietu instalacyjnego Cumulative Update. Nie musimy zaczynać od wersji RTM czy też SP1 w przypadku Exchange 2013, co jest częstym błędem osób korzystających z witryny pobrać dla licencji wolumenowych - z tej strony jest nam potrzebny tylko klucz licencyjny.

31 lipca 2016

Aktualizacje Skype for Business Server dla SQL Server Availability

Zamieszczam gościnnie artykuł Jacka Światowiaka o nieco nietypowej aktualizacji Skype for Business w konfiguracji z SQL Server Availability.
Skype for Business Server może wykorzystywać wysoką dostępność SQL określaną jako Availability Group. O ile proces konfiguracji jest dość intuicyjny to aktualizacja baz danych już nie do końca.


Rys.1. Konfiguracja SQL Store
Dla SQL pracującego w trybie Availability Group definiuje się dwa parametry, dwa adresy URL:
  • SQL Server Availibility Group Listener FQDN
  • SQL Server FQDN

 W standardowej konfiguracji oba adresy URL mają taką samą wartość.


Rys. 2. Konfiguracja SQL Availability Group

Aktualizacje Skype for Business Server przychodzą w postaci pakietów zbiorczych. Sam proces ich instalacji jest dosyć prosty. Wyłączamy usługi SFB na wszystkich serwerach Front End poleceniem:
Stop-CsWindowsService
Potem instalujemy pakiet SkypeServerUpdateInstaller.exe

Następnie należy zaktualizować schemat i konfigurację baz danych na serwerze SQL (Back End Server). W tym celu należy wykonać polecenie:

Install-CsDatabse  –Update -ConfiguredDatabase -sqlServerFQDN  -verbose

Niestety kreator aktualizacji wywali się dość dziwnym komunikatem błędu, iż konto nie może się dostać do WMI serwera SQL. Wstępne próby weryfikacji uprawnień nie rozwiązały problemu, gdyż w rzeczywistości problem jest w innym miejscu.
Rys.3. Okno błędu kreatora aktualizacji baz danych

Problemy leży w adresie URL serwera SQL.
Rys.4. Modyfikacja adresu URL serwera SQL na czas aktualizacji baz danych
Aby prawidłowo zaktualizować bazy należy:

  • Zmodyfikować adres FQDN serwera SQL – na adres fizycznego węzła na którym jest aktywna instancja availability group związanej z bazami danych SFB,
  • Opublikować topologię,
  • Uruchomić polecenie: Install-CsDatabse –Update -ConfiguredDatabase -SqlServerFQDN -verbose.
Teraz aktualizacja zakończy się powodzeniem
Rys.5a. Aktualizacja baz SQL Skype for Business

Rys.5b. Aktualizacja baz SQL Skype for Business

Następnie należy ponownie zmodyfikować adres URL serwera SQL na pierwotny i ponownie opublikować topologię. Po czym uruchomić usługi na serwerach Front End:

Start-CsWindowsService

30 czerwca 2016

Czerwcowe poprawki dla Skype for Business 2015

Dwa dni temu trochę po cichu pojawiła się trzecia paczka poprawek dla Skype for Business 2015. Oprócz usunięcia kilku błędów, pojawiło się w niej  kilka istotnych uzupełnień funkcjonalnych:
Video Based Screen Sharing (VBSS) to ważna zmiana funkcjonalna, poprawiająca wydajność i optymalizująca połączenia udostępniające pulpit, poprzez zmianę typu połączenia z RDP. VBSS pojawił się już kilka miesięcy temu w kliencie Skype for Business 2016 (od wersji 16.0.6330.1000), jednak działał tylko w połączeniach bezpośrednich pomiędzy takimi klientami. Teraz stało się to możliwe również w połączeniach konferencyjnych poprzez serwer SfB. Po zainstalowaniu poprawki na wszystkich serwerach z funkcjonalnością konferencyjną (ASMCU) we własciwościach polisy konferencyjnej pojawia się nowa pozycja - Application Sharing Mode, jak widać na ponizszym rysunku.Domyślnie włączona jest opcja VBSS (VideoWithFalllback), ale możemy to zmienić:
Set-CsConferencingPolicy -ApplicationSharingMode RDP






















Możliwość wykorzystania dodatkowych numerów alarmowych pewnie nie będzie w Polsce specjalnie popularna, więc nie będę się rozwodził, ale na pewno rozszerzenie polisy głosowej o opcję zajętości jest pożyteczne.  Użytkownicy mają do dyspozycji dwie opcje:
  • Busy on Busy
  • Voicemail on Busy
Czyli albo kiedy rozmawiamy nowa rozmowa jest odrzucana z sygnałem zajętości, albo jest przerzucana na pocztę głosową. Planowanie i konfiguracja tej funkcjonalności jest dokładnie opisane w dokumentacji produktu. Funkcjonalność offline message pozwala nam wysłać wiadomość do kontaktu, który chwilowo nie jest dostępny. Zamiast komunikatu błędu, że kontakt jest niedostępny, otrzymamy informację o fakcie, że kontakt jest offline, jednak gdy nasz kontakt się pojawi przy komputerze dostanie informację o przegapionych konwersacjach. Jest to realizowane z wykorzystaniem EWS, wykorzystując dostarczanie informacji do skrzynki Exchange użytkownika. Funkcjonalność oprócz serwera zaktualizowanego do CU3 (opcja offline message włączona w CU3 domyślnie) wymaga również odpowiednio nowego klienta - Skype for Business 2016 C2R build 16.0.6701.1000 lub nowszy. Funkcjonalność możemy oczywiście wyłączyć, zgodnie z opisem w dokumentacji poprzez wykonanie komendy:
Set-CsImConfiguration -EnableOfflineIM $False

29 czerwca 2016

Włączenie wszystkich usług potrzebnych do pracy Exchange

Czasem instalacja nowego Cummulative Update'u lub poprawki bezpieczeństwa dla Exchange kończy się błędem, a nawet co gorsza kończy się poprawnie, lecz z jakiś powodów program instalacyjny nie przywróci poprawnego statusu wszystkich niezbędnych do poprawnego działania usług Exchange. Jako człowiek leniwy napisałem sobie krótki skrypcik, który co prawda nie ma rozbudowanej logiki, ale po prostu zmienia status usług Exchange, które powinny mieć ustawiony typ startu jako automatyczny na poprawną wartość. Skrypt uwzględnia usługi z wersji Exchange 2016 CU, działa również dla serwera Exchange 2013 z dowolnym CU.
#
# Script to change Echange Services Startup Type to proper value
#

# Start WMI as it was disabled
Set-Service Winmgmt -Startup Automatic # WMI was disabled
Set-Service Winmgmt -Status Running # WMI needs to be started


# Start IIS as it was disabled
Set-Service W3SVC -StartupType Automatic 
Set-Service IISADMIN -StartupType Automatic

# Start other services that were disabled during update
Set-Service RemoteRegistry -StartupType Automatic
Set-Service AppIDSvc -StartupType Automatic
Set-Service Pla -StartupType Automatic

# Exchange 2013 
set-service MSExchangeADTopology -StartupType Automatic
set-service MSExchangeAntispamUpdate -StartupType Automatic
set-service MSExchangeDagMgmt -StartupType Automatic
set-service MSExchangeDelivery -StartupType Automatic
set-service MSExchangeDiagnostics -StartupType Automatic
set-service MSExchangeEdgeSync -StartupType Automatic
set-service MSExchangeFastSearch -StartupType Automatic
set-service MSExchangeFrontEndTransport -StartupType Automatic
set-service MSExchangeHM -StartupType Automatic
set-service MSExchangeImap4 -StartupType Automatic
set-service MSExchangeIMAP4BE -StartupType Automatic
set-service MSExchangeIS -StartupType Automatic
set-service MSExchangeMailboxAssistants -StartupType Automatic
set-service MSExchangeMailboxReplication -StartupType Automatic
set-service MSExchangePop3 -StartupType Manual
set-service MSExchangePOP3BE -StartupType Manual
set-service MSExchangeRepl -StartupType Automatic
set-service MSExchangeRPC -StartupType Automatic
set-service MSExchangeServiceHost -StartupType Automatic
set-service MSExchangeSubmission -StartupType Automatic
set-service MSExchangeThrottling -StartupType Automatic
set-service MSExchangeTransport -StartupType Automatic
set-service MSExchangeTransportLogSearch -StartupType Automatic
set-service MSExchangeUM -StartupType Automatic
set-service MSExchangeUMCR -StartupType Automatic
set-service HostControllerService -StartupType Automatic
set-service FMS -StartupType Automatic
set-service wsbexchange -StartupType Manual
# Exchange 2016
set-service MSExchangeNotificationsBroker -StartupType Manual
set-service MSExchangeCompliance -StartupType Automatic
set-service MSComplianceAudit -StartupType Automatic
set-service MSExchangeHMRecovery -StartupType Automatic
#
# end of script
#

27 czerwca 2016

Federacja Skype for Business i Skype

Jakiś czas temu pisałem o konfiguracji federacji Lynca 2013 i Skype. Od ponad roku przede wszystkim wdrażam SfB, więc dobrze byłoby pokazać różnice również na blogu.
W zasadzie zasada działania i kroki przygotowawcze wyglądają podobnie jak w przypadku Lynca 2013. Jeżeli mamy tenanta O365, to wystarczy zaznaczyć jeden checkbox. Jeżeli jednak korzystamy z wersji on-premises, to mamy trochę więcej kroków do wykonania. Również z formalnego punktu widzenia należy zacząć od wejścia na stronę https://pic.lync.com.















Po zalogowaniu się kontem Microsoft Id, powiązanym z umową wolumenową, wskazać numer umowy licencyjnej, w ramach której kupione są licencje na Skype for Business, następnie wskazać domenę sip-ową i serwer Edge, poprzez który wystawiona jest federacja.



















Od czasów Lynca proces trochę się usprawnił i aktywacja federacji trwa teraz kilkadziesiąt, a czasem nawet kilkanaście minut.
















Po stronie serwerów Skype for Business trzeba przede wszystkim włączyć w Topology Builderze federację i dodatkową opcję, której nie było w Lyncu 2013 - wyszukiwanie w katalogu globalnym Skype.













Kolejne kroki to ponowna definicja publicznego dostawcy dla Skype:
Remove-CsPublicProvider -Identity Skype
New-CsPublicProvider -Identity Skype -ProxyFqdn federation.messenger.msn.com -IconUrl https://images.edge.messenger.live.com/Messenger_16x16.png -NameDecorationRoutingDomain msn.com -NameDecorationExcludedDomainList "msn.com,outlook.com,live.com,hotmail.com" -VerificationLevel UseSourceVerification -Enabled $true -EnableSkypeIdRouting $true -EnableSkypeDirectorySearch $true
Dobrze jest również dodatkowo włączyć w polisie dostępu zewnętrznego obsługi audio/video:
Set-CsExternalAccessPolicy -Identity -EnablePublicCloudAudioVideoAccess $true -EnableOutsideAccess $true
Po chwili w kliencie Skype kiedy zaczniemy wyszukiwać kontakt pokaże się dodatkowa zakładka - katalog Skype


21 czerwca 2016

CU2 dla Exchange 2016 - zmiany w DAG

Microsoft właśnie wydał paczki poprawek - Exchange Server 2016 Cumulative Update 2 and Exchange Server 2013 Cumulative Update 13. Obie paczki oprócz usunięcia kilku błędów funkcjonalnych zapewniają wsparcie dla .Net Framework 4.6.1, którego udostępnienie na Windows Update jako rekomendowana aktualizacja, wprowadziło sporo problemów, o czym pisałem niedawno. Inna pożyteczna i potrzebna zmiana to wprowadzenie podpisu SHA-2 do certyfikatów wystawianych przez serwer Exchange (self-signed). Warto pamiętać, że część przeglądarek już niebawem zacznie blokować dostęp do stron zabezpieczonych certyfikatem z SHA-1.
W przypadku Exchange 2016 zaszło również kilka zmian w cmdletach - scalenie ról CAS i Mailbox powoduje w przypadku niektórych poleceń wygenerowanie ostrzeżeń o zmianie funkcjonalności, jak na poniższym rysunku:

W CU2 wprowadzono zmiany, porządkujących zmiany w przypisaniu ról do serwerów.
Przed CU2 informacja o rolach serwera wyglądała tak jak na rysunku z lewej, po instalacji CU zniknęła rola ClientAccess, jednak serwer jest nadal świadomy tej funkcjonalności (rysunek z prawej):
Kolejną ciekawą i dla wielu przydatną zmianą jest modyfikacja funkcjonalności DAG. Sześć i pół roku po wprowadzeniu funkcjonalności DAG, w końcu przypisywanie priorytetów do replik bazy danych zaczęło mieć sens. W trakcie tworzenia kolejnych replik bazy danych w ramach DAG nadajemy kolejnym replikom atrybut ActivationPreference z kolejnym numerem. Ale niestety, dotychczas trzeba było aktywować repliki zgodnie z naszymi preferencjami ręcznie lub poprzez uruchomienie skryptu - np. dostępnego na serwerach Exchange RedistributeActiveDatabases.ps1.
W Cumulative Update 2 zespół produktowy zmodyfikował działanie Primary Active Managera, czyli procesu koordynującego działanie replik baz danych w ramach DAG. Do właściwości DAG został dodany atrybut - PreferenceMoveFrequency, który określa z jaką częstotliwością są sprawdzane wartości ActivationPreference replik poszczególnych baz danych i Replication Service aktywuje odpowiednie repliki bazy zgodnie z wartościami ActivationPreference. Domyślną wartością jest jedna godzina, jednak jeżeli jest to dla nas niewygodne, możemy tą wartość zmienić wykonując komendę:
Set-DatabaseAvailabilityGroup -PreferenceMoveFrequency
Jeżeli z jakiegoś powodu nie chcemy stosować nowej funkcjonalności, musimy uruchomić komendę:
Set-DatabaseAvailabilityGroup -PreferenceMoveFrequency ([TimeSpan]::Zero)
Po restarcie usługi Replication Service automatyczne przełączanie zostanie wyłączone.
Funkcjonalność została dokładnie opisana w artykule na blogu zespołu produktowego.

19 czerwca 2016

Przełączanie baz w ramach DAG

Co miesiąc Microsoft wypuszcza poprawki bezpieczeństwa, a raz na kwartał pojawiają się również paczki poprawek Cumulative Updates dla Exchange. W przypadku serwerów pracujących w ramach DAG wymaga to przełączenia baz na inny serwer oraz kilku dodatkowych operacji. W wielu miejscach można znaleźć skrypty, przygotowujące serwer w DAG do instalacji poprawek i przełączenie baz na inny serwer, np. przygotowane przez Michaela von Horenbeeka.
Dobrze jest jednak zrozumieć mechanizm, wykorzystywany w trakcie przełączania, a także odpowiednio zaplanować sposób przełączania, zwłaszcza w organizacji, gdzie serwery w ramach DAG znajdują się w dwóch lokalizacjach. Poniżej postaram się opisać to zagadnienie na przykładzie dwóch lokalizacji, gdzie w każdej z nich znajdują się dwa serwery - DAG ma 4 serwery.
Pierwszym atrybutem, który odpowiada za odpowiednie przełączanie baz danych w ramach DAG jest DatabaseCopyAutoActivationPolicy, który może mieć trzy wartości - unrestricted, blocked albo intrasiteOnly. Atrybut definiowany jest dla każdego serwera osobno.
W pierwszym przypadku, baza może przełączyć się na dowolną replikę, w tej samej lub drugiej lokalizacji, co może nie być dla nas optymalne w przypadku wyłączenia pojedynczego serwera - baza może się przełączyć do zapasowej lokalizacji, co nie jest naszą intencją (przełączenie do zapasowego ośrodka powinno nastąpić w przypadku niedostępności obu serwerów w ośrodku podstawowym).
W drugim przypadku, jeżeli ustawimy parametr na serwerach w zapasowej lokalizacji na wartość blocked, przełączanie jest zablokowane, co w przypadku awarii jednego serwera w lokalizacji podstawowej wymusi przełączenie na drugi serwer w tej samej lokalizacji ale w przypadku awarii całego ośrodka podstawowego, nie nastąpi przełączenie do zapasowej lokalizacji , czyli również nie uzyskamy wymaganej funkcjonalności.
W przypadku trzeciej wartości atrybutu - intrasiteOnly przełączanie baz danych będzie ograniczone do serwerów w tym samym site, czyli w przypadku awarii całej lokalizacji również nie uzyskamy automatycznego przełączenia do lokalizacji zapasowej.
Z pomocą przychodzi nam drugi atrybut - DatabaseCopyActivationDisabledAndMoveNow. Został on wprowadzony w Exchange 2013 po to, żeby umożliwić realizację przełączenia wymuszonego. W momencie gdy zostanie on ustawiony na $true, a wartość DatabaseCopyAutoActivationPolicy na unrestricted, to po awarii serwera w ośrodku podstawowym, przełączenie na taki serwer będzie możliwe tylko wtedy, gdy nie będzie dostępna inna zdrowa replika bazy danych - czyli zgodnie z założeniami, jeżeli obie repliki w ośrodku podstawowym ulegną uszkodzeniu/wyłączeniu baza przełączy się na serwer w ośrodku zapasowym, a w momencie, gdy jedna z kopii w ośrodku podstawowym uzyska status healthy, zostanie wymuszone przełączenie na ten serwer - czyli automatyczny powrót do ośrodka podstawowego. Zatem żeby bazy były dostępne na serwerach w ośrodku podstawowym i przełączały się automatycznie do ośrodka zapasowego, na wszystkich serwerach w obu ośrodkach musi być ustawiona wartość domyślna polisy AutoActivation (unrestricted) oraz na obu serwerach w ośrodku zapasowym musi być zmieniony atrybut DatabaseCopyActivationDisabledAndMoveNow na wartość $true poprzez wykonanie komendy:
set-mailboxserver -DatabaseCopyActivationDisabledAndMoveNow $true
Oczywiście, żeby automatycznie przełączenie między ośrodkami nastąpiło, File Share Witness musi znajdować się w trzeciej lokalizacji sieciowej.
Bardzo ciekawie to zagadnienie opisał Paul Cunningham na swoim blogu.

14 czerwca 2016

Limity na wielkość baz danych w Exchange

Ostatnio kilkukrotnie spotkałem się z pytaniem o limit na wielkość bazy danych w serwerze Exchange 2013 Standard - po przekroczeniu 1TB, baza nie chciała się montować, co było szczególnie uciążliwe w przypadku DAG, gdzie przecież przełączanie baz danych musi odbywać się automatycznie. Oficjalne informacje podają, że w Exchange 2013 i 2016, ograniczenie na wielkość bazy danych to 16 TB i wynika bardziej z ograniczeń na wielkość pliku w systemie Windows, oczywiście tworzenie, obsługa, a zwłaszcza backupowanie takiej bazy danych może stanowić poważne wyzwanie. Skąd więc wziął się taki problem? Sięgnijmy najpierw do historii.
Exchange 2003 dosyć mocno ograniczone były możliwości użycia wersji serwera w wersji Standard - dostępna była tylko jedna baza skrzynkowa i domyślny limit na wielkość bazy 16GB (przy 8TB limitu w wersji Enterprise). Service Pack 2 umożliwił rozszerzenie limitu do 64GB, jednak wymagało to zmian w rejestrach.
Kolejna wersja produktu - Exchange 2007 zwiększyła limit ilości baz w wersji Standard do pięciu, ale "na dzień dobry" miała ustawione ograniczenie na 250 GB dla pojedynczej bazy (mimo, że nominalnie bazy mogą mieć nawet 16TB). Tutaj też trzeba było zastosować modyfikacje kluczy rejestru, dla każdej bazy oddzielnie - na podstawie tego samego artykułu co dla wersji 2003.
Wydawałoby się, że Exchange 2010 przełamie złą passę, jednak jak się okazało zmienił się tylko limit - domyślnie wersja Standard miała ustawiony limit na 1TB, przy nominalnej wielkości 16TB. Oczywiście to ograniczenie też można było zmienić przez modyfikację klucza w rejestrze, ale co najdziwniejsze, ta blokada, chyba przez zapomnienie, została przeniesiona do Exchange 2013 i dawała się we znaki co najmniej do poziomu CU7. Na szczęście po zainstalowaniu CU12 problem znika.W Exchange 2016 na szczęście nie ma już żadnych ograniczeń (poza teoretycznym limitem 16TB).

04 czerwca 2016

Office Servers Summit 2016


Już 21 czerwca w siedzibie Microsoft odbędzie się konferencja Office Servers Summit 2016, na której wszyscy polscy MVP w kategorii Office Servers & Services powiedzą, co ciekawego i nowego można zobaczyć w technologiach serwerowych rodziny Office 2016. Chociaż Skype dla firm pojawił się ponad rok temu, a Exchange 2016 przeszło pół roku temu, to premiera Sharepointa 2016 i Office Online Servera 2016 odbyła się zaledwie kilka tygodni temu. Co więcej, Sharepoint 2016 w połączeniu z SQL 2016, którego premiera miała miejsce zaledwie trzy dni temu zyskuje dodatkowe możliwości (np. w zakresie BI). Pozostałe produkty również się zmieniają (np. w Office 365 co miesiąc pojawiają się nowe funkcjonalności). Dodatkowo Jakub Galus z Audiocodes opowie o narzędziach do integracji Skype for Business Online z telefonią stacjonarną. Warto więc przyjść i sprawdzić. Zapraszam do rejestracji na konferencję - http://officeserverssummit2016.evenea.pl/

22 maja 2016

Walka ze spamem - DMARC

Kiedy już mamy skonfigurowany rekord SPF oraz DKIM (konfigurację DKIM dla Office365 opisywałem w poprzedniej notatce), możemy uzupełnić konfigurację ochronną o DMARC.
Domain-based Message-based Authentication, Reporting & Conformance (DMARC) to specyfikacja publiczna dostępna od 2012 roku, opisująca metodę walki z phishingiem. Polega to na wykorzystaniu zarówno informacji o serwerze wysyłającym pocztę opisanych w rekordzie SPF, jak i zweryfikowaniu certyfikatu serwera poprzez DKIM. Dodatkowo DMARC umożliwia przekazywanie odbiorcy wytycznych, co powinien zrobić z naszym mailem, kiedy nie może zweryfikować pozytywnie SPF lub DKIM.
Poniższy rysunek, znaleziony w serwisie ReturnPath, pokazuje zasadę działania polisy DMARC:
DMARC flow
Żeby DMARC dla naszej domeny zadziałał, musimy mieć zdefiniowany odpowiedni rekord w publicznym DNS. Oczywiście tu zaczynają się schody - jak go uworzyć, jakie informacje są obowiązkowe i jak opisać poszczególne wartości?
Składnia rekordu jest stosunkowo prosta i składa się z kilku niezbędnych informacji, jak w przykładzie:
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:emailaddress@yourdomain.com; ruf=mailto:emailaddress@yourdomain.com;"

Poniższa tabela pokazuje wartości poszczególnych atrybutów:
WartośćDefinicjaPrzykładowa wartość
vWersja protokołu DMARCv=DMARC1
pct% wiadomości do filtrowaniapct=100
rufadres do wysyłania maili niezgodnych z polisąruf=mailto:authfail@pepug.org
rua
rf
ri
adres do wysyłania raportów od ISP
format generowania raportu
interwał generowania raportu (w sekundach)
rua=mailto:aggrep@pepug.org
rf=afrf lub rf=iodef
ri=86400
pustawienia polisy dla domenyp=quarantine, p=reject lub p=none
spustawienia polisy dla subdomensp=reject
adkimTryb Identifier Alignment dla DKIMadkim=strict lub adkim=relaxed
aspfTryb Identifier Alignment dla SPFaspf=relaxed lub aspf=strict

Nie wszystkie atrybuty są niezbędne do poprawnego działania polisy, żeby utworzyć rekord, najprościej skorzystać z jednego z dostępnych w internecie kreatorów, np. https://www.unlocktheinbox.com/dmarcwizard. Jeżeli nie jesteśmy pewni, czy mamy poprawnie ustawione wartości SPF i DKIM, najlepiej zacząć od polisy none, będziemy wtedy dostawać raporty z informacją, jak traktują maile z naszej domeny inni. Jeżeli wszystko działa poprawnie, możemy zmienić polisę na quarantine, a nawet reject.
UWAGA: Nie wszystkie dostępne w internecie systemy DNS pozwalają na tworzenie rekordów zaczynających się od "_", więc warto to sprawdzić.

Problem z Lyncem/SfB po aktualizacji .Net Frameworka

Systemy należy aktualizować, zwłaszcza, gdy poprawka łata dziurę w zabezpieczeniach aplikacji, jednak znowu zespół Frameworka nie zweryfikował w pełni czy coś nie zostanie popsute. Wydana 10 maja poprawka Security Update for .NET Framework (3156757) skutecznie rozwala funkcjonalności konferencyjne serwerów Lyncowych i Skype for Business:
  • Whiteboards
  • Uploading PowerPoint Presentations
  • Sharing Notes
  • Polls
  • Q&A
Jak na razie zespół produktowy opisał jak poprzez dodanie odpowiednich kluczy w rejestrach obejść problem, mam nadzieję, że niedługo zostanie wydana odpowiednia poprawka do systemu.

24 kwietnia 2016

Nowa możliwość poznawania technologii chmurowych dla IT Pro

Kolejne zmiany w technologiach, wykorzystywanych w IT pokazują, że specjalista IT musi dużo czasu poświęcić na aktualizację wiedzy i poznawanie nowości technologicznych. Od kilku lat Microsoft promuje swoje technologie chmurowe i mimo tego, że najczęściej nadal zajmuję się technologiami działającymi w serwerowniach klientów, to staram się nadążać, a przynajmniej śledzić zmiany technologii chmurowych, zwłaszcza, że są one coraz bardziej powiązane ze sobą jak i z technologiami on-premises (modele hybrydowe wdrożenia). W tym tygodniu Microsoft żeby wspomóc specjalistów IT w dostosowywaniu się do nowych technologii chmurowych uruchomił dw nowe programy – Microsoft IT Pro Cloud Essentials oraz Microsoft IT Pro Career Center.  
IDC prognozuje, że o ile całość zatrudnienia w IT będzie rosła o 4% każdego roku do roku 2020, to liczba stanowisk związanych ze środowiskiem chmurowym będzie zwiększać się kilkukotnie szybciej. Prognozuje się, że do roku 2020, ponad 1/3 stanowisk IT będzie związana z technologiami  chmurowymi.  
Żeby sprostać tym wyzwaniom trzeba poznawać szybko zmieniające się technologie chmurowe. Microsoft dotychczas udostępniał 30-dniowe wersje ewaluacyjne, ewentualnie roczne (np. w ramach subskrypcji trenerskiej). Teraz pojawiła się możliwość przedłużenia testów, z dodatkowym wsparciem, a nawet voucherem na wybrany egzamin. Takie możliwości daje nam program Microsoft IT Pro Cloud Essentials, który obejmuje:
- usługę Azure z limitem kosztowym, do wypróbowania różnych scenariuszy, jak np. backup, bezpieczeństwo, disaster recovery.
- subskrypcja Pluralsight na wybrane szkolenia on-line.
- rozszerzone wsparcie poprzez forum TechNet.
- możliwość zgłaszania incydentów technicznych dla usługi Azure.
- voucher egazminacyjny.
- rozszerzone czasowo triale na Enterprise Mobility Suite oraz Office 365.

Dodatkowo można spróbować poszukać nowych wyzwań na portalu Microsoft IT Pro Career Center.
Portal Microsoft IT Pro Career Center przedstawia możliwe ścieżki kariery w chmurze, pozwala lepiej poznać role chmurowe oraz uzyskać dodatkowe informacje: 
- Mapa stanowisk IT związanych z chmurą.
- Informacje o zapotrzebowaniu na poszczególne role i widełkach płacowych.
- Ścieżki rozwoju na poszczególne role.
- Informacje na temat trendów rynkowych i wymaganiach ze strony pracodawców.

Kształcić na pewno się warto, więcej informacji można znaleźć na wymienionych powyżej portalach lub na blogu zespołu produktowego.

11 kwietnia 2016

Exchange 2007 - pożegnanie czas zacząć

Właśnie przed chwilą zespół produktowy Exchange umieścił na swoim blogu przypomnienie, że równo za rok skończy się rozszerzone wsparcie dla Exchange 2007. Ta pierwsza wersja systemu przygotowana na bazie Powershella miała szereg zalet, ale czas leci - w październiku minie 10 lat od premiery Exchange 2007 (kilka tygodni temu minęła 20 rocznica obecności Exchange na rynku) i nowsze wersje wprowadziły wiele usprawnień. Tradycjonaliści, którzy trzymają się nadal tej wersji systemu powinni jednak zaplanować w najbliższym czasie aktualizację systemu do wersji 2013 (przypomnę, że do 2016 nie można) lub do Exchange Online. Już od dawna pakiety Rollup Updates uwzględniają tylko krytyczne poprawki bezpieczeństwa nie odnosząc się do innych problemów.

29 marca 2016

Odzyskiwanie danych Exchange - Kernel for Exchange Recovery

Rozmawiając na temat systemu Exchange prędzej czy później pojawia się temat zabezpieczenia, a właściwie odzyskiwania danych pocztowych użytkowników.
Zabezpieczenie na poziomie replikacji baz danych między serwerami Exchange (czyli Database Availability Group – DAG) jest świetną metodą na zabezpieczenie przed awarią bazy danych, czy nawet całego serwera Exchange. Staram się wykorzystywać tę funkcjonalność we wszystkich środowiskach Exchange 2010 i 2013, które wdrażam. Jednak nie zawsze jest możliwość wdrożyć środowisko wysokodostępne. Czasem również może przydarzyć się nawet przy stosowaniu DAG jakiś problem – np. awaria macierzy, na której były wykreowane grupy dyskowe, użyte przez Exchange. Oczywiście każdy serwer powinien używać innej macierzy lub wewnętrznych dysków serwera, ale wiadomo – zgodnie z prawem Murphy'ego coś może pójść nie tak. Co zrobić w wypadku, gdy znajdziemy się w sytuacji, gdy mamy tylko jedną replikę jakiejś bazy danych, a na dodatek kopia ta jest uszkodzona?
Nawet najnowsze wersje Exchange nie zawsze są w stanie sobie z takim problemem poradzić samodzielnie. Nie mając aktualnego backupu dobrze jest pomóc sobie w takim wypadku narzędziem zewnętrznym, które potrafi odzyskać dane z uszkodzonej bazy danych.
Z narzędziem Kernel for Exchange Recovery zetknąłem się ładnych kilka lat temu, jeszcze na etapie Exchange 2003. Później wracałem do niego wielokrotnie przy okazji różnych problemów, które rozwiązywałem w różnych organizacjach Exchange (można uzyskać licencję na jedną organizację lub dla konsultanta – na nielimitowaną ilość organizacji Exchange). Wracałem do Kernela, bo jest bardzo prosty w użyciu, nie wymaga skomplikowanych kroków przygotowawczych, no i jego cena jest bardzo korzystna.
Instalacja jest banalnie prosta. Uruchamiamy program instalacyjny i po kliknięciu kilku razy Next mamy zainstalowany produkt (możemy zmienić folder instalacyjny). Kernel może być zainstalowany na dowolnym systemie operacyjnym Windows (nawet Windows 10) i obsługuje pełen zakres dostępnych wersji Exchange, łącznie z Exchange 2016 oraz Exchange Online w usłudze O365.















UWAGA: Do odzyskiwania danych wymagany jest Microsoft Outlook w dowolnej wersji (najlepiej wspieranej, czyli począwszy od Outlook 2010). Profil Outlokowy również jest potrzebny, natomiast może to być konto tymczasowe.
Przy próbie pierwszego uruchomienia zostaniemy poproszeni o podanie emaila i powiązanego z nim klucza instalacyjnego, po czym od razu przejdziemy do trybu wyboru bazy danych.
























Mając wybraną bazę danych (może być nawet podłączona poprzez udział sieciowy) wybieramy tryb skanowania i po kliknięciu przycisku "Finish", jak widać na poniższym rysunku, otwiera nam się lista skrzynek pocztowych i folderów w poszczególnych skrzynkach danej bazy danych.







Teraz możemy wybrać tryb, w jakim chcemy odzyskiwać dane - do pliku pst (Save to PST) lub do istniejącej innej bazy Exchange. Najnowsza wersja narzędzia umożliwia również zapis do skrzynki Exchange Online lub folderu publicznego, jak pokazuje poniższy rysunek.
Jeżeli wybierzemy opcję zapisu, a właściwie eksportu do Exchange, musimy podać w kolejnym kroku konto, które ma odpowiednie uprawnienia w docelowym systemie. Przy eksporcie do pliku PST, wystarczy podać lokalizację, w której tworzony będzie plik (ewentualnie kilka plików, jeżeli chcemy ograniczyć ich rozmiar). I to wszystko. Po krótszej lub dłuższej chwili (w zależności od wielkości skrzynki) zawartość skrzynki lub wybranego przez nas folderu zostanie pobrana z pliku edb i zapisana we wskazanej przez nas lokalizacji jak pokazuje poniższy rysunek.
Proste? Proste.


21 marca 2016

CU2 dla Skype for Business 2015

Całkiem po cichu Microsoft wydał 18 marca pakiet Cummulative Update 2 dla Skype for Business Server 2015. Nową funkcjonalnością, która pojawiła się w tej wersji produktu jest możliwość użycia Modern Authentication (ADAL), co wymaga jednak zainstalowania ADFS 3.0 i dodatkowych kroków konfiguracyjnych, zgodnie z opisem w dokumentacji. CU2 rozwiązuje również kilka problemów, takich jak kłopoty z połączeniem przez klienta webowego z komputera z Windows 10.
Opis zmian w CU2 oraz procedurę instalacyjną można znaleźć w artykule KB3061064.
Samą poprawkę można pobrać z tej lokalizacji

16 marca 2016

Poprawki do Exchange we wszystkich wersjach

15 marca czyli wczoraj wydano poprawki do rodziny serwerów Exchange:
 O ile poprawki dla serwerów 2007 i 2010 to czysta kosmetyka (głównie aktualizacja kontrolki OWA S/MIME do użycia certyfikatu z podpisem SHA-2), w Exchange 2010 można w konsoli EMC znaleźć dodatkowo link do zewnętrznego kreatora konfiguracji hybrydowej (taki jak stosowany od kilku miesięcy w nowszych wersjach), to pakiety CU dla Exchange 2013 i 2016 zawierają sporo zmian i poprawek. Najbardziej zauważalna zmiana to zastąpienie samorozpakowującego się archiwum w Exchange 2016 CU1 obrazem ISO. Dla środowiska z kilkoma serwerami jest to dużo wygodniejsze w użyciu (wystaczy podmontować płytę z poziomu Windows lub z poziomu wirtualizatora, ale zamiast 1,5 GB musimy ściągnąć plik wielkości 6,4GB (!).
Jet również niestety łyżka dziegciu. Niedawno pisałem o problemach z .Net Frameworkiem 4.6.1. Miałem nadzieję, że problem zostanie rozwiązany i uwzględniony w kwartalnych aktualizacjach, niestety nie udało się grupom produktowym dogadać - usunięcie problemu, a co za tym idzie wsparcie dla .Net Frameworka 4.6.1 ma być zawarte dopiero w kolejnym pakiecie CU.
Kolejny problem, a w zasadzie niedogodność, to znacznie dłuższy czas instalacji pakietu w wersjach 2013/2016 na platformie Windows Server 2012 R2. O ile normalnie pakiet Cummulative Update w Exchange 2013 instaluje się kilkadziesiąt minut, to teraz można zauważyć co najmniej dwukrotne wydłużenie tego procesu (!). Dlaczego tak się dzieje? Znowu okazuje się, że Framework generuje dodatkowe problemy. Po zainstalowaniu poprawki KB3097966 pojawia się właśnie takie wydłużone dodawanie komponentów do serwera Exchange. Zespół produktowy .Net Framework pracuje nad usunięciem tego problemu, ale na razie zalecanym obejściem problemu jest wykonanie na wszystkich serwerach Exchange na platformie Windows 2012 R2 komendy:
“%windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update”
Ciekawie opisał procedurę aktualizacji serwerów Exchange 2016 na swoim blogu Paul Cunningham. Oczywiście dobrze jest również przeczytać informację na blogu zespołu produktowego.

3.2.1.Wydano!

W zeszłym roku Microsoft wydał Skype for Business 2015 i Exchange 2016 ale nadal rodzina Office Servers 2016 nie była gotowa - brakowało Sharepointa. W poniedziałek 14 marca Sharepoint Server 2016 uzyskał status RTM i w końcu można powiedzieć o pełnej rodzinie produktów. Co prawda będzie dostępny do pobrania dla klientów wolumenowych dopiero na początku maja, ale wersję ewaluacyjną można pobrać już dziś. Razem z Sharepointem pojawił się również Project Server 2016 - produkt mocno powiązany. 4 maja ma odbyć się wirtualna premiera produktu, a chętni mogą przeczytać o nowych funkcjonalnościach w dokumencie Sharepoint Server 2016 Overview Guide.
Mam nadzieję, że niebawem będę mógł również zaprosić na Office 2016 Community Launch, ale to na razie jeszcze tajemnica ;)

10 marca 2016

Walka ze spamem - SPF, DKIM, DMARC

Kiedy 10 lat temu wprowadzono system Exchange 2007, mechanizmy walki ze spamem były stosunkowo ubogie - weryfikacja nazwy serwera w RevDNS operatora, listy RBL i niewiele więcej. Jednak opracowywany od 2004 roku standard SPF, opublikowany jako draft RFC 4408 oraz jego Microsoftowe rozszerzenie Sender Id - draft RFC 4406 (RFC dla SPF został zaktualizowany jako 6652 i 7208) i , a Sender Id został zaimplementowany w Exchange 2007. Napisałem już kiedyś artykuł na temat SenderId, więc nie będę się powtarzał, warto jednak zająć się nowszymi metodami podniesienia bezpieczeństwa. Na ostatnim spotkaniu PEPUG prezentowany był DMARC, a jakiś czas temu DKIM, więc uznałem, że warto tym razem poświęcić parę słów tym rozwiązaniom.
DKIM czyli DomainKeys Identified Mail (opisana w 2009 roku w RFC 5585) to usługa polegająca na zabezpieczaniu wysyłanych maili kluczem domenowym. Żeby klucz ten można było zweryfikować, w DNS umieszczany jest rekord zawierający klucz publiczny odpowiadający danej domenie.
















Od przeszło pół roku usługa Office365 pozwala na weryfikację maili przychodzących poprzez DKIM, możliwości wykorzystania tej usługi posiada również wiele komercyjnych rozwiązań antyspamowych. Od niedawna pojawiła się również możliwość zabezpieczania ruchu wychodzącego.
W tym celu po pierwsze musimy dodać do DNS naszej domeny dwa rekordy CName (nie TXT!).
W przykładzie użyję domeny pepug.net.

Host name:          selector1._domainkey
Wskazanie na hosta: selector1-domainGUID._domainkey.O365Domain
TTL:                3600 

Host name:          selector2._domainkey
Wskazanie na hosta: selector2-domainGUID._domainkey.O365Domain
TTL:                3600

Jakie wartości podstawić pod domainGUID O365Domain?
DomainGUID to wartość, która jest wstawiana jako początkowy człon rekordu MX (przed suffixem mail.protection.outlook.com), dla tenanta naszej firmy. W omawianym przykładzie jest to ciąg pepug-net, jak pokazuje poniższy rysunek:

O365Domain, to nazwa tenanta, wskazana w konfiguracji usługi - w omawianym przykładzie pepugnet.onmicrosoft.com.
Czyli odpowiednie wartości to selector1-pepug-net._domainkey.pepugnet.onmicrosoft.comselector2-pepug-net._domainkey.pepugnet.onmicrosoft.com.






Po skonfigurowaniu DNS, możemy włączyć usługę DKIM w ustawieniach domen pocztowych, obsługiwanych przez nasz tenant. W tym celu przechodzimy w konsoli administracyjnej do administracji Exchange, zakładki "Ochrona" - "DKIM". W prawym panelu akcji jest dostępny przycisk "Włącz" (wyróżniony na niebiesko). 













Po włączeniu tej funkcjonalności zmieniają się ustawienia, jak widać na poniższym rysunku:















Po wysłaniu wiadomości widać w nagłówku informację o użyciu DKIM i szczegóły podpisu:





















Alternatywnie można użyć skryptu Validate-DkimConfig.ps1, opisanego na blogu Terry'ego Zinka, do weryfikacji poprawności utworzonych rekordów. Wyniki działania skryptu widać na poniższym rysunku:

Niestety dla Exchange Server 2010/2013/2016 on-premises, nie ma jak na razie możliwości włączenia takiej funkcjonalności. Są co prawda zewnętrzne dodatki umożliwiające skorzystanie z tej funkcjonalności, niektóre płatne, jak np. EA DomainKeys/DKIM for Exchange Server lub bezpłatne jak DKIM Signing Agent for Microsoft Exchange Server. Mam nadzieję, że niedługo, przynajmniej w najnowszej wersji Exchange 2016 zostanie dodana opcja konfiguracji DKIM-a.
W kolejnym poście opiszę funkcjonalność DMARC.

27 lutego 2016

Dynamiczne grupy dystrybucyjne - filtrowanie użytkowników

Tworząc dynamiczne listy dystrybucyjne czy polisy list adresowych w panelu administracyjnym serwera Exchange możemy wybrać tylko kilka podstawowych atrybutów - "State or province", "Country", "Department" oraz jedną z 15 wartości Custom Attributes (rysunek poniżej).




















Co jednak w przypadku, gdy chcemy stworzyć filtr na podstawie np. nazwy miasta? Czy trzeba tą wartość skopiować do Custom Attribute? Na szczęście nie jest to potrzebne.
Zespół produktowy uwzględnił jeszcze wiele innych atrybutów, jednak w żadnej wersji systemu nie umieścił ich w kreatorze. Żeby było ciekawiej, nazwy atrybutów Exchange nie zawsze są takie same w Exchange, co w Active Directory, a niektóre atrybuty nie mają nawet swoich odpowiedników w AD (!). Żeby nie popełnić błędu dobrze jest sprawdzić listę, która jest dostępna np. w artykule
Na liście musimy zatem odszukać odpowiedni nazwę odpowiedniego atrybutu. Jeżeli chcemy filtrować po nazwie miasta, np. Warszawa, to musimy utworzyć grupę, wykonując komendę:
New-DynamicDistributionGroup -Name WawaUsers -RecipientFilter {(City -eq 'Warszawa')}
Co ciekawe, jak podejrzymy właściwości tak zdefiniowanej grupy, to zobaczymy komunikat, że filtr został utworzony w Powershellu i w ten sam sposób może być zmieniony (rysunek poniżej).













Jeżeli sprawdzimy właściwości z poziomu shella, to zobaczymy, że system automatycznie dodał dodatkowe warunki, doprecyzowujące zakres filtrowania:







Jak widać, możemy w wyrażeniach, będących elementami filtru stosować wilcard i różne wyrażenia logiczne.