Skip to Content

IT nieuczesane.
category

Category: Cloud

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:

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:

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:

lub

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’:

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:

i fragment kodu, który ustawia DTMF:

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:

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:

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.

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.

SSPR vs contact info

ciekawy case dotyczący uruchamiania Self-Service Password Reset (SSPR) i zarazem lekcja – workaround to nie solution q:

zgłosił się do mnie zapłakany klient, że uruchamiają SSPR i muszą jakoś dostarczyć dane użytkowników do portalu. do niedawna nie było to możliwe (uservoice z 2o18), ale od jakiegoś czasu Microsoft w swojej wielkości dostarczył… no właśnie, co dostarczył? obejście problemu opisane tutaj. ‚czemu obejście?’ zapyta ktoś, kto uważnie przestudiuje, sprawdzi i stwierdzi że działa…

…ano problem polega na tym, że informacje do SSPR brane są z atrybuty ‚StrongAuthenticationUserDetails’. ten atrybut ma kilka cech odróżniających go od zwykłego atrybutu np. ‚telephoneNumber’ a jednym z nich jest fakt… że nie wypełnia wizytówki użytkownika. jest niewidzialny.

i teraz taki myk…

tak wygląda użytkownik, który wszedł na portal i wypełnił sobie dane do MFA/SSPR:

i wyświetlmy sobie właściwości w AAD:

a teraz, za artykułem, prepopuluję (dziś super po polsq) atrybuty:

no i output takiej operacji:

co się dzieje dalej? hasło dla testuser02 resetuję i działa. kiedy próbuję dostać się do portalu o365, dostaję standardowe pytanie o uzupełnienie obligatoryjnych pól do zabezpieczenia konta (czyli te do MFA, które zapisują się w StrongAuthenticationUserDetails).

a więc to …’rozwiązanie’ nie działa dla MFA, jest obejściem dla SSPR, i dane ‚zabezpieczające’ stają się *publicznie* dostępne dla wszystkich w organizacji ROTFLMAO.

eN.

SkypeOnlinePowershell wywala się błędem o braku VC++ redistributable

exploruję tamat BOTów (super sprawa pod kontem obniżenia kosztów HelpDesk!) i aby zarejestrować BOTa w SfB dla tenanta trzeba zainstalować bohatera tytułowego – Skype for Business Online Connector. pomimo spełnienia wszystkich warunków (prerequisites), instalator wywala się z informacją, że brakuje VS C++ Redistributable. trochę się z tym pomęczyłem, nic nie udało mi się znaleźć na forach, więc trzeba grzebnąć samemu.

główny log nic powiedział, ale w logu *_TenantPowerShell.msi.txt jest coś takiego:

no to już blisko rozwiązania… bo wskazana ścieżka nie istnieje. znalazłem wpisy od innych paczek VS redist i na tej podstawie zrobiłem nowy plik reg do obecnej wersji:

instalator łyknął. gra i buczy (:

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

konsola EXO z MFA

PowerShell dla EXO to porażka, zwłaszcza z włączonym MFA. już sam fakt, że należy jej szukać w części ‚hybrid’ nie jest logicznie wyjaśnialny. podstawowym problemem jest jednak zaszyty hard-limit czasu sesji na 15 min. teoretycznie to czas bez aktywności (idle), ale zdarza mi się, że działający skrypt się sypie… najbardziej doqczliwe było jednak to, że za każdym razem trzeba się uwierzytelniać i przy każdym kolejnym połączeniu ponownie importowane są commandlety, a dodając do tego MFA… zaczyna się robić na prawdę nieprzyjemnie.

szukałem po forach i po doqmentach i miałem na prawdę dziwne pomysły jak to rozwiązać… aż w końcu znalazłem rozwiązanie. dodam, że trywialne.

jeśli uruchomi się po prostu ‚Connect-EXOPSSession’ … nie da się żyć. a wystarczy uruchomić z parametrem:

i owszem, sesja nadal jest zrywana po 15 min ale następuje automatyczne ponowne uwierzytelnienie, bez konieczności wpisywania hasła czy potwierdzania drugiego składnika. nie są również ponownie importowane commandlety. w skrócie – w końcu da się pracować.

być może to tak oczywiste, że nikt o tym nie pisze. być może to było wielką czcionką na ‚pierwszej stronie’. ale być może uratuję kogoś tym wpisem przed całkowitą utratą nerwów, czego byłem już kilka razy bliski przygotowując raporty z EXO.

eN.

Ribbon dies, long live the Ribbon!

zbliża się nowy wygląd dla Office365. czekam z nieciepliwością, bo nigdy się ze ‚wstążką’ nie polubiłem

source

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

 

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:

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:

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

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.

 

 

 

 

Ograniczenia Exchange Hybrid

[updated]

pomimo, że hybryda Exchange jest dość typowym scenariuszem i to raczej docelowym środowiskiem dla większości większych firm, to niestety niesie ze sobą sporo ograniczeń. zwłaszcza w okresie migracji może to stanowić spory problem.

poniżej zebrane – nie wiem, czy wszystkie. ograniczenia dotyczą dostępu do skrzynek pomiędzy środowiskami (cross-premise)

  • nie działa ‚automapping’ dla kont cross-premise. czyli jeśli osoba w chmurze ma dostęp do skrzynki współdzielonej onprem to musi dodać ją ręcznie we właściwościach – sama się nie zmapuje.
  • największe hece są z kalendarzami dla skrzynek cross-premise. po migracji traci się udostępnienie, a przy ponownym udostępnieniu nie widać detali. jednym z obejść problemów jakie znalazłem jest ponowne udostępnienie skrzynki.. ale z OWA. to nie wszystko! akceptacja też musi być z OWA. ciekawy opis tu.
  • bardziej ogólnie problem polega na tym, że nie wszystkie uprawnienia są obsługiwane dla scenariuszy cross-premise. zwłaszcza uprawnienia item-level. i chociaż na stronie jest informacja że ‚sand as’ nie działa, to da się to zrobić.
  • nie ma dostępu do skrzynek archiwalnych dla cross-premise
  • właściciele grup nie mogą zarządzać grupami dystrybucyjnymi z Outlook. jako obejście można stworzyć skrót do narzędzia systemowego.

znasz inne?

eN.