Skip to Content

IT nieuczesane.
category

Category: Cloud

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.

to się nie powinno zdarzyć… [combo]

takiego przypadq w-files nie miałem od dawna. od początq do końca – same zagwozdki. a zaczęło się tak…

objawy i pierwsza diagnoza

użytkownik zgłasza, że niektóre maile kierowane do niego, wysyłane są … na prywatną skrzynkę innej osoby. środowisko w hybrydzie exchange a cała sprawa zadziwia, bo zgłoszenie jest od użytkownika onprem.

po krótkim debugowaniu udaje się ustalić, że w AAD użytkownik ma wypełniony atrybut ‚otherMails’. czemu innego użytkownika to da się wytłumaczyć ale czemu Exchange wysyła maile korzystając z tego atrybutu?? czy to oznacza kompromitacją routingu Exchange? mocno niepokojące zachowanie..

schodzimy głębiej

po dalszym dochodzeniu udaje się ustalić kilka innych faktów. większość pominę, bo pomimo, że dały dużo pikanterii do sprawy, i mocno utrudniły całe dochodzenie wprowadzając w ślepe zaułki, sqpię się na najważniejszym. udało się ustalić, że to konto jest widziane jako ‚GuestMailUser’ przez Exchange lub ‚Guest’ w AAD. to już lepiej, ponieważ parę rzeczy da się wyjaśnić: Exchange używa właśnie atrybutu otherMails [który wbrew nazwie jest typu ‚string’ a nie tablicą] do wysyłki, a to oznacza, że pomimo iż sytuacja jest co najmniej dziwna, to nie jest kompromitacja całego tenanta. udało zawęzić się grupę zagrożonych użytkowników do kilqnastu osób.

no to impas: w onprem AD nie ma nigdzie informacji z adresem zewnętrznym, a w o365 nie da się go usunąć, ponieważ obiekt jest synchronizowany, więc zmiany autorytatywnie mogą pochodzić tylko z AD.

dla niektórych użytkowników udaje się skonwertować obiekt na ‚member’ poprzez „set-msoluser -userprincipalname <UPN> -userType member

ale po wyświetleniu pełnego obiektu AAD „get-AzureADUser -searchstring <UPN>|fl” okazuje się, że w atrybucie proxyaddresses cały czas siedzi adres #EXT#. czyli konwersja obiektu jest obejściem problemu, ale niedostatecznym rozwiązaniem.

jak do tego doszło?

no dobra. sytuacja opanowana, maile nie wyciekają. ale jak to się w ogóle mogło zdarzyć?

jak zwykle w takich przypadkach, nie da się tego na 1oo% potwierdzić, ale scenariusz był najprawdopodobniej taki:

  • był sobie tenant, który nie był w pełni zsynchronizowany
  • projekt rozpoczął się od testu SharePoint, gdzie jacyś użytkownicy bawili się, testowali, licho-wie-co jeszcze.
  • ponieważ tenant nie był w pełni zsynchronizowany, ba! zmieniane były UPNy użytkowników, ktoś wysłał zaproszenie do zasobu na SP. użytkownik przyjął to zaproszenie, ale zamiast się zalogować jako user tenanta, zalogował się jako zewnętrzny użytkownik, podając firmowy email. został więc utworzony obiekt Guest, z mailem odpowiadającym mailowi firmowemu
  • po uporządkowaniu UPNów i wymuszeniu synchronizacji część obiektów się nie zsynchronizowała. ktoś popoprawiał obiekty z błędem tak, żeby zadziałał soft-match. teoretycznie podczas takiej operacji, obiekt synchronizowany z onprem, powinien ‚nadpisać’ obiekt Guest i stać się Member. ale tak się nie stało…

co na to Microsoft i czy to się powtórzy?

sprawę oczywiście potwierdzałem ze wsparciem MS żeby mieć jakieś autorytatywne odpowiedzi. potwierdzili scenariusz jak do tego doszło, z zastrzeżeniem, że nie mają pełnych danych z tamtego okresu. sprawdzili jednak, że ktoś manipulował przy obiekcie zmuszając do spasowania z onpremowym.

kolejne zapewnienie jakie otrzymałem, to iż już jakiś czas temu wdrożony został patch, który chroni przed takimi sytuacjami – czyli w trakcie synchronizacji nie może w efekcie dojść do pozostawienia obiektu jako Guest. sytuacja jest tak trudna i ulotna, że nie podejmuję się weryfikacji.

mówiąc w skrócie: to się nie ma prawa powtórzyć.

grande finale

jedynym sensownym rozwiązaniem problemu jest usunięcie użytkowników z synchronizacji, wywalenie ze śmietnika i powtórna synchronizacja. drugim rozwiązaniem byłaby dalsza eskalacja we wsparciu tak, aby użytkownicy nie potracili dostępów [bo przecież ich konta zostaną usunięte i utworzone totalnie nowe obiekty], ale od razu zastrzegli, że to może nawet nie zostać zaakceptowane a na pewno długo potrwa.

no więc usunąłem z synchronizacji… ale na koniec czekała mnie jeszcze jedna niespodzianka. otóż nie byłem w stanie usunąć niektórych kont ze śmietnika. co ciekawe get-msolUser -ReturnDeletedUsers pokazywał, że są tam te obiekty.. ale przy próbie usunięcia wywalało błąd, że obiekt nie istnieje.

a więc na koniec ostatni w-files: po wyświetleniu atrybutów obiektu poza UserPrincipalName znalazłem SignInName. dla użytkowników, których nie udało się usunąć, różnił się on tym, że był zawiera lokalny prefix domenowy – czyli np. zamiast username@logincunion.com było username@logicunion.com.pl . tak wyglądały te obiekty przed wspomnianą wcześniej zmianą UPN, i jak widać gdzieś ta informacja utknęła. i pomimo, że remove-msolUser -RemoveFromRecycleBin ma parametr ‚-UserPrincipalName’ to de facto używa właśnie SignInName …

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.

Azure Stack GA

cloud computing australia

kilka luźnych myśli…

po pierwsze Azure Stack jest w GA i od przyszłego miesiąca można już zamawiać . oczywiście na liście 46 krajów Polski nie ma. dla tych, którzy jeszcze o Azure Stack nic nie wiedzą – jest to rozwiązanie Appliance, które można wstawić do własnej serwerowni, i korzystać z niego jak z Azure.. .którym w zasadzie jest. odwrócenie starej idei, gdzie firmy dzierżawiły kawałek publicznego Data Center aby mieć je do własnego użytkq. tutaj odwrotnie – wstawia się zabawki dostawcy do własnej serwerowni. ale rozlicza się nadal tak, jak Azure – czyli nie jest to zastępstwo dla Azure Packa, czy dobrze wdrożonego System Center. pomysł zaiste ciekawy, niewątpliwie organizacje, które z powodów wydajnościowych czy bezpieczeństwa chcą mieć dane u siebie, mogą teraz udomowić kawałek Azure (:

pełnej funkcjonalności nie ma, a część funkcji zawsze będzie potrzebowała sięgnąć gdzieś na zewnątrz, ale wiele dodatkowych scenariuszy to otwiera.

najciekawszy art jaki znalazłem dot. dostępności Azure Stack jest analizą rynkową. zabawne jest, że po kilq latach całego zamieszania wokół chmury, nadal powinno się zaczynać od ‚swojej definicji’ chmury. w podlinkowanym arcie pada cytat, że według AWS ‚chmura’ oznacza zawsze i tylko ‚chmurę publiczną’, zastanawiały mnie też małe liczby stojące za przychodami Microsoft ‚z chmury’ co wyjaśniło się w arcie na CNBC, z którego wynika, że Office 365 jest chmurą .. .i nie jest równocześnie O_o . efekt jest taki, że pierwszy art zdaje pytanie czy MS będzie w stanie doścignąć niedościgniony AWS [wartość 14,6 mld USD], w drugim widać, że ‚jeśli liczyć chmurę MS [wartość 6,8 mld USD] razem z Office 365 to wartość będzie 15,2 mld USD’. huh.

podobnie się czułem na prezentacji Archona na  Sysops/Devops gdzie przez pierwsze pół godziny nie byłem pewien o czym mówi… a chodziło to, że moje rozumienie chmury – bardziej PaaS i SaaS, rozmija się z projektami, o których mówił, gdzie aplikacje są budowane bardziej IaaS+docker. to była dobra lekcja (:

podsumowując – mówisz o chmurze, zacznij od kontekstu, czyli co przez to rozumiesz.

a na koniec trochę o ‚Project Olympus‚. jakoś do tej pory nie miałem okazji się z tym zderzyć a temat ciekawy. i znów pokazuje jak to świat stanął na głowie… to jest Open Compute Project – open source’owy projekt architektury data center, gdzie MS jest jednym z największych [największym?] kontrybutorem. i podczas gdy AWS, cytując z podlinkowanego artu:

We run our own custom-made routers, made to our specifications, and we have our own protocol-development team. It was cost that caused us to head down our own path, and though there’s a big cost (improvement)… the biggest gain is in reliability.

…w tym czasie MS staje się coraz bardziej integralną częścią open sourcowego świata, zarówno na poziomie dostosowywania swoich produktów do otwartych standardów, samego kodu źródłowego Linux i wielu aplikacji działających na tej platformie, aż po otwarte standardy hardware.

jest ciekawie.

eN.

 

kto ma licencję?

scenariusz

podczas migracji w hybrydzie jest taki dziwny moment, kiedy userzy są zawieszeni w dwóch środowiskach – onprem i online. skrzynki jeszcze onprem i czekają na swoją kolejkę do przerzucenia, ale już mają być włączone pozostałe usługi. zatem trzeba przypisać userom licencję z wyłączonym service planem dla Exchange Online – inaczej user będzie miał zdublowaną skrzynkę i część poczty nie będzie dochodzić [znaczy będzie, tylko nie do tej skrzynki co trzeba]. po jakimś czasie skrzynkę się migruje i włącza service plan dla usera. jest okres 3o dni ‚grace period’ kiedy wszystkie usługi – czy to Skype fB czy Exchange – działają bez licencji, m.in. po to, żeby bez względu na czas migracji był okres przejściowy na zrobienie porządq.

może się więc zdarzyć, że ktoś przez przypadek nie będzie miał włączonego service planu i po 3o dniach straci dostęp do mailboxa. np. wywalił się skrypt, albo ktoś zapomniał przy jakiejś fali migracyjnej to zrobić… whatsoever.

zarządzanie licencjami póki co jest niewygodne – z niecierpliwością czekam na zarządzanie licencjami prze grupy – a na razie, to właśnie zarządzanie licencjami jest sporą niedogodnością. konstrukcja obiektów licencyjnych jest dość nieprzyjemna, moduły MSOnline i AzureAD totalnie się różnią, co oznacza całkowite przepisanie starych skryptów [albo używanie v1 – póki co nie zapowiadają, że zostanie wyłączona], łącznie z logiką….

kto nie ma licencji?

.. to aqrat mega proste…

  • połączyć się do Exchange Online

  • połączyć się do AzureAD v2 [można i v1 – ale kod jest dla v2, trzeba mieć moduł AzureAD]

  • i sam kod

czego powyższa linijka nie wychwyci?

  • ktoś może mieć licencję, ale nie włączony service plan dla ExOL
  • ktoś może mieć licencję… np. na Project Online. i się nie wyświetli
  • skrzynki współdzielone nie potrzebują licencji

wyłączony service plan

a tu się zaczynają schody, bo trzeba zajrzeć do środka licencji. poniższy kod *nie jest skryptem* – to PoC, niechlujnie naskrobany na kolanie:

co jest źle w powyższym kodzie?

  • sprawdzany service plan jest dla licencji E3 – trzeba sprawdzić jak się nazywają service plany i obsłużyć różne typy licencji. tutaj robocze założenie, że wszyscy mają taką samą licencję… i że jest to licencja w ogóle zawierająca Ex
  • wykorzystywanie ‚write-host’ jako output jest dopuszczalne w roboczych sytuacjach, na szybko, ale jest bardzo złym zwyczajem w skryptach – trudno to potem obsłużyć, rozszerzyć, cokolwiek…

eN.

 

Send As w środowisq hybrydowym

scenariusz

przenosiny do o365 – codzienność. Hybryda Exchange – codzienność. teraz jak zaplanować migrację kont? alfabetycznie? a może lokalizacjami?

największym ogranicznikiem są uprawnienia dla skrzynek. w sfederowanej rzeczywistości nie wszystko jest przechodnie – uprawnienia nadane dla Exchange OnPrem niekoniecznie działają dla userów OnLine i vice-versa. oficjalny guide jest tu: https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx . dla tego podstawowym wyznacznikiem powinny być skrzynki współdzielone, które powinny być przenoszone grupami -> skrzynka + wszyscy którzy mają do niej dostęp.

co do samego artu – pierwszą rzeczą, na którą warto zwrócić uwagę jest to, że dotyczy on wersji Exchange 2o13 i 2o16. niewprost jest zatem informacja, że Exchange 2o1o jest niewspierany. oficjalnie. ale nieoficjalnie działa tak samo – nie przetestowałem 1oo% przypadqw ale różnic nie widzę.

jest jednak ciekawe zdanie, na którym bym chciał się sqpić:

We don’t, however, support the use of the Send-As, Receive-As, or Send on behalf of mailbox permissions in hybrid deployments between on-premises Exchange and Office 365 organizations

z moich doświadczeń wynika, że jak najbardziej da się nadać SendAs dla dowolnej skrzynki. cały ambaras tkwi w tym, żeby uprawnienie nadać po dobrej stronie – tego DLA kogo są uprawnienia. zaraz pokaże na przykładzie.

jak to zrobić?

z tymi uprawnieniami to jest generalnie trochę namieszane – są aż 3 różne mechanizmy działając na różnych poziomach i do każdego jest inne polecenie. jest jak jest, i stało się tak, że jedna skrzynka jest lokalnie, druga zdalnie. co można zrobić?

środowisko:

  • testuser@w-files.pl jest na Ex 2o1o onprem
  • manager@w-files.pl jest zmigrowany do o365

przykładowe nadanie uprawnień dla skrzynki będzie wyglądało tak:

  • nadanie uprawnień Full Access, bo granularne nie działają. to uprawnienie działa na poziomie folderów w mailboxie.

  • nadanie Send on Behalf. to uprawnienie zapisywane jest dla mailboxa.

  • i na koniec uprawnienie Send As. to uprawnienie jest na poziomie obiektu Active Directory ponieważ wiąże się z delegacją uprawnienia. nie do końca rozumiem jak ten mechanizm jest obsługiwany przez Exchange, ale niewątpliwie informacja jest zapisywana dla obiektu AD. i tu jest clue dla działania SendAs dla hybrydy – ponieważ są dwa AD – OnPrem oraz OnLine, to najlepiej wykonać polecenie w obu, a na pewno musi być wykonane w AD, w którym jest obiekt korzystający z niego:

podsumowanie

no i działa.  a miało nie działać q:

eN.

 

 

Microsoft Teams – złe strony medalu

Problemy w MS Teams

ponieważ podzieliłem się ogólną oceną Teams, jak na członka Loży Szyderców przystało, czas podzielić się spostrzeżeniami, których raczej nie znajdzie się oficjalnych materiałach.

najciekawszy artyqł dotyczący słabości Teams znalazłem na Petri. poza opisywanymi komplikacjami związanymi z faktem, że nie do końca wiadomo gdzie tak na prawdę dane Teams, największym wynikającym z tego problemem jest fakt, że nie bardzo wiadomo jak tworzyć kopię zapasową danych, a zarazem bardzo łatwo je usunąć, nieomal przez przypadek.

usunięcie grupy o365

usunięcie jest stałe i nie ma tzw. ‚soft delete’ pozwalające na szybkie przywrócenie. jak może dojść do usunięcia całego projektu? otóż Teams oparte jest [m.in.] na mechanizmie Office 365 Groups. o365G są współdzielone z innymi aplikacjami – np. Planner. czyli jedna grupa jest podstawą dla wielu innych aplikacji. o obu tych rozwiązaniach – o365 Groups oraz Planner napiszę pewnie więcej w przyszłości ale teraz ciekawy, acz straszny scenariusz:

tworząc nowy zespół w Teams automatycznie tworzone jest wiele innych elementów: grupa o365, site SharePoint, plan w Planner i kilka innych elementów. Teams spina to w całość. plan można podpiąć w Teams jako zakładka albo wejść bezpośrednio przez aplikację Planner. no i załóżmy, że zrealizowaliśmy już zadanie w Plannerze i chcemy je usunąć wraz z taskami. robi się to klikając w trzykropek -> Edit Plan -> delete Plan… i tu zaczyna się ciekawie.

pomimo opisu ‚Delete Plan’ osoba, która się nie wczyta w treść ostrzeżenia dokona potwornej rzezi, usuwając grupę o365, a wraz z nią wszystko – Teams, doqmenty, portal SP i tak dalej… a ponieważ nie ma soft-delete ani kopii zapasowej… robi się bardzo smutno.

można powiedzieć, że o grupy o365 należy dbać jak o własne oko.

wiele planów

o ile z poziomu aplikacji Planner można założyć tylko jeden plan per grupa, o tyle z Teams można założyć kilka planówi – jako zakładki – czyli do jednej grupy będzie dowiązane wiele planów…. z tą drobną niedogodnością, że nie są one dostępne z poziomu Plannera. nie działają linki przekierowujące, a jeśli usunie się zakładkę, to pozostanie osierocony plan.

czyli – jeden zespół, jedno zadanie do zaplanowania…

synchronizacja grup

jakoś to jest dziwnie skonstruowane – jeśli założy się zespół, to grupa o365 widoczna jest natychmiast w panelu office365. ale jeśli założy się, lub zmodyfiqje grupę z poziomu panelu o365, to zmiana synchronizowana jest… do 24h [SIC!].

jest to ponoć w trakcie przeróbek i zachowanie powinno zmienić się w najbliższych miesiącach.

Skype

kolejnym problemem, a może w tym przypadku – ‚utrudnieniem’ – jest inkorporowanie usługi Skype for Business, nie korzystając ze standardowych bibliotek. to bardzo dziwny wynalazek, krytykowany również przez sam team odpowiedzialny za SfB w MS. wszystkie konwersacje prowadzone w ramach Teams nie są widoczne nigdzie w SfB ani zachowywane w mailbox, również Presence jest oddzielnym bytem. całe rozwiązanie działa rozłącznie z ‚lokalnym’ SfB i powoduje to sporo niejasności.

dostępność

Teams wymaga licencji. szczęśliwie dostępny jest w większości licencji, więc wewnętrznie dla firmy może to nie być problem, niemniej np. w projekcie w którym uczestniczę, ze względu na dużą ilość użytkowników, migracja następuje krokowo, a licencje przypisywane są użytkownikom w kolejnych falach migracji. w takim scenariuszu, duża część użytkowników nie jest w stanie współuczestniczyć w projekcie.

większym i powszechniejszym problem jest brak wsparcia dla kont z poza organizacji – ten feature jest zapowiedziany, z tego plotek wiem, że ma się pojawić w ciągu 2-3 miesięcy. zobaczymy.

inne problemy i niedogodności

to oczywiście tylko główne przykłady. według mnie ważnym problemem jest również brak możliwości tworzenia skrótów do pliqw w ramach Teams. powoduje to, że przesunięcie pliq zamiast być jedną z podstawowych operacji staje się krytyczną, i zostawia uszkodzone linki lub duplikaty.

innym problem jest brak możliwości linkowania doqmentów z OneDrive. to z kolei zaburza podstawową ideę pracy na pojedynczej instancji pliq. czyli jeśli zaczęliśmy pracę nad plikiem w OD, to trzeba go dodać do Teams i na wszelki wypadek skasować, żeby nie utrzymywać dwóch kopii.

ale i tak jest super

podobnych niedogodności zalazłem jeszcze kilka, właśnie w ramach obsługi pliqw i uprawnień. niemniej jeśli się wie co omijać – nie są to jakieś straszne problemy. biorąc pod uwagę szybkość rozwoju aplikacji o365 można spodziewać się, ze niniejszy wpis będzie stawał się nieaktualny i wkrótce będzie można o nim zapomnieć.

eN.

Microsoft Teams

razem

Microsoft Teams to najmłodsze dziecko Office365 – GA ledwie 4 miesiące temu. zgodnie z nazwą, jest to narzędzie ułatwiające pracę grupową. od lutego uczestniczę w projekcie wdrożenia Office365, w którym postanowiliśmy wykorzystać to narzędzie i sprawdzić co to jest w ogóle warte… i muszę przyznać, że Teams są REWELACYJNE.

jeszcze w lutym Kamil opowiadał o Teams ogólnie, na WGUiSW i trochę się podśmiewaliśmy, że kolejne niepotrzebne narzędzie – wystarczy już szmatławego Yammera, kulejącego SharePoint, przestarzałej poczty, i niedorobionego Skype for Business – po co kolejny tool, który nie daje w zasadzie nic nowego?

może stwierdzenie ‚nie potrafię sobie wyobrazić pracy bez MS Teams’ jest na tą chwilę przesadą, ale potrafię sobie wyobrazić projekty, gdzie staje się jedynym wykorzystywanym narzędziem komunikacji. ma olbrzymi potencjał i należy się z nim koniecznie zaznajomić. ma oczywiście wady – jak każda wczesna [i późna zresztą też (; ] wersja aplikacji, ale nie zamierzam się na początq sqpiać na złych stronach. zatem…

…czym MS Teams są, a czym nie są

w zasadzie, żeby zacząć od początq, powinienem opisać ‚Office365 groups’… ale nie skleja mi się to, zacznę zatem w typowy dla mnie sposób – gdzieś od środka.

jedną z największych bolączek we wszystkich projektach/firmach jest Poczta Elektroniczna aka e-Mail, wykorzystywana do wszystkiego. gdyby nie limity na wielkości załączniqw, to programy do obróbki video musiałyby obsługiwać serwery poczty jako storage. efekt jest taki, że każdy plik, nad którym się pracuje, kopiowany jest do wielu osób. te wprowadzają poprawki, odsyłają, tworząc kolejne wersje i kopie pliqw. wyszukiwanie aktualnej wersji, komentarzy do treści czy zmian, to masakra.

rozwiązaniem na te bolączki, już dawno temu, miał stać się SharePoint. miał to być prosty, intuicyjny CMS z bibliotekami pozwalający na współdzielenie różnego typu obiektów [pliki, kalendarze, kontakty, wiki etc] i co ważne – automatycznym wersjonowaniem. opis niemal ‚jak ulał’ pasuje do MS Teams… jaka jest zatem różnica? SharePoint owszem, daje wszystkie te możliwości techniczne, ale z pominięciem pierwszej części – ‚prosty i intuicyjny’. samo korzystanie z SP jest co najmniej nieprzyjemne, no i ten cholerny klient do synchronizacji bibliotek… niby jest NGSC a do dnia dzisiejszego sprawia problemy i nie wspiera bibliotek z ewidencjonowaniem. ile to już lat? 16! [SIC!] Microsoft strzelił sobie w kolano, nie potrafiąc przez tyle lat zrobić prostego narzędzia ułatwiającego korzystanie z bibliotek SP.

…aż pojawiły się MS Teams. to jest prosty, intuicyjny front-end, łączący w jednym miejscu wiele aplikacji Office 365 [i nie tylko] – SharePoint, o365 groups, Planner, SfB, Office WebApps i więcej. efektem jest przestrzeń do pracy grupowej, funkcjonująca w intuicyjny, ‚naturalny’ sposób. pojawiło się już tyle wideo prezentujących Teams, że nie jestem pewien czy jest sens pisać kolejną ‚instrukcję obsługi’ ale kilka słów od siebie dodam.

  • kolejne dwa problemy przy projektach – rzadko kiedy wszyscy wiedzą kto zajmuje się czym – zawsze są dziury, choćby z tego powodu, że pojawia się nowe, nietypowe zadanie i ‚kto to ma zrobić’. efektów jest wiele – od problemów ze znalezieniem właściciela akcji, po masy spamu projektowego, gdzie maile wysyła się do kilqnastu czy nawet kilqdziesięciu osób, tak na wszelki wypadek żeby dotarło. czasem okazuje się, że w nagłówq i tak zabrakło tej kluczowej postaci, a pozostali są wqrzeni, że dzień-w-dzień przychodzi masa informacji, która ich nie dotyczy. prosty mechanizm kanałów tematycznych, które może założyć każdy z członków, pozwala na wprowadzenie porządq. jednocześnie informacja pozostaje dostępna dla wszystkich, dzięki czemu może być łatwiej dostrzeżona, przekierowana i obsłużona

  • podczas dysqji pojawia się potrzeba dodania pliq [lub odwrotnie – pojawia się plik wymagający dysqsji] – wystarczy go dodać… i zacząć razem pracować. w trakcie edycji pliq [korzystając wersji Office Web], cały czas widać kontekstowy dialog. niby drobiazg – ale w końcu nie muszę przegrzebywać się przez stosy wątqw dotyczących tego samego pliq, w różnych wersjach! w jednym miejscu mam plik, oraz całą dysqsję, która go dotyczy.

  • w ramach kanału są różne potrzeby – planowanie/logistyka, materiały video, Knowlege Base… – i wszystkie te materiały można po prostu podczepić jako kolejna zakładka dla kanału. kolejne ‚niby nic’ – ale dzięki temu nie muszę trzymać oddzielnie bookmarków do różnych materiałów, w różnych aplikacjach. w prosty sposób możemy udostępniać je wszystkim, i do tego kontekstowo – co nie jest bez znaczenia. przykład z życia – w ramach jednego z wątqw projektowych, który mnie nie dotyczy, utworzony jest mały site SP, na którym coś tam sobie wymieniają z zewnętrznymi vendorami. generalnie mnie to nie interesuje, ale musiałem coś szybko zweryfikować. wyszukanie ‚jakiegoś’ URLa w mailach sprzed kilq miesięcy, wysłanych przez ‚jakąś’ osobę, to mówiąc delikatnie ‚strata czasu’. kończyło się zazwyczaj kolejnym mailem z pytaniem ‚czy ktoś widział, czy ktoś zna’. teraz po prostu wchodzę na kanał danej grupy, a strona jest podczepiona jako zakładka. poniżej przykład, gdzie na kanale ogólnym wisi mała aplikacja zrobiona na SP do zgłaszania i obsługi problemów w ramach projektu

  • proste mechanizmy, dzięki którym projekt nie jest tysiącem puzzli, porozrzucanych po rożnych aplikacjach, a każdy z członków widzi inne elementy układanki. w końcu jest zorganizowany w ramach jednej przestrzeni [workspace], i każda nowa osoba dołączająca do projektu w naturalny sposób ma dostęp do całości, w zorganizowany sposób, zamiast musieć odtwarzać całość.

podsumowując

dawno nie byłem tak hmmm… podekscytowany żadnym gadżetem czy apką [Polacy raczej się nie ‚get excited about’, ale o dziwo tym razem, to słowo pasuje]. a zatem to pierwszy i na pewno nie ostatni wpis w tym temacie. aplikacja ma potencjał, ale bez wiedzy o jej wadach i problemach można zrobić srogą krzywdę całemu projektowi, niemal przez przypadek.

na koniec jeszcze jedna drobna dygresja dotycząca oczywistej oczywistości – że choćby nie wiem jakie narzędzia i jak intuicyjne dostarczyć, trzeba chęci nauczenia się pracy nimi/z nimi. niejednokrotnie zdarzyło mi się pracować w projekcie, gdzie SP był podstawą pracy grupowej, współdzielenia doqmentów, w projekcie oczywiście wykwalifikowani i wielokrotnie certyfikowani inżynierowie… a tam w bibliotece pliki typu:

  • Projekt XYZ_v1.o.docx
  • Projekt XYZ_v1.2.docx
  • Projekt XYZ_v2.o.docx

…przyzwyczajenia prawdziwą naturą człowieka…

eN.

Teams i grupy o365

taka drobna ciekawostka… większość aplikacji o365 opiera się na ‚Office 365 groups‚. ciekawe jest to, że zależnie od aplikacji to nie zawsze jest dokładnie ta sama grupa, a raczej zawartość jest synchronizowana do kopii grupy dla aplikacji. podobnie jak grupa w AD onprem jest synchronizowana do grupy AAD w o365.

efekt jest dość zaskaqjący. jeśli manipuluje się przynależnością do Teamu w Teamsach, z poziomu aplikacji, jako właściciel danego Teamu/grupy, to zamiany są odzwierciedlane natychmiast. ale jeśli dokonuje się manipulacji na grupie od strony office 365 [np. dodanie/usunięcie członka], jako administrator, to zmiany w Teams zostaną zsynchronizowane… w ciągu 24h [SIC!]. jest to trochę dziwne. np. w tym samym czasie SharePoint widział zmianę od razu.

dwa wnioski:

  • lepiej unikać zarządzania administracyjnego – lepiej zostawić to właścicielom Teamów
  • trzeba pamiętać, że ‚sowy nie są tym czym się wydają’

eN.

URI PowerShell dla Skype Online

PowerShell zarówno dla Exchange jak Skype Online dostępny jest poprzez stworzenie sesji WinRM i zaimportowanie zdalnych komend. prosta komenda połączenia do SkypeOL to po prostu:

…ale ja jakoś od zawsze trafiam w nietypowe przypadki [środowiska] i połączyć się nie mogłem, ponieważ DNS nie wskazuje jeszcze na środowisko, do którego się chcę połączyć. po przeczesaniu internetów wszędzie trafiałem na ‚pomoc’ aby dopisać parametr -OverrideAdminDomain “my.domain.365” . bezwartościowa, ponieważ tak jak pisałem, DNS nie jest jeszcze skonfigurowany. ale jest jeszcze jeden parametr, tym razem bardziej pomocny: -OverridePowershellUri . tylko to URI trzeba znać.

trzeba odpalić przeglądarkę na jakimś komputerze z DNS ustawionym na zewnątrz i wpisać: https://sched.lync.com . po uwierzytelnieniu zostaniemy przekierowani na URI dla naszego tenanta np: „https://webdir1f.online.lync.com/Scheduler/?AuthCookieName=RtcAuth” . dla PS będzie to: „https://webdir1f.online.lync.com/OcsPowershellLiveId”.

trochę wchodzenie przez komin, ale czasem trzeba pokombinować (; jak ktoś zna prostszy sposób to się proszę pochwalić.

eN.