Postanowiłem napisać słów kilka o integracji systemu Microsoft Lync Server 2010 z rozwiązaniem Avaya. Pewnie większość zapyta się po co? Jest kilka powód za, między innymi klient który obecnie używa rozwiązań głosowych Avaya, chciałby dorzucić IM’a (Instant Messaging) i dzwonienie z Lync 2010 za pośrednictwem Avaya.
Tutaj znowu nasuwa się pytanie, po co dzwonić z Avaya, a nie z Lync Server bezpośrednio? Odpowiedź jest prosta, bo klient kupił usługi SIP trunkingu lub H.323 trunkingu od ISP, które są już terminowane na systemie Avaya lub po prostu chce mieć dwa systemy działające (może tylko w niektórych oddziałach firmy).
Cała integracja opiera się o scenariusz RCC (kontrolowanie systemu zdalnego przez użytkownika AD), gdzie użytkownik posiadający komunikator może się z niego wydzwaniać/odbierać (hold/unhold, transfer, itd.) połączenia za pośrednictwem systemu Avaya, czyli mówiąc prosto przełączyć się również na słuchawkę hardwarową awajki. Integracja pomiędzy klientem Lync 2010 i Avaya Communication Manager odbywa się za pośrednictwem TR/87 over SIP. Pomiędzy Lync Server 2010 a Avaya ACM w komunikacji pośredniczy serwer Avaya AES, który jest pewnego rodzaju API i interfejsem komunikacyjnym – CSTA over SIP do Lync, a CTI do Avaya ACM. Oczywiście na samym AES musimy mieć zainstalowane certy z CA w naszej domenie AD. Cała procedura konfiguracji jest mocno skomplikowana i źle udokumentowana w przewodnikach stworzonych wspólnie przez Avaya i Microsoft.
Co zyskamy w tej integracji? Siłę komunikatora Lync + konferencje + presence + dostęp do Exchange VoiceMail połączoną z systemem typu Enterprise Telephony Network od Avaya.
Co jest potrzebne w labie do zestawienia tej integracji?
Avaya Core Releases
· Avaya Session Manager 6.1 SP5
· Avaya Aura System Platform 6.0.3 + patch 6.0.3.3.3
· Avaya Aura Communication Manager 6.0.1 SP 5.01
Avaya Unified Communication Releases
· Avaya Aura Application Enablement Services 6.1.1 (r6-1-1-30-0)
Microsoft Unified Communication Releases
· Podstawowe role Windows Server 2008 R2 z ostatnimi poprawkami: ADDS+DNS (forest and domain level set to Windows Server 2008 R2), ADCS (Certificate Authority).
· Lync Server 2010 and Lync 2010 (client) with latest hotfix (wymagane KB2493736).
· Exchange Server 2010 with Update Rollup 6 (lub późniejszy) for Exchange Server 2010 Service Pack 1 (KB2608646).
Architektura rozwiązania:
Po co nam ten serwer Avaya AES?
Odpowiada on za konwersję planu numeracyjnego, żeby numery krótkie które są z reguły wykorzystywane w systemie Avaya były odpowiednio przetłumaczone na numery w formacie E.164 rozumianym przez Avaya – konfiguruje się to w sekcji („Dial Plan Settings – Conversion Rules for Default” and „Dial
Plan Settings – Conversion Rules – switchname) w AE Services Management Console. Mamy dwie opcje From TelURI i To TelUri.
From TelURI: konwertowanie z normalized TelURI number do extension lub dial string, które jest przechwytywane przez system Avaya (Communication Manager).
To TelURI: konwertowanie z extension lub dial string do normalized TelURI, które jest przechwytywane przez Microsoft Lync 2010.
Licencjonowanie na AES: W celu włączenia wymaganego TR/87 na serwerze AE Server są potrzebne licencje typu Unified CC API Desktop Edition licenses. To jest licencjonowanie per-user, czyli każdy aktywny klient Microsoft Office Communicator lub Lync 2010 konsumuje 1 licencję Unified Desktop license.
Trzeba włączyć TR/87 na serwerze AES (standardowo jest wyłączone): AES używa portu 4723 do komunikacji pomiędzy Microsoft Lync Server 2010 a AE Services. Włączamy to z poziomu OAM — Networking -> Ports page and Apply changes.
Po stronie AES musimy dodać jeszcze Communication Managera, czyli Switch Connection oraz TSAPI link, co zostało dokładnie opisane w tym przewodniku (http://support.avaya.com/css/P8/documents/100127029).
Pozostało nam jeszcze dokonfigurowanie dial planu i zasad konwersji o których pisałem powyżej. W moim przypadku ACM używa numerów 7 cyfrowych: 666+XXXX, więc musimy w jedną stronę uzupełniać do 11 cyfr formatu E.164, a w druga usuwać – zrobimy nam to jedna reguła po stronie AES’a:
Nie będę opisywał procedury dodawania linka z Avaya ACM do AES, bo jest to opisane tutaj (http://support.avaya.com/css/P8/documents/100127029).
Teraz najciekawsza część, czyli LYNC – let’s Lync!
I tu jest największa kupa – jeśli źle wygenerujemy cert to będzie źle. Na początek instalacja zaufanego certu na Lync Server. Procedurę opisano nie szczegółowo w dokumecie http://support.avaya.com/css/P8/documents/100127013. Podczas instalacji zaufanego certyfikatu, należy pamiętać, że Microsoft Lync Server i AE Serices musi użyć tego samego urzędu certyfikacji lub wystawcy w tym samym łańcuchu certyfikatów.
Przechodzimy do Windows 2008 CA Server Console, uruchamiamy CA MMC snap-in. Right click na Certificate Templates i wybieramy Manage.
Prawy klik na RAS and IAS Server, i wybieramy duplicate template.
RAS and IAS template został wybrany, ponieważ zawierea Client and Server Authentication Application Policies wymagane przez Avaya AE Services.
Na zakładce General tab, należy podać unikalną nazwę dla templatu, przykładowo“AES”.
Na zakładce Request Handling, pole Purpose ustawiamy na Signature and encryption. Ustaw Minimum key size na 1024.
Na dole zakładki Request Handling, wybierz cryptographic service providers (CSPs), które powinny zostać użyte:
· Microsoft DH SSchannel Cryptographic Provider
· Microsoft Enhanced Cryptographic Provider v1.0
· Microsoft RSA SChannel Cryptographic Provider
Na zakładce Subject Name, sprawdź czy opcja Supply in the request została zaznaczona.
Na zakładce Extension, sprawdź czy sygnatura Digital signature została zaznaczona. Szyfrowanie (Encryption) powinno być ustawioe na wartość “Allow key exchange only with key encryption”.
Otwieramy Certification Authority snap-in i w Certificate Templates wybieramy New Certificate Template to Issue. Tutaj musimy wybrać poprzednio wygenerowany szablon certyfikatu “aes” i klikamy OK – powinien być teraz dostępny w Certificate Templates.
Ta procedura wygenerowała nam cert, którego użyjemy na serwerze Lync Server 2010, który zawiera Client and Server Authentication Policies wymagane przez AE Services.
Odpalamy Lync Server Deployment Wizard. Wybieramy “Install or Update Lync Server System”.
W kroku 3 wizarda, “Request, Install or Assign Certificates” wybieramy Run lub Run Again. Tutaj też pokażę tylko najważniejszą część – oczywiście robimy Request certu.
Na stronie Specify Alternate Certificate Template, wybieramy box Use alternate certificate template for the selected certification authority. Wprowadzamy nazwę wcześniej wygenerowanego certu “aes” i przechodzimy dalej.
Na stronie Name and Security Settings wizarda, wpisz nazwę “aes_cert” i wybierz szyfrowanie 1024 (tak jak w cercie).
Oczywiście w kolejnym kroku wybieramy SIP domain, pozostawiamy Additional Subject Alternate Names i przypisujemy certyfikat do serwera Lync Server 2010: “Assign this certificate to Lync Server certificate usages”.
Po stronie AES Server trzeba jeszcze dodać zaufany certyfikat z AD i wygenerować cert dla serwera w AD – wszystko opisane jest w przewodniku do którego linkowałem powyżej.
Configuring Remote Call Control (RCC) w Lync Server 2010
Lync Server 2010 Management Shell będzie wykorzystany do dodania AES’a jako RCC gatewaya.
Uruchamiamy polecenie, żeby zebrać info o obecnej konfiguracji serwera (najlepiej skopiować te dane):
PS C:UsersAdministrator.lync01> Get-CsStaticRoutingConfiguration
(should return null results unless a static route has previously been configured)
Identity : Global
Route : {}
PS C:UsersAdministrator.lync01> Get-CsSipDomain
(To view configured SIP domain(s). This will not be modified during RCC configuration in this example)
PS C:UsersAdministrator.lync01> Get-CsTrustedApplicationPool
(Retrieves settings for one or more pools that contain the computers that host trusted applications)
For help with the Lync Server management Shell:
PS C:UsersAdministrator.lync01> Get-Help
Teraz pozostało nam stworzyć statyczne trasy do RCC gateway. Tworzymy zmienną $TLSRoute.
PS C:UsersAdministrator.lync01> $TLSRoute = New-CsStaticRoute –TLSRoute -Destination aes352.uclabs.com -Port 4723 -UseDefaultCertificate $true -MatchUri *.uclabs.com
PS C:UsersAdministrator.lync01> Set-CsStaticRoutingConfiguration -Route @{Add=$TLSRoute}
Tworzymy trusted application.
PS C:UsersAdministrator.lync01> New-CsTrustedApplicationPool –Identity aes352.uclabs.com -Registrar hq666se.aes352.uclabs.com -Site hq666 -TreatAsAuthenticated $true -ThrottleAsServer $true -RequiresReplication $false
Następnia dodajemy trusted application do pool:
PS C:UsersAdministrator.lync01> New-CsTrustedApplication -ApplicationID hq666 -TrustedApplicationPoolFqdn aes352.uclabs.com -Port 4723
Użyj Get-CsStaticRoutingConfiguration oraz Get-CsTrustedApplicationPool, żeby podejrzeć wprowadzone zmiany:
PS C:UsersAdministrator.lync01> Get-CsStaticRoutingConfiguration
PS C:UsersAdministrator.lync01> Get-CsTrustedApplicationPool
Implementujemy zmiany cmdletem:
PS C:UsersAdministrator.lync01> Enable-CsTopology
Ostatnia faza konfiguracji to włączenie użyszkodnika RCC po stronie serwera LYNC – przykład w formie obrazkowej:
No i można testować interop!
Konrad Sagała od 17 lat zajmuje się projektowaniem i wdrażaniem systemów informatycznych opartych o różne platformy sieciowe, od 12 lat związany z platformą Microsoft Windows Server. Do jego specjalności należą: projektowanie i wdrażanie systemów usług pocztowych i pracy grupowej Microsoft Exchange, projektowanie systemów usług katalogowych Active Directory, projektowanie infrastruktury sieciowej, usług bezpieczeństwa i zarządzania systemami. Jest twórcą jednej z największych w Polsce struktur Active Directory i Exchange. Twórca 
Piotr Pawlik blog 