Am instalat un nou server Exchange 2016 și am migrat toate cutiile poștale de pe serverul Exchange 2010 la acesta.
Apoi am migrat toate cutiile poștale și folderele publice de la MSEX2016 la Office 365 și am retrogradat și am oprit MSEX2010.
AD local este sincronizat cu Azure AD de către Azure AD Connector pe unul dintre serverele noastre locale.
Acest lucru a funcționat timp de câteva săptămâni fără probleme. Toți clienții au putut accesa folderele publice și căsuțele lor poștale pe O365.
Ieri am retrogradat MSEX2016, care fusese deja oprit pentru testare cu câteva zile înainte.
Nu a existat niciun PF activ pe acesta, dar nu a fost posibilă eliminarea bazelor de date în mod obișnuit, deoarece a arătat întotdeauna că serverul este încă în modul de migrare.
Nu a ajutat să setați manual atribute (cum ar fi MigrationComplete...) și în cele din urmă le-am eliminat cu opțiunea de forță, am retrogradat serverul și l-am oprit.
După aceea, pe clienți a apărut mesajul că Administratorul Exchange a efectuat modificări care au necesitat o repornire a clientului Outlook.
Nu sunt sigur de ce a apărut acest mesaj, deoarece toți clienții erau deja conectați la O365 și nu ar fi trebuit să existe nicio conexiune stabilită la vechiul MSEX2016.
Ieri, am schimbat și conectorul Azure AD, care sincronizează doar câteva dintre OU-urile necesare.
Astăzi a apărut problema că nimeni nu a mai putut accesa PF.
Am aflat atunci că SID-ul permisiunilor de folder ale grupurilor alocate sunt afișate ca necunoscute.
SID-urile utilizatorului arată bine, problema este doar pe grupuri.
M-am gândit mai întâi că asta are ceva de-a face cu limitarea OU a conectorului Azure AD și am reactivat sincronizarea completă așa cum era înainte, dar nu a ajutat.
De asemenea, nu pot schimba nicio permisiune prin WebGUI, se termină cu următorul mesaj.
`System aruncă o excepție la calcularea expresiei Lambda: [ Boolean(@0[ApplyToSubFolders]) ] Excepția a fost aruncată de ținta unei invocări.
EROARE
Sistemul aruncă o excepție la calcularea expresiei Lambda: [ Boolean(@0[ApplyToSubFolders]) ] Excepția a fost aruncată de ținta unei invocări.`
Am reușit să creez un nou folder de „test” în PF-ul rădăcină, dar nu pot să setez nicio permisiune acolo prin WebGUI.
Este posibil să schimbați permisiunile printr-un client Outlook.
Dacă elimin acolo una dintre permisiunile de grup și o adaug din nou, atunci SID-ul este afișat și totul funcționează bine. Înseamnă pentru mine că toate grupurile sunt cunoscute în general la O365 (sunt afișate și acolo în Exchange Admin WebGUI), dar pe permisiunile existente nu îi sunt alocate.
De ce nu este posibil să setați o permisiune PF prin WebGUI?
De ce și-a pierdut alocarea de la permisiunile existente ale grupului de foldere publice către SID-uri și cum să o rezolve fără a elimina și a adăuga din nou toate permisiunile manual?
Editare 1 (Luni 2021-10-18):
Între timp, permisiunile de grup au dispărut complet.
Editare 2 (Joi 21-10-2021):
Există un bilet Microsoft deschis de luni, dar nu pot explica de ce au dispărut permisiunile și inginerii lor de software lucrează la el pentru a afla ce s-a întâmplat. Ei investighează, de asemenea, de ce nu este posibilă setarea permisiunilor prin WebGUI.
Soluția propusă de ei a fost să seteze manual toate permisiunile pe toate folderele cu Outlook sau cu PowerShell, ceea ce nu m-a mulțumit întrucât avem aproximativ 2700 de foldere. Nu au fost dispuși („construcția de scripturi personalizate este în general în afara limitelor noastre de asistență”) să furnizeze un script pentru a aplica din nou permisiunile din fișierul XML care a fost creat în timpul migrării și nu au apărut cu nicio altă soluție pentru a obține permisiunile înapoi.
Între timp, am putut să aplic din nou permisiunile pentru folderele publice acest scenariu creat de mine și de sprijinul comunității.
Editare 3 (sâmbătă, 30.10.2021)
MS spune că problema cu setările de permisiuni WebGUI este bine cunoscută:
„problema raportată este cauzată de o problemă cunoscută (care este abordată de echipa noastră de inginerie de produs din backend)”
Aceștia recomandă să utilizați clienții Outlook sau PowerShell pentru a modifica permisiunile pentru folderele publice.
În plus, ei spun că nu pot dovedi că permisiunea nu a fost ștearsă de o activitate de administrator, deoarece jurnalul nostru de audit nu a fost activat (în conformitate cu MS implicit) și nu pot afișa înregistrări despre aceasta.
Le-am trimis din nou captura de ecran care arată situația ciudată cu SID-ul lipsă de pe permisiunile de grup pentru a sublinia că aceasta este o problemă în infrastructura MS.
Sunt singurul tip care are acces de administrator și sunt sigur că nu am șters permisiunile din folderele publice.
Editare 4 (duminică, 14.11.2021)
Răspuns de la MS:
„În ceea ce privește problema atribuirii de permisiuni prin interfața de utilizare a centrului de administrare, colegul meu a spus că această problemă este deja publicată extern, deoarece problema este cunoscută de ceva timp. După cum am menționat anterior, echipa noastră de inginerie de produs lucrează în prezent la dezvoltarea unei remedieri permanente. , cu toate acestea, nu există momentan ETA specific, așa că nu putem confirma pe deplin când să ne așteptăm la rezoluție. Pentru mai multe informații, puteți consulta, de asemenea, Permisiunile și setările pentru foldere publice nu se propagă în EAC articol (include și scriptul PowerShell pe care l-am sugerat, care este soluția oficială pentru această problemă pe care colegii noștri au furnizat-o)."
„Din informațiile pe care ni le-ați împărtășit până acum (inclusiv captura de ecran de la EAC, care arată SID-urile lipsă), colegul meu bănuiește că folderele publice afectate au fost migrate normal la Exchange Online, cu toate acestea, grupurile de securitate Mail care acordă permisiuni. cu utilizatorii nu au fost sincronizate ulterior (sau a existat o problemă cu procesul de sincronizare). Ca urmare, aceste grupuri de permisiuni au fost considerate orfane/învechite și au fost șterse cu agentul nostru de coerență, care rulează la fiecare 7 zile în backend. "
„Fiind vorba de acestea, acest comportament este prin proiectare, dar, din păcate, nu putem confirma pe deplin de ce permisiunile au fost detectate ca învechite în primul rând. Pentru mai multe informații despre această problemă, vă recomandăm să revizuiți oficialul Anunțarea Agentului de coerență a folderelor publice pentru Exchange Online postare de la echipa de dezvoltare Exchange, care explică cum funcționează agentul.”
