Wymuszenie webowego udziału w konferencjach Lyncowych

Jednym z problemów, z jakim możemy się spotkać organizując lub biorąc udział w konferencjach webowych na platformie Lync Server 2013, jest wymuszanie połączenia przez Lynca, którego mamy zainstalowanego w systemie. Niby drobiazg, ale jeżeli ktoś zainstalował sobie Office 2013 Pro Plus na domyślnych ustawieniach, albo co gorsza zrobił to za niego ktoś z wyższymi uprawnieniami, a nie ma skonfigurowanego konta na serwerze Lyncowym lub nie jest on wdrożony w naszej firmie, to kiedy klikniemy w link z zaproszeniem na spotkanie, zostanie automatycznie otwarty Lync, próbując podłączyć nas do konferencji. Niestety Lync 2013 nie posiada opcji pracy anonimowej, więc bez zalogowania się do serwera Lync, połączenie nie zostanie nawiązane, nie zostawiając nam ścieżki alternatywnej

Sam w ostatnich dniach znalazłem się w podobnej sytuacji – po “zwisie” komputera i twardym restarcie uszkodzony został folder magazynu certyfikatów osobistych. Przez kilka dni próbowałem znaleźć rozwiązanie, ale problem był nieoczywisty, nie pokazujący sensownych błędów w logach i skutkował wyłącznie problemem z uruchomieniem Lynca 2013 (zarówno wersji pełnej jak i Basic). Dopiero serwis Microsoft i PFE, do którego zwróciłem się z prośbą o pomoc, znalazł źródło problemu.

Przy okazji pokazał mi ciekawy trick, o którym nie wiedziałem – jeżeli chcemy podłączyć się do konferencji Lync Server klientem webowym, zamiast zainstalowaną w systemie pełną wersją Lynca, wystarczy dodać do odnośnika, który dostaliśmy w mailu z zaproszeniem na spotkanie frazę ?sl=1 ->

Czyli np. zamiast https://meet.lync.com/pepug365/ziembor/0M9J2OL1 łączymy się z adresem https://meet.lync.com/pepug365/ziembor/0M9J2OL1?sl=1.

Zamiast próbować otworzyć połączenie do konferencji w Lyncu, od razu otworzy się połączenie do strony webowej konferencji, na której możemy się zalogować, używając naszego konta, ale możemy również połączyć się po prostu podając identyfikator, którego system nie będzie weryfikować:

Trick działa zarówno w konferencjach organizowanych z użyciem Office365 (rysunek powyżej) jak w wersji on-premises (poniżej). W tym drugim wypadku nadal możemy kliknąc w link pozwalający nawiązaniu połączenia z użyciem desktopowego Lynca.

Niby drobiazg a przydatny.

Publiczne certyfikaty dla Lync Servera

Dawno nie zaglądałem do artykułu http://support.microsoft.com/kb/929395/en-us, który wymienia urzędy certyfikacyjne, które są zalecane dla usług Unified Communications. Przez bardzo długi czas były na liście dostępne tylko 3 certyfikaty (z chwilowym pobytem urzędu GoDaddy), ale jak widać w aktualizacji dokumentu z września 2013, urzędów jest teraz aż osiem. Warto o tym pamiętać, zwłaszcza pod kątem problemów z konfiguracją wymaganego do publikacji prezentacji powerpointowych certyfikatu dla serwera Office Web App Server (nie działa poprawnie z certyfikatem wiildcardowym), więc optymalne jest użycie na serwerze WAS certyfikatu z urzędu wewnętrznego, schowanie serwera WAS za Reverse Proxy (np. sprzętowym Load Balancerem) i tam opublikowanie certyfikatu zawierającego wszystkie nazwy, zalecane przez Microsoft w dokumentacji - Request and Configure a Certificate for Your Reverse HTTP Proxy.

Zalecane przez Microsoft dla serwerów Lync urzędy certyfikacyjne :

• Entrust http://www.entrust.net/microsoft/ 
• Comodo http://www.comodo.com/msexchange 
• DigiCert http://www.digicert.com/unified-communications-ssl-tls.htm 
• GlobalSign http://www.globalsign.com/ssl/buy-ssl-certificates/unified-communications-ssl/ 
• WISeKey http://www.wisekey.com/en/Products/digital-identities/Pages/ssl-solutions.aspx 
• GeoTrust http://www.geotrust.com/ssl/ssl-certificates-san-uc/ 
• Thawte http://www.thawte.com/ssl/san-uc-ssl-certificates/index.html 
• Symantec (czyli VeriSign)
  https://www.symantec.com/theme.jsp?themeid=san-ssl-certificates

Exchange 2013 SP1 – drobna poprawka dla agentów transportowych

Nawet najdłużej testowany pakiet nie jest w stanie w 100% ustrzec się błedów. Tak samo jest z pakietem SP1 do Exchange 2013. W trakcie wykonaywanych ostatnich szlifów do pakietu, omyłkowo źle sformatowano wiersz komentarza w dwóch plikach konfiguracyjnych, co powoduje blokowanie niestandardowych agentów transportowych – zarówno tych przeznaczonych do skanowania maili pod kątem ochrony jak i wykonujących inne zadania. Na szczęście koledzy ze wsparcia technicznego CodeTwo szybko opisali problem na swoim blogu technicznym, a dzisiaj również Microsoft wydał poprawkę, która usuwa problem - Third-party transport agents cannot be loaded correctly in Exchange Server 2013.

Dla firm, które używają dedykowanych produktów antywirusowych, instalowanych na Exchange albo produktów typu CodeTwo Exchange Rules PRo, może być to uciążliwe (przed wykonaniem zmiany należy agenta ondinstalować, a na koniec ponownie zainstalować), ale niestety. Jak mówią niektórzy “Taki mamy klimat”.

Exchange 2013 Service Pack 1

W zeszłym tygodniu opublikowano Service Pack 1 do Exchange 2013 (zgodnie z planem aktualizacji określany również symbolem CU4). Był on długo i drobiazgowo testowany przez użytkowników programu TAP I MVP (cięzko mi policzyć ile razy aktualizowałem kolejne wersje beta w labie). Wyczerpujący artykuł na temat wprowadzonych zmian znalazł się na blogu zespołu produktowego, ja jednak mimo wszystko chciałem pokazać kilka opcji, które wg. mnie są interesujące.

Jedną z najciekawszych wprowadzonych zmian jest na pewno danie administratorom możliwości podglądu, jakie polecenia PowerShell są wykonywane przez serwer, w trakcie zarządzania poprzez interface webowy (Exchange Admin Center). Po kliknięciu w menu pomocy w pozycję “Show command logging” (w polskiej wersji interface “Pokaż rejestrowanie poleceń”), jak widać na poniższym rysunku:

Po kliknięciu w tą pozycję, otwiera się osobne okno, w którym pokazywane są kolejne cmdlety, odpowiadające opcjom, które wybieramy w konsoli administracyjnej:

Opcja ta przyda się mniej doświadczonym administratorom do zapoznania się z bogatym zestawem komend Exchange, a czasem również tym bardziej doświadczonym, bo czasami działanie kreatorów pozostawia sporo wątpliwości, co tak naprawdę w systemie się dzieje.

Kolejnym ważnym aspektem jest wprowadzenie nowego protokołu komunikacyjnego MAPI-HTTP. Z punktu widzenia otwieranych portów nic to nie zmienia (również wykorzystywany jest port TCP 443), jednak upraszcza to komunikację pomiędzy klientem i serwerem oraz ułatwia ewentualny troubleshooting. Bardzo ciekawie różnice pomiędzy RPC over HTTP oraz MAPI over HTTP opisał na blogu polskich PFE Krzysiek Kubicki.

Wprowadzenie roli Edge w zasadzie nic nowego nie wniosło (poza możliwością wykorzystania tego samego pakietu instalacyjnego dla wszystkich ról serwerowych Exchange), na pewno pozytywną cechą SP1 jest za to wsparcie dla systemu Windows 2012 R2.

Mi jednak najwięcej satysfakcji dało uwzględnienie mojej pracy i sugestii dotyczących uzupełnienia informacji wykorzystywanych przy tworzeniu polis DLP o pięć dodatkowych typów klasyfikacji danych – z czego trzy związane z Polską (wszystkie trzy zgłoszone do Microsoftu, opisane i udokumentowane przeze mnie). Powinno to pozwolić polskim firmom lepiej wykorzystać możliwości, jakie daje ta funkcjonalność Exchange 2013 – więcej informacji o zmianach, dotyczących DLP w Servie Packu 1 znajdziecie w artykule na blogu zespołu produktowego.

Instalując Service Pack 1 nie zapominajmy o pakiecie językowym dla funkcji głosowych (niestety, jeżeli był zainstalowany wcześniej, starsza wersja musi zostać odinstalowana przed instalacją SP1, a dopiero na końcu instalujemy nową wersję polskiego pakietu językowego Exchange 2013 SP1 UM Language Pack.