Rund um Windows, Exchange und Active Directory

Kategorie: Exchange (Seite 1 von 2)

Netzwerkadapter einem anderen Netzwerkprofil zuweisen

Mal wieder drüber gestolpert. Bei der Konfiguration eines separaten Netzwerkadapters für die DAG-Replikation auf einem Exchange 2016-Server wird er dem Netzwerkprofil „öffentliches Netzwerk“ zugeordnet und deshalb sehr restriktiv in der Firewall und den erweiterten Freigabeeigenschaften konfiguriert.
Ich habe dort kein Standard-Gateway eingetragen, weil die Exchange-Server sich ja in einem eigenen kleinen IP-Subnetz direkt unterhalten sollen.

Nun möchte ich erreichen, dass dieser Adapter dem privaten Netzwerkprofil zugewiesen wird.

Man öffne eine administrative Powershell und dann

PS C:> Get-NetConnectionProfile

Name : Nicht identifiziertes Netzwerk
InterfaceAlias : REPL
InterfaceIndex : 13
NetworkCategory : Public
IPv4Connectivity : NoTraffic
IPv6Connectivity : NoTraffic

Name : contoso.com
InterfaceAlias : LAN
InterfaceIndex : 8
NetworkCategory : DomainAuthenticated
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

PS C:\>Get-NetConnectionProfile -InterfaceAlias "REPL" |
Set-NetConnectionProfile -NetworkCategory Private

Erneuertes Zertifikat im Windows mit privatem Schlüssel verknüpfen

Im Zuge der SSL-Zertifikatserneuerungen wegen der neu signierten (Symantec)-Zertifikate die ja, wenn man sie nicht erneuert, unter Chrome ab Version 70 und auch später anderen Browsern ab mitte September Warnungsfenster anzeigen,  hatte ich für einen Exchange-Server routinemäßig einen neuen CSR (Certificate Signing Request) erzeugt. 

Doch der Zertifikatsdienstleister hat unter der Haube den originalen CSR für das Erneuern verwendet, was dazu führte, dass ich zwar ein neues Zertifikat bekam, dies aber nicht zum neu ausgestellten privaten Schlüssel passte. Stattdessen erhielt ich beim Importversuch eine Fehlermeldung, dass das Zertifikat bereits vorhanden sei (halt das bisherige). 

Weiterlesen

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.

« Ältere Beiträge