Results for tag "exchange"

AD-Attribut Mailadressen auslesen

Ich bin ein großer Fan von PowerShell. Die Befehle gerade für das Active Directory bzw. Exchange erleichtern die Arbeit doch sehr. Allerdings findet man sich manchmal in Situationen wieder, in denen man etwas durchführen möchte ohne dass einem die PowerShell zur Verfügung steht. Dazu gehört das Auslesen von AD-Attributen in älteren Umgebungen ohne PowerShell.

Konkret hatte ich das Problem in einer Exchange 2003 Umgebung mit nur einem Domänenkontroller und der lief unter Windows 2000(!). Fragt lieber nicht…

Ziel war ein Umzug der Postfächer in ein neues Active Directory mit Exchange 2016. Aufgrund des Windows 2000 DCs (und dem Nichtvorhandensein von 3rd Party Tools) musste ein Teil der Arbeiten manuell gemacht werden. Zumindest für die Anlage der Benutzer konnte ich aber das PowerShell-Skript „Prepare-MoveRequest“ benutzen.

Nun wollte ich aber gerne überprüfen, ob alle SMTP-Adressen der Benutzer vollständig und korrekt übertragen wurden. Auf dem Zielsystem war das dank PowerShell ja kein Problem; nur die Option gab es in der Quellumgebung nicht. Hierzu griff ich dort zuerst auf CSVDE zurück. Das führte aber zu einem kleinen Problem…

Hierzu muss man wissen, dass Benutzer mehrere Mailadressen haben können. Fragt man nur das Attribut „mail“ ab, bekommt man höchstens die Adresse, die für ausgehende Mail eingetragen wird.

csvde -r "(mail=*)" -d "dc=contoso,dc=com" -l mail -f "C:\Temp\gal.csv"

Was man eigentlich abfragen will ist das Attribut „proxyAddresses“. Dummerweise enthielt dieses Attribut aber, neben den SMTP-Adressen, in meinem Fall auch noch X400- und X500-Adressen. Ich habe dann innerhalb von Excel versucht, diese Adressen irgendwie beim Import der CSV-Datei abzuspalten; aber dazu ist mein Excel Kung Fu wohl zu schwach.

Eine Suche im Internet brachte mich dann auf das Tool „ADFIND“[1],[2]. Leider entsprach das Ergebnis noch nicht meinen Wünschen. Aber nach ein bisschen Kopfkratzen kam ich dann auf

C:\System\AdFind.exe -nolabel -b OU=Desktop_User,DC=contoso,DC=com proxyAddresses

| find /I "smtp" > smtp-addresses.txt

(alles in einer Zeile)

Die Datei enthielt dann zwar eine Adresse pro Zeile; aber da es sich nur um 80 Mailboxen handelte, reichte das Ergebnis vollkommen aus.

Vielleicht hilft das ja jemand weiter.

[1] https://serverfault.com/questions/207574/how-to-export-all-e-mail-addresses-from-exchange-2003

[2] http://www.joeware.net/freetools/tools/adfind/index.htm

 

 

Wenn ich jedes Mal einen Euro dafür bekommen würde…

Leider trifft man immer wieder auf Windows-Umgebungen (Active Directory), in denen User einen Account zum Arbeiten und zum Administrieren nutzen. Ich möchte jetzt gar nicht über die Gründe sprechen, die aus Security-Sicht dagegen sprechen. Aber während einer Exchange-Migration tritt dann immer wieder ein Problem auf…

Folgendes Szenario: der neue Server ist aufgebaut und es werden die ersten User migriert. Plötzlich melden sich einzelne User, bei  denen die Synchronisierung ihres Smartphones mit ihrem Postfach nicht mehr klappt[1]. Schaut man sich nun die betroffenen User an, stellt man fest dass sie Mitglied in einer oder mehrere administrativen Domänen-Gruppen sind. In diesem Fall greift etwas, dass unter dem Stichwort „AdminSDHolder“ bekannt ist. Um administrative Konten zu schützen, werden regelmäßig (jede Stunde) alle Konten auf diese Mitgliedschaft geprüft. Falls das betreffende Konto Mitglied z.B. in der Gruppe der Domänen-Administratoren ist, dann wird die Berechtigungsvererbung abgeschaltet. Das führt aber auch dazu, dass Exchange nun bestimmte Rechte auf dem User fehlen. Aber ohne diese Eintragung findet keine Erstsynchronisation statt…

Bei  der ersten Synchronisation mit dem neuen Server wird im Regelfall das Gerät im Benutzerkonto eingetragen. Fehlen Exchange aber die entsprechenden rechte, schlägt diese Eintragung fehl.

Was kann man da tun:

– kurzfristig: die Vererbung wieder einschalten. Siehe hierzu [2], [3] oder [4]

– langfristig: Administratoren müssen zwei Konten nutzen. Das mag unbequem sein, ist aber auch aus anderen Gründen sinnvoll. Und bei der Gelegenheit kann man ja auch mal schauen, ob wirklich für alle Mitglieder dieser Gruppen die Mitgliedschaft (noch) notwendig ist.

Wer sich für die Hintergründe interessiert, findet entweder unter den obigen Links etwas oder auch unter [5] bzw. [6].

Dieses Problem tritt immer wieder auf (bei einem Kunden war es schon unser running gag); daher also die Überschrift…

[1] Alternativ können sie sich auf dem neuen Server nicht an Outlook Web Access anmelden. Hier liegt es daran, dass man bei der ersten Anmeldung die bevorzugte Sprache und die Zeitzone angeben muss; das wird dann im Benutzerkonto vermerkt. Diese Eintragung schlägt aber fehl, weil Exchange die entsprechenden Rechte auf dem User fehlen.

[2] http://www.msxfaq.de/konzepte/adminsdholder.htm

[3] http://www.serverhowto.de/Der-AdminSDHolder.477.0.html

[4] http://blog.mrinas.de/2011/11/12/adminsdholder-oder-warum-habe-ich-keine-rechte/

[5] http://blogs.technet.com/b/askds/archive/2009/05/07/five-common-questions-about-adminsdholder-and-sdprop.aspx

[6] http://policelli.com/blog/archive/2009/11/06/understanding-adminsdholder-and-protected-groups/

PS: wie immer gilt: für den Inhalt der externen Links bin ich nicht verantwortlich.

Dude, where is my OWA?

Ich migriere gerade bei einem Kunden von Exchange 2003 auf Exchange 2013. Da wir rein mit Bordmitteln arbeiten, müssen wir den Zwischenschritt über Exchange 2010 machen. Ich bearbeite gerade ein Problem mit den öffentlichen Ordnern und deshalb musste ich meine Mailbox zurück auf den alten Server verschieben (um sicherzustellen, dass in meinem Outlook auch der alte „Öffentliche Ordner“ Speicher genutzt wird).

Im Gespräch mit dem Administrator kamen wir auf das neue (ab Exchange 2010 geltende) Berechtigungsmodell zu sprechen (Stichwort: RBAC). Ich wollte seinen User nun so berechtigen, dass er auch den neuen Server administrieren darf. Dazu rief ich aus der Toolbox den entsprechenden Punkt auf. Dieser Punkt wird aber in Exchange 2010 über die ECP-Konsole administriert, also über den Browser.  Und dort wurde mir dann nach der Anmeldung eine Fehlermeldung präsentiert:

Seite nicht gefunden. Mit der von Ihnen eingegebenen Adresse ist kein Zugriff auf das Postfach möglich. Die korrekte Adresse erhalten Sie vom Helpdesk.

Nachdem ich dann ein bisschen gesucht hatte und auf die Lösung gestossen bin, war das wieder so ein „hätte ich auch selbst drauf kommen können“ Moment. Ich melde mich beim Exchange 2010 OWA an, um auf die ECP-Seite zu kommen. Nur liegt ja mein Postfach auf dem „alten“ Server, auf dem es keine ECP-Seite gibt. So schlägt der Redirect natürlich fehl.

Merke für die Zukunft: eigenen Test-Account anlegen.

 

 

PowerShell + Exchange 2010: Status der Export Requests abfragen

In Exchange 2010 kann man ja schön aus der PowerShell heraus (entsprechende Rechte vorausgesetzt) Mailboxen in PST-Dateien exportieren. Hierzu erstellt man mit dem Kommando New-MailboxExportRequest einen neuen Export Request, der dann nach kurzer Zeit abgearbeitet wird. Man kann zwar die Requests am Ende mit Remove-MailboxExportrequest wieder löschen; aber es kann Situation geben, in denen man auf die erledigten/fehlgeschlagenen Requests noch zugreifen will (um z.B. den Grund für einen Fehlschlag später nachschlagen zu können). Oder man hat einfach vergessen sie zu löschen;-)

Mit dem Befehl Get-MailboxExportRequest Statistics kann man sich Informationen über einen Export Request anzeigen lassen; anbei ein Beispiel, wobei ich mich auf einige Attribute beschränke. Der Befehl

get-mailboxexportrequest -name MailboxExport7 -mailbox „fabrikam.com/Benutzer/Thomas Wallutis“ | get-mailboxexportrequeststatistics | fl name,status,filepath,sourcemailboxidentity,sourcedatabase, starttimestamp, completiontimestamp, bytestransferred, itemstransferred

führt zu der Ausgabe

Name : MailboxExport7
Status : Completed
FilePath : \\server\pst-files\thomas.wallutis.pst
SourceMailboxIdentity : fabrikam.com/Benutzer/Thomas Wallutis
SourceDatabase : Mailbox Database 0248583270
StartTimestamp : 08.09.2014 14:03:27
CompletionTimestamp : 08.09.2014 14:26:46
BytesTransferred : 1.065 GB (1,143,315,403 bytes)
ItemsTransferred : 10745

„Name“ ist hierbei der Name des Export Requests, wobei Requests je anch Art des Aufrufs auch denselben Namen haben können. Interessant ist hierbei nun das Attribut „StartTimeStamp“, wenn ich mir alle Requests anzeigen lassen will, die zur selben Zeit gestartet sind. „CompletionTimestamp“ ist etwas problematisch, da ein fehlerhafter Export Request (z.B. mit falschem Parameter) auch ind er Liste auftaucht, aber das Attribut ist dann leer.

Das Interessante bei Filtern im Zusammenhang mit PowerShell ist, welcher Filter der gerade Passende ist. Im hierbetrachteten Fall möchte ich alle Requests sehen, die am selben Tag gestartet sind; allerdings ohne Angabe der Uhrzeit. Der passende Vergleichsoperator ist dann „-match“, da er auf passende Teilausdrücke prüft:

get-mailboxexportrequest | get-mailboxexportrequeststatistics | where { $_.StartTimeStamp -match „09.09.2014 „} | fl sourcemailboxidentity, status

Dieser Aufruf gibt mir alle Mailboxen zurück, die am betreffenden Tag exportiert wurden (unabhängig davon ob der Export erfolgreich war).

Vielen Dank an Andreas E. für den Tipp mit „-match“.

 

Spaß mit Office365 – Teil 1

Mit der Cloud ist es wie mit dem rheinischen Karneval (zumindest wenn man Kunden in Köln hat): man muß es nicht mögen, aber entgehen kann man Beidem nicht.

Ich beschäftige mich seit einigen Tagen mit O365; genauer gesagt mit einem O365 E3 Plan und der Migration von Exchange dorthin. Dabei fallen einem ein paar Dinge auf; heute geht es mir insbesondere um die Befehle zur User-Administration.

Es gibt zwei Wege zur Benutzeradministration: die Weboberfläche und PowerShell. Über die Weboberfläche legt man einen User an und legt fest, ob dieser administrative Rechte bekommt. Gibt man dem User hier z.B. das Recht „Globaler Administrator“, kann dieser aber noch nicht Teilbereiche wie Exchange administrieren. Dieses gelang mir erst, nachdem ich dem User auch eine Exchange-Lizenz zugewiesen habe.

Während der Migration musste ich mehrfach User auf der O365 Seite löschen (dazu vielleicht ein anderes Mal mehr). Dabei bin ich über etwas gestolpert, was vielleicht auch Anderen schon Kopfschmerzen bereitet hat. Bei der Synchronisation zwischen OnPremise- und O365-Server tauchte die Meldung auf, dass der User schon vorhanden ist. Wie ich auf die harte Tour lernte, wird bei der Option „Übernahme-Migration“ (empfohlen für kleinere Umgebungen) immer ein neuer User auf O365-Seite erzeugt. Leider habe ich bisher nichts gefunden, aus dem klar hervorgeht, auf welche Attribute hierbei geprüft wird; die Fehlermeldung war da nicht hilfreich. Nehmen wir mal an, dass der User „Klaus Test“ heisst und der Username klaus.test ist. Wird nun bei der Synchronisation klaus.test angemeckert („schon vorhanden“), dann kann es sich um ein Exchange-Attribut oder um ein Azure AD Attribut handeln.

Über die Weboberfläche kann ich dem User die Postfach-Lizenz entziehen, was zur Löschung des Postfaches führt. Ferner kann ich (an anderer Stelle) den User komplett löschen.
Nun beginnt der interessante Teil: auch nach dem Löschen des Users bekomme ich immer noch die Fehlermeldung bzgl. des existierenden Users bei der Synchronisation. Der User landet nämlich im Papierkorb und kann von dort wiederhergestellt werden. Ich habe nur keine Möglichkeit in der Weboberfläche gefunden, wie man dort einen User auch aus dem Papierkorb löscht.

Es bleibt also wieder mal „nur“ die PowerShell. Hier lauert aber der Haken: es gibt zwei verschiedene Powershell-Sessions! Nehmen wir mal an, wir wollen Exchange Online per PowerShell verwalten. Wie benötigen dazu eigentlich nur einen Windows 7 oder 8 PC (bzw. die entsprechende Serverversion) sowie .Net Framework 4.5 bzw. 4.5.1 sowie Windows Management Framework 3.0/4.0.

Zuerst muss ich angeben, mit welchem User ich auf Exchange Online zugreifen möchte. Das geht wie an anderer Stelle auch über

$UserCredential = Get-Credential

Es geht eine Anmeldebox auf, in die man die Anmeldedaten einträgt. Diese werden dann in der Variable $UserCredential abgelegt. Im nächsten Schritt wird die Verbindung zu Exchange Online aufgebaut:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Die erstellte Session wird noch eingebunden:

Import-PSSession $Session

Wichtig ist, dass man die Session auch wieder beendet, nachdem man sie nicht mehr braucht. Andernfalls muss man warten, bis die Session automatische beendet wird, bevor man sich wieder verbinden kann:

Remove-PSSession $Session

Nachlesen kann man das in der Exchange Online-Hilfe, aus der ich die Befehle übernommen habe: http://technet.microsoft.com/en-us/library/jj984289%28v=exchg.150%29.aspx

Damit stehen nun Exchange PowerShell-Befehle zur Verfügung wie z.B. Get-Mailbox. Führt man diesen Befehl aus, sieht man übrigens auch dass die Postfächer nicht zwingend auf einem Server liegen müssen.

Auch der Befehl Get-User ist vorhanden. Schauen wir uns nun in der Exchange-Hilfe an, wofür welcher Befehl genutzt wird, so finden wir:

Get-User: Verwenden Sie das Cmdlet Get-User, um alle Benutzer aus der Gesamtstruktur abzurufen, die den angegebenen Bedingungen entsprechen. [1]

Get-Mailbox: Mithilfe des Cmdlets Get-Mailbox können Sie die Postfachobjekte und -attribute anzeigen, Eigenschaftenseiten auffüllen oder Postfachinformationen an andere Tasks übergeben. [2]

Interessant ist hierbei die Frage, welche Befehle es für das Entfernen eines Benutzers gibt. Exchange unterscheidet hier Disable-Mailbox und Remove-Mailbox (ein Delete-User gibt es nicht). Der erste Befehl entfernt nur das Postfach sowie die Exchange-Attribute; der zweite Befehl entfernt auch das AD-Benutzerkonto.

Das Problem hierbei ist nur, dass das AD-Konto neuerdings für 30 Tage aufbewahrt wird. Wie kann man nun das Userobjekt dauerhaft löschen?

Und hier wird es jetzt spannend: man benötigt Zugriff auf das Azure Active Directory. Unglücklicherweise geht das aber nicht über die oben beschriebene Session; hierzu benötigen wir auch ein neues PowerShell-Modul.

Hierbei ist zu beachten, dass es sowohl PowerShell für Azure[3] als auch ein PowerShell-Modul für Azure Active Directory[4] gibt.

Ich will hier nicht alle Schritte wiedergeben; die angegebenen Links enthalten gute Anleitungen. Ich möchte nur kurz zeigen, wie die Verbindung aufgebaut wird.

Zuerst werden wieder die Anmeldedaten abgefragt und in einer Varibalen abgespeichert:

$msolcred = get-credential

Danach wird die Verbindung aufgebaut; man beachte hier die gegenüber der O365-Anbindung deutlich einfachere Syntax:

connect-msolservice -credential $msolcred

Einen Befehl Remove-Msolservice oder Disconnect-Msolservice scheint es nicht zu geben.

Hat man nun erfolgreich die Verbindung aufgebaut, kann man sich endlich die gelöschten Objekte anzeigen lassen:

Get-MsolUser -ReturnDeletedUsers | fl

Man beachte hierbei den Zusatz „Msol“ beim Befehl!

Für das Löschen benötigt man nun die ObjectId des Users:

Remove-MsolUser -ObjectId d21855e9-7979-4ea0-9681-04628bf418da -RemoveFromRecycleBin -force

Danach überzeugt man sich durch ein erneutes Ausführen von

Get-MsolUser -ReturnDeletedUsers | fl

dass das Objekt wirklich gelöscht wurde.

Ich würde empfehlen nach der Löschung einige Zeit zu warten, bevor man den User erneut anlegt.

[1] http://technet.microsoft.com/de-de/library/aa996896%28v=exchg.150%29.aspx

[2] http://technet.microsoft.com/de-de/library/bb123685%28v=exchg.150%29.aspx

[3] http://azure.microsoft.com/de-de/documentation/articles/install-configure-powershell/

[4] http://technet.microsoft.com/en-us/library/jj151815.aspx