Godinama smo slušali kako je Graph API de facto “kontrolna površina” Microsoft 365 i da bi se trebao koristiti za sve integracije/automatizacije i aplikacije. Ipak, godinama nakon ovog putovanja, stvarna priča još uvijek pokazuje fragmentiranu pokrivenost čak i kroz osnovna radna opterećenja (*kašalj* Exchange Online *kašalj*). Što se tiče nadležnosti, situacija je nešto bolja s barem operacijama eDiscovery koje pokriva Graph API. Ali općenito, puno toga za poželjeti.
Što nas dovodi do MC1238428, koji nas obavještava da za mjesec dana (23. ožujka 2026.) Microsoft planira službeno razdvojiti korisničko sučelje i iskustva temeljena na PowerShell-u kada su u pitanju slučajevi eDiscovery. Evo cjelovitog teksta objave centra za poruke:
Drugim riječima, počevši od 23. ožujka 2026., svako pretraživanje eDiscovery ili slučaj eDiscovery kreiran ili izmijenjen putem postojećeg skupa PowerShell cmdleta NEĆE biti vidljiv na portalu Purview. Bilo koji administrator/operator koji pristupa korisničkom sučelju Purview neće ni biti svjestan postojanja takvih slučajeva, što je više od problema s vidljivošću, budući da zadržavanje eDiscovery također može utjecati na životni ciklus korisničkog računa. Što je i povod za današnje priopćenje javnog servisa.
Kao što je uobičajeno, objava centra za poruke malo je oskudna s detaljima i ne daje jasan odgovor na koje će bitove korisničkog sučelja utjecati, pa bih predložio oprezan pristup i pretpostavku “sve”. Također nam ne govori hoće li sinkronizacija nastaviti raditi u drugom smjeru, tj. hoće li se promjene učinjene u slučajevima/pretragama vidljivim u korisničkom sučelju i dalje odražavati na izlazu postojećih PowerShell cmdleta. Isto vrijedi i za promjene napravljene putem Graph API-ja.
Post centra za poruke također se nejasno spominje PowerShell revizijski zapisnicišto bismo, pretpostavljam, trebali čitati kao “Jedinstveni dnevnik revizije”. Nadam se da je moja pretpostavka točna i da će se revizijski zapisi koji se odnose na slučajeve i pretraživanja eDiscovery-a nastaviti prikupljati kao dio jedinstvenog revizijskog dnevnika, bez obzira na to koja je metoda korištena za izvođenje operacija. Vidjet ćemo.
Sada, zašto cijenim Microsoftovo kretanje u smjeru iskustva temeljenog na Graph API-ju (iako puževim korakom), pomalo sam zbunjen pristupom koji je uzet u ovom slučaju. Zasigurno se PowerShell cmdleti mogu ažurirati za proxy potpuno iste operacije koje koristi korisničko sučelje, čime se eliminiraju takva nepovezana iskustva? Da ne spominjemo da čak i danas još uvijek moramo iskoristiti – Vrsta kućišta parametar za Get-ComplianceCase cmdlet, ako želimo nabrojati sve slučajeve. Ulaganje malo inženjerskog truda u “modernizaciju” PowerShell cmdleta svakako bi bilo cijenjeno, ali pretpostavljam da Microsoft ne smatra administratorsko iskustvo vrijednom investicijom za sve te teško zarađene $$$.
Zapravo, dok sam jadnog raspoloženja, razgovarajmo io nekim drugim nedavnim primjerima na frontu Purviewa. Nove krajnje točke upita Unified audit log na Graph API-ju slijede isti model, manje-više. Kao što smo raspravljali u naš početni pregledsvi upiti izvršeni putem dopuštenja aplikacije ne prikazuju se kada se koriste metode GET/LIST putem dopuštenja delegata i obrnuto. Uzimajući u obzir koliko osjetljivi mogu biti podaci izloženi putem UAL upita, ovo je opet više od jednostavnog problema s vidljivošću.
Pomalo tangentno, još uvijek nemamo podršku za rad sa svim cmdletima povezanim s Purviewom u kontekstu aplikacije (principal usluge). Što je još gore, dokumentacija ostaje nedovršeno, pa čak i pogrešno, s nekim od navedenih cmdlet-a koji zapravo rade s CBA sesijama, dok druge pogođene cmdlete tek treba dodati u članak. Umjesto toga, prisiljeni smo pratiti “najave” objavljene kao dio objava centra za poruke (tj. MC1131771 i MC1213770), u sklopu kojega saznajemo o nadolazećim promjenama podržanih metoda povezivanja i cmdleta.
Očito, korisnici mogu razumjeti potrebu za modernizacijom dijelova usluge, čak i u scenarijima gdje promjene rezultiraju stvaranjem dodatnih troškova na “našoj” strani. Pa opet, žuriti s promjenama samo da bi se ispunili neki interni rokovi i bez uzimanja u obzir korisničkog iskustva, ili se čak truditi objaviti odgovarajuću dokumentaciju, nije ići. Microsoft, sigurno možete bolje?
