Skip to Content

IT nieuczesane.
category

Category: ExOnline

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.

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.

Exchange hybrid – niespójność informacji

ogólnie synchronizacja jest jednostronna – z onprem do online. obiektami środowiska hybrydowego najlepiej zarządza się z onprem, ponieważ w o365 są tylko do odczytu… ale są pewne wyjątki, powodujące niespójność. przykładem może być konwersja skrzynki User<>Shared.

od momentu, kiedy skrzynka jest już w ExOL, o statystyki czy operacje na skrzynce, trzeba sięgać bezpośrednio. o ile get-recipient można uruchomić również onprem, o tyle np. konwersję typu należy przeprowadzić w ExOL. dodajmy do tego fakt, że synchronizacja jest w jedną stronę i…

…po konwersji skrzynki, jeśli uruchomimy get-recipient lokalnie, to pokaże nam typ z przed konwersji. w efekcie, jeśli takie operacje są wykonywane często, statystyki będą przekłamywane. należy więc po dokonaniu konwersji ręcznie zmodyfikować atrybuty w AD tak, aby odpowiadały obecnemu stanowi. trzeba przy tym uważać, bo nazwy są bardzo podobne i łatwo je pomylić:

 SharedMailbox UserMailbox
msExchRemoteRecipientType 100 6
msExchRecipientTypeDetails 34359738368 2147483648
msExchRecipientDisplayType -2147483642 -2147483642

szczegółowy opis parametrów tutaj

przykładowy link do dalszej lektury: http://jetzemellema.blogspot.co.uk/2016/02/convert-user-mailbox-to-shared-in.html

eN.

user@tenant.onmicrosoft.com w hybrydzie

każdy obiekt użytkownika w o365 w hybrydzie ma standardowo zakładane dwa adresy email:

  • user@tenant.mail.onmicrosoft.com – który służy jako email routingowy. EXO jest de facto oddzielnym środowiskiem, oddzielną organizacją Exchange, a więc jeśli jest email user@w-files.pl, musi istnieć sposób na przesłanie maila do konkretnego serwera – wtedy wykorzystywany jest ten adres.
  • user@tenant.onmicrosoft.com – który jest tworzony na podstawie standardowej polityki adresowej EXO. czy użytkownik jest synchronizowany, czy założony bezpośrednio – jest nadal mailboxem i podlega polityce.

istnieją różne scenariusze, w których chcielibyśmy zmienić istniejący adres – np. chcemy go zwolnić tak, aby mógł być wykorzystany dla innego obiektu. ale….

w środowisq hybrydowym wszystkie zmiany muszą być zrobione w on-prem. próba dokonania adresu bezpośrednio w EXO skończy się Acc Denied. ale…

jeśli wykonamy polecenie

to zobaczymy adres routingowy user@tenant.mail.onmicrosoft.com ale nie będzie na liście adresu EXO /:

jak zatem go zmienić?

da się, ale wymaga nieco gimnastyki. skoro nie da się zmienić dla konta synchronizowanego to trzeba je uczynić na chwilę kontem lokalnym o365. a więc kroki są następujące:

  • przesunąć obiekt w on-prem AD do OU, które nie jest synchronizowane
  • wymusić/poczekać na synchronizację
  • konto w AAD zostanie usunięte wraz z mailboxem
  • odzyskać konto w AAD [np. restore-msolUser]
  • zmienić adres w EXO
  • przywrócić pierwotną lokalizację obiektu w AD
  • poczekać na synchronizację

jeśli konto zniknie przy pierwszym cyklu, może to wynikać z niepełnym sync w domenie on-prem. najlepiej wykonywać operacje na AD, z którego jest robiony sync do AAD.

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.

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.

 

 

nazwa katalogu ‚calendar’

exchange-logoniby trywialne… znalazłem kilka rozwiązań, ale żadne mi nie odpowiadało. to moje:

eN.

modern authentication – uwierzytelnienie do chmury

adalchmura zmienia wszystko. kto tego nie odczuł, to chyba przez ostatni rok był na wakacjach na Marsie. od długiego czasu Microsoft przepisuje wszystkie usługi na WS*, podstawą integracji Azure z onpremem jest ADFS, musi przyjść kolej i na protokoły uwierzytelnienia. stare, ‚LANowskie’, mają swoje wady przy wykorzystaniu w takiej integracji. odpowiedzią jest coś, co nazywa się ‚modern authentication’.

do czego służy? krótko – do pobrania tokenu z Azure AD, którym aplikacje będą mogły się posługiwać w celu uwierzytelnienia. efekt końcowy – natywne wsparcie dla MFA (MultiFactor Authentication) przez aplikacje oraz realizacja pełnego, przeźroczystego SSO dla aplikacji Azure.

nowość!(?)

modern authentication jest obecnie w fazie public preview – a więc w zasadzie go jeszcze nie ma. największy buzz zaczął się w listopadzie 2o15, kiedy pojawiała się nowa wersja biblioteki… ale co ciekawe, nowością nie jest. jeden z lepszych wpisów, wyjaśniających działanie biblioteki można znaleźć tutaj – datowane na sierpień 2o12… biblioteka, która odpowiedzialna jest za realizację logowania przeszła nazewniczne metamorfozy – AAL (Windows Azure Authentication Library), WAAL, a obecnie ADAL (Microsoft Azure Active Directory Authentication Library).

lista obecnie wspieranych cech i zakresu gotowości ADAL jest w poście z listopada, który wspominałem oraz na technecie. na razie więcej informacji developerskich – dość normalne dla produktu w tej fazie.

w praktyce

w praktyce potrafi skorzystać już z tego office2o16 (outlook, skype) oraz office2o13. przy czym w o16 ten typ uwierzytelnienia jest włączony standardowo, w o13 wymagane są poprawki (standardowe, więc jeśli ktoś dba o aktualizacje, to tą funkcjonalność ma) oraz włączenie funkcji w rejestrze.

to jednak nie wystarczy. podstawową zmianą jest włącznie obsługi modern authentication dla office365 – a konkretnie dla Exchange OL:

set-organizationconfig -oauth2clientprofileEnabled $true

po włączeniu, outlook i skype urzywają już MA zamiast basic authentication, co w praktyce przekłada się na niby błahą, ale istotną zmianę – nie ma już ramki z pytaniem o użytkownika i hasło, gdzie jedynym sposobem automatyzacji jest zaznaczenie opcji ‚save credentials’ i przechowywanie ich w credential managerze. teraz zmiany hasła są również przeźroczyste dla użytkownika końcowego.

eN.

Exchange – uprawnienia do kalendarzy zasobów

exchange-logoogólnie

prosty scenariusz: trzeba założyć zasób, reprezentujący samochód firmowy tak, aby ludzie mogli go sobie rezerwować. następnie chcemy aby wszyscy widzieli kto go wypożyczył i dokąd zabrał. standardowo większość informacji jest ukryta i widać tylko ogólny wpis.

w tym celu należy nadać uprawnienia do kalendarza nie jest trudno i jest sporo linków, które szybko wskażą, że można to zrobić poleceniem:

… ale:

  • po pierwsze to nie zawsze zadziała (w Polsce można uznać, że prawie nigdy)
  • są bardziej złożone scenariusze. no i co daje ‚reviewer’?? dla tego warto wiedzieć więcej – np. jakie inne uprawnienia można nadać
  • czemu nadal nie ma wszystkich informacji
  • a co przy jeszcze bardziej wymyślnych wymaganiach dotyczących automatyki? jak jeszcze może ‚reagować’ taki obiekt na rezerwację?

lokalizacja

czemu w PL nie zadziała? ponieważ ‚calendar’ to nazwa katalogu, a ta jest zlokalizowana. żeby było śmieszniej nazwa będzie zależna od… ustawień przeglądarki w momencie tworzenia obiektu zasobu (użytkownikom definiuje się kraj). sweet. ponieważ mam główną przeglądarkę ustawiona na en-US, żeby nie oglądać raniących w oczy auto-tłumaczeń technetowych czy portalu office365 w którym ciężko się połapać, część obiektów ma ‚calendar’ a część ‚kalendarz’. zakładając z command line zawsze tworzy ‚calendar’ pomimo polskich regionalsów, więc mniemam, że ten sposób jest bardziej deterministyczny (ale trzeba by porobić więcej testów na różnie zlokalizowanych systemach).

czyli zapis ścieżki do konkretnego folderu to „roomResource@wfiles.pl:\kalendarz” . i znów – tyle dość łatwo i szybko można wyszperać na forach… ale pozostaje pytanie – jak wylistować wszystkie katalogi?? skoro jest kalendarz, to pewnie są jakieś inne foldery i może da się z nimi coś zrobić? i jak sprawdzić czy to jest ‚calendar’ czy ‚kalendarz’? ale najpierw…

uprawnienia

standardowo, po utworzeniu zasobu sali lub ekwipunq jedyne co widać w kalendarzu to ‚busy’. equipmentMBXdef

można to zmienić i umożliwić bardziej pełny widok nadając uprawnienia LimitedDetails lub Reviewer (pełna lista uprawnień tutaj). różnica jest dość poważna. ograniczone detale pozwolą na zobaczenie organizatora i lokalizacji ale nie pozwolą otworzyć zdarzenia ze względu na brak uprawnień:

equipmentMBXrevequipementMBXnoaccnadanie uprawnień podglądacza (; pozwoli otworzyć wpis w kalendarzu i w pełni mu się przyjrzeć:

equipmentMBXdetaa gdzie informacje??

na pierwszy rzut oka może wygląda dobrze, ale ktoś choć trochę bardziej spostrzegawczy zauważy, że pole tematu oraz szczegółowe informacje chyba nie dają pełnych informacji. i faktycznie – standardowo, założenie jest takie: ktoś wynajmuje salę, wysyła zaproszenie, więc w tym zaproszeniu umieszcza informacje o czym będzie rozmowa, pewnie agendę, może jakieś materiały dodatkowe itd. zasób sali dostaje to samo zaproszenie co każdy inny – a to byłby niekontrolowany wyciek informacji. nie byłoby miło, gdyby cała firma wiedziała, że właśnie dyrektorzy spotykają się, np. żeby omówić zwolnienia pracowników… dla tego standardowe opcje są ustawione restrykcyjnie i wycinają wszystkie informacje.

są jednak scenariusze, w których niektóre osoby muszą wiedzieć więcej – np. dział logistyki musi wiedzieć gdzie jest samochód i po co. wtedy trzeba wykonać następujące operacje:

  • nadać ludzikom uprawnienia ‚limitedDetails’ żeby widzieli ‚kto’ ale niewiele więcej (set-MailboxFolderPermission)
  • nadać wybrańcom uprawnienia ‚reviewer’ żeby mogli wejść i zobaczyć detale (add-MailboxFolderPermission)
  • no i skonfigurować zasób tak, żeby te informacje przyjmował a nie wycinał. (set-CalendarProcessing)

zobaczmy jakie zachowania można dla zasobu ustawić:

wszystkich nie ma sensu tłumaczyć, można przeczytać na technecie, nas interesują konkretnie DeleteSubject, DeleteComents. jak widać można również pozwolić na załączniki, kontrolować czy zatwierdzanie jest automatyczne czy wymaga ręcznego potwierdzenia, czy w polu tematu dodawana jest nazwa użytkownika… i inne. przykładowa konfiguracja zasobu:

i w takim przypadq dział logistyki może zobaczyć takie krzaczki…

equipmentMBXfulllista folderów

na koniec powrócę do listy folderów. tu niestety niespodzianka: nie da się wylistować folderów dla zasobu. ponieważ zasób jest skrzynką… ale równocześnie nią nie jest. jest – i te foldery są, ale nie jest – bo tak twierdzi system. poniżej mała zabawa – wylistowanie folderów dla regularnego mailboxa, próba wylistowania dla zasobu i dowód, że jednak wszystkie foldery są…

przy czym normalny user ma nazwy katalogów po polsq bo zakładając tak miał zdefiniowaną licencję, a zasób po ang. bo był zakładany z linii poleceń, a zasoby licencji nie posiadają. wykorzystanie ‚get-mailboxfolderpermission’ w połączeniu z intuicją to jedyny sposób jaki znalazłem, żeby sprawdzić czy dany folder istnieje dla zasobu…

eN.