Virtual Study

05 grudnia 2016

Czy warto używać funkcjonalności Persistent Chat?

Jedną z wielu ról, które można wdrożyć w systemie Skype for Business Server 2015 jest Persistent Chat Server. Niektóre firmy korzystają z tej funkcjonalności intensywnie, inne wcale jej nie wykorzystują, a część z organizacji używających SfB nawet nie wiedzą o jej istnieniu i nie zastanawiają się, czy jej wdrożenie może być dla firmy korzystne. W ostatnich tygodniach Microsoft udostępnił w ramach Office 365 nową usługę - Microsoft Teams, która jest odpowiednikiem Persistent Chat w usługach chmurowych, dlatego też warto przyjrzeć się bliżej każdej z nich.
Czym jest Persistent Chat? Nie będę teraz zagłębiać się w architekturę, wymagania sprzętowe i możliwe topologie wdrożenia, bo z tych tematów wyszedłby cały cykl artykułów, ale chciałbym spróbować napisać, po co w ogóle używać tej usługi i w jakich przypadkach może okazać się ona użyteczna.
O ile sama desktopowa aplikacja Skype for Business, podobnie jak Skype może być traktowana jako osobisty komunikator, umożliwiający szybki kontakt audio, wideo i tekstowy z wybranymi znajomymi lub współpracownikami, to dodając do architektury komponent Persistent Chat, wprowadzamy nową formę współpracy w ramach grupy pracowników, określaną kompleksowo jako CEC (Chat-enabled collaboration).
Klient Skype for Business standardowo pozwala nam nawiązać komunikację z jedną osobą lub większą ilością osób (konferencja), jednak po zakończeniu danej dyskusji jej przebieg jest archiwizowany i w zasadzie nie jest już kontynuowany. Piszę 'w zasadzie', ponieważ najnowsze wersje aplikacji pozwalają nam otwierać przerwane konwersacje, a nawet wysyłać wiadomości do osób chwilowo niedostępnych, tak żeby dostały wiadomość po uruchomieniu klienta (tzw. offline mode).
Persistent Chat Server dodaje do SfB pokoje rozmów (chat rooms), które pozwalają nam na przechowywanie konwersacji w ramach danego pokoju dowolnie długo, powiadamiając nas o nowych dyskusjach w pokojach rozmów, które są dla nas interesujące. Jak w praktyce może wyglądać korzystanie z Persistent Chat? Jednym z przykładów wykorzystania tej funkcjonalności może być zarządzanie projektami. Jeżeli w dużej firmie, wielu pracowników często podróżuje lub pracuje z domu, koordynacja projektów nie jest zadaniem banalnym. Wysyłanie wszystkich informacji mailem czy też wymiana informacji konwersacjami SfB nie jest w pełni efektywna i część informacji może nie docierać do wszystkich członków zespołu projektowego lub po prostu być przeoczona w natłoku innych wiadomości pocztowych. Rozwiązaniem problemów może być utworzenie pokojów spotkań dla poszczególnych projektów, a nawet dla poszczególnych faz konkretnych projektów. Tworząc pokój rozmów możemy wskazać osoby biorące udział w projekcie. W ten sposób każda z tych osób uzyskuje informację o nowych informacjach pojawiających się w związku z pracami w projekcie i jednocześnie ma wgląd w historię dyskusji związanych z danym tematem/zagadnieniem.
Inne scenariusze zastosowań mogą dotyczyć np. obsługi dokumentów księgowych, różnego rodzaju wniosków, a nawet powiadomień o błędach w aplikacjach czy pojawiających się w środowisku awariach.
Oprócz pokojów rozmów (kierując się analogią do powyższego przykładu o nazwach związanych z konkretnymi projektami), które z czasem mogą stać się całkiem obszerne, jeżeli umieścimy w nich wiele wypowiedzi, każdy użytkownik SfB może utworzyć sobie kanały tematyczne, które służą do śledzenia dyskusji zawierających konkretne słowa kluczowe, a nawet dodatkowo wskazać powiązania tych słów z konkretnymi nadawcami.
   
Definiując kanał tematyczny wskazujemy również powiadomienie, jakie ma zostać wygenerowane w przypadku pojawienia się wiadomości z konkretnego kanału, jak widać na poniższym rysunku.























Jak widać, dla każdego kanału możemy dostosowywać powiadomienia do naszych preferencji, łącznie ze specyficznym dźwiękiem (innym dla wiadomości normalnej i z wysokim priorytetem).
Warto również skonfigurować sobie domyślne powiadomienia dla . Będą one działały również dla wszystkich pokojów rozmów, których śledzenie włączyliśmy.




















Oczywiście ustawienia powiadomień dla Persistent Chat znajdziemy w opcjach klienta SfB, pod niezbyt fortunnie przetłumaczonym tytułem 'Rozmowa trwała'.























Dla firm, które mają wdrożony portal intranetowy, np. na serwerze Sharepoint, funkcjonalność Persistent Chat może okazać się niepotrzebna, ale jeżeli ktoś ma tylko Exchange, to może warto użyć tej funkcjonalności zamiast list dystrybucyjnych?
Dla większych organizacji, gdzie zachodzi potrzeba odseparowania dostępu do zasobów, administrator usługi może dodatkowo utworzyć kategorie, w ramach których przydzielane są grupy osób mogących korzystać z poszczególnych grup pokojów rozmów. Utworzenie kategorii pozwala również oddzielnie definiować wspólne ustawienia takie jak możliwość dodawania plików do pokojów, mozliwość przeglądania historii rozmów w ramach pokojów oraz użycie zaproszeń do korzystania z pokojów.

24 listopada 2016

Integracja Skype for Business i Exchange - kwestia autodiscovera

Prezentacja statusu dostępności to bardzo wygodna funkcjonalność Skype for Business. Niektórzy twierdzą, że umożliwia szpiegowanie (bo pokazuje kiedy przez jakiś czas nie dotykamy klawiatury), ale dla mnie umożliwia przede wszystkim szybki kontakt ze współpracownikami i kontrahentami, pokazując kiedy są dostępni. W środowisku, gdzie jest wdrożony również Exchange, można używać również mechanizmów integracyjnych do pobierania danych z kalendarza użytkownika w Exchange, w celu automatycznej zmiany statusy z 'dostępny' na 'zajęty'. Dodatkowo klient SfB może wyświetlać informacje publikowane przez asystenta OOF. Funkcjonalność tą możemy wyłączyć (domyślnie jest włączona) w opcjach klienta SfB.

Jak działa ten mechanizm? Wbrew pozorom nie jet to takie oczywiste i w wielu środowiskach może działać on niepoprawnie. Klient SfB, podobnie jak Outlook wykorzystuje usługę EWS (Exchange Web Services), do odpytania serwerów Exchange o dane z kalendarza (Availability Service). Podobnie jak Outlook, klient SfB również używa usługi Autodiscover do odpytania Exchange o konfigurację EWS. Jednak jak to mówią, diabeł tkwi w szczegółach. Na komputerach należących do domeny, Outlook sprawdza w pierwszej kolejności informację znajdującą się w rekordzie SCP (Service Connection Point). Jego wartość możemy sprawdzić wykonując komendę:
Get-ClientAccessServer | select name,AutoDiscoverServiceInternalUri
Na komputerze poza domeną Outlook szuka url - najpierw https://domenapocztowa/autodiscover/autodiscover.xml, następnie, w  drugim kroku sprawdza url https://autodiscover.domenapocztowa/autodiscover/autodiscover.xml, a w trzeciej kolejności sprawdzany jest rekord SRV dla usługi autodiscover (_autodiscover._tcp.domenapocztowa). W przypadku klienta SfB ścieżka jest dużo prostsza, co w wielu środowiskach może spowodować nieco problemów - sprawdzany jest tylko i wyłącznie rekord https://autodiscover.domenapocztowa/autodiscover/autodiscover.xml. Jeżeli nie jest on dostępny, to mogą pojawić nam się komunikaty, mówiące o problemach z integracją, a nawet okna logowania (które oznacza próbę uwierzytelnienia w Exchange). 
Jak zweryfikować, czy SfB poprawnie integruje się z Exchange? Najprościej sprawdzić, zerkając na konfigurację (prawoklik+Ctrl na ikonie skype w pasku zadań)

Następnie sprawdzamy. Jeżeli są wyświetlone ścieżki EWS i widać informację 'Status EWS jest OK', to wszystko powinno działać poprawnie.

Jeżeli ścieżki EWS nie są wyświetlane, to przeważnie również wyświetlana jest informacja o nieprawidłowej konfiguracji EWS lub braku takiej konfiguracji. W większości przypadków świadczy to o tym, że SfB nie był w stanie pobrać informacji o konfiguracji EWS poprzez autodiscover. Oprócz braku rekordu A dla nazwy autoodiscover może to być spowodowane również np. niepoprawną konfiguracją usługi proxy.

18 października 2016

APN Promise Technology Summit 2016

Już pojutrze odbędzie się w Warszawie doroczna konferencja techniczna, przygotowana przez moją firmę - APN Promise Technology Summit 2016
APN Promise Technology Summit
Jak zwykle jestem odpowiedzialny za ścieżkę Communication, na którą serdecznie zapraszam - będzie się działo!

ITDEV CONNECTIONS 2016

W niedzielę wróciłem z konferencji IT/Dev Connections 2016, która odbywała się w Las Vegas. Nie jest to event tak duży jak Ignite, zaledwie 1000-1200 uczestników, ale w tym przypadku to zaleta. Przez 4 dni odbywało się równolegle około 15-20 sesji prowadzonych przez MVP i niezależnych ekspertów, skupiając się na technologicznych szczegółach i praktycznych doświadczeniach wdrożeniowych, zamiast marketingowym pustosłowiu.


W ramach IT/Dev Connections można było obejrzeć sesje w następujących  ścieżkach:
  • Cloud and Datacenter (42 sesje)
  • Community (17 sesji)
  • Data Platform & Business Intelligence (49 sesji)
  • Development Platform, Tools and DevOps (49 sesji)
  • Enterprise Collaboration (58 sesji)
  • Enterprise Management, Mobility and Security (59 sesji)
  • Solutions (7 sesji)
Już kilkukrotnie słyszałem dużo dobrego na temat tej konferencji i muszę przyznać, że nie zawiodłem się. Mniejsza powierzchnia centrum kongresowego hotelu Aria (w porównaniu z ośrodkami gdzie odbywały się konferencje TechEd czy Ignite) dała wiele okazji do spotkań z prelegentami i innymi uczestnikami konferencji. Często niestety wybór sesji był trudny, bo w tym samym czasie prowadzone były sesje zarówno z nowych funkcjonalności Windows Server 2016 (Nano, wirtualizacja, kontenery), zarządzaniu tożsamością jak rozwiązywaniu problemów w Exchange.
Grupa produktowa Exchange była reprezentowana przez kilku najbardziej znaczących specjalistów z Redmond, pod przywództwem Grega Taylora. Oczywiście grupa MVP w kategorii Exchange Server (a właściwie już od roku Office Servers & Services, ale związanych przede wszystkim z systemem Exchange) była liczna, jak widać na poniższym zdjęciu.

Na zdjęciu znaleźli się wszyscy MVP, uczestniczący w konferencji, stoją od lewej:
Kucają od lewej:
Konferencja była zdecydowanie techniczna - poziom sesji 300 i 400, z minimalną ilością firm partnerskich, które prezentowały swoje produkty, jednak znalazła się tam polska firma CodeTwo, oferująca znane od dawna oprogramowanie do stopek w Exchange, teraz również w wersji dla Exchange Online oraz oraz narzędzia ułatwiające migrację i wykonywanie kopii zapasowych skrzynek Office 365.

16 października 2016

LS File Transfer Agent Service zgłasza błąd 1034 po usunięciu serwera z topologii

Niedawno zauważyłem uciążliwy problem po usunięciu z topologii serwera, który poprzednio pełnił rolę CMS. Usługa LS File transfer Agent Service cyklicznie zgłaszała błąd 1034 (jak widać na poniższym rysunku), co oczywiście śmieciło w konsoli SCOM-a, a dodatkowo wprowadzało zamieszanie w logach serwera: 

Zasadniczo powinno pomóc wymuszenie odświeżenia konfiguracji poprzez wykonanie komendy
Invoke-CsManagementStoreReplication, jednak po jej wykonaniu i po sprawdzeniu konfiguracji poprzez Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus, serwer usunięty z topologii i odinstalowany, był widoczny w tablicy DeletedReplicas.
Podobny problem opisał na swoim blogu Thomas Poett, pokazując niewspieraną ale skuteczną metodę polegającą na ręcznym usunięciu z SQL-a odpowiedniego wiersza z tabeli [Replica]. W przypadku, który rozwiązywałem, jednak sposób opisany przez Thomasa nie do końca pomógł - SQL nie pozwalał usunąć wiersza ze względu na referecje w innych tabelach. Faktycznie okazało się, że w tabeli ReplicaStatus są odwołania do tabeli identy
Nie jestem ekspertem od SQL-a, więc zamiast tworzyć kolejne linie T-SQLa, zrobiłem to z wykorzystaniem SQL Management Studio. Po połączeniu do serwera, na którym jest Central Management Store, przeszedłem do widoku tabel tej bazy (rysunek poniżej).  
Następnie wyświetliłem pierwszych 200 rekordów tabeli [Replica].
Korzystając z kolumny ReplicaId, zweryfikowałem wartość z wiersza, odpowiadającego serwerowi, który powinien być skasowany, a następnie przeszedłem do edycji wierszy tabeli [ReplicaStatus] i usunąłem wszystkie wiersze z tym samym numerem.
Teraz już wiersz z tabeli [Replica] pozwala się skasować. I błędy 1034 w logu aplikacyjnym przestaje się pojawiać.


11 października 2016

Naprawa statusu usług Exchange

Pół roku temu opublikowałem na blogu skrypt, który przywracał poprawny status wszystkich usług Exchange, wyłączonych przez niepoprawnie zakończoną aktualizację. Jednak nie byłem zadowolony z takiej postaci skryptu i nieco go poprawiłem. Zamiast wypisywać kolejne komendy zmiany statusu usług Exchange, nowa wersja skryptu pobiera listę usług oraz poprawny status usługi z pliku csv (dwie kolumny - SrvName i Mode) i następnie w pętli dla każdej z usług sprawdza, czy nie ma ona statusu "Disabled".

Ponieważ parametr filtrowania wyników oczekuje czystego stringu a nie zmiennej, więc dodatkowo tworzę zmienną, zawierającą definicję filtru dla konkretnego serwisu.
Jeżeli usługa ma tryb uruchomienia ustawiony na "Disabled", to skrypt zmienia ustawienia serwisu zgodnie z informacjami w drugiej kolumnie pliku csv. Taką wersję skryptu opublikowałem w galerii Technet. Skrypt należy uruchamiać w kontekście administratora (zmienia ustawienia usług systemowych), ale nie potrzebuje powłoki Exchange ponieważ działa tylko na poziomie WMI i serwisów.

29 września 2016

REST API w Exchange

Kilka dni temu pisałem o CU3 dla Exchange 2016. Na konferencji Ignite w Atlancie, Microsoft zaprezentował jeszcze jedną funkcjonalność, której wcześniej nie ujawniono - wsparcie dla REST API. W środowiskach hybrydowych ułatwi to uwierzytelnianie i ujednolici wsparcie aplikacyjne w O365 i on-premises. Przy okazji pojawił się dodatkowy wirtualny katalog na potrzeby developerskie - /api. Informacje o zmianach można znaleźć na stronie o rozszerzeniach programistycznych dla Outlooka.

26 września 2016

Migracja skrzynek raz jeszcze

O migracji skrzynek pocztowych pomiędzy różnymi wersjami Exchange pisałem już kilkukrotnie, ostatni raz o migracji do wersji 2013. Kilka lat minęło, pojawiła się nowa wersja i nieco już na rynku okrzepła (właśnie wydano CU3), ale niestety wydajność migracji pozostawia wiele do życzenia.
Nadal wydajność pozostawia wiele do życzenia, a optymalizacja nie jest wcale oczywista. Dla osób, które korzystają z konsoli webowej, przenoszenie nawet pojedynczych skrzynek będzie trwało bardzo długo. Mimo wszystko postaram się zebrać kilka przydatnych wskazówek, działających zarówno dla serwerów Exchange 2013 jak i 2016.
Niektórzy twierdzą, że warto w pliku konfiguracyjnym usługi Mailbox Replication - “MSExchangeMailboxReplication.exe.config” zwiększyć wielkość bufora. Domyślnie zapisany jest parametr:
ExportBufferSizeKB=”512″
zamiast 512 należy w cudzysłowiu wpisać 10240 i zrestartować usługę. Powinno trochę pomóc, ale niestety niewiele.
Kolejnym zaleceniem, które wiele osób podkreśla, jest wyłączenie indeksowania baz danych - tych docelowych, które dodatkowo najczęściej spięte są w grupę DAG, co dodatkowo powoduje replikację danych między nimi i zwiększa obciążenie serwerów. Można to zrobić bardzo prosto poleceniem:
Set-MailboxDatabase -identity "Baza skrzynkowa" -indexEnabled $false
To przyspiesza część operacji, ale jak dla mnie niezadowalająco.
Żeby migracja zaczęła wykonywać się w miarę sprawnie należy wyłączyć lub obejść wbudowany w Exchange mechanizm throttlingu, czyli dławienia procesów. Opisywałem to w poście, który wymieniałem na początku artykułu:
new-moverequest -identity "skrzynka" -targetdatabase "Baza skrzynkowa" -priority highest -BadLimitRequest 50
Niektórzy zalecają piority emergency, ale wg mnie highest jest wystarczająca. Dzięki temu zadania migracyjne mają odpowiednio wysoki priorytet wykonania. Przy okazji dodanie niezerowego limitu na ilość uszkodzonych elementów też jest dobrą praktyką.

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.