Morgans Exchange tips #2:
Morgan Simonsen fra Ementor er del av Speaker Community og som alltid bidrar han med tips og triks som kan hjelpe deg i din jobb. Enjoy...
Lei av MSExchangeIS 9548 meldinger i Application loggen?
Helt siden Exchange 2000 ble lansert og en postboks gikk fra å være et selvstendig directory objekt til å bli en attributt på en bruker, har vi slitt med denne nå berømte (eller beryktede) feilmeldingen i Application loggen på våre Exchange servere:
Type: Warning
Event: 9548
Date Time: 14.06.2006 12:21:05
Source: MSExchangeIS
ComputerName: EXCH1
Category: General
User: N/A
Description: Disabled user /O=LAB/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=USER1 does not have a master account SID. Please use Active Directory MMC to set an active account as this user's master account.
For å forstå hvorfor denne meldingen kommer må vi vite litt mer om hvordan Exchange fungerer.
Bakgrunn
For at en postboks skal kunne fungere i databasen (Store) må den ha en SID assosiert med seg. Som nevnt er en postboks bare en attributt på et brukerobjekt og kan ikke eksistere uten å være koblet til en bruker. Dette er en stor forskjell fra Exchange 5.5 hvor postbokser ikke trengte en slik assosiasjon og kunne fungere utmerket uten noen som helst kobling mot en bruker. Uten en bruker å kobles mot kan ikke en Exchange 200x postboks engang ha en e-postadresse. Hvis store.exe prosessen, som er databasemotoren i Exchange 200x, ikke klarer å finne ut hvilken bruker en postboks er koblet til kan det føre til forsinkelser på Exchange serveren og ulike typer feilmeldinger. Dette gjelder spesielt operasjoner hvor ACL (Access Control Lists) skal vurderes. Feks klarer ikke store.exe å korrekt avgjøre en brukers tilgang til feks en Public Folder hvis det ikke lar seg gjøre å finne korrekt objekt i Active Directory som en postboks er koblet til. Husk at Exchange er 100% avhengig av Active Directory for sikkerhetsfunksjonalitet. I normal drift er dette ikke noe problem. Aktive kontoer (ikke disabled) med postbokser knyttet til seg, har en attributt som heter objectSID, denne forteller Exchange helt nøyaktig hvilken konto som denne postboksen tilhører og hvilken konto som skal benyttes når store.exe utfører ulike sikkerhetsrelaterte operasjoner i databasen.
Deaktiverte brukere (disabled users)
Men hva med en bruker som er deaktivert? Da kan ikke lenger objectSID attributten brukes av store.exe. I et slikt tilfelle komme en ny attributt på banen, nemlig msExchMasterAccountSid. Dette er også en attributt på den nå deaktiverte brukeren og den er kun aktiv (og skal kun ha en verdi) når brukeren som en postboks er koble mot er deaktivert. Det er nå denne attributten som forteller store.exe hvilken konto i Active Directory som skal brukes for denne postboksen. Årsaken til at det er slik er følgende: En postboks kan ikke eksistere alene i databasen uten å ha en brukerkonto å kobles til. I mange tilfeller ønsker vi å ha postbokser som ikke er knyttet til aktive brukere, feks ressurkontoer, fellespostbokser eller lignende. Disse brukerne, som ikke benyttes til daglig pålogging, ønsker vi av sikkerhetsmessige årsaker å deaktivere. For at de skal kunne fortsette å fungere etter deaktiveringen er mekanismen med msExchMasterAccountSid laget. (Denne regelen er altså noe som er definert internt i Exchange. )Det finnes også andre tilfeller hvor denne problemstillingen er aktuell; feks ved bruk av Active Directory Connector mellom Exchange 5.5 og Active Directory i et migreringscenario. ADC vil som oftest lage flere deaktiverte brukere som har postbokser som må fungere.
Problemet
Alt denne høres jo tilsynelatende enkelt ut, hvorfor får vi da denne feilmelding? Og hvorfor kommer den så ofte? Svaret er at i det øyeblikket vi deaktiverer en bruker med postboks så blir ikke msExchMasterAccountSid attributten oppdatert med data, og følgelig så kan ikke store.exe finne riktig konto. Derfor kommer 9548 feilmeldingen i Application loggen. Hyppigheten på meldingen kommer av at hver gang store.exe forsøker å gjøre en operasjon knyttet til sikkerhet som angår en deaktivert bruker så vil den ikke kunne finne riktig konto og derfor logge feilen. Dette skjer minimum en gang hver natt under Exchange database vedlikehold (online maintenance), i mange tilfeller oftere.
Løsningen
Det er tre måte å fjerne denne meldinge på loggen ifra:
1. Manuelt
På hver deaktiverte konto med postboks må du gå inn på Exchange Advanced fanen, velge Mailbox rights og gi rettigheten ”Associated External Account” til SELF objektet. SELF er en såkalt well-knows SID og er egentlig en peker tilbake på brukerobjektet selv. Det du i praksis her gjør er å putte den aktuelle brukerens SID inn i msExchMasterAccountSid attributten, som igjen gjør at Exhcange kan finne korrekt bruker.
2. Automatisert – Script eller NoMAS
Å sette ”Associated External Account” rettigheten er en grei løsning for en eller to brukere, men hva med 100 eller 1000? Det sier seg selv at det er uaktuelt å tilbringe så mye tid i Active Directory Users and Computers Derfor kan også prosessen automatiseres. Microsoft har utviklet et verktøy kalt NoMAS (No Master Account SID) som søker igjennom katalogen og finner deaktiverte objekter som ikke har msExchMasterAccountSid attributten satt, og setter den til SELF objektet. NoMAS finner også aktive brukere som har msExchMasterAccountSid og fjerner den. Aktive brukere skal nemlig, som nevnt, ikke ha denne attributten satt, de skal benytte objectSID attributten. NoMAS kan du få gratis ved å kontakte Microsoft Support.
Hvis du liker utfordringer kan du også selv lage din egen versjon av NoMAS vha et ADSI VBScript eller NOMAD. Du vil da måtte lage et LDAP søk som finner alle deaktiverte brukere som har en msExchMasterAccountSid verdi og slette denne. Jeg har laget et slikt script hvis noen har lyst til å se hvordan det gjøres.
3. Hotfix – NY!!!
Nå kommer vil egentlig til poenget med hele dette tipset. Microsoft har nemlig endelig fått øynene opp for dette problemet og kommet med en hotfix som løser det en gang for alle. Det ble blesluttet av utviklingsteamet da Exchange 2000 ble designet at alle deaktiverte kontoer måtte ha msExchMasterAccountSid attributten og at det var denne som skulle benyttes som postboksens SID. En såkalt CDCR (Critical Design Change Request) er blitt godkjent og implementert, som endrer på dette kravet. Hotfixen endrer altså hvordan Exchange forsøker å finne den riktige brukeren i Active Directory for en postboks. La oss først se hvordan det fungerte før hotfixen:
1) Hvis kontoen som er assosiert med postboksen er deaktivert, og har msExchMasterAccountSid, og msExchMasterAccountSid ikke er SELF objektet, da skal msExchMasterAccountSid benytte som brukeren for denne postboksen. (Dette er feks tilfelle hvor en postboks brukes av en annen bruker eller gruppen enn den som postboksen er knyttet til.)
2) Hvis kontoen som er assosiert med postboksen er aktiv, eller den er deaktivert og har msExchMasterAccountSid satt til SELF objektet, da skal objectSid attributten benyttes for postboksen.
3) Hvis kontoen som er assosiert med en postboks er deaktivert, og ikke har msExchMasterAccountSid, eller hvis Exchange ikke kan avgjøre om brukeren er aktiv eller deaktivert pga tilgangskontroll, eller om Exchange ikke kan lese objectSid av samme årsak, da mislykkes operasjonen og 9548 feilmeldingen logges. (Første del er årasken til neste alle 9548 feilmeldinger vi ser på våre Exchange servere.)
Etter at hotfixen er lagt inn endres prosessen slik:
1) Hvis kontoen som er assosiert med postboksen er deaktivert, og har msExchMasterAccountSid, og msExchMasterAccountSid ikke er SELF objektet, da skal msExchMasterAccountSid benytte som brukeren for denne postboksen. (Ingen endring her.)
2) Hvis kontoen som er assosiert med postboksen er aktiv, eller den er deaktivert og har msExchMasterAccountSid satt til SELF objektet, eller hvis brukeren er deaktivert og ikke har msExchMasterAccountSid, da skal objectSid attributten benyttes for postboksen. (Stor endring.)
3) Hvis Exchange ikke kan avgjøre om brukeren er aktiv eller deaktivert pga tilgangskontroll, eller om vi ikke kan lese objectSid av samme årsak, mislykkes operasjonen og 9548 logges.
Etter hotfixen kan vi altså fortsatt få 9548 feilmeldinger, men da er årsaken et konkret problem med den assosierte kontoen.
Hotfixen kommer i to utgaver; en for Exchange SP1 og en for Exchange SP2, den er også planlagt inkludert i SP3 til Exchange 2003. SP1 utgaven er beskrevet i KB 903158, og SP 2 utgaven i KB 916783. Begge hotfixer kan fåes ved å kontakte Microsoft Support på telefon 22022545. Det vil ikke komme noen fix for Exchange 2000, hotfixen er bare for Exchange 2003.
Personlig har jeg lagt denne hotfixen inn på alle de Exchange servere jeg administrerer uten å se noen problemer, jeg anbefaler defor at alle gjør det samme. Selv om 9548 er en warning og ikke en error, kan den som sagt påvirke ytelsen og funksjonaliteten på din Exchange server.
Lykke til!
Morgan
