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
• Multiple Emergency Number
• Busy Options
• Offline Message

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ż odpowiedniej aktualizacji po stronie klienta:

• Click-to-Run
  
  • FRDC: 16.0.6965.2055 i nowsze
  • DC: 16.0.6741.2048 i nowsze
  • FRCC/CC: 16.0.7070.2013 i nowsze
• MSI: 16.0.4401.1000 (Lipcowa paczka poprawek PU)

Funkcjonalność możemy oczywiście wyłączyć, zgodnie z opisem w dokumentacji poprzez wykonanie komendy:

Set-CsImConfiguration -EnableOfflineIM $False

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

#

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

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.

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.

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

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/