bolesne i śmieszne

albo ilość albo jakość. Microsoft niemal zawsze wybiera to pierwsze. a im większy jest Azure/o365 – tym gorzej ze stabilnością i jakością. błędów jak ten, który zaraz opiszę, jest masa, ale ten mnie po pierwsze rozśmieszył, po drugie to śmiech przez łzy – bo straciłem półtora tygodnia… może komuś oszczędzę tej przyjemności?

kontekst: konfiguracja polityk Conditional Access dla Windows 365 Cloud PC. jeśli chcemy utworzyć dostęp warunkowy, działający 'wewnątrz’ w365CPC, ale równocześnie pozwalająca na logowanie się do niej samej to polityka musi mieć zrobiony wyjątek na aplikacje w365CPC, bo sama jest częścią 'All Cloud Apps’.  artyqł opisujący jak to zrobić można łatwo wyszukać, a kluczowy okazał się wyjątek na aplikację 'Azure Virtual Desktop’…

#1 dodajemy wyjątek na aplikację windows 365 – tu bez problemu, wyszuqję apkę i działa:

pięknie wyszuqje. więc teraz #2 – dodaję 'Azure Virtual Desktop’…

…średnio widać, ale nie ma liście tego, czego szukam. próbuję bardziej restrykcyjne słowa kluczowe – 'virtual’ a potem 'desktop’…

…apki nie ma. naszukałem się, ticket założony… a jakość wsparcia idzie w parze z samym produktem. słychać, że braqje ludzi na rynq. poziom 'dialogu’ ze wsparciem jest gorszy niż z Cyfrowym Asystentem w wersji beta – te dużo więcej rozumiały już lata temu, i odzywają się językiem, który bardziej przypomina angielski. każda rozmowa to wielo-minutowe 'przepraszam, proszę powtórzyć’ – bo albo ktoś gurgla do słuchawki, albo dzwoni z jakiegoś bazaru w słuchawkach za 5PLN, to makabra jakaś jest. i przy każdej rozmowie trzeba powtarzać wszystko co było w mailach – więc zaczynam podejrzewać, że nie umieją czytać. ale to tak na boq…

do rozwiązania doszedłem w końcu sam, przypadkiem, ponieważ słowem kluczowym do wyszukania 'Azure Virtual Desktop’ jest… 'Windows’:

jak widać, jest więcej aplikacji, których nazwy nie zawierają tego ciągu znaqw, a mimo to pojawiają się podczas wyszukiwania. pech – pewnie 99% innych osób od razu wpisuje 'windows’ i od razu widzi obie apki na ekranie… a mi się zachciało całość wpisać, razem z '365′ /:

bałagan jaki jest w tych nowych produktach jest kosmiczny. nie ma dnia, żebym nie znalazł jakiegoś glitcha – czy to w GUI czy w samych commandletach PS. zaczynamy coraz więcej płacić za tempo rozwoju i intuicja mi podpowiada, że to dopiero początek – już niedługo złożoność i wielkość systemów zje ich twórców, bo to nie jest tak, że Microsoft jakoś odstaje od innych firm. mam wrażenie że Internet jest bardzo à la mode – bo 9o-te są na fali. jak mi się czasem przypadkiem zdarzy uruchomić przeglądarkę bez ad-blockera, to nie wiem co się na ekranie dzieje. osoby z padaczką mogą dostać ataq. na początq lat 2k, jak wychodziło web2.o, były już świetne strony, które były lekkie i dynamiczne – ładowały się tylko w elementach, które się zmieniały i zawierały to, co było potrzebne. i co się z tym stało? większość Internetu to niechlujnie napisane aplikacje, przeładowane niepotrzebnymi dystraktorami, nawalone reklam albo innych elementów, a każde kliknięcie to przeładowanie… a miało być tak pięknie…

eN.

zarządzanie użytkownikami w hybrydzie

ponieważ to pytanie wraca do mnie niemal przy każdym projekcie i ponieważ obserwuję problem w zrozumieniu tych mechanizmów, zamieszczam krótkie podsumowanie najważniejszych informacji, które powinny pomóc w przygotowaniu doqmentacji 'zarządzania użytkownikiem’ oraz administracji w środowisq hybrydowym.

’Hybryda’

wedle moich obserwacji najważniejsze, a zarazem wymykające się intuicji jest to, że 'hybryda’ tak na prawdę w większości wdrożeń powinna być nazywa 'hybrydy’ – w liczbie mnogiej. w standardowym scenariuszu mamy bowiem:

  • hybryda tożsamości – połączenie pomiędzy AD i AzureAD. obiekty wraz z atrybutami synchronizowane są z onprem do Chmury, zapewniając (przy odpowiedniej konfiguracji) pojedynczą tożsamość i SSO (lub same-password w mniej wykwintnej implementacji)
  • hybryda Exchange – połączenie pomiędzy Ex a EXO. to co zaburza intuicję jest fakt, że wiele atrybutów Exchange jest przechowywanych w AD i synchronizowanych w ten sam sposób. jednak włączenie/wyłączenie hybrydy Exchange to w dużej mierze właśnie zdefiniowane czy ten zestaw atrybutów ma być synchronizowany czy też nie.
  • hybryda SfB – czyli połączenie pomiędzy onpremowym Lync/SfB a SOL/Teams. i tutaj podobnie jak w przypadq Exchange – mylącym jest fakt, że w takim środowisq informacje na temat konta SfB są zapisywane w AD i tak synchronizowane.

każdą z nich można mieć lub nie mieć … no ok, hybryda tożsamości musi być w każdym scenariuszu – ale Ex czy SfB to już kwestia wymagań klienta.

teoretycznie 'hybryda’ powinna dawać jedno, centralne miejsce zarządzania i unifikację… de facto sprawa jest bardziej zagmatwana, ale poniżej przedstawione zasady powinny pomóc

Zarządzanie użytkownikami

zarządzanie użytkownikami w środowisq tożsamości hybrydowej odbywa się w zasadzie w pełni z onprem. w tym przypadq jest zatem najmniej zmian w kwestii procedur zarządzania.

wyjątkiem są:

  • zarządzanie licencjami, ale wtedy na pomoc przychodzi Group-Based Licensing .
  • wymuszenie zmiany hasła
  • do różnic można dorzucić jeszcze rozwiązywanie problemów i audyt – oczywiście zdarzenia logowania i te 'ruchome elementy’ dzieją się w ramach AAD więc tutaj też trzeba sięgnąć do chmury…. a w zasadzie do obu środowisk na raz (a w ogóle to najlepiej jakiś SIEM zintegrowany).

należy dodać do tego pewne bardziej skomplikowane sytuacje, ponieważ wybór strony gdzie należy wykonać akcję może się różnić zależnie od metody uwierzytelnienia (PH, PTA, ADFS) lub wdrożenia SSPR – ale to są wszystko kwestie z zakresu obsługi hasła czy blokady konta.

Zarządzanie Exchange

ten element jest najbardziej kłopotliwy i hybryda Ex generalnie ma swoje specyficzne ograniczenia… największą pomocą jest tutaj traktowanie oddzielnie skrzynki i użytkownika. w ogólności są dwie perspektywy: administracja serwisem i użytkownikiem. pierwsze jest proste do wyjaśnienia:

  • Ex i EXO są rozdzielne – polityki bezpieczeństwa, mail flow, ustawienia globalne – robi się oddzielnie po obu stronach i nie są to elementy podlegające synchronizacji.
  • sprawa jest dość skomplikowana w przypadq polityki maili (recipient policies) bo … przenikają się częściowo. nie mogę teraz znaleźć linka.. ale w uproszczeniu najlepiej też zarządzać z onprem – ponieważ tam jest konto użytkownika i synchronizowany atrybut 'proxyAddresses’

przy zarządzaniu pojedynczym użytkownikiem:

  • operacje związane z kontem użytkownika wykonuje się z onprem (aliasy mailowe, zmiany nazw/opisów/informacji)
  • operacje związane ze skrzynką – po tej stronie gdzie jest skrzynka [bo może być przecież albo tu albo tam] (limity skrzynki, statystyki, uprawnienia). w skrócie to, co robi ’set-mailbox*’ wykonuje się tam, gdzie ten mailbox leży.

jest kilka 'dzwinostek’ typu uprawnienie 'send as’ które wynika z faktu, że jest de facto zapisywane w AD i niesynchronizowane. zarządzanie, czy wspomniane przetwarzanie polis recipient policies, które w specyficznych przypadkach może wydawać się niespójne… są też różnice zależnie czy która wersja jest w OnPrem (zwłaszcza, jeśli to Ex 2o1o).

napisanie spójnych procedur zarządzania dla Exchange Hybrid jest wyzwaniem.

Zarządzanie SfB

do czasu Teamsów sprawę dało się jeszcze ogarnąć. szczęśliwie dla SfB w zasadzie nie ma specjalnie zarządzania

  • konto w hybrydzie trzeba włączyć/wyłączyć, co robi się oczywiście po stronie onprem,
  • wszelkie zarządzanie danymi o userze to de facto zapis do AD – więc też onprem

są oczywiście elementy integracji VoIP, polisy czy inne elementy usługi – i to jest rozdzielnie dla każdej strony.

  • przypisanie polis – to tam, gdzie jest konto SfB, oddzielne są polisy więc zależnie od strony hostującej, tam się te polisy definiuje i przypisuje.

hybryda SfB jest imho najtrudniejsza do zestawienia ale najmniej potem przy niej administracji i 'ruchomych elementów’ a najtrudniejsze części to równocześnie te najrzadziej wykorzystywane czyli część integracji z VoIP, cloud PBX itp.

procedury administracyjne nie wymagają zatem specjalnych zmian.

na zakończenie

o ile hybryda tożsamości to 'must have’ dla każdego środowiska opartego o AD, o tyle przejście do cloud-only i rezygnacja z hybrydy jest posunięciem często możliwym a w takim przypadq – sugerowanym. środowiska hybrydowe tylko pozornie są 'zunifikowane’ – po obu stronach barykady (firewalla) są produkty w innych wersjach i choć mają symulować 'jedną organizację’ to jest to proteza, która wprowadza sporo niejasności i komplikacji w konfiguracji i zarządzaniu. konieczność wykorzystania PowerShell do części zadań powoduje, że niektóre zadania normalnie wykonywane przez helpdesk, nagle są eskalowane do 2giej linii. przykładem mogą być procedury provisioningu użytkownika w hybrydzie Ex1o z EXO – gdzie nie ma wsparcia zakładania konta ze skrzynką online z interfejsu, a skrzynkę współdzieloną da się tylko zrobić hackując z poziomu atrybutów AD bo nawet PowerShell w tej wersji nie ma opcji ’-Shared’ która pojawiła się w Ex13.

przejście dla tych usług na cloud-only znacznie ułatwia administrację.

eN.

MFA, SSPR – 'unified experience’?

scenariusz

typowy w-files czyli hejcik przy kawie. dziś o konfiguracji MFA oraz fakcie, że od czasów portalu Azure, który niewielu już pamięta, ten fragment cały czas jest w starej wersji. można się do niego dostać linkiem https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx i wygląda tak:

…już pominę kwestię, że MFA jest jednym z częściej koniecznych obszarów do obsługi przez 2gą linię, a nie ma możliwości użycia RBAC i konieczny jest Global Admin, czy taki szczegół, że 'podpowiedzi’ pokazują prywatne pule adresowe (LoL).

żeby zaadresować te problemy i w końcu dać nowy interfejs, powstał ’combined security information registration (preview)’. na razie 'preview’ – chociaż nie wiem po co w tych czasach dodawać taki dopisek, skoro wszystko jest w metodyce CI/CD co oznacza 'neverending preview’. dodajmy teraz do tego SSPR – czyli Self-service Password Reset. konfiguracja wygląda tak:

 

efekt?

otóż ustawienia metod uwierzytelnienia dla MFA, skonfigurowane w SSPR mają pierwszeństwo nad ustawieniami z MFA server. czyli np. :

  • chcielibyśmy dać możliwość ludziom użycie dowolnej metody 2FA (call, text, app) i równocześnie wymusić, że podczas zmiany hasła musimy skorzystać z odpowiadania na pytania – nie da się. jeśli włączymy X metod uwierzytelnienia, te same będą dozwolone przy resecie hasła.
  • konfiguracja MFA z panelu użytkownika znika. na razie nie udało mi się znaleźć jak 'wyklikać się’ do ekranu zmiany opcji. użytkownik musi skorzystać z linka bezpośredniego – https://aka.ms/mfasetup .
  • nawet jeśli SSPR jest konfigurowany tylko dla ograniczonej ilości osób (np. przez grupę), to i tak te opcje działają na wszystkich
  • nie oznacza to wcale, że stary MFA server setup jest już zbędny! ponieważ to jest jedyna opcja, która działa z nowego miejsca – cała reszta, czyli opcja trusted IP czy ile czasu MFA jest cache’owane – to wszystko konfiguruje się ze starego panelu.

no. łatwiej teraz jest, nie?

eN.

 

ClickOnce

emotHateporanny hejcik przy kawie.

jest sobie taka stara technologia dostarczania aplikacji – ClickOnce. i chociaż na stronach eMeSu nie ma informacji, że jest 'depricated’ mimo to – jest. z tym rodzajem instalacji można spotkać się w kilq miejscach w M365 – trafiłem na trzy, pamiętam dwa:

  • instalacja PowerShell dla EXO w hybrid mode
  • eDiscovery export tool

sposób w jaki taka apka jest opublikowana powoduje, że nie da się (standardowo) użyć opcji 'uruchom jako’, udostępnić komuś, przenieść między profilami czy cokolwiek innego. ale nie to jest najpasqdniejsze. na tej stronie jest informacja, że aby uruchomić aplikację należy mieć Internet Explorer. jest też info o FF z jakimś dodatkiem – tego nie testowałem ale nie omieszkam. drugą przeglądarką, choć nie wymienioną, był/jest Edge. był – ponieważ nowy Edge, na Chromium już nie jest. pozostaje więc konieczność używana IE /:

drogi Microsofcie… czasem brak mi słów. z jednej strony wszyscy przestali nadążać za nowo-pojawiającymi się opcjami, dodatkami, panelami etc – a z drugiej, podczas dochodzenia w incydencie bezpieczeństwa trzeba odpalać spapranego IE, o którym cały świat wolałby już zapomnieć i waszym interesie jest, żeby to się stało ASAP…

eN.

Migracja w hybrydzie – zakończenie pojedynczej skrzynki w zadaniu synchronizacji

ciekawostka, bo wszyscy piszą, że się nie da… a się da.

jeśli założy się zadanie migracyjne Ex-EXO w którym jest wiele kont, to można potem usunąć pojedynczą skrzynkę użytkownika, ale nie bardzo jest sposób na to, żeby tylko jedną skończyć. jeśli jednak się przyjrzeć w jaki sposób działa parametr 'AutoComplete’ dla wsadu migracji, sprawa okazuje się oczywista.

korzystając z PowerShell, jeśli chcemy zsynchronizować skrzynki ale ręcznie ustalić kiedy mają się przełączyć wygląda to np tak:

$binBatch=[System.IO.File]::ReadAllBytes($bPath)
$mbParam=@{
    name="transza01";
    AutoComplete=$false;
    AutoStart=$true;
    badItemLimit='50';
    CSVData=$binBatch;
    SourceEndpoint='MigrationEndPoint';
    TargetDeliveryDomain='w-files.pl'
} 
New-MigrationBatch @mbParam

gdzie opisywanym parametrem jest oczywiście 'AutoComplete’. ale kiedy podejrzy się potem takie zadanie – gdzie to sobie siedzi? jeśli posłużymy się get-migrationUser żeby to znaleźć – nie bardzo się uda. parametr jest dziedziczony z całego wsadu, stąd może wydawać się niemożliwe ukończenie pojedynczej skrzynki. jeśli jednak wyświetli się i sprawdzi w jaki sposób jest to de facto zrealizowane, to rozwiązanie nasuwa się samo. tak na prawdę dla całego zadania ustawiany jest atrybut 'completeAfter’ na jakąś chorą datę – w tym przypadq wyjątkowo szybko:

PS C:\_scriptZ> Get-MigrationBatch -Identity transza01|select completeAfter*

CompleteAfter CompleteAfterUTC
------------- ----------------
01.01.4501 00:00:00 01.01.4501 00:00:00

wyjątkowo szybko, bo zazwyczaj widzę 31.12.9999 . z jakiegoś powodu tym razem czas został kapkę skrócony, ale i tak jestem zbyt niecierpliwy, żeby czekać tyle czasu (;

…a zatem aby skończyć pojedynczą synchronizację wystarczy ustawić jej czas 'completeAfter’ na obecny. korzystam z jednej z dwóch metod:

set-migrationUser <user-email> -CompleteAfter ((get-date).ToUniversalTime())

lub

set-migrationUser <user-email> -CompleteAfter ((get-date).AddDays(-1))

ustawiając datę z przeszłości – jeśli chcę mieć 1oo%, że to nie chodzi o UTC. nie porównywałem czy efekt jest identyczny. przez jakiś czas nic się nie dzieje (statystyki nie pokazują statusu jako 'completing’), ale po ok 1h skrzynka jest 'completed’.

eN.

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.

Group Based Licensing dla o365

GBL

możliwość zarządzania licencjami przez grupy AD to nieoceniona pomoc w każdym większym środowisq. co prawda spędziłem kilka ładnych godzin nad fajnym skryptem, którym można masowo zarządzać licencjami wraz z poszczególnymi planami serwisowymi, jednak możliwość ułatwienia administracji jest bezcenna. trzeba zatem było z łezką w oq wrzucić skrypt do projektów wymarłych i zająć się okiełznaniem grup.

ogólnie, GBL pozwala na przypisanie licencji (niemal) dowolnej grupie AAD, dzięki czemu zarządzanie licencjami sprowadza się do prostych operacji zmiany członkostwa. pomimo, że funkcjonalność jest jeszcze w public preview, uważam, że warto się mocno zainteresować, bo operacje licencyjne przeważnie są realizowane albo przez 1szą linię, gdzie korzystanie ze skryptów nie koniecznie jest mile widziane, albo przez automatyczne systemy zarządzania tożsamością, jako część procesu nowego użytkownika.

ponieważ jest to świetnie udokumentowane, nie będę się rozpisywał o podstawach, ale przedstawić ciekawe przypadki i problemy.

[info: art opisuje środowisko hybrydowe]

gdzie jest haczyk?

pierwszy i podstawowy haczyk, pojawia się już na poziomie projektowania grup. rzadko kiedy zdarza się, żeby wykorzystywany był pojedynczy typ licencji, czy nawet dwa-trzy. zazwyczaj jest wiele różnych wyjątków, wynikających z różnorodności zapotrzebowania – niektórzy będą mieli E3, inni E5, jeszcze inni będą potrzebować pojedynczych planów (np. PowerBI, AudioConferencing) jako uzupełnienie niższej licencji. są też dodatkowe produkty takie jak Visio czy Project, które też raczej wszystkim użytkownikom się nie qpuje.

okazuje się, że ilość wyjątków może być całkiem spora, warto zastanowić się więc nad modelem hybrydowym – np. używać grup do zaspokojenia przyjętych standardów, co zrealizuje 9o%, i to tych, przy których normalnie trzeba użyć jakiegoś skryptu. wyjątki natomiast obsłużyć ręcznie 'wykliqjąc’. jednolite rozwiązania są dużo łatwiejsze w zarządzaniu, i ogólnie jestem przeciwnikiem mieszania metod zarządzania tym samym fragmentem jednak w tym przypadq:

  • funkcja jest nadal w preview. public, bo public, i testowana jest już ok ok. 2 lat, jednak nie ma gwarancji co się zmieni w finalnej wersji. zakładam że nic, w porywach do niewiele, ale trzeba mieć z tyłu głowy ew. poprawki co całego projektu, lepiej więc go póki co nie komplikować
  • braqje na razie dobrych artyqłów z praktyki [co staram się załatać (: ], który pokazywały by realne bolączki i ryzyka.

mechanizm trzeba najpierw dobrze poznać i zrozumieć niuanse i konflikty, zanim wdroży się go globalnie. a więc pomimo, że docelowo najlepiej mieć czyste zarządzanie GBL, sugeruję zacząć od podejścia ewolucyjnego. dać sobie trochę czasu na nauczenie się zachowania mechanizmu i rozwiązywania problemów… o których może uda mi się kiedyś napisać.

double-trouble

z technicznego punktu widzenia, największym problemem są plany powiązane. niektóre plany są od siebie zależne i nie uda się przypisać jednego-bez-drugiego. przykłady:

  • plan 'Office Online’ wymaga planu 'SharePoint’
  • plan 'AudioConferencing’ wymaga planu 'Skype/Teams’

zależnie od implementacji, albo osoby nie będą miały oczekiwanej licencji, bo nie spełniają kryterium, albo w ogóle nie uda się utworzyć grupy licencyjnej. przykładowy scenariusz:

  • osoby posiadają licencje o365 E3 ale potrzebują tworzyć spotkania z opcją call-in. czyli trzeb im dodać plan 'Audio Conferencing’.

nie da się utworzyć grupy licencyjnej zawierającej wyłącznie ten plan, ponieważ nie ma gwarancji spełnienia warunq posiadania Skype/Teams. obejściem jest dodanie do grupy zarówno planu AC oraz Skype z licencji E3, trzeba się oczywiście upewnić, że nie więcej scenariuszy w firmie – np. trzeba będzie założyć grupę AC wraz z Skype E1 – co bardzo skompliqje zarządzanie.

trouble-double

…czyli to samo ale odwrotnie. usuwamy osoby z grupy licencyjnej, ba! usuwany całą grupę licencyjną. grupy w AD nie ma, wchodzimy do AAD… i grupa nadal jest, zawiera wszystkich członków, licencje nadal są przypisane, nie ma błędów synchronizacji… to czemu u licha grupa została??

otóż może tak się zdarzyć, że usuwamy grupę zawierająca licencję 'nadrzędną’ a gdzieś, wedle algorytmu, może zostać podrzędna. czyli np. usuwamy licencje zawierająca SharePoint, a są  grupie osoby które maja Office Online. AAD stwierdza, że to doprowadzi do konfliktu, więc bloqje całą operację.

jeśli usuwamy grupę licencyjna – zalecam zacząć od usunięcia wszystkich członków, synchronizacji, a potem dopiero usunięcie grupy.

konflikty licencyjne

przy złożonej strukturze grup mogą wystąpić konflikty licencji. taka sytuacja zdarza się w momencie, kiedy wedle grup użytkownik będzie miał przypisane plany z różnych grup. nie zapisałem niestety przykładowych przypadqw, ale miałem okazję oglądać sytuację, w której licencja nie została przypisana, ponieważ pomieszane były poziomy planów z różnych licencji – czyli jakiś plan z licencji E3 kolidować z innym planem, z E1.

podczas projektowania grup GBL lepiej przypisywać możliwie pełne licencje – zbytnie kombinowanie na poziomie planów szybko doprowadzi do scenariuszy konfliktowych.

podsumowanie

mechanizm GBL oceniam rewelacyjnie. AAD świetnie pokazuje komunikaty błędów, pomaga w debugowaniu i ogólnie całość jest bardzo fajnie przemyślana. nie jest jednak pozbawiony limitów, i nie zawsze będzie się nadawał. należy zapoznać się z niuansami działania, przemyśleć scenariusze użycia licencji w firmie i sprawdzić czy nie ma przypadqw na tyle skomplikowanych, że nie opłaca się go używać. stworzenie zbyt dużej ilości grup, dających możliwości granularnego zarządzania planami może albo posqtkować niezłym misz-maszem i wcale nie ułatwić życia, albo w specyficznych przypadkach być niemożliwe.

podsumowując 'KEEP IT SIMPLE’. znalezienie środka może być wyzwaniem jeśli scenariuszy licencyjnych jest wiele.

eN.

aplikacje o365 w licencji Business Premium

tak się jakoś składa, ze względu na klientów z którymi współpracuję, że nabywane są licencje Enterprise – czy to E3 czy E5. do tej pory żyłem w przekonaniu, że to najbardziej wypasione licencje, więc jest w nich już wszystko.

na wczorajszym WGUiSW zobaczyłem podczas prezentacji Marka o Office365 aplikację 'bookings’, która mnie mocno zaskoczyła, ponieważ sądziłem, że znam wszystkie. po krótkim śledztwie okazuje się, że licencja Business Premium zawiera pakiet aplikacji dla SMB, w którym są:

Niedostępność aplikacji w planach Enterprise Microsoft tłumaczy faktem, iż ich architektura nie jest w tej chwili wystarczająco skalowalna. niestety na roadmapie nie widzę, aby apki miały się pojawić się w tych planach.

po co w Enterprise aplikacje SMB? dla zaspokojenia małych, lokalnych projektów. często niezależne grupy projektowe potrzebują tanich narzędzi. np. firma korzysta z SalesForce jako CRM ale pewien dział potrzebuje wewnętrznie zarządzać swoimi klientami. a więc czasem warto pomieszać planami…

eN

usuwane danych użytkownika z Office365

niby proste. ale jest 'ale’….

User

po usunięciu użytkownika – zostaje w śmietniq. to proste. czyli należy usunąć usera a potem go usunąć ze śmietnika

remove-MsolUser -UserPrincipalName user@w-files.pl

get-MsolUser -UserPrincipalName user@w-files.pl -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin

 

Exchange

teraz nie mogę znaleźć… ale jestem przekonany, że w artyqłach była informacja że po takim usunięciu wszystkie dane są również usuwane… ale tak nie jest! okazuje się, że skrzynka zostaje:

get-recipient user@w-files.pl -IncludeSoftDeletedRecipients

Name RecipientType
---- -------------
User, wufajls   UserMailbox

get-recipient user@w-files.pl -IncludeSoftDeletedRecipients | Remove-Mailbox -PermanentlyDelete

OneDrive

z OneDrive jest jeszcze dziwniej, bo po usunięciu użytkownika site nadal jest widoczny jako aktywny. jako dowód – po wykonaniu tego polecania, OD użytkownika nadal nie będzie na liście:

Get-SPODeletedSite -IncludeOnlyPersonalSite | FT url

natomiast wyświetlenie aktywnego site OD pokaże go:

Get-SPOSite -Identity https://w-files-my.sharepoint.com/personal/user_w-files_pl

Url Owner Storage Quota
--- ----- -------------
https://w-files-my.sharepoint.com/personal/user_wufajls_pl user@w-files.pl 1048576

opis algorytmu dla OD można zleźć w artykule na support.office.com. site jest widoczny i dostępny przez 7 dni po usunięciu użytkownika i dopiero potem trafia do śmietnika.

podsumowując

  • proste operacje 'pod spodem’ wcale niekoniecznie są takie proste.
  • każdy serwis żyje własnym życiem i ma własne zasady – office365 to nie jest pojedyncza usługa!
  • jeśli ktoś ma 'onpremową intuicję’ to należy się jej wyzbyć.
  • to wszystko to niby niuanse, ale bywają istotne – zwłaszcza jeśli trzeba odtworzyć konto w AAD oraz ze względu na aspekty bezpieczeństwa i dostępu do danych.

eN.