Budući da sam još uvijek pod utjecajem svoje iznenadne želje da generiram neke alate temeljene na Windows Forms-u, radio sam na skripti koja bi oponašala Outlookovu funkciju upravljanja delegatima. Dijalog i logika iza alata su gotovi, ali dok sam izvodio testove na nekim zamršenijim scenarijima, naišao sam na problem s korištenjem Set-MailboxFolderPermission cmdlet za uklanjanje oznake “delegate”. TL;DR – jednostavno ne radi kako se očekuje. Evo detalja.
Počnimo s podsjećanjem čitatelja da je prije nekoliko godina set of *-Dozvola mape poštanskog sandučića cmdleti su poboljšani za rukovanje scenarijima “delegiranja”. Detaljne informacije o tome možete pronaći u našem izvorni članak na temu. Ovi ažurirani cmdleti služe samo za neke od mogućih konfiguracija koje podržavaju Outlook ili EWS, ali ih je u to vrijeme bilo lijepo imati. Međutim, s nadolazećim ukidanjem EWS-a i prelaskom na New Outlook klijent, stvari postaju još gore. Zapravo, nedavno objavljen metode “parity”, kao dio API-ja “admin” oslanjaju se na *-Dozvola mape poštanskog sandučića cmdleti za implementaciju podrške za scenarije delegiranja i stoga su dizajnom ograničeni u funkcionalnosti u usporedbi s EWS-om.
Imajući gore navedeno na umu, odlučio sam implementirati “poslovnu logiku” alata na temelju skupa *-Dozvola mape poštanskog sandučića cmdlete i čak su se pozabavili nekim od njihovih nedostataka u alatu. Ali više o tome u našem sljedećem članku. Za aktualni je pozornica spremna i vrijeme je za veliko otkriće – the Set-MailboxFolderPermission ima problema s rukovanjem Delegat zastava u sklopu SharingPermissionFlags vlasništvo.
Problem utječe samo na određene konfiguracije “delegata”, ali s obzirom na zadane postavke koje koristi Outlook, trebao bi biti relativno široko rasprostranjen (ako odlučite upravljati delegatima putem PowerShell-a, to jest). Za ilustraciju možemo koristiti sljedeći primjer:
#Initial state
Get-MailboxFolderPermission gosho:\Calendar
FolderName User AccessRights SharingPermissionFlags
---------- ---- ------------ ----------------------
Calendar Vasil US {Editor} Delegate
#Try to toggle SharingPermissionFlags
Set-MailboxFolderPermission gosho:\Calendar -User vasilus -AccessRights Editor -SharingPermissionFlags None
#Change is not reflected
Get-MailboxFolderPermission gosho:\Calendar
FolderName User AccessRights SharingPermissionFlags
---------- ---- ------------ ----------------------
Calendar Vasil US {Editor} Delegate
Kao što možete vidjeti na gornjoj snimci zaslona, imamo korisnika za kojeg je dodan barem jedan delegat (tj. drugom korisniku je dodijeljeno Urednik dopuštenja za mapu Kalendar i prima kopije pozivnica za sastanak i adrese odgovora vlasniku poštanskog sandučića). Ako želimo ukloniti spomenuti “delegirani” pristup, možemo koristiti ili Remove-MailboxFolderPermission za brisanje cijelog unosa ili iskoristite Set-MailboxFolderPermission cmdlet za prebacivanje stanja “delegiranja”, osiguravajući da će drugi korisnik nastaviti uživati u pristupu mapi Kalendar. Ali kao što možete vidjeti iz izlaza zadnjeg cmdleta, unos dopuštenja ostao je u izvornom stanju.
Moji početni napori u rješavanju problema bili su bačeni u pogrešnom smjeru zbog nekih upitnih unosa u dokumentacija za cmdlete. Nakon nekog vremena postalo je jasno da bez obzira na kombinaciju parametara koje sam isprobao, unos Delegata nije nestao. Jedino što je upalilo je da resetirati kolekciju delegata ali to ima neke neželjene nuspojave. Pa, također se može ukloniti unos dopuštenja u cjelini, kao što je gore spomenuto, a zatim ga ponovno dodati. Što se zaobilaznih rješenja tiče, sigurno nije najgore koje smo morali koristiti s Microsoft 365, ali ipak nije baš željeno.
Zanimljivo je da je čak i ponovno postavljanje zbirke delegata bilo samo privremeno rješenje. Ponovno dodjeljivanje delegata u kasnijoj točki rezultiralo je istim ponašanjem, tako da je problem bio ponovljiv, na neki način. Isprobavanje protiv niza različitih poštanskih sandučića i delegata preko raznih stanara koje koristim rezultiralo je ponašanjem pogodaka i promašaja, daleko od bilo kakve pouzdane metode za reprodukciju problema. U svom očaju okrenuo sam se dobrom starom EWS-u i metodama upravljanja delegatima koje podržava.
Uz pomoć EWS-a GetDelegates metodamisterij se brzo rasplinuo. Provjera bilo kojeg od zahvaćenih poštanskih sandučića pokazala je odgovarajući skup unosa unutar zbirke delegata, tako da smo imali paritet na tom frontu. Međutim, također je pokazao neslaganje između načina na koji Get-MailboxFolderPermission cmdlet je prijavio oznaku delegata u usporedbi sa “neobrađenim” podacima. Kao što je prikazano na snimci zaslona u nastavku, svi problematični unosi imaju a lažno vrijednost za ReceiveCopiesOfMeetingMessages zastava:
Ova zastava je ono što čini delegata, ako se oslonimo na dokumentacija: Korisnik postaje delegat za kalendar, što uključuje primanje pozivnica za sastanke i odgovora. Međutim, stvarnost je malo složenija i kao što je već nagoviješteno, skup PowerShell cmdleta koje imamo ne odražava potpunu sliku. Izgleda kao Get-MailboxFolderPermission cmdlet provjerava prisutnost delegatskog unosa pohranjenog unutar poštanskog sandučića, kao što je prikazano na gornjoj snimci zaslona. NE provjerava vrijednost ReceiveCopiesOfMeetingMessages zastava.
Sada kada smo taj dio shvatili, kako ćemo se pozabaviti ključnim problemom? Ovdje se postavlja pitanje zašto u odgovoru EWS-a dobivamo unos delegata. Gledajući u Dozvole objekt za svaki od vraćenih delegatskih unosa otkriva odgovor – svi “neispravni” imaju barem jedan dodatni unos dopuštenja (iz skupa podržanih “zadanih” mapa: Inbox, Zadaci, Kontakti, Bilješke i Dnevnik, uz Kalendar):
Uklanjanje dodatnog unosa dopuštenja ključ je za rješavanje problema. Nakon što se pobrinemo za to, ponovno postavljanje vrijednosti ReceiveCopiesOfMeetingMessages zastavica će ispravno ukloniti informacije o delegatu, kako iz zbirke delegata EWS-a, tako i iz SharingPermissionFlags vlasništvo. Međutim, imajte na umu da morate “zagolicati” vrijednost zastavice da bi se to dogodilo, iako konfiguracija samo s dopuštenjima Kalendara i ReceiveCopiesOfMeetingMessages vrijednost postavljena na False ne bi trebala rezultirati unosom delegata. Pa pretpostavljam da također možemo tvrditi da EWS ne rješava stvari tako dobro.
Nakon što uklonite bilo koji unos dopuštenja za pogođenog korisnika iz mapa Pristigla pošta, Zadaci, Kontakti, Bilješke ili Dnevnik, moći ćete koristiti Set-MailboxFolderPermission cmdlet kako je predviđeno:
Također je zanimljivo primijetiti da i OWA ima problema s “tumačenjem” takve konfiguracije. Kad god naiđe na unose u zbirci delegata gdje ReceiveCopiesOfMeetingMessages postavljeno na False, prikazat će se Običaj za razinu dopuštenja, iako tehnički jest Urednik. Pokazat će vam kako različiti timovi unutar Microsofta ne uspijevaju slijediti isti skup standarda i definicija.
Ukratko, ako naiđete na scenarije u kojima Set-MailboxFolderPermission cmdlet naizgled ne uspijeva unijeti promjene u SharingPermissionFlags svojstvu, razmotrite provjeru je li istom korisniku dodijeljena dopuštenja za jednu od ostalih “zadanih” mapa. Ako je to doista slučaj, vrijednost SharingPermissionFlags zastava bi se mogla netočno prikazati kao Delegat čak i u scenarijima u kojima je već očišćeno.
Iako to ne bi trebalo utjecati na dotične korisnike, ako vam toliko smeta, problem možete riješiti tako da prvo uklonite sva dopuštenja na razini mape dodijeljena mapama Inbox, Tasks, Contacts, Notes ili Journal za istog korisnika. U tom trenutku možete ponovno pokrenuti Set-MailboxFolderPermission cmdlet za brisanje oznake delegata. Ne zaboravite ponovno dodati dopuštenja mape gdje je to potrebno. Druga alternativa je korištenje prekidača -ResetDelegateUserCollection, ali to također zahtijeva da ručno ponovno dodate dopuštenja u većini slučajeva. Odaberite svoj otrov.
