Allt detta är enkelt. Men det som störde oss var hur vi efter evenemanget ska räkna ut vem som äger vilken e-postadress. Till exempel om ett e-postmeddelande skickas till [email protected] då vet du vart det tar vägen? Är den mappad till en offentlig mapp, eller kanske till ett användarkonto? Om det senare, vems då? Är det en sekundär eller tertiär adress för ett konto som har ett mer mänskligt primärnamn, som [email protected]? Tja, det visar sig att det är anmärkningsvärt svårt att ta reda på sådan information med hjälp av Microsofts standardverktyg för AD.
Det finns några mycket användbara kommandoradsverktyg som låter dig gräva i dessa områden i katalogen: DSGET, till exempel, är ganska lätt att använda men det returnerar bara den primära e-postadressen för ett givet objekt. För att komma djupare in i stillheten måste vi använda verktyget DSQUERY. Stewart Jump kom på följande, vilket är en njutning:
dsquery * forestroot -scope subtree -filter (proxyadresser=smtp:[email protected]) -attr visningsnamn adspath
Om du skriver allt på en rad och ersätter [email protected] med lämplig e-postadress som du försöker slå upp, kommer du att returneras AD-namnområdet för objektet som äger det. Jag körde det mot mitt namn i min katalog och fick detta tillbaka:
C:>dsquery * forestroot -scope subtree -filter (proxyadresser=smtp:[email protected]) -attr visningsnamn adspath
visningsnamn adspath
Jon Honeyball GC://jonhoneyball.com/CN=Jon Honeyball,CN=Users,DC=jonhoneyball,DC=com
Som du kan se har detta omedelbart identifierat objektet i AD som äger namnet.
Du kan göra fler trick också, speciellt om du kombinerar kommandona. ’dsquery user -name Jon*|dsget user -office’ letar upp objekten i katalogen vars namn börjar med ’Jon’ med hjälp av DSQUERY-kommandot och skickar det sedan genom DSGET-verktyget för att returnera deras Office-namn. I det här fallet har jag namnet ”Suffolk” på min katalogpost för egenskapen ”kontor”.
C: >dsquery användarnamn Jon* | dsget user -office
kontor
suffolk
dsget lyckades
Så där har du det. Att begränsa dig till de klumpiga MMC-fönstren (Microsoft Management Console) är ingen bra idé, och det finns en hel del kraft att hitta i kommandoradsapplikationerna. Naturligtvis skulle inget av detta vara nödvändigt om serverledningsgruppen hade en ordentlig uppsättning grafiska modelleringsverktyg för AD, men det börjar låta som ett upprepat gnäll om hur Microsoft kastade bort en enorm marknadsföringsfördel med Visio, och på lång sikt läsare kommer tydligt ihåg min ståndpunkt i det ämnet.
