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