Microsoft uveo značajka za spremanje stavki poslanih u ime/poslanih kao dijeljenih (i kasnije korisničkih) poštanskih sandučića prije više od deset godina. Pokrili smo još nekoliko puta nakon prvog izdanja, najnovije zbog buga koji je uzrokovao kopiranje poslanih stavki svim članovima grupe za distribuciju, kada je prosljeđivanje navedenoj grupi bilo u igri. Ali čini se da značajka još uvijek ima neka iznenađenja, čak i nakon toliko vremena.
Pitanja i odgovori postavljaju neka pitanja
A nedavno pitanje u Q&A izazvao daljnje istraživanje. Korisnik je konfigurirao korisnički poštanski sandučić s oboje Pošalji kao i Potpuni pristup dopuštenja, zajedno s MessageCopyForSentAsEnabled zastava. Prilikom slanja poruka putem “standardne” metode, sve je radilo kako se očekivalo, s kopijom poruke pohranjenom u delegatovoj i delegatorovoj mapi Poslane stavke. Međutim, kada se poštanskom sandučiću pristupilo u “izravnom” načinu, bilo korištenjem otvoriti drugi poštanski sandučić funkcionalnosti u OWA-i ili ga dodajte kao dodatni račun u Outlooku je poslana poruka spremljena samo u (vlastiti) poštanski sandučić delegata.
Ovdje treba razjasniti dvije stvari. Prvo, ova je funkcionalnost već neko vrijeme podržana za korisničke poštanske sandučiće, tako da ne bi trebalo biti razlike sa scenarijem “dijeljenog poštanskog sandučića”. Osim što je svakako lakše razumjeti kada govorimo o zajedničkim sandučićima umjesto o “delegatorskom”. Druga točka je da je značajka dizajnirana kako bi osigurala da se poslane poruke kopiraju u poštanski sandučić “delegatora” (dijeljeni) i ne utječe na to hoće li biti pohranjene u poštanskom sandučiću pošiljatelja. Što je i bio cilj u ovom scenariju.
Usput, također sam bio pod dojmom da bi prebacivanje zastavice doista trebalo rezultirati pohranjivanjem kopija poslanih poruka u oba poštanska sandučića, ili sam samo bio stariji trenutak prisjećajući se kako bi značajka trebala funkcionirati. Za provjeru ispravnosti ispitao sam Exchange MVP DL i brzo dobio odgovor koji je potvrdio kakvo je očekivano ponašanje, kao i obećanje da ću to pojasniti u službena dokumentacija da izbjegnemo daljnju zabunu.
Dakle, dobili smo odgovor. Uključivanje MessageCopyForSentAsEnabled/MessageCopyForSendOnBehalfEnabled zastavica ne rezultira pohranjivanjem kopija poslanih poruka u oba poštanska sandučića, ona samo osigurava da će onaj koji je delegat dobio kopiju. Što se tiče poštanskog sandučića delegata, kao i kod korisnika koji stvarno šalje, ponašanje ovisi o klijentu. Drugim riječima, kopija može ili ne mora biti pohranjena unutar njegovih Poslanih stavki, ovisno o tome kako radimo dio slanja. Proširimo ovo.
Zapravo, već jesmo opširno raspravljali kako se “klasični” Outlook ponaša kada je u igri više računa i delegirane dozvole. Iako su se stvari malo promijenile dolaskom novog Outlooka i moderne verzije OWA, još uvijek vrijedi sljedeće pravilo – kopija poslane poruke bit će spremljena u delegatov poštanski sandučić, osim ako se operacija ne izvodi dok se dijeljenom (delegatorovom) poštanskom sandučiću pristupa u “izravnom” načinu. Potonji scenarij moguć je samo kada je delegat odobren Potpuni pristup dopuštenja uz Pošalji kao/Pošalji u ime jedan i pristupa poštanskom sandučiću kao dodatni račun u programu Outlook ili putem Otvorite drugi poštanski sandučić funkcionalnost u OWA.
Jednostavan način za ilustriranje ove razlike u ponašanju je korištenje dobrog starog “klasičnog” Outlooka i Pošalji pomoću dijalog. Kada imate poštanski sandučić ovlaštenika dodan kao potpuni račun u programu Outlook, odgovarajući račun dostupan je za odabir pod Pošalji pomoću dijaloški okvir, i doista je njegova vrijednost iskorištena prema zadanim postavkama. Međutim, možete nadjačati ovo ponašanje da biste umjesto njega koristili račun delegata pritiskom na Iz padajući > Druga adresa e-pošte…a zatim ga odaberite pod Pošalji pomoćukao što je prikazano u nastavku:
Učinkovito, Pošalji pomoću vrijednost određuje gdje će kopija poslane poruke biti pohranjena. Ako odabrana vrijednost odgovara onoj od Iz polje, koje je u našem slučaju delegatov (dijeljeni) poštanski sandučić, kopija će biti spremljena samo u vlastitom poštanskom sandučiću. Ako je Pošalji pomoću vrijednost odgovara delegatovom računu, poslana poruka bit će pohranjena u delegatovoj mapi Poslane stavke, a zatim kopirana u delegatov (dijeljeni) poštanski sandučić jedan, ako MessageCopyForSentAsEnabled se uključuje.
Za scenarij koji smo opisali na početku, koristeći Pošalji pomoću značajka može biti prikladno zaobilazno rješenje, iako uključuje neke dodatne klikove. Međutim, imajte na umu da Pošalji pomoću značajka je dostupna samo kada je višestruki računi konfigurirani u Outlooku, tako da ovo nije rješenje za scenarije u kojima želite samostalan profil sa samo poštanskim sandučićem ovlaštenika koji je dodan kao dodatni račun. Osim toga, ni New Outlook klijent ni OWA ne izlažu Pošalji pomoću kao značajka. Što je tužno, jer značajka ima svoju upotrebu. Ako ništa drugo, pomaže u ilustriranju temeljnog uzroka ovakvog ponašanja!
Ako poštanskom sandučiću ovlaštenika pristupate u neizravnom načinu, tako da ga dodate kao dodatni poštanski sandučić u programu Outlook, putem funkcije automatskog mapiranja ili mu uopće ne pristupate, Pošalji pomoću vrijednost je efektivno postavljena na delegatov poštanski sandučić, stoga ćete uvijek vidjeti poslanu poruku sačuvanu u delegatovoj mapi Poslane stavke. Ovisno o tome jesu li relevantne zastavice promijenjene, poruka će se naknadno kopirati u (dijeljeni) poštanski sandučić ovlaštenika.
Revizijski trag
Također je važno znati koji se podaci mogu dobiti iz izvora kao što su Unified Audit Log ili Message Trace. To može pomoći u određivanju načina na koji je poruka poslana i je li njezina kopija spremljena u scenarijima u kojima možda nemate izravan pristup uključenim korisnicima (ili poštanskim sandučićima).
Počnimo s revizijskim dnevnikom. Možemo pogledati osjetila operacija:
#Fetch SendAs events for the past 10 days $logs = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date).AddDays(1) -Operations SendAs #Get the relevant properties out of AuditData $logs.AuditData | ConvertFrom-Json | select CreationTime,Operation,*MailboxGuid,MailboxOwnerUPN,SendAsUserSmtp,@n="Item";e=$_.Item.Subject,SaveToSentItems
Obratite pažnju na razliku između vrijednosti u gornjem primjeru. tamo, MailboxGuid i MailboxOwnerUPN odrediti delegata, dok SendAsUserMailboxGuid i SendAsUserSmtp dajte nam delegatov poštanski sandučić. Ako vrijednosti povežemo s onim što smo naučili gore, znamo da je u prvom primjeru poruka “poslana pomoću” delegatskog poštanskog sandučića, dok je u drugom korišten onaj delegata, možda u “izravnom” načinu. The SaveToSentItems vrijednost je Pravi u oba scenarija, govoreći nam da bismo trebali biti u mogućnosti pronaći kopiju poslane poruke unutar delegatovog (dijeljenog) poštanskog sandučića. Ali samo će prvi scenarij rezultirati prisutnošću kopije u Poslanim stavkama delegata.
Još jedna korisna primjena revizijskog dnevnika je traženje bilo kojeg Stvoriti događanja. Ne, ono dokumentacija jasno kaže da se takvi događaji NE generiraju za slanje poruka. Međutim, stvaranje kopije poslane stavke ne spada u ovu kategoriju, stoga možete očekivati da ćete pronaći takve događaje u UAL-u. Budući da se mogu miješati s “uobičajenim” događajima stvaranja, možda ćete htjeti primijeniti dodatne filtre kako biste ograničili broj dohvaćenih unosa:
#Fetch all Create events for the shared (delegator's) mailbox Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date).AddDays(1) -Operations Create -UserIds sharednew@michev.info
Jedno zanimljivo zapažanje iz gornjeg primjera i svih sličnih zapisa po tom pitanju je prisutnost aplikacije prve strane (Microsoft) s ID-om od 51a0d90a-2243-4935-ad59-efc78b7197ee. U javno dostupnoj dokumentaciji ne spominje se spomenuta aplikacija, ali na temelju dokaza iz revizijskog dnevnika možemo obrazloženo pretpostaviti njezinu uključenost u značajku “spremi u poslane stavke”. I možemo iskoristiti njegovu vrijednost da dohvatimo samo događaje relevantne za našu raspravu:
#Fetch all events referencing 51a0d90a-2243-4935-ad59-efc78b7197ee Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date).AddDays(1) -FreeText 51a0d90a-2243-4935-ad59-efc78b7197ee
Sada, budući da navedeni objekt nije izložen ni u jednom administratorskom sučelju, ne možemo čak ni biti sigurni je li navedeni ID ID aplikacije (clientID) ili principala usluge (predstavljanje aplikacije unutar lokalnog zakupca). Svi unosi također sadrže a HostAppId vrijednost od c999ed3e-27ae-4cb3-b3a2-46b056af63d3za koju je vjerojatnije da predstavlja “roditeljsku” aplikaciju, s obzirom na činjenicu da Glen spominje to u jednom od svojih članaka. U svakom slučaju, jedna od te dvije vrijednosti trebala bi biti od pomoći kao filtar.
Uz događaje u dnevniku revizije, praćenje poruka također može otkriti detalje relevantne za našu raspravu. Za najbolje rezultate morat ćete iskoristiti prošireno izvješće. U njemu potražite POŠALJI događaj, i prilagođeni_podaci polje. Evo primjera:
Podaci koji se nalaze u navedenom polju informiraju nas da je kopija poslane poruke pohranjena u poštanskom sandučiću ovlaštenika, kao i navodni pošiljatelj adresa. Dodatni podaci koje možete dobiti iz praćenja poruka uključuju povratni_put i popis agenata koji su djelovali na poruku, dio poruka_info mrlja (naći ćete spomen na Agent za poslane stavke dijeljenog poštanskog sandučića u njemu).
