Exchange – organisationsweit Weiterleitungen herausfinden

Es gibt einige Stellen, an denen Weiterleitungen eingerichtet sein können.
Patrick Grünauer hat das hier mal sehr gut zusammengefasst und mit 3 CmdLets lassen sie sich übersichtlich anzeigen.

ERGÄNZUNG: Grund dafür, dass ich versucht habe, herauszufinden, wo welche Weiterleitungen konfiguriert sind, war der Umstand, dass ein User meldete, dass Mails an einen abwesenden Kollegen immer automatisch an ein Funktionspostfach weitergeleitet werden. Ich konnte aber nirgends eine entsprechende Weiterleitung finden.
ABER: Es war ein OOF konfiguriert (nur intern). Reproduzierbar getestet ist es wirklich so, dass wenn der OOF (zumindest via Powershell-CmdLet von Serverseite aus) aktiviert ist, Mails weitergeleitet werden, wenn deaktiviert, dann nicht. Strange. Das Postfach ist schon uralt und wurde schon von Exchange 5.5 immer migriert. Mittlerweile ist es eine Exchange 2010-Umgebung.

Exchange Server 2016 – CU8-Upgrade

Klasse Checkliste von Frank Carius für das Upgrade einer Exchange-Server-DAG. In meinem Fall von CU6 nach CU8. Für das Schema- und AD-Upgrade sollte man nach der Schema-Erweiterung mit den üblichen Tools

repadmin /syncall /force
repadmin /replsum
repadmin /showrepl
Dcdiag /v

zunächst alle DCs wieder konsistent machen.

Dann geht’s los. Hier entlang.

Exchange 2010 – aktuelle Anmeldungen herausfinden

Manoman…nicht alles wird einfacher mit neueren Versionen. Möchte man gern sehen, welche Benutzer sich innerhalb der letzten Stunde am Exchange-Server angemeldet haben, hilft folgendes, übersichtliches CmdLet:

Get-Mailbox -Resultsize Unlimited | Get-MailboxStatistics | where-object {$_.LastLogonTime -gt (get-date).AddHours(-1)} | select Displayname, LastLogonTime | Sort LastLogonTime

Oder folgendes:

Get-LogonStatistics -Server „SERVERNAME“ | Sort-Object -property UserName -unique | where-object {$_.LastAccessTime -gt (get-date).AddMinutes(-30)}

Aber Achtung – OWA-Zugriffe werden hier nicht angezeigt.

MS Exchange 2010 – Backup mit der Windows Server-Sicherung und Powershell

Soll ein Exchange-Server gesichert werden, passiert das in der Regel z.B. so, dass man ihn mit einem Backup-Agent der zentralen Backuplösung versorgt, den Backupjob anlegt und ein paar Konfigurationen vornimmt.
Hat man diese zentrale Backuplösung nicht, kann man die integrierte Windows Server-Sicherung ab Server 2008 nutzen. Zumindest ab Exchange 2007 SP2, denn erst hier kam das VSS-Plugin (Volume Shadow Copy Service / Schattenkopien) für die Windows Server-Sicherung mit hinzu.
Wie man dann einen zeitgesteuerten Backupjob zusammenklickt, so dass Datenbanken und Logs gesichert werden, findet man schnell im Netz. Das Ergebnis ist dann aber ein Haufen von Dateien und mehreren Verzeichnissen – nicht mehr, so wie vormals, einzelne, .bkf-Dateien.
Wir müssen also noch komprimieren, packen und auf einen Backupserver kopieren. Im Fehlerfall möchten wir natürlich eine Benachrichtigung per E-Mail und ein Logfile. Außerdem soll das Backup der letzten 7 Tage in ein jeweiliges Wochentagsverzeichnis gespeichert werden. Zunächst lokal und dann in eine Freigabe eines Backupservers mit gleicher Ordnerstruktur.
Und da es noch ein paar andere Dinge gibt, die es zu beachten gilt, habe ich mir ein Powershell-Script für das Ganze geschrieben. Damit hat man ein tägliches .zip-File, das das Backup in ein jeweiliges Wochentagsverzeichnis kopiert. Im Fehlerfall (und wenn man möchte, auch im Erfolgsfall), wird man per Mail incl. Logfile benachrichtigt.

Um ZIPpen zu könnnen, habe ich mich für 7-Zip entschieden, was vorher installiert sein muss. Das packen ist Out-Of-The-Box bei der Powershell nur mit einer etwas längeren Codepassage möglich – und das Script ist so schon lang genug ;-). Ansonsten müssten nur die Pfade und ein paar Konstanten angepasst werden, dann sollte es laufen. Achtung wegen Zeilenumbrüchen. Ach ja – es wurde bei mir getestet mit Server 2008 R2 und Exchange-Server 2010 SP3 RU1.

Hier der direkte Download als ZIP: Exchange-daily-backup-official_v13

Update:
Im ZIP-File befindet sich auch eine Textdatei „diskshadow_script.txt“, in der der Laufwerksbuchstabe angepasst werden muss, auf der die Schattenkopien nach erfolgtem Backup aufgeräumt werden sollen. Das entspricht normalerweise der Backuplocation im Kopf des Backupscriptes.
Die Datei muss im selben Verzeichnis liegen, wie das Backup-Script.

Fehler 0x80070643 bei Installation des RU6 für Exchange 2010 SP2

Gestern versucht, RU6 zu installieren. Aktuell ist RU5v2. Es erschien ein Windows-Update Fehler (0x80070643) – übrigens funktionierte auch das Script „StartDAGServerMaintenance.ps1“ in der EMS nicht mehr. D.h. automatischer Wartungsmodus für einen Server, wenn man eine DAG hat, war nicht möglich. Ursache war das vor 4 Wochen per WindowsUpdate herausgebrachte „Windows Management Framework 3.0“, das u.a. die Powershell 3.0 mitbringt und diese wiederum nicht mit Exchange 2010 SP2 RU5v2 zusammenarbeitet. 🙂
Vorgehensweise ist hier, das Update (KB2506146) zu deinstallieren, neu zu starten, dann das RU6 (diesmal erfolgreich) zu installieren. Zuvor kann man übrigens trotzdem das Maintenance-Script benutzen – nur mit der PowerShell 2.0. Einfach eine neue Verknüpfung auf den Desktop legen mit folgendem Ziel:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2 -noexit -command „. ‚C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1‘; Connect-ExchangeServer -auto“

Exchange 2010 – Ressourcenreservierung mit E-Mail an Vertreter

Es soll eine Ressource vor der automatischen Genehmigung (Attribut „AutomateProcessing“) eine Freigabe vom Vertreter anfordern. Leider kommt die E-Mail nicht beim Vertreter an und die Ressource wird vom System automatisch gebucht.

Grund waren bei uns die Attribute „AllBookInPolicy“ (muss auf $false) und „AllRequestInPolicy“ (muss auf $true). Bei den standardmäßig angelegten Ressourcen ist das genau andersherum…

Set-CalendarProcessing -Identity <ResourcenPostfach> -AutomateProcessing AutoAccept -ResourceDelegates <email@des.stellvertreters> -AllBookInPolicy:$false -AllRequestInPolicy:$true

MSXFAQ.DE – AdminSDHolder

MSXFAQ.DE – AdminSDHolder.

Wenn Berechtigung „senden als“ in einem Exchange-Postfach nicht bleibt.

  1. Aus überwachter Gruppe entfernen
  2. Wert admincount auf 0 setzen
  3. Berechtigungen des Objektes zurücksetzen und von übergeordneten Ordner erben lassen

Exchange 2010 – Geräte für ActiveSync beschränken

Stichwort Pushmail. Toll, wenn Kollegen mit 1-2-3 Klicks ihr Smartphone um das Firmen-E-Mail-Konto ergänzt haben und diese dann ruck-zuck via Pushmail darauf landen. Nicht so toll ist, wenn man das mit jedem x-beliebigen Gerät machen kann – der Benutzer benötigt im Zweifelsfall nur den Benutzernamen und das Passwort in der Windows-Domäne. Gut – an der Authentifizierung ändern wir in diesem Artikel nichts, aber zumindest schränken wir die Endgeräte ein, mit denen sich Benutzer verbinden dürfen.

Ähnlich wie man in WLANs die Endgeräte festlegen kann, die sich verbinden dürfen, indem man einen MAC-Adressenfilter konfiguriert, funktioniert das auch bei ActiveSync.

Zunächst sollte man generell nur den Benutzern in den Eigenschaften des AD-Objekts die Funktion aktivieren, die auch Pushmail/ActiveSync einsetzen dürfen:

Dann kann man mittels EMS-Befehle die Smartphones anhand deren DeviceID beschränken. Im Standard ist das entsprechende Feld nämlich leer und bedeutet, dass beliebige Smartphones erlaubt sind.

Um herauszufinden, welches Smartphone der Benutzer registriert hat, verwendet man das CmdLet

Get-ActiveSyncDeviceStatistics -Mailbox:“Name@domaene.tld“ | fl DeviceID

Im Anschluss beschränkt man die erlaubten Smartphones:

Set-CASMailbox -Identity: „Name, Vorname“ -ActiveSyncAllowedDeviceIDs: „<DeviceID_1>“,“<DeviceID_2>“

Siehe http://technet.microsoft.com/de-de/library/aa998933.aspx.

Wer das Thema Absicherung weiter beleuchten möchte, sollte sich zudem noch die Themen Zertifikate und ActiveSync-Postfachrichtlinien anschauen.

Exchange 2010 – sichern von Daten ausgeschiedener Mitarbeiter

Es kommt ja mal vor, dass Kollegen das Unternehmen verlassen.
Nun gibt es ganz sicher eine Checkliste zur Deaktivierung des User-Accounts im Netz. 😉 Bezüglich des E-Mail-Accounts unter Exchange könnte dann nachfolgendes interessant sein.

Ist die Unternehmensrichtlinie dahingehend gestrickt, dass keine privaten Mails zugelassen sind, muss das Mail-Postfach langzeitarchiviert werden (andernfalls vielleicht auch, wenn der Mitarbeiter vorher seine privaten Mails herausgefiltert hat). Eine einfache Möglichkeit unter Exchange 2010, ohne dass der Admin gleich auf den Postfachinhalt zugreifen muss, sind folgende EMS-Befehle:

Exportieren des Postfachs in ein .pst-File auf eine Freigabe eines Servers:

New-MailboxExportRequest -Mailbox „Nachname, Vorname“ -FilePath „\\Server\BackupDB\Name_Backup.pst“

Da der Export serverbasiert läuft, kontrolliert man anschließend, ob er vollständig durchgelaufen ist:

Get-MailboxExportRequestStatistics -Identity Name\MailboxExport

Ist alles ok, kann der Job gelöscht werden:

Get-MailboxExportRequest | Remove-MailboxExportRequest

Weitere Impressionen unter http://technet.microsoft.com/de-de/library/ee633455.aspx.

Database Maintenance in Exchange 2010

Database Maintenance in Exchange 2010 – Exchange Team Blog – Site Home – TechNet Blogs und http://www.msxfaq.de/admin/defrag.htm und http://www.msxfaq.de/admin/database.htm.