Aktualizacje antimalware w Exchange 2016

Jakiś czas temu pisałem na blogu artykuł o tym jak naprawić/ręcznie zaktualizować silnik Antimalware w Exchange 2013. Artykuł cieszył się dużym zainteresowaniem - problem jest dosyć popularny. Po kilku wdrożeniach Exchange 2016 z przykrością muszę zauważyć, że niestety w nowej wersji Exchange nie udało się Microsoftowi wyeliminować całkiem tego problemu.

Na szczęście jednak rozwiązanie problemu jest dużo prostsze. Wystarczy tylko otworzyć w Exploratorze Windows folder z binariami silnika antimalware, znajdujący się w katalogu - <Ścieżka instalacyjna Exchange>\FIP-FS\Data\Engines\amd64\Microsoft\bin - system stwierdzi brak uprawnień dla administratora, zaktualizuje ACL i po restarcie usługi Microsoft Filtering Management Service lub po odczekaniu do kolejnej sesji aktualizacyjnej najnowsza wersja silnika zostanie pobrana i usługa zacznie działać poprawnie.

Grudniowe aktualizacje Exchange

Właśnie ukazały się poprawki do Exchange - CU11 do Exchange 2013, RU12 do Exchange 2010SP3, oraz RU18 do Exchange 2007 SP3. Jak widać na powyższej liście nie ma Exchange 2016. Poprawki do tej wersji Microsoft zapowiedział na następny kwartał.

Najwięcej zmian wprowadza CU11 do Exchange 2013. Nie są one rewolucyjne, ale po pierwsze są niezbędne dla serwerów pracujących w hybrydzie z O365, po drugie wprowadzają zmiany funkcjonalne w pracy w trybie mieszanym z Exchange 2016 i 2010. Zmiany te zespół produktowy opisał w osobnym artykule na swoim blogu - Exchange management shell and mailbox anchoring.

CU11 nie rozszerza schematu, ale wprowadza kilka zmian w modelu RBAC, więc niezbędne jest przygotowanie lasu (co oczywiście wymaga uprawnień Enterprise Admina). No i oczywiście nieszczęsny UMLanguage Pack - jest nowy, ale przed instalacją CU11 poprzedniego trzeba odinstalować. Podobnie jak poprzednio, CU11 można instalować jako aktualizację na dowolną wczesniejszą poprawkę lub jako nowy serwer.

Shared Line Appearance w Skype for Business CU1

Główną zmianą czy też rozszerzeniem funkcjonalnym, jakie pojawiło się w pakiecie Cummulative Update 1 jest funkcjonalność Shared Line Appearance (SLA). Ma ona pozwolić grupie użytkowników/urządzeń współdzielić numer dla rozmów wychodzących oraz przychodzących. Analogiczne funkcjonalności istnieją np. w Asterisku czy CUCM.

Żeby obsłużyć SLA w CU1 pojawiły się nowe cmdlety, które pozwalają przypisać numer do grupy, przypisywać indywidualne numery do grupy i weryfikować ich przypisanie, a nawet ustalać ilość połączeń, które jednocześnie można przeprowadzić - https://technet.microsoft.com/en-us/library/gg398867.aspx. Dla połączeń przychodzących można ustawić sygnał zajętości (Busy on Busy), jeżeli wszyscy w grupie rozmawiają, Można również przekierować połączenie na pocztę głosową.

Dodatkowo w ramach grupy podpiętej do linii współdzielonej można sprawdzić status połączeń innych osób w grupie, zaparkować rozmowę i odebrać z innego telefonu w ramach grupy.

Nowa funkcjonalność jak na razie jest dostępna w telefonach Polycom VVX z firmware 5.4.1 (a właściwie ma być, bo nadal ta wersja firmware jeszcze oficjalnie nie jest dostępna). Dzięki uprzejmości polskiego biura Polycom dostałem do testów telefony VVX 500 i 400 z beta wersją nowego firmware’u. Przy okazji dodam, że telefony Polycom VVX obsługują opisywaną przeze mnie technologię Better Together over Ethernet, pozwalającą na przekierowywanie rozmów z klienta Lync/Skype for Business do telefonu. Oprogramowanie BToEConnector (aktualna wersja 3.1) nie wymaga konfiguracji, ale ma ograniczenie w porównaniu z odpowiednikami Audiocodesa czy SNOM-a – wymaga aby komputer był podpięty do sieci poprzez port ethernetowy w telefonie.

Wrócę jednak do funkcjonalności SLA. W pierwszej kolejności oczywiście musimy ją skonfigurować na serwerze SfB. Musimy zacząć od dodania nowej aplikacji, powiązanej z daną pulą serwerową (jej FQDN podajemy w wywołaniu komendy):

New-CsServerApplication -Identity 'Service:Registrar:%FQDN%/SharedLineAppearance' -Uri http://www.microsoft.com/LCS/SharedLineAppearance  -Critical $false -Enabled $true -Priority (Get-CsServerApplication -Identity 'Service:Registrar:%FQDN%/UserServices').Priority 

Kolejnym krokiem jest aktualizacja modelu zarządzania poprzez role:

Update-CsAdminRole

a następnie zrestartować usługę FrontEnd:

Stop-CsWindowsService RTCSRV 
Start-CsWindowsService RTCSRV

W ten sposób nasze środowisko jest przygotowane do SLA, możemy utworzyć pierwszy obiekt SLA. Jest to po prostu zwykły obiekt użytkownika domenowego (funkcyjnego), dla którego jest konfigurowana funkcjonalność SLA. Użytkownik musi być włączony do SfB i mieć przydzieloną funkcjonalność Enterprise Voice. Jeżeli utworzymy w domenie użytkownika SLAGroup1, włączymy mu funkcjonalność SfB z opcją Enterprise Voice to następnym krokiem jest ustawienie konfiguracji:

Set-CsSlaConfiguration -Identity SLAGroup1 -MaxNumberOfCalls 2 -BusyOption BusyOnBusy

Oczywiście, ilość równoległych połączeń i zachowanie w przypadku zajętości należy ustalić w zależności od środowiska.

Mając konfigurację możemy dodać delegatów, czyli osoby współdzielący dany numer/linię telefoniczną.

Add-CsSlaDelegates -Identity SLAGroup1 -Delegate sip:konrad.sagala@promise.pl

Na telefonie pojawią się dodatkowe pozycje, pozwalające odebrać rozmowy w imieniu grupy:

TLS – zalecenia dla Exchange

UPDATE – ciekawy i bardzo obszerny wpis na temat wpisów w rejestrach i możliwości włączania/wyłączania poszczególnych algorytmów kryptograficznych można znaleźć tutaj - http://blogs.technet.com/b/askds/archive/2015/12/08/speaking-in-ciphers-and-other-enigmatic-tongues-update.aspx.

Rozmawiając o wdrożeniach Exchange, często pojawia się temat bezpieczeństwa dostępu i optymalnego zabezpieczenia dostępu klienckiego. Chociaż nie ma informacji o włamaniach z wykorzystaniem OWA, to poprawne skonfigurowanie protokołów dostępowych. Jest to istotne zwłaszcza w kontekście skompromitowania protokołu SSL 3.0 i pojawiających się w związku z tym zagrożeń. Bardzo dobry artykuł na ten temat pojawił się na blogu zespołu produktowego Exchange w lipcu tego roku - http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx. Opisano w nim ogólne zasady, których należy się trzymać, a nawet kroki konfiguracyjne, które należy wykonać. W skrócie chodzi o:

• wyłączenie protokołu SSL 3.0 na serwerach i klientach i oparcie komunikacji o protokół TLS, jeżeli się da to 1.2, ewentualnie 1.1 lub 1.0.

• jeżeli jest to możliwe to zablokowanie szyfrowania RC4 jako metody niewiarygodnej,

• wyłączenie hashowania MD5/MD2

• wykorzystanie RSA-2048 przy generowaniu nowych kluczy certyfikatów,

• przejście na podpis SHA 256-bit lub wyższy, jeżeli to możliwe

Oczywiście instalowanie na bieżąco poprawek zabezpieczeń na serwerach Exchange jest również warunkiem niezbędnym.

Pozwalam sobie umieścić rysunek z domyślnymi ustawieniami SSL w kolejnych wersjach Windows Server:

Zawsze jednak dobrze jest dodatkowo zabezpieczyć system Exchange poprzez reverse proxy, w przypadku środowiska składającego się z kilku serwerów, dobrze jest to realizować na urządzeniach, które jednocześnie realizują load balancing, jak np.LoadMaster firmy Kemp. Tutaj przy publikacji usług Exchange wszystko staje się proste (zwłaszcza gdy wybierzemy szablon z reenkrypcją) – w bardzo prosty sposób mamy możliwość wyłączenia SSL 3.0 oraz RC4. Domyślnie po włączeniu szablonu Exchange 2013z reenkrypcją i przypisaniu certyfikatu mamy ustawienia jak na rysunku poniżej:

Dodatkowo z listy ustawień algorytmów szyfrujących możemy wybrać szablon bez RC4 lub zdefiniować własny, również dodatkowo okrojony:

Takie ustawienia dają nam zgodność z zaleceniami bezpieczeństwa. przynajmniej dla protokołów SSL/TLS. Jakie to proste.

Pakiet poprawek CU1 do Skype for Business

Oficjalnie pokazał się pakiet aktualizacji CU1 dla Skype for Business 2015. Trochę długo po premierze (wcześniej była wydana jedna mała poprawka funkcjonalna i poprawka zabezpieczeń), ale dobrze, że w końcu jest. Informacje o zmianach można znaleźć w artykule https://support.microsoft.com/en-us/kb/3061064. W odróżnieniu od Lync 2013 nie ma potrzeby aktualizować baz danych.

Problem z certyfikatami Starfield w Firefoxie

Właśnie zauważyłem, że nowa wersja Firefoxa blokuje certyfikaty Starfield, nawet jeżeli doda się wyjątek bezpieczeństwa:

Dopiero zaimportowanie certyfikatu urzędu pośredniczącego rozwiązuje ten problem. W tym celu wchodzimy w Firefoxie w Opcje -> Zaawansowane -> Certyfikaty -> Wyświetl certyfikaty -> Organy certyfikacji –> Importuj.

Następnie wskazujemy certyfikat “Stafield Secure Certification Authority” i potwierdzamy import, zanaczając dodatkowo opcję “Zaufaj temu certyfikatowi przy identyfikacji witryn internetowych”.

Kolejne połączenie przebiegnie pomyślnie. Co ciekawe problem pojawił się ostatnio i występuje tylko w Firefoxie. Ciekaw jestem czy podobne problemy pojawiły się dla jakiś innych dostawców certyfikatów?

Automatyzacja konfiguracji wirtualnych katalogów Exchange

Zaczął się sezon na migracje, także do Exchange 2016. Jednym z elementów konfiguracji jest odpowiednie przygotowanie wirtualnych katalogów dla roli CAS. Exchange od dawien dawna dla  każdej z usług webowych udostępnia nazwę zewnętrzną (exernal URL) i wewnętrzną (internal URL). Od Exchange 2013 ten dualizm dotyczy również usługi Outlook Anywhere – wcześniej można było zdefiniować tylko publiczną nazwę hosta dla tej usługi. Żeby było ciekawiej, nie wszystkie nazwy można skonfigurować przez Exchange Admin Center, co utrudnia proces. Dla jednego serwera musimy zdefiniować więc następujące URL-e:

• dwa dla usługi ActiveSync,
• dwa dla OWA,
• dwa dla ECP,
• dwa dla OAB,
• dwa dla EWS,
• dwa dla Outlook Anywhere,
• dwa dla Poweshell,
• dwa dla MAPI (jeżeli włączamy ten typ dostępu),
• jeden dla Autodiscover (jako atrybut serwera CAS)

Daje nam to 17 URL-i na jeden serwer (!), czyli całkiem sporo. A jeżeli w organizacji mamy kilka takich serwerów do skonfigurowania daje nam to odpowiednio więcej wpisów. Jakiś rok temu, żeby zaoszczędzić sobie pracy przygotowałem (a w zasadzie uaktualniłem) skrypt, który automatyzuje ten proces, jak widać na poniższym rysunku. W ostatni weekend znalazłem chwilę, żeby to trochę poprawić i dopasować do Exchange 2016. Zapraszam do korzystania i przekazywania sugestii na temat możliwych ulepszeń.

Aktualizacja dla Lync Room Systems

10 listopada Microsoft wydał istotną aktualizację dla urządzeń Lync Room Systems wszystkich producentów - Crestron, Polycom oraz SMART-a, który dostosowuje szatę graficzną do nowej wersji systemu – Skype for Business. Urządzenie SMART w DemoRoom Promise również się zaktualizowało i teraz przedstawia się jako Skype for Business:

Więcej informacji na blogu - https://blogs.office.com/2015/11/06/a-new-skype-for-business-look-for-lync-room-systems/

Integracja Exchange 2016 ze Skype for Business 2015

Jakiś czas temu pisałem na blogu o integracji Exchange 2013 z Lyncem 2013. Kwestie dotyczące wykorzystania unified store nie uległy zmianie, więc po weryfikacji URL usług webowych puli serwerów SfB oraz usługi autodiscover dla poczty, po stronie serwerów Exchange musimy wykonać skrypt Configure-EnterprisePartnerApplication.ps1. Podobnie jak w wersji 2013 znajduje się on w katalogu z innymi skryptami Exchange. Składnia parametrów również nie uległa zmianie – niezależnie od tego, czy będziemy łączyć się z Lync 2013 czy z Skype for Business 2015, to jako parametr połączenia podajemy “Lync”:

Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl “https://<EnterprisePoolFQDN>/metadata/json/1″ -ApplicationType Lync

Kolejnym etapem jest konfiguracja po stronie SfB – utworzenie aplikacji partnerskiej:

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.<domain>/autodiscover/metadata/json/1

Jeżeli nie zrobiliśmy literówki, to test integracji powinien zakończyć się sukcesem:

Test-CsExStorageConnectivity -SipUri “user@domain” –Verbose

Integracja w zakresie OWA w Exchange 2013 jest dosyć uciążliwa. Również już o tym pisałem wcześniej, więc tylko przypomnę, że kluczowym elementem konfiguracji była edycja pliku web.config, co niestety wymagało ponownej edycji pliku po każdej instalacji pakietu Cummulative Updates. W Exchange 2016 na szczęście mechanizm ten został poprawiony. Został do tego wykorzystany mechanizm nadpisywania ustawień domyślnych. W przypadku organizacji z jednym serwerem Exchange sytuacja jest prosta – sprawdzamy jaki certyfikat jest przypisany do usługi OWA

New-SettingOverride -Name <Nazwa> -Component OwaServer -Section IMSettings -Parameters @(“IMServerName=<Pool FQDN>”,”IMCertificateThumbprint=<Odcisk Certyfikatu>”) -Reason “OWA IM config”

Nazwa ustawienia może być dowolna. Następnie musimy odświeżyć ustawienia serwera:

Get-ExchangeDiagnosticInfo -Server $ENV:COMPUTERNAME -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

Na koniec pozostaje restart usługi webowej (nie musimy restartować całęgo IIS-a, wystarczy restart puli OWA:

Restart-WebAppPool MSExchangeOWAApppool

Jeżeli jednak mamy kilka serwerów Exchange, a na dodatek wykorzystują one indywidualnie wygenerowane certyfikaty (z innymi odciskami), to wtedy musimy zdefiniować oddzielne override’y dla każdego z serwerów, jak to opisuje Jens Trier Rasmussen na swoim blogu. Jeżeli mamy serwery o nazwach EX1 oraz EX2, to komendy będą wyglądały następująco:

New-SettingOverride SetIMServerEx1 -Server Ex1 -Component OwaServer -Section IMSettings -Parameters @('IMServerName=<Pool FQDN>') -Reason "OWA IM config"
New-SettingOverride SetIMCertificateThumbprint1 -Server Ex1 -Component OwaServer -Section IMSettings -Parameters @('IMCertificateThumbprint=<Odcisk Certyfikatu 1>') -Reason "OWA IM Config"
New-SettingOverride SetIMServerEx2 -Server Ex2 -Component OwaServer -Section IMSettings -Parameters @('IMServerName=<Pool FQDN>') -Reason "OWA IM config"
New-SettingOverride SetIMCertificateThumbprint2 -Server Ex2 -Component OwaServer -Section IMSettings -Parameters @('IMCertificateThumbprint=<Odcisk Certyfikatu 2>') -Reason "OWA IM config"

Następnie na każdym z serwerów EX1,EX2 należy wymusić odświeżenie konfiguracji (tak jak dla pojedynczego serwera komendą Get-ExchangeDiagnosticInfo), a następnie zrestartować pulę OWA.

Kolejnym krokiem jest wskazanie, że integracja ma być włączona (co ciekawe, tutaj używamy parametru jeszcze z czasów Office Communications Servera). Najwygodniej wykonać komendę korzystając z potokowania dla wszystkich witryn razem:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingEnabled $True -InstantMessagingType OCS

Dodatkowo powinniśmy taką samą operację przeprowadzić na poziomie polis OWA. Jeżeli nie tworzyliśmy własnych polis, wystarczy zmodyfikować polisę domyślną:

Set-OwaMailboxPolicy -Identity “Default” -InstantMessagingEnabled $True -InstantMessagingType “OCS”

W interface OWA powinna pojawić się teraz informacja o statusie SfB:

Jeżeli nadal nie możemy się zalogować do “usługi wiadomości błyskawicznych”, dodatkowo powinniśmy w konfiguracji Skype for Business wskazać serwery Exchange jako zaufaną pulę serwerów (wykorzystując nazwę dostępową dla usługi OWA):

New-CsTrustedApplicationPool -Identity <owa FQDN> -Registrar <Pool FQDN> -Site <Site name> -RequiresReplication $False

Następnie w nowoutworzonej puli dodajemy aplikację, wskazując dodatkowo port komunikacyjny. Oczywiście po stronie Exchange należy zweryfikować, czy port nie jest zablokowany przez ustawienia firewalla:

New-CsTrustedApplication -ApplicationId OutlookWebApp -TrustedApplicationPoolFqdn <owa FQDN> -Port 6100

Pozostaje odświeżenie ustawień:

Enable-CsTopology

Osobnym zagadnieniem jest integracja w zakresie Unified Messaging. Tutaj nie ma zmian w stosunku do Exchange 2013, więc może do tego zagadnienia  wrócę innym razem.

Wyłączanie chwilowe Direct Access na kliencie

Dawno nie pisałem, ale nadmiar pracy i testy nowych technologii, które miały status NDA trochę mi to utrudniały. Ale żeby nie zapomnieć chciałem dodać jedną informację o używaniu Direct Access. Jest to świetna technologia, człowiek cały czas podłączony jest do lokalnych zasobów firmowych, może używać krótkich nazw serwisów intranetowych niezależnie od tego, gdzie jest podpięty. Jednak czasem bywa to uciążliwe, zwłaszcza gdy chcemy sprawdzić poprawność publikowanych usług od strony Internetu. Do wyłączenia Direct Accessa niezbędne jest zatrzymanie dwóch usług systemowych – asystenta usług sieciowych i IP Helpera, co w normalnych warunkach wymaga odpalenia konsoli services.msc, znalezienia odpowiednich usług i ich zatrzymanie. Oczywiście odwrócenie konfiguracji wymaga włączenia tych usług lub restart komputera. Dużo szybciej jest przygotować sobie skrypt powershell, który możemy “prawokliknąć” i wybrać opcję “Run with powershell”. Cały problem polega na tym, że zatrzymanie usług wymaga odpalenia skryptu z wyższymi uprawnieniami (nieszczęsny UAC). Pomyślałem sobie, że najprościej włączyć eskalację uprawnień wewnątrz skryptu, co też uczyniłem, wykorzystując konstrukcję opisaną na blogu Bila Armstronga - http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/09/23/a-self-elevating-powershell-script.aspx:

#
# script to stop Direct Access on user computer
# if user has local administrator permission
#

# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
 
# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
 
# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
    {
    # We are running "as Administrator" - so change the title and background color to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"
    $Host.UI.RawUI.BackgroundColor = "DarkBlue"
    clear-host
    }
else
    {
    # We are not running "as Administrator" - so relaunch as administrator
   
    # Create a new process object that starts PowerShell
    $newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";
   
    # Specify the current script path and name as a parameter
    $newProcess.Arguments = $myInvocation.MyCommand.Definition;
   
    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";
   
    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);
   
    # Exit from the current, unelevated, process
    exit
    }
 
 
stop-service NCASvc
stop-service iphlpsvc

Na podobnej zasadzie można oczywiście realizować inne operacje cykliczne operacje, np. zmiany adresu IP.

Kolejne pakiety poprawek do Exchange

Kilka dni temu pojawiła się poprawka bezpieczeństwa do Exchange 2013 CU9, a od dzisiaj dostępny jest pakiet Cumulative Update 10 dla Exchange Server 2013, oczywiście raze z zaktualizowanymi pakieta UM Language Packs. Jak co kwartał równolegle pojawiła się paczka Exchange Server 2010 Service Pack 3 Update Rollup 11 (KB3078674). Tym razem aktualizacji dla Exchange 2007 już nie było. Dużymi krokmi zbliża się premiera Office 2016 i nowej wersji serwera Exchange 2016, do którego migracja z wersji 2007 nie jest już wspierana. Więcej informacji na blogu zespołu produktowego.

BToE – inne spojrzenie (Yealink)

Jak prezentował niedawno na spotkaniu PEPUG Marcin Wikieł, liczba telefonów współpracujących z Lyncem stopniowo rośnie. Tym razem miałem możliwość testowania telefonu YealinkT48G, który właśnie uzyskał status kwalifikowanego dla Lynca 2013 ze wsparciem dla Skype for Business, razem z modelem T22P. Oczywiście użycie telefonu Yealink w organizacji Lyncowej wymaga dedykowanego firmware (aktualna wersja 35.7.0.35). Niestety na stronie publicznej supportu nie jest on jeszcze dostępny, ale dzięki wsparciu dystrybutora Acnet, udało mi się go uzyskać. Wymagane jest również wgranie odpowiedniej licencji na telefon. Podobnie jak SNOM czy Audiocodes, telefony Yealink mają możliwość zarządzania przez stronę webową, gdzie w wygodny sposób można zaktualizować zarówno firmware jak i licencję, jak pokazuje poniższy rysunek. Co ciekawe, interface dostępny jest również po polsku.

Po zaktualizowaniu frmware telefonu do wersji Lync i odpowiedniej licencji (docelowo telefony Yealink mogą być dostarczane z odpowiednią licencją i oprogramowaniem), pojawia się możliwość zalogowania przy pomocy rozszerzenia numeru i PIN-u, tak jak na innych telefonach sprzętowych dla środowiska Lync 2013.

Po zalogowaniu pojawia się ekran ogólny, na którym jednak widać od razu w prawym górnym roku informacje o zalogowanym użytkowniku.

Po przejściu do ulubionych zobaczymy nasze lyncowe kontakty z grupy ulubionych, co pokazuje poniższy rysunek. Jeżeli kontakt ma dodane zdjęcie, to jest ono widoczne również na telefonie.

Kolejna zakładka pokazuje historię połączeń, zarówno odebranych jak i nieodebranych.

W zakładce kontaktów zobaczymy grupy kontaktów, w takim układzie jak ustawiliśmy sobie w Lyncu. Ciekawą opcją jest możliwość integracji z Lyncem/SfB na naszym komputerze – podobnie jak w przypadku wcześniej testowanych przeze mnie telefonów – Better Together over Ethernet. Po zainstalowaniu niewielkiego dodatku Yealink BToE Connector for Lync(aktualna wersja 2.0.13.0) i uruchomieniu aplikacji następuje proces parowania z telefonem. Najprościej podać adres IP telefonu i wcisnąć przycisk “Pair”.

Po chwili aplikacja schowa się w pasku zadań, pokazując status sparowania jak widać na poniższym rysunku.

Telefon pojawi się również jako domyślna słuchawka na liście urządzeń Lynca/SfB.

Testy przebiegły pomyślnie, telefon działa fajnie. Kolejna interesujaca alternatywa, zwłaszcza dla osób/firm, które lubią kolorowe wyświetlacze i możliwość wyświetlania więcej informacji o swoich kontaktach.

Skype for Business Preview

Update 15.04.2015

Wczoraj był “Patch tuesday” i wieczorem wyszła razem z poprawkami do Office 2013 finalna wersja Skype for Business 2015 jako aktualizacja Lynca. Niestety, pomimo tego, że domyślnie przy pierwszy uruchomieniu pojawia się Skype for Business, to potem dla serwera Lync 2013 przełącza na wygląd zgodny z Lync 2013. Jednak po zmianie klucza w rejestrze EnableSkypeUI (opisanego poniżej) z wartością 01 00 00 00, interface przełącza się na S4B. Dla osób, które usypiają komputer zamiast go wyłączać, na dwa tygodnie takie obejście powinno starczyć

W prezentacji na temat zmian wyglądu interface’u dokładnie opisano możliwości zmian i zależności od wersji serwerowej Lynca/S4B.

-----------------------------------------------------------------------------------------------------

Chociaż mogę testować nową wersję Lynca. czyli Skype for Business (SfB) już od kilku miesięcy, to dopiero od momentu ukazania się publicznej wersji Preview można o nim mówić i pisać. Pojawienie się publicznej wersji Preview umożliwiło również przystąpienie do testowania SfB na szerszą skalę. Interface jest zmieniony dosyć znacząco od strony wizualnej, jak widać na rysunku poniżej, ale jak na razie (z serwerem Lync 2013) funkcjonalność jest prawie taka sama.

Ciekawie listę zmian opisuje na swoim blogu Matt Landis, więc nie będę powtarzał szczegółów, warto może jednak posumować:

• Dostępna jest pełna lista emoticonów, dostępnych w Skype
• Okno “Call Control”, które pojawia się, kiedy S4B nie jest aktywnym programem:
• Call Quality Feedback after Lync media call
• Lokalizacja na ekranie okna alertu o nadchodzącej rozmowie może być dowolnie ustawiana.
• Call transfer jest łatwo dostępny i może być realizowany jednym kliknięciem (przy połączeniu z linii miejskiej, z numeru niepowiązanego z kontaktami SfB). Przy połączeniu od kontaktu, dodatkowo trzeba kliknąć w przycisk “Call Control”

Dobrze jest zainstalować lutowy pakiet poprawek do serwera Lync 2013, który poprawia współpracę, a ponadto pozwala wymusić użycie starego interface’u, co na pewno może być istotne dla osób, które nie lubią zbyt gwałtownych zmian.

Po zainstalowaniu pakietu. w polisie użytkownika pojawi się dodatkowa opcja – “EnableSkypeUI”, z domyślną wartością $null, jak widać na poniższym rysunku. Oczywiście możemy ustawić wartość $true, co nic nie zmieni – nadal klient Skybe for Business będzie prezentował się jak powyżej - obie wartości domyślne pozwalają na pokazanie nowego interface’u SfB.

Jednak możemy tą wartośc ustawić na $false, co będzie skutkowało wyświetleniem klienta w postaci identycznej jak w Lync 2013. Zmiana będzie widoczna po zaktualizowaniu polisy na kliencie i restarcie maszyny.

Możemy również zmodyfikować wszystkie polisy klienckie:

Get-CsClientPolicy | Set-CsClientPolicy -EnableSkypeUI $false

Zmianę tę możemy również wymusić na kliencie poprzez modyfikację klucza rejestru, tworząc klucz HKEY_CURRENT_USER\Software\Microsoft\Office\Lync\EnableSkypeUI

Co ciekawe, klucz jest typu binarnego, a nie REG_DWORD, co nieco utrudnia konfigurację - EnableSkypeUI może być ustawione na wartość 01 00 00 00 (True) lub 00 00 00 00 (False).

Zachęcam do testowania, wersja finalna ma być dostępna jeszcze przez wakacjami.

Kemp Load Master za darmo?

Od kiedy Microsoft wycofał się ze sprzedaży Forefront TMG i UAG, zainteresowałem się rozwiązaniami alternatywnymi, głównie Load Balancerami Kemp Technologies, które potrafią publikować serwery Exchange, Lync i innych usług. O ich funkcjonalności pisałem wielokrotnie na blogu, wdrażając je również w wielu firmach. Od kilku dni Kemp dodatkowo wprowadził nową możliwość dla klientów, którzy potrzebują przez dłuższy czas sprawdzić funkcjonalność Load Balancerów lub w małej firmie użyć ich produkcyjnie – bezpłatną wersję bez ograniczeń czasowych. Jeżeli wydajność będzie niewystarczająca można bardzo prosto zaktualizować licencję do wersji komercyjnej. Poniżej porównanie funkcjonalne:

Feature	Free LoadMaster	Commercial LoadMaster
Deployment on all supported hypervisors(VMware, Hyper-V, KVM, Xen, Oracle VirtualBox)	Yes	Yes
Balancer Throughput License (L7)	Up to 20Mbps	Up to 10Gbps
TLS (SSL) TPS License (2K Keys)	Up to 50	Up to 12,000
Layer 4 concurrent connections	Limited only by throughput license and available memory	Up to 3,000,000
Max Servers / Virtual Clusters	1000/256	1000/1000
TMG Replacement	Yes	Yes
GSLB Multi-Site Load Balancing	Yes	Yes
Support	Community	Up to 24 x 7 available
Layer 4/7 Load Balancing	Yes	Yes
Web Application Firewall Pack (AFP)	Yes	Yes – option to include commercial ruleset
Content Switching	Yes	Yes
Caching, Compression Engine	Yes	Yes
IPS (SNORT-Rules compatible)	Yes	Yes
L7 Cookie Persistence (Active/Passive)	Yes	Yes
Optimized templates for all major application workloads	Yes	Yes
Active/Hot-standby Redundant Operation	No	Yes
Edge Security Pack(TMG Replacement)- Pre-Authentication- Single Sign On- Persistent Logging	Yes	Yes
IPSec Tunnels	Yes	Yes
Licensing Mechanism	Online (Call home every 30 days to refresh)	Online and Offline

Wersja bezpłatna co 30 dni automatycznie aktualizuje licencję. Wystarczy tylko pobrać obraz maszyny wirtualnej, założyć sobie konto na stronie Kempa (KempID) i aktywować licencję online.

Kolejny ciekawy przypadek scripting agenta

Niedawno pisałem o wykorzystaniu extension agenta w Exchange 2013. Kolejny ciekawy przykład wykorzystania rozszerzenia scripting agenta można znaleźć na blogu PFE. Jeżeli chcemy monitorować zmiany uprawnień na skrzynkach bardzo ważnych osób w naszej firmie, wystarczy do pliku ScriptingAgentConfig.xml (tworzenie pliku opisałem we wspomnianym wcześniej poście) dodać sekcję, dodającą akcję dla cmdleta Add-MailboxPermission:

<Feature Name="EventWrite" Cmdlets="Add-MailboxPermission">

<ApiCall Name="OnComplete">

$GrantedPermissionUser = $provisioningHandler.UserSpecifiedParameters["User"]

$identity = Get-Mailbox $provisioningHandler.UserSpecifiedParameters["Identity"]

$Alias = (Get-Mailbox "$identity").alias

$AccessRights = $provisioningHandler.UserSpecifiedParameters["AccessRights"]

if ($AccessRights -eq "FullAccess")

{

if ( @("CEO_Alias","CFO_Alias","COO_Alias") -like $alias)

{

write-eventlog -logname Application -source MailboxAudit -eventID 100 -entrytype Error -message "$GrantedPermissionUser was given Full Mailbox Access to $identity's Mailbox."

}

}

</ApiCall>

</Feature>

W ten sposób dla aliasów zdefiniowanych w tablicy @("CEO_Alias","CFO_Alias","COO_Alias"), akcja poprawnie zakończonego dodania uprawnień zostanie zakończona wygenerowaniem zdarzenia w application logu o wskazanym przez nas eventId i komunikacie. Oczywiście możemy dodać inną akcję – np. wysłanie maila do oficera bezpieczeństwa.

Office 365 Summit Amsterdam

Właśnie trwa drugi i ostatni dzień Summitu poświęconego nowościom w Office 365. Zarówno nowym funkcjonalnościom Exchange, narzędziom programistycznym jak i Skype for Business, czyli nadchodzącej nowej wersji Lynca.

Ponieważ w Europie jest tylko jeden taki event, więc ludzi zjechało się całkiem sporo (jak widać na poniższym zdjęciu z Key Notes).

Mnie najbardziej zainteresowała ścieżka Skype for Business – architektura, ścieżki migracji i inne technikalia. Niestety, nie można było popracować na nowej wersji serwera, ale mam nadzieję, że już niedługo uzyskam taką możliwość. Na pewno sesje z tej tematyki pojawią się na spotkaniach PEPUG – wprowadzenie do SfB będzie prezentował Piotr Pawlik już w najbliższy czwartek. Ja też postaram się zebrać trochę przemyśleń na temat informacji zebranych na Summicie i opublikować kilka kolejnych postów.

BToE raz jeszcze

Latem zeszłego roku napisałem post o funkcjonalności Better Together Over Ethernet w telefonach Audiocodes serii 400 (czyli sterowaniem z desktopowego klienta Lynca sprzętowym telefonem lyncowym). Od tego czasu zarówno klient Windows jak firmware telefonów został kilkukrotnie zaktualizowany i pracuje dużo lepiej i stabilniej. Aktualna wersja aplikacji desktopowej ma numerek 1.0.3, a wersja firmware dla wszystkich modeli linii 400, która wspiera BToE – 2.0.9.65.

Jednak nie tylko Audiocodes nie próżnowało. Finalną wersję analogicznego oprogramowania udostępnił klientom również SNOM. Miałem o nim napisać na jesieni, jednak duża ilość projektów, które wtedy realizowałem nieco przesunęła termin publikacji. Z drugiej strony, podobnie jak w przypadku Audiocodesa od tego czasu producent wprowadził szereg poprawek i usprawnień podnosząc jakość produktu. Aktualna wersja oprogramowania SNOM składa się z klienta desktopowego (wersja 1.1.19 – dostępna wersja 32 bity oraz 64 bity) oraz nowej generacji firmware – aktualna wersja to 8.8.3.27 (tylko dla linii 700). Co ciekawe, najprostszy model certyfikowany dla Lynca (710) nie wspiera BToE, zamiast tego wprowadzono model 715, który obsługuje tę funkcjonalność. Jednak formalnie proces certyfikacji jeszcze nie został zakończony, więc nie widać go na liście telefonów oficjalnie kwalifikowanych dla Lynca.

Jak to działa? Koncepcja połączenia telefonu z komputerem jest nieco inna niż w przypadku telefonów Audiocodes, jednak w większości przypadków konfiguracja jest stosunkowo prosta i intuicyjna. Pierwszym krokiem jest zaktualizowanie oprogramowania na telefonie - można to zrealizować poprzez pulę Lyncową – SNOM udostępnia firmware dla swoich telefonów w postaci dystrybuowanej przez usługę Device Update Lynca. Po aktualizacji firmware w menu telefonu pojawi się dodatkowa pozycja – 7 - UC Menu.

Po wejściu w menu widać opcje specyficzne dla współpracy ze środowiskiem Lync, a w tym wypadku najważniejsza jest opcja 1 – Better Together.

Teraz można przejść do opcji parowania – możemy podać albo pełną nazwę komputera (FQDN) albo adres IP naszego komputera (opcja 3 lub 2).

Teraz możemy sprawdzić ustawienia (opcja 4 – Information).

Telefon pokazuje status niesparowany (niestety całe menu nie zostało przetłumaczone), zapisany adres IP oraz domyślny port komunikacyjny (w przypadku firewalla na stacji roboczej powinniśmy utworzyć regułę dla portu 7005).

Po zainstalowaniu klienta desktopowego i jego uruchomieniu pozostaje nam wybranie z menu Better Together na telefonie opcji 1 - Pair Now. Po chwili zestawiania połączenia, aplikacja kliencka (niebieski znaczek na pasku statusu Windows) pokaże status połączenia z konkretnym telefonem, który po restarcie komputera powinien zostać automatycznie nawiązany.

Jedyną drobną niedogodnością jest fakt, że przy pierwszym połączeniu w Lyncu pojawi się dodatkowe okno logowania (Lync automatycznie wykryje telefon dzięki specjalnemu sterownikowi USB). Teraz uzyskamy funkcjonalność zestawiania z telefonu połączeń wybieranych z Lynca na desktopie. Oczywiście możemy znaleźć kontakt poprzez Address Book Service z menu telefonu albo przypisać go na stałe do jednego z przycisków szybkiego wybierania (wtedy dodatkowo będzie nam się wyświetlał status kontaktu – wolny/zajęty/nieaktywny, co zresztą widać na powyższych zdjęciach), jednak dla wielu osób dużo szybsze i wygodniejsze jest użycie do tego Lynca/Outlooka i skorzystanie z integracji BToE.

Polycom dostarcza analogiczne rozwiązanie dla telefonów z linii VVX, jednak nie do końca udało mi się udokumentować testy i nie chciałbym być tendencyjny, twierdząc, że problemy z nimi związane leżą po stronie sprzętu.

Nietypowy certyfikat dla puli Lyncowej

Niedawno miałem ciekawy problem (LS Protocol Stack event 14501 i 14428), dotyczący koegzystencji serwerów Lync z infrastrukturą Cisco CUCM/VCS. Pomimo faktu wygenerowania certyfikatów przez ten sam wewnętrzny urząd połączenia TLS pomiędzy serwerami zgłaszały błędy. Znalazłem w sieci podobny przypadek, jednak przygotowanie certyfikatu dla takiego scenariusza (domyślnie certyfikat serwera Lync jest konfigurowany tylko dla certyfikacji serwerowej (OID 1.3.6.1.5.5.7.3.1), a w tym wypadku jest wymagana dodatkowo certyfikacja kliencka (OID 1.3.6.1.5.5.7.3.2). Jak to zrobić najprościej? Domyślne metody nie pozwalają na taką operację – ani kreator certyfikatów z Lync Deployment Wizarda ani tym bardziej zawarty w IIS, formatka webowa urzędu certyfikacyjnego również nie pozwala na utworzenie takiego certyfikatu. Jednak narzędzia linii komend certreq/certutil mają bogate możlwości, które nam to ułatwią. W tym celu musimy sobie przygotować plik inf, zgodnie z artykułem “How to request a certificate with a Custom SAN”. Pik powinien zawierać wpisy jak poniżej:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=lync.pepug.org"  
Exportable = TRUE                   ; Private key is exportable
KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1                         ; AT_KEYEXCHANGE
KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment
MachineKeySet = True                ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ;Server Authentication
OID=1.3.6.1.5.5.7.3.2 ;Client Authentication

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=lync.pepug.org&"
_continue_ = "dns=fe1.lab.pepug.org&"
_continue_ = "dns=fe2.lab.pepug.org&"
_continue_ = "dns=lsweb.pepug.org&"
_continue_ = "dns=lyncdiscover.pepug.org&"
_continue_ = "dns=lyncdiscoverinternal.pepug.org&"
_continue_ = "dns=dialin.pepug.org&"
_continue_ = "dns=meet.pepug.org&"
_continue_ = "dns=sip.pepug.org"

[RequestAttributes]
CertificateTemplate = WebServer1

Dwa słowa komentarza – w sekcji EnhancedKeyUsageExtension wskazujemy, że ma być obsługiwana zarówno opcja Server jak i client Authentication. Ponieważ chcemy certyfikat zainstalować na kilku serwerach w puli, więc wybieramy opcję zezwolenia na eksport klucza prywatnego. W sekcji RequestAttributes wskazujemy wykorzystywany w naszej firmie szablon tworzenia certyfikatu, jednak najciekawszy zapis zawiera sekcja Extensions – ponieważ certyfikat serwera Lync musi zawierać zarówno nazwy hostów jak i szereg innych nazw wykorzystywanych przez Lynca, więc wykorzystujemy specyficzny zapis z użyciem konkretnego identyfikatora dla certyfikatów SAN (zapis działa począwszy od Windows 2008).

Wygląda to trochę nietypowo, ale działa. Teraz tylko pozostaje utworzenie certyfikatu z użyciem narzędzia certreq:

Na jednym z serwerów wykonujemy komendę:

certreq –new certLync.inf certLync.req

Następnie po skopiowaniu pliku (ewentualnie zdalnie, jeżeli jest taka możliwość) na serwer z urzędem certyfikacji generujemy certyfikat:

certreq –submit certLync.req certLync.cer

Teraz pozostaje tylko zainstalowanie certyfikatu:

certreq -accept certLync.cer

i przypisanie go do usług serwera FrontEndowego (no i po wyeksportowaniu do pfx-a instalacja na drugim serwerze w puli).

Po restarcie usług komunikacja pomiędzy systemami zaczyna działać poprawnie.

Cmdlet Extension Agent dla Exchange 2013 – modyfikacja ustawień skrzynki pocztowej

Jedną z ciekawych i ciągle mało znanych funkcjonalności w Exchange 2013 (chociaż pojawiła się już w Exchange 2010) jest możliwość wykorzystania agenta skryptowego do realizowania dodatkowych akcji po wykonaniu standardowego cmdleta Exchange. Przykładem może być operacja tworzenia skrzynki Exchange – enable-mailbox lub new-mailbox nie posiadają opcji pozwalających np. na ustawienie domyślnego języka i strefy czasowej. Przypomniał o tym ostatnio Tony Redmond na swoim blogu. Podobnie w przypadku włączenia funkcjonalności SingleItemRecovery lub audytowania musimy wykonać dodatkowe operacje. Automatyzację konfiguracji tych parametrów umożliwia nam dodatek Cmdlet Extension Agents, a tak naprawdę to jeden z 8 agentów – Scripting Agent:

Jak możemy go użyć?

W katalogu instalacyjnym Exchange, w podkatalogu Bin\CmdletExtensionAgent znajdują się niezbędne rozszerzenia oraz przykład pliku konfiguracyjnego jak widać na poniższym rysunku:

Tworząc plik konfiguracyjny (obowiązkowa nazwa ScriptingAgentConfig.xml)definiujemy w nim, dla jakich komend wykonywane są dodatkowe operacje i jakie są warunki początkowe. W przypadku uzupełnienia operacji tworzenia skrzynki w pliku xml dodajemy sekcję dla odpowiednich komend i uzależniamy wykonanie sekwencji dodatkowych czynności od poprawności wykonania komendy podstawowej (weryfikując rezultat zwrócony przez metodę “OnComplete”). Oczywiście możemy dodać więcej operacji. Poniższy plik opisuje operację ustawienia polskiej wersji językowej, godziny rozpoczęcia pracy w firmie, polskiej strefy czasowej. Włączone zostaje również SingleItemRecovery oraz audytowanie operacji na skrzynce (tylko administrator i delegaci, żeby włączyć audytowanie dla właściciela należy dodatkowo zdefiniować, jakie operacje są rejestrowane).

<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">
    <Feature Name="Mailboxes" Cmdlets="New-Mailbox, Enable-Mailbox">
        <ApiCall Name="OnComplete">
        if($succeeded) {
            $Name= $ProvisioningHandler.UserSpecifiedParameters["Name"]
            Set-Mailbox $Name -Languages "pl-PL"
            Set-MailboxRegionalConfiguration $Name -DateFormat "yyyy-MM-dd" -TimeZone "Central European Standard Time"
            Set-MailboxCalendarConfiguration $Name -WorkingHoursStartTime "09:00:00"
            Set-Mailbox $Name -SingleItemRecoveryEnabled $true
            Set-Mailbox $Name -AuditEnabled $true
        }
        </ApiCall>
    </Feature>
</Configuration>

Plik musi znajdować się na wszystkich serwerach z rolą Mailbox. W ten sposób, jeżeli nie popełniliśmy błędu dla każdej nowo tworzonej skrzynki, zostaną ustawione parametry pokazane powyżej, niezależnie czy będzie ona tworzona z poziomu Exchange Management Shella czy konsoli webowej.

Oczywiście musimy najpierw włączyć agenta komendą:

Enable-CmdletExtensionAgent “Scripting Agent”

Zmiany w certyfikatach publicznych

Kiedy Microsoft ogłosił w drugiej połowie zeszłego roku koniec wsparcia dla certyfikatów wykorzystujących SHA-1 z dniem 1.01.2017, wydawało się to terminem odległym. Jednak Google już od listopada 2014 zaktualizował przeglądarkę Chrome, tak żeby wyświetlała ostrzeżenia dla certyfikatów z SHA-1, wygasających w 2017 roku i stopniowo takie obostrzenia będą się powiększać. Co zatem należy zrobić? Przejść na certyfikaty wykorzystujące SHA-2 (przeważnie jest to SHA-256). Na pozór nic prostszego. Jednak odnowienie certyfikatów do Exchange u kilku klientów w ostatnich dniach pokazało mi, że dostawcy już taką zmianę realizują – nowe certyfikaty, m. in GoDaddy czy też RapidSSL przychodzą ze zmodyfikowaną wersją algorytmów. Co ciekawe, w przypadku zaleceń dla serwerów Exchange zarówno kreator jak i cmdlet generujący nowy wniosek o certyfikat używają domyślnie (i nie ma możliwości tego zmienić) SHA-1. Mam nadzieję, że zespół Exchange wkrótce się obudzi i zostanie to poprawione w kolejnych wersjach (w tym kwartale powinien być dostępny kolejny Cummulative Update). Jak na razie rozwiązanie jest proste, chociaż nie tak oczywiste.

Mając stary certyfikat podpisany SHA-1, dostajemy po wniesieniu opłaty nowy certyfikat wygenerowany przez dostawcę, zgodnie z danymi firmy. Jednak jego standardowy import na serwer z poziomu narzędzi Exchange lub konsoli IIS nie podłącza go do klucza prywatnego.

Stosujemy zatem obejście opisane w artykule bazie wiedzy Microsoft KB889651 lub na serwisach dostawców certyfikatów.

Czyli po sprawdzeniu numeru seryjnego certyfikatu wykonujemy komendę:

certutil –repairstore my <serial number>

Certyfikat został podpięty do klucza prywatnego, teraz możemy podłączyć usługi Exchange, Lynca czy dowolne inne.

Co nam przyniesie rok 2015?

Jakoś tak jest, że na przełomie roku wypada zrobić krótkie podsumowanie. Rok 2014 minął nie wiadomo kiedy, w nawale pracy nawet nie bardzo miałem czas w ostatnich dwóch miesiącach publikować jakieś artykuły – kilka z nich czeka na dokończenie i publikację – mam nadzieję, że nadrobię to przy okazji urlopu. Na bieżąco starałem się publikować krótkie wpisy na Twitterze, co zaowocowało wzrostem ilości tzw. Followerów (do 350). Mimo wszystko jednak wydaje mi się, że był to rok udany, patrząc na statystyki odwiedzin bloga, wyglądało to całkiem interesująco, ze średnią miesięczną ponad 2000 odwiedzin:

Co nam przyniesie rok 2015? Zmiany na pewno będą duże – Windows 10 powoli zaczyna nabierać kształtów, w tym roku również pojawi się nowa rodzina produktów Office. Na razie informacje są NDA, ale jak tylko można będzie udostępnić informacje na temat Office 16, Skype for Bussiness lub Exchange 16 (do których wersji Beta mam dostęp) na pewno się nimi podzielę. Podobnie jak doświadczeniami z kolejnych ciekawych projektów.