Skip to Content

IT nieuczesane.
category

Category: office365

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.

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

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.

 

 

 

 

czy OneDrive ma skanowanie antywirusowe?

krótko – tak, ma. zarówno OD jak i SP. tutaj można znaleźć kilka szczegółów.

to, co jest dodatkowo ciekawe, to kwestie prywatności… skoro działa skaner antywirusowy, to znaczy że eMeS może zajrzeć do zawartości pliqw? w zasadzie to indexer też działa – przecież jest search, który dokładnie to robi – skanuje [‚zagląda’] do pliqw po to, żeby pomóc je wyszukiwać.

poza politykami prywatności i zapewnieniami ze strony Microsoft, że żaden pracownik nie ma wglądu w treści klientów bez ich wiedzy i zgody, nie udało mi się znaleźć technicznego ‚dowodu’ że tak faktycznie jest. w końcu usługi działają w zupełnie innym kontekście. pozostaje zaufanie, poparte również tym, że jeśli choćby jeden taki przypadek wyciekł publicznie, odbyłby się globalny lincz i utrata zaufania.

eN.

Fixes and Workarounds

coś, co warto sobie dodać do bookmarków – Fixes or workarounds for recent Office issues. na tej stronie znajdują się aktualne informacje dotyczące znanych błędów wraz z rozwiązaniami. w moim przypadq – nagle przestało mi działać uwierzytelnienie ADAL/MFA w outlook. w części windows/outlook/other issues można znaleźć, że ostatni fix coś uszkodził i na razie obejściem jest wyłączenie ADAL. albo poczekanie na fixa do fixa (;

Unable to create second profile with different account on ADAL enabled tenant. [WORKAROUND]

Last Updated: February 7, 2018

ISSUE

When you try to configure a secondary account from the same Office 365 tenant in Outlook 2016 (Current Channel) with ADAL enabled, you receive the following error: „An encrypted connection to your mail server is not available. Click Next to attempt using an unencrypted connection.”

STATUS: WORKAROUND

To workaround this issue, you can disable ADAL on the client. To do this, follow these steps to Disable modern authentication on devices.

**********

warto mieć link pod ręką!

eN.

współdzielenie OneDrive – ciekawostki

OneDrive Sharing

na początek oczywiste oczywistości:

  • OneDrive to de facto SharePoint. główne ustawienia współdzielenia [Sharing] dziedziczy z globalnych ustawień SP
  • od jakiegoś czasu dostępny jest OneDrive Admin Center z poziomu Office365. z jego poziomu można pozornie ustawić zabezpieczenie współdzielenia na poziomie niższym, niż jest zdefiniowany w SharePoint. ale nie można [co zresztą jest opisane małym druczkiem na dole].

  • od niedawna rozbudowany został klient OneDrive – w końcu można nadawać uprawnienia ‚bezpośrednio’ z Exploratora. co mnie pozytywnie zaskoczyło – okienko uprawnień jest renderowane przez OneDrive.exe a nie, tak jak się spodziewałem, iexplore.exe/edge .

Jak powstaje ACE dla osoby z zewnątrz

i tu się zaczyna robić ciekawie. standardowo, do czego przyzwyczaiły nas systemy operacyjne, flow jest taki:

  • użytkownik wybiera plik i nadaje uprawnienia
  • tworzony jest ACE – Access Control Entry – który staje się nieodłączną częścią pliq… w dużym uogólnieniu.
  • osoba próbuje się dostać
    • uwierzytelnia się
    • token uwierzytelniony porównywany jest z ACL [Access Control List] w poszukiwaniu ACE dla danego usera – rodzaj filtra
  • osoba dostaje dostęp lub nie.

wydaje się tak oczywiste… a jednak dla pliq współdzielonego z osobą z zewnątrz w OneDrive, jest inaczej. czy zastanawiałeś się po co jest poniższa opcja? skoro można uzyskać dostęp przez osobę inną niż zaproszona, to znaczy, że ACE nie może istnieć w momencie dostępu. zakładając, że wyłączone są linki anonimowe, w dużym uogólnieniu wygląda to tak:

  • użytkownik wybiera plik, uprawnienia edit/view i adres osoby z zewnątrz.
  • tworzony jest *link*, URL, zawierający token dostępu. ten link wysyłany jest mailem.
  • osoba, która otrzymała link otwiera go. zakładając, że wymuszone jest uwierzytelnienie, zostanie przekierowana na stronę logowania.
  • po pozytywnym uwierzytelnieniu, na podstawie linka generowane jest ACE, które dopiero teraz dopisywane jest do pliq
  • tworzone jest również konto [jeśli nie było wcześniej] „username_server.name#EXT#@company.onmicrosoft.com” w AAD

czemu tak i jakie to ma konsekwencje

opisywane zachowanie będzie zależne od kilq ustawień bezpieczeństwa na SP – czy włączone są linki anonimowe, oraz czy mogą być otwierane przez osoby inne, niż te, do których się je oryginalnie wysłało. współdzielenie linkiem jest znane od lat, i dość oczywiste, dla osób korzystających z usług chmurowych. po prostu w rozproszonym świecie chmury, gdzie nie ma centralnej bazy użytkowników, token jest przekazywany wraz z linkiem – w dużym skrócie posiadanie linka oznacza posiadanie dostępu. stąd powstały mechanizmy rozszerzające to rozwiązanie – np. o wymaganie uwierzytelnienia. czemu zatem link wysłany przez jedną osobę, standardowo może być otworzony przez inną? ta opcja została stworzona głównie z tego powodu, że ludzie korzystają z masy adresów, i mogą mieć konto MS Account założone z innym adresem niż my znamy – np. wysyłamy do kogoś na x@gmail.com a ktoś ma konto MS Account jako x@outlook.com. dzięki temu osoba nie jest zmuszona zakładać kolejnego konta, co było istotne zwłaszcza jakiś czas temu, kiedy nie istniał uproszony proces zakładania konta, i było to bardzo upierdliwe. ale ze względu na bezpieczeństwo, nie włączenie tej opcji, jest dość niepokojącym scenariuszem i sugerowałbym jednak, aby wymuszać weryfikację odbiorcy. w takim wypadq, nawet jeśli przekaże się linka innej osobie [lub zostanie wykradziony!], nie zostanie on obsłużony. można się przyczepić, że komunikat błędu pokazuje zdekodowany adres email osoby, która oryginalnie była w tokenie, ale nie jest to już tak wielki problem.  załóżmy, że opcja jest na ‚default’, czyli może być otwarty przez inną osobę. co się stanie, jeśli roześlę link do stu osób? czy wszystkie będą miały dostęp? NIE. link zawiera ‚token jednorazowego dostępu’. pierwsza osoba się dostanie i dla niej utworzony zostanie ACE, pozostałe osoby dostaną acc denied.

ciekawostki (bugs?)

nie może obyć się bez zagadek w-files. trafiłem na dwie. w porywach do trzech q:

  1. jeśli jakiś user ma wpisany alternate email z jakimś adresem zewnętrznym – np. x@gmail.com, i chcemy udostępnić plik tej osoby na tenże adres zewnętrzny… to się nie uda. AAD rozpoznaje użytkownika jako wewnętrznego i co prawda wysyła linka [zależnie od tego z jakiego interfejsu skorzystamy zachowanie może być różne], ale nie ma szansy zalogować się na kontem x@gmail.com .
  2. jak sądzicie, czy usunięcie konta #EXT# z AAD spowoduje, że osoba straci dostęp do pliq? scenariusz:
  • administrator doszedł do wniosq, że posprząta trochę, i *dla bezpieczeństwa* usunie konta #EXT# żeby zabrać dostępy.

no to się zdziwi, ponieważ usunięcie konta, nie powoduje usunięcia ACE – te systemy są rozdzielne, i nie ma ‚centralnego repozytorium dostępów’. a ponieważ centrum uwierzytelnienia jest również rozłączne z naszym systemem, user zostanie poprawnie uwierzytelniony [przez Microsoft Account a nie przez nasz tenant AAD], ACE istnieje – ergo dostęp będzie. nie wierzycie – spróbujcie, podzielcie się wrażeniami. właśnie ta część pracy – odpowiedź na pytanie ‚kto ma gdzie dostęp’ – jest nadal niełatwym zadaniem. 3. PS. czy zwróciliście uwagę, że w OneDrive for Business jest ‚shared with me‚ a w OneDrive personal jest ‚Shared by me‚? i żadne ze środowisk nie udostępnia mechanizmu dla pełnego rozeznania się co komu i dla nas….  

OneDrive for Business OneDrive personal

eN.

‚Gorący ziemniak’ – Skype for Business

Disjoint Communications

usługi komunikacyjne dostarczane przez MS zawsze były w dużym dysonansie – z jednej strony całe linie hardware, integracja z komputerem – pełny VoIP i Video Conferencing… na ulotkach. z drugiej… masakra – kto konfigurował OCS czy Lync wie o co chodzi. masakryczny end-user experience z brakiem historii wiadomości w ramach klienta, kłopotami z synchronizacją książki adresowej czy kalendarza, ciężka konfiguracja sieciowa i integracja – zarówno z Exchange jak i centralkami VoIP. Unified Communication było świetną ideą, i nawet w kilq firmach widziałem to dobrze wdrożone i nieźle działające. ale praca przy projektach UC – huh. kamieniołomy. powoli, wraz z pojawieniem się Skype for Business, zaczynało to w miarę sensownie działać a SfB Online wszystko uprościł. ale oczywiście usługi SaaS nie są dla każdego…

Unified Intelligent Communication

aż tu nagle pojawia się Teams. niby narzędzie zupełnie nie związane, ale z jakiegoś powodu decydują się inkorporować SfB w Teams… przepisując kod. raczej korzysta się z gotowców i aplikacje wykorzystują wzajemnie swoje możliwości – te same biblioteki, czy DCOM, żeby nie pisać dwa razy tego samego. to było dość dziwne. efekt dość qriozalny – niby w Teams jest SfB ale wiadomości są zupełnie rozdzielne – wysłane w ramach Teams są tylko w Teams, wysłane via SfB są tylko w .. skrzynce Exchange. od jakiegoś czasu chodziła plotka, że Teams przejmie tą funkcjonalność, ale trochę nie chciało mi się wierzyć… aż tu takie newsy:

wygląda to na niezłą rewolucję w grupach projektowych…

jest kilka takich produktów, które przeszły ciężką drogę w ramach MS, niektóre jej nie przeżyły – jak rodzina ‚forefront’, do której zaadoptowany został MIIS stając się na chwilę FIMem, żeby przetrwać jako jeden z nielicznych jako MIM. to chyba na razie rekordzista w ilości nazw produktowych [MMS -> MIIS -> ILM -> FIM -> MIM]. usługi VoIP/Video zdają się doganiać [LCS -> OCS -> Lync -> SfB -?Teams?].

ciekaw jestem jak to będzie wyglądało? jeśli nie będzie ‚cienkiego klienta’ – cienkiego w porównaniu do Teams, które przecież mają dużo szersze zastosowanie – to usługi takie jak ‚presence’ czy IM będą mało wygodne. w sumie ‚presence’ jest w dowolnym miejscu – czy to outlook, czy SharePoint. a IM? zostanie przerzucone do Teams czy do Outlook? huh. decyzja biznesowo wyjaśnialna, ale dla firm i dla użytkownika końcowego, to będzie gruby bałagan. przestawienie się z ‚klienta IM i konferencji Video’ na ‚aplikację do pracy grupowej’ nie będzie proste…

…ale przecież nie tak dawno pisałem, że wyobrażam sobie, żeby w projektach MS Teams stało się jedynym wykorzystywanym narzędziem. a zatem czekam na łzy grupy projektowej Exchange (;

gorący ziemniak

w sumie to mam więcej pozytywnych emocji o tej decyzji, bo mam wrażenie, że SfB, podobnie jak MIM, to takie gorące ziemniaki, które niby potrzebne, ale nikt ich nie chce i nie do końca wiadomo co z nimi zrobić, więc podrzuca się je do następnego w kolejce. sam produkt dostarcza bardzo fajną funkcjonalność, ale to za mało na samodzielność. więc są adoptowane tam, gdzie podąża w danym momencie trend – a teraz jest hype na Agile i Grupową Komunikację [znowu].

boję się tylko tego, że o ile MS Teams jest świetnym produktem do małych projektów i można go już semi-produkcyjnie używać, to jest masakrycznie niedojrzały. mam nadzieję, że transformacja potrwa wystarczająco długo i spokojnie, żeby zdążył stać się w pełni przemyślanym narzędziem, bo inaczej wyjdzie z tego olbrzymi ‚szwajcarski scyzoryk’ – niby super, z tysiącem gadżetów, ale kto chce nosić takie bydle w kieszeni?

eN.

eN.

%d bloggers like this: