Exchange 2013 / 2010 - Verteilen der Datenbanken anhand der Präferenz

DAG ist eine feine Sache. Nie war es einfacher seine Exchange Daten ausfallsicher zur Verfügung zu stellen. Doch nach einem Failover gibt es keinen automatischen Failback der Datenbanken, obwohl den Datenbanken Präferenzen vergeben werden können oder besser müssen.

Bei mangelndem Monitoring der Exchange Server kommt es sogar vor, dass ein geschehener Failover nicht einmal auffällt. Um dies zu überwachen nehme ich meist ein Script von Paul Cunningham welches mir immer dann ein Mail schreibt, wenn auf dem Exchange etwas nicht so ist wie ich mir das wünsche: Test-ExchangeServerHealth

Wenn ich nun also feststelle, dass meine Datenbanken nicht auf den dafür vorgesehenen Servern aktiv sind, bediene ich mich eines Scripts welches wir von Microsoft bei der Installation von Exchange 2013 oder 2010 erhalten haben: RedistributeActiveDatabases.ps1

Um die mitinstallierten Scripts verwenden zu können müssen wir in der Exchange Shell zuerst in das entsprechende Verzeichnis wechseln. Die geht am einfachsten mittels folgenden Cmdlet:

cd $exscripts

Folgendes Cmdlet platziert die Datenbanken gemäss den konfigurierten Präferenzen:

.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$false

Weitere Infos zum Script findet ihr hier: Managing mailbox database copies (im unteren Bereich)

Lokales Administrator Passwort auf mehreren Computern ändern

Sicherheitsexperten empfehlen Passwörter regelmässig zu ändern. Dies wird in Firmenumgebungen meist über die Passwort Richtlinie (Default domain policy) durchgesetzt. Dabei werden aber die Passwörter der lokalem Administratoren-Konten meist vergessen. Wenn ein Eindringling einmal über das lokale Administratoren-Konto Zugriff auf einen Server erlangt hat ist es ein Leichtes auch Passwörter von Domänen-Konten heraus zu finden.

In grösseren Umgebungen ist es aber eher Umständlich die lokalen Administratoren-Passwörter regelmässig von Hand zu ändern. Dafür gibt es ja schlisslich auch Power Shell. so lassen sich auf einen Schlag die lokalen Administratoren-Passwörter von mehreren Computern / Servern ändern.

Active Directory Cleanup

Die digitale Welt stellt uns vor ganz neue Herausforderungen. Eine digitale Unordnung fällt nicht so schnell auf wie eine Digitale. Doch auch in der digitalen Welt ist Ordnung die halbe Miete. Digitale Unordnung findet man oft in der Active Directory. Server / Computer die ausser Betrieb genommen wurden oder Userobjekte von Mitarbeitern welche die Firma verlassen haben geistern oft noch lange in der AD umher und Ordnung zu schaffen ist sehr zeitraubend. Zum Glück hat uns Microsoft in den neueren OS-Versionen eine Power Shell Untersützung für die AD spendiert.

Nicht mehr verwendete Computerobjekte in der AD finden:

Eine Möglichkeit veraltete Computerobjekte in der AD zu finden ist zu schauen wann sich ein Computer zuletzt an der AD angemeldet hat. Dies kann über 2 verschiedene Parameter geschehen:

Get-ADComputer <Computer Name> -LastLogon

Finde Computerobjekte in deiner AD

Seit wir auch im AD-Umfeld mit Power Shell arbeiten können haben sich diverse neue Möglichkeiten ergeben um die eigene AD zu managen. Hier mal ein paar befehle um Computer oder Server in der AD zu finden und das Ergebnis nach bedarf zu filtern:

Finde alle Computer in der AD (Ausgabe in ein CSV):

Get-ADComputer -Filter { OperatingSystem -Like '*' } | Select -Exp Name | Out-File "C:\Scripts\Find_all_Computers_with_OS\All_Computers.csv"

Finde alle Windows Server in der AD (Ausgabe in ein CSV):

Get-ADComputer -Filter { OperatingSystem -Like '*Windows Server*' } | Select -Exp Name | Out-File "C:\Scripts\Find_all_Computers_with_OS\All_Windows_Servers.csv"

Remote Wipe oder Mobile Device Verwaltung für User deaktivieren

Seit Exchange 2010 können User ihre Mobile Devices über OWA selbst verwalten. Diese Funktion erlaubt den Usern auch für ihre Mobile Devices selbst Remote Wipes durchzuführen. Dies ist so nicht immer gewünscht und kann mittels einer OWA Mailbox Policy eingeschränkt werden.

Eine Default OWA Mailbox Policy wird bei der Installation von Exchange erstellt, diese OWA Mailbox Policy wird aber nicht automatisch auf User angewendet. Es kann also die Default OWA Mailbox Policy angepasst oder eine neue OWA Mailbox Policy erstellt werden.

Mit folgendem Befehl kann der/die Name/n der bestehenden OWA Mailbox Policy/s ausgelesenen werden:

Get-OwaMailboxPolicy |  select name

Ob einem User schon eine OWA Mailbox Policy zugewiesen ist kann mit folgenden Befehl geprüft werden:

Get-CASMailbox b.brunner | FL OWAMailboxPolicy

Um die Mobile Verwaltung für User in OWA zu unterbinden kann die OWA Mailbox Policy folgendermassen angepasst werden:

Set-OwaMailboxPolicy "Default" -ActiveSyncIntegrationEnabled:$false

Nun muss die OWA Mailbox Policy nur noch einem User zugewiesen werden:

Set-CASMailbox b.brunner -OwaMailboxPolicy "Default"

Bei der nächsten Anmeldung des Users in OWA ist der Navigationspunkt "mobile devices" nicht mehr ersichtlich.

Exchange Shell Befehle remote ausführen

Wenn Exchange Shell Befehle von einem Server ohne Exchange Installation ausgeführt werden sollen kann folgendes verwendet werden:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<URL virtuelles Verzeichniss Powershell>/powershell -Authentication Kerberos
Import-PSSession $Session -AllowClobber
<COMMANDS>
Remove-PSSession $Session

Exchange 2013 - Mobile Device Policy zuweisen

Um eine Mobile Device Policy mehreren Benutzern zuzuweisen können folgende Cmdlets verwendet werden:

Allen Benutzern im AD die gleiche Mobile Device Policy zuweisen:

Get-CASMailbox -ResultSize Unlimited | Where {$_.ActiveSyncMailboxPolicyIsDefaulted -eq $false} | Set-CASMailbox -ActiveSyncMailboxPolicy "My_MPR"

Allen Benutzern in einer OU eine Mobile Device Policy zuweisen:

Get-Mailbox -ResultSize Unlimited | Where {$_.OrganizationalUnit -eq "my.domain.com/iTrain/Mitarbeiter" -and $_.RecipientType -eq "UserMailbox"} | Set-CASMailbox -ActiveSyncMailboxPolicy "My_MPR"

Anmeldung an Exchange 2013 EAC mit internem Zertifikat nicht möglich

Unser gute Franky hat einen guten Blogeintrag zum Thema interne Zertifikate für Exchange 2013 verfasst: http://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/

Den Tipp von Franky habe ich schon oft benutzt, vor allem in Umgebungen mit einer .local Domain.

Nun habe ich bei einem Kunden mal wieder die interne CA bemüht um die CAS Kommunikation intern damit abzusichern. Nach Anleitung von Franky habe ich eine Zertifikatsvorlage erstellt und damit ein Zertifikat für die Exchange Server ausgestellt.

Nachdem wir dem Zertifikat den Dienst IIS zugewiesen haben konnten wir uns erstaunlicherweise nicht mehr an der EAC anmelden. Also haben wir über den IIS wieder das öffentliche Wildcard-Zertifikat zugewiesen. Siehe da, die Anmeldung an der EAC war wieder möglich.

Exchange Migrationen - Übernahme der internen Relay Konnektoren

Die meisten Firmen mit einer Exchange Umgebung haben auf ihren Exchange Servern spezielle Empfangs-Konnektoren konfiguriert welche es internen Systemen erlauben Mails über den Exchange Server zu senden, ohne sich authentifizieren zu müssen. Wie man solche Empfangs-Konnektoren konfiguriert habe ich ein einem früheren Blogpost erläutert: Exchange 2013 - Interner Relay Konnektor erstellen

In diesem Post will ich eine Möglichkeit aufzeigen, wie solche Konnektoren bei einer Migration einfach übernommen werden können.

In einem ersten Schritt werden die erlaubten IPs, welche den Konnektor verwenden dürfen, in eine Variable geschrieben:

$ips = (Get-ReceiveConnector "SRVEXC01\Internal Relay").RemoteIPRanges

SRVEXC01         = Name des Exchange Servers
Internal Relay     = Name des Empfangs-Konnektors

Nun kann der neue Empfangs-Konnektor über die Shell erstellt werden. Dabei werden die Remote IPs mit Hilfe der Variable eingefügt:

New-ReceiveConnector -TransportRole FrontendTransport -Name "Internal Relay" –Server "SRVEXCNEW01” -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers,ExchangeLegacyServers,AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIPRanges $ips

Welche Parameter es für das Cmdlet New-ReceiveConnector gibt ist übersichtlich auf TechNet aufgelistet: New-ReceiveConnector

Installationsprobleme Exchange 2013 - Check whether this is a valid user account

Bei der Vorbereitung einer AD für die Installation von Exchange 2013 wurde mir bei der Ausführung des Befehls "Setup /PrepareAD" folgende Fehlermeldung angezeigt:

Active Directory must be prepared with 'Setup /PrepareAD'. However, the current user account doesn't have the permissions required even though it's a member of the 'Enterprise Admins' group. Check whether this is a valid user account.

 Die Meldung ist mal wieder nicht besonders Aussagekräftig. "Du hast alles richtig gemacht aber irgendwas stimmt noch immer nicht, rate doch was es ist ;-)"

Nach längerer Suche haben wir dann das Problem gefunden. Wahrscheinlich durch ein etwas zu ambitioniertes Harding der Domäne wurde die "Default Domain Controller Policy" angepasst. Normalerweise wird über die "Default Domain Controller Policy" den Administratoren das Recht "manage auditing and security log" vergeben.

 Durch die Berechtigung der Administratoren können bei der Installation von Exchange auch die Exchange Server eingetragen werden. Bei diesem Kunden war nun die Berechtigung für Administratoren entfernt. Dies war der Grund für die Fehlermeldung. Nachdem der User, unter welchem wir Exchange installieren wollten, diese Berechtigung erhalten hat (gpudate /force) klappte die Vorbereitung der AD ohne Probleme.

Exchange 2010: Outlook Verbindung nach Reboot nicht möglich

Bei einer Migration auf Exchange 2010 bin ich kürzlich auf ein spezielles Phänomen gestossen. Nach erfolgreicher Installation von Exchange 2010 haben wir ein Testpostfach auf den neuen Exchange 2010 verschoben. Nach der Verschiebung hat Outlook seine neue Konfiguration über den Autodiscoverdienst ohne Probleme erhalten. Doch der Start von Outlook klappte nicht. Mit aktiviertem Cache-Modus erhielten wir folgende Fehlermeldung:

Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie eine Verbindung mit Microsoft Exchange mit ihrem aktuellen Profil herstellen.

Wenn wir den Cache-Modus deaktivierten bekamen wir eine Fehlermeldung die recht bizarr wirkt:

Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Die Datei "C:\Users\Username\AppData\Local\Microsoft\Outlook\Username@domain.ch - Outlook.ost" ist keine Outlook-Datendatei (OST).

Service Pack 1 für Exchange 2013 released

EDIT: Vorsicht - Die ersten Probleme mit dem SP1 sind schon aufgetaucht: http://eightwone.com/2014/03/05/exchange-2013-sp1-transport-agent-fix/

Gestern (25.02.2014) wurde das SP1 für Exchange 2013 released. Das Service Pack wurde von vielen sehnlichst erwartet. Nicht unbedingt aus technischen Gründen, sondern eher weil viele eine Migration auf eine neue Exchange Version erst nach erscheinen des ersten SPs ins Auge fassen, auch wenn schon 3 CUs erschienen sind.

Folgendes sind die spannenden Neuerungen welche mit dem SP1 dazu kommen:

• Installation des Exchange 2013 auf einen Server 2012 R2 wird nun unterstützt
• Domain Controllers unter Server 2012 R2 werden nun unterstützt
• Domain oder Forest functional Level 2012 R2 wird nun unterstützt
• MAPI over HTTP wurde als zusätzliches Protokoll für Clientverbindungen hinzugefügt
• DLP Richtlinien Tipps werden nun auch in OWA angezeigt
• EDGE Rolle wurde hinzugefügt

und noch so einiges mehr. Weitere Informationen windet ihr auf folgenden Seiten:

The Exchange Team Blog

EighTwOne #821

Exchange 2013 Training

Die iTrain GmbH (welche mein Arbeitgeber ist) bietet immer wieder Exchange Kurse an. Falls jemand Interesse an einer solchen Schulung hat, findet ihr Informationen und Termine auf unserer Website:
http://www.itrain.ch/de/it-education

Exchange 2013 auf Server 2012: Probleme beim erstellen einer DAG

Wenn Exchange 2013 auf einem Server 2012 installiert ist, gibt es Probleme beim Bilden einer DAG. Die Erstellung der DAG ist möglich, doch wenn man versucht Mailbox Server zur DAG hinzuzufügen kommt eine Fehlermeldung.

Um das Problem zu beheben, muss der FQDN im AD Clusterobjekt von Hand hinzugefügt werden.

Wenn man das AD-Objekt anschaut, sieht man, dass das Feld "DNS-Name" leer ist:

Es ist aber nicht möglich, direkt in das Feld rein zu schreiben. Dies muss über die Registerkarte "Attribute Editor" gemacht werden. Das zu befüllende Attribut heisst "dNSHostName":

Dies alleine löst aber das Problem noch nicht. Die Berechtigungen auf dem Objekt stimmen auch noch nicht. Wenn man im jetzigen Zustand versucht Mailbox Server zur DAG hinzuzufügen, bekommt man eine Fehlermeldung die besagt, dass der Zugriff verweigert wurde. Um dies zu beheben, muss man unter der Registerkarte "Security" der Gruppe "Exchange Trusted Subsystems" noch "Full Access" geben:

Nachdem dies erledigt ist, ist das Problem aber noch immer nicht vollständig gelöst. Im letzten Schritt muss das Objekt auch noch deaktiviert werden. Nun klappt es auch mit dem Hinzufügen von Mailbox Servern zur DAG.

Ich finde es doch sehr verwunderlich, dass dies auch nach dem Erscheinen des CU3 noch nicht behoben wurde...