Uruchamianie usług chmurowych w hybrydzie

Usługi czyli EXO (Exchange Online) i SOL (Skype for Business Online). Problem w hybrydzie polega na tym, że nie można skorzystać z interfejsu portal.office.com – należy konta założyć w środowisq onprem. i oczywiście prostą odpowiedzią byłoby skierowanie do commandletów Exchange i SfB w onprem… ale po co wtedy byłby wpis?

Scenariusz

zakładamy konto użytkownika i chcemy aby od razu miał skrzynkę w EXO i uruchomione usługi SOL. można założyć całość w onprem a potem migrować… ale to straszna strata czasu i wysiłq.

Standardowo

niemniej zacznę od standardowej metody, ponieważ tak to się robi oficjalnie.

po założeniu konta w AD, należy wykonać enable-RemoteMailbox – opis polecenia oraz doqmentacja do hybrydy. następnie trzeba włączyć konto SOL poleceniem enable-CSUser, a sztuczka polega na dodaniu parametru  “-HostingProviderProxyFqdn sipfed.online.lync.com”.

problem z tym rozwiązaniem jest taki, że żeby założyć konto potrzebne są aż trzy różne moduły: Active Directory, Exchange oraz Skype for Business. Prawidłowo administracja powinna być tak zorganizowana, że administratorzy logują się na stację zarządzającą, gdzie mają wszystkie narzędzia zainstalowane – w szczególności te wymienione. i oczywiście sugerowałbym aby tak to się odbywało. jednak… życie pisze własne scenariusze, np. taki, że jest sobie system HR, z którego wypływają dane o użytkownikach. i jak developer ma sobie z tym poradzić? do LDAP dość łatwo się dostać i są do tego standardowe biblioteki w samym frameworq, a do Ex czy SfB już tak różowo nie jest.

HACKED

….podam sposób, jak można założyć mailbox i włączyć SIP, wyłącznie przy pomocy modułu Active Directory/dostępu do LDAP. zaletą takiego rozwiązania jest brak konieczności instalacji pozostałych – i to właśnie był czynnik, który zmusił mnie do zrobienia takiego rozwiązania. zacznę od przestrogi:

zaprezentowane rozwiązanie nie jest wspierane, a konsekwencje użycia mogą być ciężkie do przewidzenia – dla tego przetestuj dokładnie, upewnij się, że rozumiesz co robisz i jak to działa tak, aby w razie co być w stanie naprawić. pełne commandlety wykorzystują mechanizmy sprawdzające poprawność ustawianych wartości, czy nie występują duplikaty w domenie, i wiele innych, których tutaj nie ma – a więc można namieszać. korzystasz na własną odpowiedzialność.

no to jak już się przestraszył[ae]ś, to teraz rozwiązanie.

w zasadzie najważniejszym trikiem jest zrozumienie jak działa hybryda – wszystkie zmiany wprowadzane są w onprem i synchronizowane do chmury. czyli wskazane polecenia – enable-RemoteMailbox czy enable-CSUser – wbrew temu co możesz sądzić, w żaden sposób nie łączą się z Office365. jedyne co robią, to modyfiqją wartości atrybutów w AD. w związq z tym można napisać skrypt, który dokładnie to zrobi.

nie będę zamieszczał całego skryptu – są w nim elementy specyficzne dla konkretnego klienta – ale wszystko co niezbędne znajdziesz poniżej.

Exchange

atrybuty, które należy zmodyfikować mogą się różnić, zależnie od klienta – wiadomo, różne firmy mają różne wymagania. poniżej zestaw atrybutów ‘podstawowych’:

    $EXOattributes=@{
        'mail'=$oUser.UserPrincipalName
        'mailNickname'              =$oUser.SamAccountName
        'msExchPoliciesExcluded'    =@('26491cfc-9e50-4857-861b-0cb8df22b5d7') #disable automatic email address creation
        'msExchRecipientDisplayType'='-2147483642'
        'msExchRecipientTypeDetails'='2147483648'
        'msExchRemoteRecipientType' ='1'
        'msExchUMDtmfMap'           ="" 
        'msExchVersion'             ="44220983382016" #Ex2010 ; Ex13 = "88218628259840" ; Ex16 = "1125899906842624"
        'proxyAddresses'            ="" 
        'showInAddressBook'         ='CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=LOGICUNION,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=LOGICUNION,DC=LAB'
        'targetAddress'             ="SMTP:$($oUser.SamAccountName)@LogicUnion.mail.onmicrosoft.com"
    }

to, co widać powyżej, to oczywiście zestaw atrybutów obiektu User w AD, niezbędnych do założenia skrzynki.

• mail: $oUser to obiekt użytkownika, pobrany wcześniej jako “$oUser=get-aduser <name> -properties *”. tutaj założenie jest, że podstawowy email jest taki sam jak UPN
• mailNickname: standardowo jest taki sam jak SAM
• msExchPoliciesExcluded: jeśli chcę ustawiać adresy email ręcznie to wskazana polisa (GUID taki sam dla każdego Ex) jest odpowiednikiem odznaczenia ‘Automatically update email addresses…’ . jeśli adresy będą się wypełniały standardowymi polisami, to można pominąć
• msExchangeRecipient*: wskazują na typ skrzynki. szczegóły tutaj. ogólnie – wskazuje, że skrzynka typu RemoteUserMailbox ma być założona
• msExchUMDtmfMap: będzie za chwilę wypełnione – funkcja poniżej. de facto chodzi o konwersję na cyferki z cyferblatu telefonu, fragment UC.
• msExchVersion: jest zawsze taka sama, i pochodzi z onpremowego Exchange. można sobie zweryfikować z jakimś lokalnym kontem
• proxyAddresses: to oczywiście aliasy. jeśli ustawiamy inne niż podstawowy, warto nie zapomnieć wyłączyć polisy msExchPoliciesExcluded…
• showInAddressBook: to CN list adresowych, w których ma się pojawić. tutaj standardowa lista globalna. ten CN można odczytać z innego użytkownika.
• targetAddress: bardzo ważne pole, wskazujące na przekierowanie do chmury. na jego podstawie robiony jest routing do chmury na connectorze.

zmienna jest typu hashtable, można więc sobie powyliczać np. proxyaddresses, poustawiać co potrzeba. np. DTMF. funkcja, która konwertuje ciągi do DTMF:

function convert-str2dtmf {
    param(
        [char[]]$str
    )
    $dtmfCodes=@{
        "a"=2;
        'b'=2;
        'c'=2;
        'd'=3;
        'e'=3;
        'f'=3;
        'g'=4;
        'h'=4;
        'i'=4;
        'j'=5;
        'k'=5;
        'l'=5;
        'm'=6;
        'n'=6;
        'o'=6;
        'p'=7;
        'q'=7;
        'r'=7;
        's'=7;
        't'=8;
        'u'=8;
        'v'=8;
        'w'=9;
        'x'=9;
        'y'=9;
        'z'=9;
    }

    $dtmfOut=""

    foreach($letter in $str) {
        $letter=([string]$letter).ToLower()
        if($dtmfCodes.ContainsKey($letter) ) { $dtmfOut+=$dtmfCodes[$letter] }
    }
    return $dtmfOut
}

i fragment kodu, który ustawia DTMF:

    $dtmfEmail=convert-str2dtmf -str $oUser.SamAccountName
    $dtmfLNFN=convert-str2dtmf -str "$($oUser.sn)$($oUser.givenName)"
    $dtmfFNLN=convert-str2dtmf -str "$($oUser.givenName)$($oUser.sn)"
    $EXOattributes.msExchUMDtmfMap=@("emailAddress:$dtmfEmail","lastNameFirstName:$dtmfLNFN","firstNameLastName:$dtmfFNLN")

zmienna jest tablicą zawierającą zazwyczaj trzy elementy w zapisie DTMF – adres email [a w zasadzie nazwa użytkownika – bez domeny], nazwa użytkownika ‘lastNameFirstName’ oraz ‘firstNameLastName’. a więc wyliczam przy pomocy funkcji konwertującej i paqję do zmiennej $EXOattributes.

kiedy $EXOAttributes zawiera wszystko to, co potrzebne, pozostaje pchnięcie tego do AD. i tutaj piękno i prostota PS:

 Set-ADUser -Identity $oUser.SamAccountName -replace $EXOattributes

i już. atrybuty są wypełniane, zsynchronizuje się do o365, a ten podejmie odpowiednie działania – czyli założy skrzynkę.

SOL

całość wykonuje się analogicznie – buduję hashtable, który potem pchnę do AD, a poniżej niezbędne atrybuty dla Skype for Business Online:

    $SOLAttributes=@{
        'msRTCSIP-DeploymentLocator'    ="sipfed.online.lync.com"
        'msRTCSIP-FederationEnabled'    =$True
        'msRTCSIP-InternetAccessEnabled'=$True
        'msRTCSIP-OptionFlags'          ='257'
        'msRTCSIP-PrimaryHomeServer'    ='CN=Lc Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=LogicUnion,DC=Lab'
        'msRTCSIP-PrimaryUserAddress'   ="sip:$($oUser.UserPrincipalName)"
        'msRTCSIP-UserEnabled'          =$true
    }

te zbudowane są dla środowiska sfederowanego, gdzie po stronie OnPrem stoi Lync 2o13. to może mieć znaczenie dla atrybutu msRTCSIP-PrimaryHomeServer – ponieważ nie wiem czy tak samo wygląda CN usługi SfB.

dla ‘OptionFlags’ link z wyjaśnieniem wartości można znaleźć tutaj.

Set-ADUser -Identity $oUser.SamAccountName -Replace $SOLAttributes

zakończenie

jak wspomniałem, nie publiqję całego skryptu, ponieważ logika wyliczania czy to proxyaddresses czy innych elementów jest dla konkretnego środowiska i każdy musi sam to oprogramować. celem wpisu jest tak na prawdę pokazanie na czym polega ‘od spodu’ założenie konta w EXO czy SOL w środowisq hybrydowym. niby każdy wie, że zmiany synchronizują się w jedną stronę, a jednak podczas rozmów, okazuje się, że wszyscy spodziewają się jakiejś dodatkowej komunikacji pomiędzy systemami. a tu nic takiego nie ma – jest tylko synchronizacja i tyle.

nie jest to zalecany sposób tworzenia… ale na pewno fajna zabawa (;

eN.