Konferencja Exchange/Lync/System Center

Już za tydzień APN Promise organizuje konferencję w Warszawie, która podobnie jak zeszłoroczny PreMTS koncentruje się na zagadnieniach z rodziny Unified Communication i System Center, ze szczególnym uwzględnieniem chmury publicznej (Office365 i Azure) oraz modelu hybrydowego.

Ja będę opowiadać o integracji funkcji głosowych dla Lync Online, Load Balancerach Kemp w Azure oraz narzędziach migracyjnych do Exchange. Serdecznie zapraszam 6 listopada do Millenium Plaza przy placu Zawiszy w Warszawie.

Nowy kwadrat magiczny Gartnera w kategorii ADC

Gartner opublikował magiczny kwadrat dla kategorii Application Delivery Controllers. Jak można się było spodziewać, leaderami są nadal F5 i Citrix, a Kemp Technologies powoli przesuwa się w górę kwadratu. Co ciekawe zniknął z niego Fortinet, za to pojawił się lokalny producent z Południowej Korei – Piolink.

Kemp jest chwalony za szeroki wybór modeli, jako jedyny z graczy oferuje opcję Bare Metal z wykorzystaniem serwerów najważniejszych producentów, dobrze oceniony jest również ze względu na przyjazne ceny. Minusami wg. Gartnera jest brak firewalla aplikacyjnego (który pojawi się już za chwilę), oraz niewielka wielkość firmy, co stanowi potencjalne zagrożenie.

Skrypt do zmiany nazw wirtualnych katalogów w Exchange

Zmiana nazw wirtualnych katalogów (a w zasadzie nazwy hosta, przez którą dostają się do Exchange klienci) wymaga wykonania wielu cmdletów (nie wszystkie nazwy można zmienić z poziomu narzędzi webowych). Łatwo przy tym coś przeoczyć lub po prostu zrobić literówkę. Jakiś czas temu opublikowałem w galerii skryptów na Technecie skrypt do listowania wszystkich tych nazw i spotkał się z ciepłym przyjęciem (ponad 500 pobrań). Teraz przygotowałem, na podstawie skryptu dla starszej wersji Exchange taki skrypcik dla Exchange 2013 i również opublikowałem na Technecie.

https://gallery.technet.microsoft.com/Set-all-virtual-directories-f4ec71d3 

Wydaje mi się, że jest dosyć przejrzysty, jak widać na poniższym rysunku:

Oczywiście, po wykonaniu skryptu należy wykonać restart IIS (najlepiej komendą iisreset /noforce /timeout:5000) na każdym modyfikowanym serwerze.

Przekierowania na Kempie

Definiując publikację Exchange na load balancerach Kempa z szablonu, automatycznie tworzony jest wirtualny serwis przekierowania ruchu portu http na https, tak że po wpisaniu nazwy hosta w przeglądarce zostajemy przekierowani do wirtualnego katalogu usługi OWA po protokole https (podobnie jak w IIS realizowane jest to poprzez obsługę kodu 302).

Jednakże, gdy chcemy wpisać krótką nazwę, a jest ona inna niż nazwa hosta, którą umieściliśmy w certyfikacie (przykładowo chcielibyśmy używać nazwy poczta, pełna nazwa serwisu OWA to poczta.pepug.org, a wewnętrzna domena Active Directory nazywa się pepug.local), to dostaniemy warning o niepoprawnym połączeniu – domyślna reguła doklei tylko /owa na końcu nazwy i zamieni http:// na https://, czyli po wpisaniu nazwy poczta, zostaniemy przekierowani na nazwę https://poczta/owa. Podobny problem będziemy mieli wpisując w przeglądarce np. adres IP wirtualnej usługi.

Co zatem robić? Najprościej jest zmienić przekierowanie na poziomie wirtualnej usługi, jednak metoda taka jest mało elastyczna – czasami na serwerach Exchange chcemy mieć dwie witryny różniące się obsługiwaną nazwą i w tym przypadku taka konfiguracja nie zadziała. Żeby ten problem rozwiązać w sposób elegancji pierwsze rozwiązanie, jakie sięnasuwa, to wykorzystanie reguł wybierających zawartość, podobnie jak to opisałem wcześniej przy okazji SSO i Sharepointa- http://pepugmaster.blogspot.com/2014/07/publikacja-sharepoint-2013-na-kempie-i.html. W tym celu tworzymy dwie reguły, które pozwolą wybrać nazwę hosta zgodną z docelową (w tym przykładzie poczta.pepug.org) lub inną wskazaną przez nas.

Teraz pozostaje nam zmodyfikować regułę przekierowania http. W tym celu musimy dodać dwa subinterface’y, na których ustawimy przekierowania.


Teraz tylko pozostaje nam w głónej definicji VIP-a włączyć Content Switching i podpiąć zdefiniowane wcześniej reguły.


Podobnie postępujemy dla innych URL-i.

Teraz jeszcze tylko wyczyszczenie ustawienia przekierowania na poziomie głównego VIP i gotowe. Niezależnie od tego, czy wpiszemy w przeglądarce nazwę poczta, poczta.pepug.org czy adres IP, zostaniemy przekierowani na url https://poczta.pepug.org/owa. Oczywiście musimy mieć w DNS dla domeny Active Directory dodany rekord host o nazwie poczta z tym samym adresem IP. Należy również pamiętać, że zadziała to tylko z poziomu sieci wewnętrznej.

Poprawki do Exchange i Lynca

Zaledwie 10 dni temu zespół Lyncowy wydał najnowszą porcję poprawek dla serwera Lync 2013, a kilka dni później dla telefonów sprzętowych:

Product	Version	Download
Lync Phone Edition (for Aastra 6721ip and Aastra 6725ip)	4.0.7577.4451	2988177
Lync Phone Edition (for HP 4110 and HP 4120)	4.0.7577.4451	2988178
Lync Phone Edition (for Polycom CX500, Polycom CX600, and Polycom CX3000)	4.0.7577.4451	2988181
Lync Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540	4.0.7577.4451	2988182

Dzisiaj zespół Exchange wydał poprawki dla wszystkich wspieranych wersji Exchange:

• Exchange 2013 CU6. Opis wszystkich poprawek można znaleźć tutaj, warto wspomnieć o poprawce dla kreatora konfiguracji hybrydowej (błąd opisany w artykule KB2988229 oraz znaczących usprawnieniach w skalowalności folderów publicznych, o czym zamieszczono osobny artykuł na blogu zespołu produktowego. Warto pamiętać o odpowiednich uprawnieniach, bo CU6, podobnie jak poprzednie pakiety rozszerzają schemat AD.
• Exchange 2010 SP3 Rollup 7. To ostatni pakiet poprawek klienckich dla Exchange 2010 (przynajmniej tak na razie twierdzi zespół produktowy).
• Exchange 2007 SP3 Rollup 14.

Lync leaderem UC wg Gartnera

Gartner opublikował magiczny kwadrat Unified Communications. Lync po raz kolejny jest leaderem w zakresie Unified Communications.

Współpraca telefonów Audiocodes serii 400 z Lync–“Better Together”

Coraz więcej producentów telefonów IP dla Lynca wprowadza możliwość współpracy telefonu ze stacjonarnym klientem – zarówno Lync 2010 jak i Lync 2013 i to nie tylko po kalblu USB, ale również bezpośrednio po sieci IP. W zeszłym roku takie funkcjonalności ogłosił zarówno Polycom jak i SNOM, o czym pisał na swoim blogu Matt Landis - http://windowspbx.blogspot.com/2013/07/how-will-lync-enhanced-better-together.html. Kilka miesięcy temu, na konferencji Lyncowej Audiocodes ogłosił uruchomienie wersji Beta swojej wersji integracji dla telefonów z serii 400HD - http://windowspbx.blogspot.com/2014/03/an-update-on-audiocodes-440hd-430hd.html?vsmaid=184. A dosłownie kilka dni temu pojawiła się finalna wersja firmware dla telefonów i aplikacji dla komputerów, przeznaczonych dla Lynca do współpracy z klientem stacjonarnym. Jak tego użyć?

Po pierwsze trzeba zaktualizować firmware w telefonie. Telefony audiocodes mają bardzo przyjemny i przyjazny interface webowy (podobny do tego na bramkach z linii Mediant), przez który można wejść i ręcznie zaktualizować firmware, jak widać na rysunku poniżej.

Tutaj od razu uwaga – logowanie przez przeglądarkę działa domyślnie na zalogowanego na telefonie usera (czyli np. jak mój SAMAccountName jest konrad, to muszę się zalogować przez przeglądarkę jako użytkownik konrad, z hasłem domenowym). Żeby zalogować się przez przeglądarkę na konto administratora (domyślnie admin i hasło 1234) trzeba się wylogować z telefonu. Niezbyt oczywiste, prawda?

Po aktualizacji firmware do wersji 2.0.5, na wyświetlaczu telefonu pojawia się dodatkowa opcja – BToE (czyli Better Together over Ethernet).

Po wybraniu tej opcji pojawi nam się kod niezbędny dla sparowania telefonu z aplikacją na komputerze:

Będzie to nam potrzebne za chwilę. Teraz instalujemy na komputerze aplikację, łączącą klienta Lyncowego z telefonem - AudioCodes Better2Gether 0.0.0.6.exe. Instalacja jest prosta – wystarczy kliknąć w plik i kilkakrotnie potwierdzić Next. Wersja beta nie chciała się instalować na Windows 8/8.1, wersja finalna na szczęście działa. Ważną kwestią, która potwierdza prawidłowe zainstalowanie aplikacji jest dodanie sterownika USB do urządzeń systemowych (rysunek poniżej).

Oprócz tego pojawi nam się na taskbarze ikonka aplikacji.

Teraz pozostaje drobiazg – sparowanie aplikacji z telefonem. W tym celu należy wybrać z meny kontekstowego opcję Enter Pair Code… i wpisać kod, który odczytaliśmy z wyświetlacza telefonu.

W tym momencie (jeżeli wszystko poszło poprawnie) zobaczymy, że instaluje nam się sterownik audio, a ikonka aplikacji zmienia kolor, zmieni nam się również układ w menu kontekstowym:

W tym momencie również na liście urządzeń, dostępnych w kliencie Lync pojawia nam się dodatkowa pozycja

Teraz po podniesieniu słuchawki telefonu i wybraniu połączenia z klienta na komputerze, rozmowa zostanie uruchomiona z telefonu. Proste, prawda?

Publikacja Sharepoint 2013 na Kempie i SSO

Konfigurując usługi Exchange i Lync czasem również mam okazję wykonać pewne akcje integracyjne dla Sharepointa. Publikacja Exchange i Lynca z wykorzystaniem zewnętrznych Load Balancerów jest dobrze opisana, zarówno przez producentów tych urządzeń jak i przez Microsoft, jednak w zakresie publikacji usług Sharepoint trudno znaleźć w internecie procedurę w tym zakresie. Zwłaszcza, że ze względu na kończące się wsparcie dla TMG, jeżeli firma chce opublikować swoją witrynę z dodatkowym zabezpieczeniem problem ten nabiera dodatkowego wymiaru. Niedługo Kemp udostępni niebawem dokumentację opisującą publikację usług Sharepointowych, jednak jak na razie tylko w zakresie pojedynczej witryny portalu firmowego.

Wielu administratorów wykorzystuje konfigurację Sharepointa, gdzie portal firmowy wykorzystuje krótką nazwę, np. http://intranet lub http://portal, a witryny użytkowników wykorzystują witrynę http://mysite. Jak w takim wypadku poprawnie opublikować Sharepointa dla naszych pracowników/współpracowników w internecie, tak żeby nie musieli przechodząc między tymi witrynami ponownie się uwierzytelniać?

Pierwszą kwestią jest oczywiście AAM (alternative access mapping). Chociaż można i bez tego skonfigurować publikację na Kempie, jednak dla porządku i spójności architektury dobrze jest zdefiniować publikację po https, z wykorzystaniem dostępnej z internetu nazwy hosta – np. https://intranet.pepug.org i https://mysite.pepug.org. Niestety Sharepoint zmusza nas do dodania certyfikatów dla tych witryn po stronie serwera IIS z poziomu konsoli IIS Managera oddzielnie, ale jak się o tym pamięta, to nie powinno być problemów.

Kolejnym krokiem jest dodanie na witrynie Sharepointowej możliwości uwierzytelnienia typu Basic.Zarówno dla witryny intranet jak i mysite. Jest ot bardzo proste, ale miejsce, gdzie to należy ustawić nie jest już takie oczywiste (przynajmniej dla mniej zaawansowanych). Należy zatem w centralnej konsoli administracyjnej Sharepointa wejść w zarządzanie aplikacjami (Central Administration-Application Management-Manage Web Application). Wybrać daną witrynę (na rysunku wybrana witryna intranet), a następnie kliknąć w przycisk Authentication Providers. Wybieramy z listy dostępnego providera (jeżeli nie konfigurowaliśmy Sharepointa w specyficzny sposób, powinien być tylko jeden – domyślny) – rysunek 2, a następnie zaznaczamy checkbox przy uwierzytelnieniu Basic (rysunek 3).

Rysunek 1. Konfiguracja opcji uwierzytelniania dla aplikacji

Rysunek 2. Wybór providera

Rysunek 3. Włączenie uwierzytelniania typu Basic

Oczywiście po tym niezbędny będzie restart IIS-a, ale nie musimy za to ręcznie zmieniać ustawień w IIS Managerze.

Przejdźmy teraz do publikacji witryny (lub całej farmy, jeżeli mamy kilka FrontEndów Sharepointa).

Na Kempie tworzymy nową wirtualną usługę, do której dodajemy dwa subinterface’y powiązane z każdą z naszych witryn:

Rysunek 4. Standardowe opcje publikacji, zalecane dla Sharepointa przez Kempa

Na poziomie głównym serwisu dodajemy również certyfikat – bądź to zawierający obie nazwy publiczne, bądź to wildcardowy dla naszej domeny.

Rysunek 5. Subinterface’y dodane dla naszych witryn

Teraz musimy utworzyć reguły,  które pozwolą wybrać z tej listy odpowiednią witrynę na podstawie nagłówka zapytania https, przekazanego przez klienta – jedną dla witryny intranet, jedną dla mysite:

Rysunek 6. Tworzenie reguły na podstawie nazwy witryny

Następnie we właściwościach zaawansowanych witryny włączamy content switching:

Rysunek 7. Włączenie content switchingu dla wirtualnej usługi

Teraz trzeba tylko przypisać odpowiednią regułę do obu witryn:

Rysunek 8. Dodanie reguły przełączania dla subinterface’u

Rysunek 9. Dodanie reguły – wybór z listy reguł

Po dodaniu reguł będzie o tym informacja pokazana we właściwościach subinterface’ów.

Rysunek 10. Lista subinterface’ów z informacją o przypisanych regułach wyboru treści

Ostatni punkt programu to skonfigurowanie ESP (Edge Security Pack) dla każdej z naszych witryn. W ramach konfiguracji ESP należy skonfigurować SSO, czyli w tym wypadku komunikację z kontrolerem/kontrolerami naszej domeny Active Directory.

Rysunek 11. Konfiguracja domeny dla SSO

Jeżeli na Kempie wcześniej było konfigurowane SSO dla Exchange, to nie musimy tego robić, wystarczy wybrać z listy już dostępnych domen.

Rysunek 12. Konfiguracja ESP dla subinterface’u

W ten sposób publikujemy obie witryny. Wpisując w przeglądarce adres https://intranet.pepug.org pojawi nam się formularz logowania, po wpisaniu nazwy użytkownika domenowego i hasła zalogujemy się do portalu, po kliknięciu na odnośnik “O mnie” zostaniemy przekierowani do drugiej publikowanej witryny http://mysite.pepug.org, bez konieczności dodatkowego uwierzytelnienia. Jeżeli wpiszemy url naszej witryny OWA np. https://owa.pepug.org/owa, to również korzystając z SSO zostaniemy zalogowani do strony OWA naszego Exchange.

Certyfikat Wildcard dla usługi POP/IMAP w Exchange

Tym razem chciałem przestawić ciekawy artykuł, przygotowany przez Jacka Światowiaka – MVP w kategorii Directory Services. Nie prowadzi własnego bloga, więc w ten sposób chciał się podzielić własnymi doświadczeniami.

Jak przypisać certyfikat typu Wildcard do usług POP/IMAP w Exchange?

UPDATE:
W Exchange 2016 nastąpiła istotna zmiana - jest bezpieczniej, ale trudniej. Nawet wpisując (jak widać dalej w artykule) nazwę usługi, należy wpisać nazwę, która jest zapisana w certyfikacie. Na szczęście zdecydowana większość certyfikatów wildcardowych oprócz nazwy *.testowa.pl ma również nazwę samej domeny - testowa.pl. Czyli konfigurując usługę musimy wpisać
set-popsettings -X509certificatename testowa.pl

Mimo że natywnym kanałem komunikacyjnym dla klientów systemu Exchange 2013 jest MAPI, to cały czas wiele organizacji musi wykorzystywać jeszcze kanały POP3/IMAP4, chociażby ze względu na aplikacje LOB. Domyślnie protokoły POP3 i IMAP4 nie są włączone w żadnej wersji serwera Exchange. By wykorzystać POP3/IMAP4 należy w pierwszej kolejności zmienić tryb uruchomienia tych usług z ‘manual’ na ‘automatic’  i włączyć odpowiednie usługi. Nie będę omawiał przeznaczenia obu usług.

Rysunek 1. Usługi Exchange – obsługa POP – konfiguracja domyślna

Rysunek 2. Usługi Exchange – obsługa POP – konfiguracja zmodyfikowana
Zakładam, że w magazynie certyfikatów konta komputera znajdują się certyfikaty wymagane przez Exchange, jak również certyfikat wildcard, co widać z rysunku 3.

Rysunek 3. Magazyn certyfikatów konta komputera
Na początek parę informacji, właściwości oraz przeznaczenia znajdujących się w tym magazynie certyfikatów.

Domyślny certyfikat typu self-sign generowany w momencie instalacji serwera Exchange	Wygenerowany certyfikat typu SAN, który został przypisany do usług webowych (IIS)
Certyfikat wykorzystywany wewnętrznie przez Exchange	Nazwy alternatywne dla certyfikatu powyżej.

Rysunek 4. Właściwości certyfikatów na serwerze Exchange
Aby podejrzeć parametry skonfigurowanej usługi POP czy IMAP, przechodzimy na poziom konfiguracji serwerów, klikamy właściwości serwera poziom POP.

Rysunek 5. Właściwości usługi POP w konsoli Exchange 2013
Najbardziej interesujące parametry dla administratora to metody uwierzytelniania:

Rysunek 6. Zmiana metody uwierzytelniania dla usługi POP
Domyślnie jest skonfigurowany mechanizm Secure TLS connection. Jednak wiele starszych klientów wymaga metody prostszej – Basic authentication (Plain text).
Aby podejrzeć, do jakich usług są przypisane poszczególne certyfikaty, należy sięgnąć w konsoli EAC na poziom Server – Certyfikaty. Jak widać z rysunku 7 certyfikat o nazwie WILDCARD nie jest powiązany z żadną usługą.

Rysunek 7. Informacje o przypisaniu certyfikatu o nazwie WILDCARD

Rysunek 8. Informacje o przypisaniu certyfikatu EX2k13

Rysunek 9. Informacje o przypisaniu certyfikatu Microsoft Exchange Server Auth Certificate

Rysunek 10. Informacje o przypisaniu certyfikatu Microsoft Exchange

Ostatni certyfikat, domyślnj nazwie WMSVC nie jest przypisany do żadnych usług pocztowych i przez Exchange nie jest wykorzystywany. Czasem na liście może również pojawić się certyfikat dla usług federacyjnych, ale to dotyczy tylko niektórych konfiguracji.

Jak widać z prezentowanych rysunków 8 i 19 do usługi pop są przywiązane aż dwa certyfikaty (sic!). Również dla usługi SMTP są przypisane dwa certyfikaty. Pozostaje odpowiedzieć na pytanie jak Exchange wybiera właściwy certyfikat, który ma być użyty z daną usługą.

Spróbujmy zatem przypisać certyfikat WILDCARD do usługi POP. Po kliknięciu na certyfikat, w jego właściwościach na zakładce Services, mamy możliwość wybrania z jakimi usługami ma on być powiązany.

Rysunek 11. Przywiązanie certyfikatu do usług
Niestety czeka na niespodzianka. Konsola nie pozwala na przypisanie certyfikatu typu wildcard do usługi POP/IMAP. Próba skorzystania z polecenia Set-PopSettings również zakończy się niepowodzeniem.

Rysunek 12. Komunikat błędu przy powiązaniu certyfikatu typu wildcard

Jak podejrzymy konfigurację poleceniem Get-PopSettings (rysunek 13), wartość pola X509CertificateName będzie dość dziwna. Nie ma w magazynie certyfikatu o takiej nazwie. Tu jest właśnie rozwiązanie naszego zagadnienia. Serwer Exchange stara się z listy certyfikatów dostępnych w magazynie wybrać najbardziej pasujący do nazwy serwera (SERWER nosi krótką nazwę EX@K13-1, nazwa ta jest zawarta w certyfikacie typu SAN, który sobie wygenerowałem korzystając z wewnętrznej jednostki certyfikującej – sam certyfikat prezentowany jest na rysunku 4 i 8.

Rysunek 13. Konfiguracja POP

Załóżmy teraz ze usługa POP wystawiona jest na zewnątrz pod jakąkolwiek nazwą – byle by była rozwiązywana na prawidłowy adres IP, np. mail2.testowa.pl – tej nazwy nie ma w naszym certyfikacie typu SAN przypisanym do usługi POP – zatem klienci POP3 zestawiając połączenie po SSL będą dostawać poniższe okno informujące o niezgodności nazw.

Rysunek 14. Komunikat niezgodności nazwy w certyfikacie
Przechwycona komunikacja jeszcze na fazie uzgadniania sesji SSL. Jak widać nie zgadza się common-name.

Rysunek 15. Przechwycony ruch negocjacji sesji SSL dla POP
Aby podstawić certyfikat wildcard należy skorzystać z polecenia Set-PopSettings.

Rysunek 15. Zmiana mapowania nazwy certyfikatu dla usługi POP
Jako nazwę certyfikat należy podać dowolną nazwę z danej domeny – tak, która nie pasuje do żadnej z nazw zawartych w certyfikacie typu SAN. Który również mógłby być przez exchange podstawiony.
Teraz Exchange próbując dopasować nazwę, do której zestawimy połączenie SSL wybierze certyfikat wildcard, ponieważ on pokrywa wszystkie nazwy dla danej domeny.

Rysunek 16. Uaktualniona konfiguracja usługi POP

Rysunek 17. Dopasowany certyfikat wildcard do sesji SSL
Teraz już klienci POP po SSL nie będą generować komunikatu błędu, a tym samym certyfikatem SSL (typu Wildcard) , będzie można obsłużyć usługi IIS, SMTP, POP3 oraz IMAP4.