Exchange Log Partition läuft voll

Grundsätzlich sollte dies nicht passieren. In einer produktiven sorgt das Backup dafür, dass die Logfiles der Datenbanken nach jedem erfolgreichen Backup gelöscht werden. Dies verhindert, dass die Log-Platten eines Exchange Servers voll laufen.

In einer Testumgebung wird eher selten ein funktionierendes Backup eingerichtet. Daher kann es vorkommen, dass die Laufwerke mit den Logfiles der DBs gefüllt werden. Um die Logs wieder los zu werden, gibt es einen simplen Trick.

1. Starte auf dem Exchange ein CMD mit erhöhten Rechten
   
2. Tippe "Diskshadow" und drücke Enter
   
3. Tippe "add volume x:" und drücke Enter (das "x" mit dem Laufwerksbuchstaben ersetzen, auf welchem die Logs liegen)
   
4. Tippe "begin Backup" und drücke Enter
   
5. Tippe "create" und drücke Enter
   
6. Wenn der Vorgang abgeschlossen ist, tippe "end Backup" und drücke Enter

Nach kurzer Zeit kann man zusehen, wie sich die Logfiles "in Luft auflösen".

Die Verwendung dieser Prozedur geschieht auf eigene Gefahr ;-)

OWA und EAS Log Analyse

OWA Log Analyse

Die Zugriffe auf OWA lassen sich mittels der IIS Logs analysieren. Dazu kann man das MS Tool «LogParser 2.2» verwenden. Das Tool lässt sich hier herunter laden:

https://www.microsoft.com/en-us/download/details.aspx?id=24659

Arbeitsordner erstellen

Für die Analyse der IIS Logs ist es am einfachsten, zuerst mal einen Arbeitsordner zu erstellen. Danach werden dort die Logs abgelegt, welche analysiert werden sollen.

Hierarchisches Adressbuch

In grossen Organisationen stellt sich immer wieder die Frage, wie Adressbücher übersichtlich gestaltet werden sollen. Seit Exchange 2010 SP1 haben wir eine neue Funktion bekommen, welche sich «Hierarchisches Adressbuch» nennt. Das Ganze sieht wie folgt aus:

Der Aufbau eines hierarchischen Adressbuches wird über Verteilerlisten gesteuert. Diese werden ineinander verschachtelt und so gekennzeichnet, dass sie im hierarchischen Adressbuch berücksichtigt werden. Wie das geht, zeige ich anhand einer Step by Step Anleitung am Beispiel der Firma, in welcher ich arbeite. Das Ziel ist, ein hierarchisches Adressbuch aufzubauen, wie ihr es oben in der Ausbildung sehen könnt.

Mail versenden mit Alias

Hatte gerade eine Anforderung eines Kunden. Dort sollen Leute Mails wahlweise unter einem Alias versenden können anstelle unter der Standard Antwort Adresse die im Postfach konfiguriert ist. Grundsätzlich ist dies nicht möglich. Es musste also ein Workaround gefunden werden.

Als erstes habe ich natürlich daran gedacht, einfach den Alias vom Postfach zu entfernen und ein separates Postfach mit der Adresse zu erstellen. Dann gibt man noch «Vollzugriff» und «Senden als» Berechtigungen für die Person, welche die Adresse verwenden will.
Nachteil dieser Lösung ist, dass der User am Ende eine weiteres Postfach im Outlook hat und auch die gesendeten Mails werden natürlich in diesem zusätzlichen Postfach abgelegt. Diese Lösung gefiel dem Kunden nicht. Die User sollen weiterhin nur ein Postfach im Outlook haben und über die Auswahl im «Von Feld» die zweite Adresse auswählen können. Auch sollen die gesendet Mails in diesem einen Postfach abgelegt werden.

Im Internet findet man auch Lösungsansätze, die sich mit einem POP3 «dummy» Postfach behelfen. Ich wollte keine POP3 auf dem Exchange aktivieren und habe weiter nach einer bessern Lösung gesucht.

Exchange 2010 - RU9 für SP3 verfügbar

Auch am 17.03.2015 wurde das RU 9 für SP3 zum download bereit gestellt. Informationen dazu findet ihr auf dem Exchange Team Blog.

Download: http://www.microsoft.com/en-us/download/details.aspx?id=46372

Knowledge Base Article: https://support.microsoft.com/en-us/kb/3030085

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)

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 ESE Performance: Spanender Blog-Post von Michel de Rooij

Wir bekommen von Microsoft bei jeder neuen Exchange Version neue Zahlen zu Performance-Verbesserung auf der DB-Seite vorgesetzt. Michel de Rooij hat sich nun mal die Mühe gemacht und die Performance von Exchange 2010 und 2013 im LAB verglichen. Hier sein äusserst spannender Blog-Post zum Thema:

http://eightwone.com/2013/12/16/exchange-storage-performance-2010-versus-2013/

Ich wünsche allen Interessierten viel Spass beim lesen.

Exchange DAG Cluster Fehler 1196 (Source Microsoft-Windows-FailoverClustering)

Normalerweise muss der Failover Cluster Manager für die Verwaltung einer DAG nicht bemüht werden. Doch wenn ich mir eine Exchange Umgebung anschaue will ich natürlich auch immer wissen ob in den Clusterereignissen Fehler zu finden sind.

Häufig treffe ich dann auf folgenden Fehler:

Protokollname:             System
Quelle:                    Microsoft-Windows-FailoverClustering
Datum:                     13.12.2013 11:50:42
Ereignis-ID:               1196
Aufgabenkategorie:         Netzwerknamenressource
Ebene:                     Fehler
Schlüsselwörter:
Benutzer:                  SYSTEM
Computer:                  EXCLAB-MBX01.mydomain.ch

Beschreibung:
Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache:
Der DNS-Vorgang wurde abgelehnt.

Service-User überschreiten DefaultThrottlingPolicy Limite

In Exchange 2010 gibt es die "Default Throttling Policy". Diese Policy kann verwendet werden, um User mit zu vielen Zugriffen vorübergehend zu sperren. Dies muss aber zuerst einmal eingeschaltet werden. Doch auch wenn die automatische Sperrung von Usern (mehr als 100 Zugriffe in der Minute) nicht eingeschaltet ist, meldet Exchange eine Überschreitung der vorgegebenen Limite. Dies geschieht vor allen für Service User von Archivsystemen und Backup-Lösungen. Auch Black Berry Service Konten können davon betroffen sein. Folgende Meldung findet sich dann im Eventlog:

*****************************************************************

The following errors are found in event log:

Log Name:          Application

Source:            MSExchange ADAccess

Date:              27.11.2013 10:02:42

Event ID:          2915

Task Category:     General

Level:             Error

Keywords:          Classic

User:              N/A

Computer:          EXC02.meinefirma.group

Description:

Process Microsoft.Exchange.RpcClientAccess.Service.exe (PID=2944). User 'Sid~MEINEFIRMA\service-user-sourceone~RCA~false' has gone over budget '6075' times for component 'RCA' within a one minute period. Info: 'Policy:DefaultThrottlingPolicy_2be1899d-34f9-41c7-94bb-31285d6d4723, Parts:RPC:6074;'. Threshold value: '100'.

*****************************************************************

Falls diese Meldung einen Service-User einer Backuplösung, Archivlösung oder von Black Berry bertifft, ist die Überschreitung des Limits nachvollziehbar. Daher kann bedenkenlos eine eigene Throttling Policy für diese Service-User erstellt werden. Das Anlegen einer neuen Throttling Policy geschiet über die Exchange Shell:

New-ThrottlingPolicy “ThrottlingPolicySourceone” -RCAMaxConcurrency $null -RCAPercentTimeInMailboxRPC $null -RCAPercentTimeInCAS $null -RCAPercentTimeInAD $null

Nach der Erstellung der neuen Throttling Policy kann diese nun den Service-Usern zugewiesen werden:

Set-Mailbox –Identity “service-user-sourceone” –ThrottlingPolicy ThrottlingPolicySourceone

Danach verschwinden auch diese Meldungen aus dem Eventlog.

Exchange Control Panel detected an invalid canary...

Ein Error, den ich oft auf Exchange Servern finde, betrifft das Exchange 2010 eigene Monitoring:

****************************************************

Log Name:      Application

Source:        MSExchange Control Panel

Date:          27.11.2013 09:39:05

Event ID:      38

Task Category: General

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      EXC01.meinefirma.group

Description:

Current User: 'meinefirma.group/Users/extest_5b0430f268f54'

Exchange Control Panel detected an invalid canary from request for URL 'https://owa.meinefirma.com/ECP/RulesEditor/InboxRules.svc/GetList'.

Canary in cookie: '9gBwZ2WnHEKOH9y0Chu4n8a0tJj1utAIRzsD_QgsxXYc6t3ohGjzO9KIZ3MttTOMslTr18Ycdoo.' mismatch with canary in header/form: ', in URL '.
**************************************************************

Eigentlich lässt sich aufgrund dieses Error-Eintrages im Eventlog keine Funktionseinschränkung von Exchange feststellen. Die Einträge sind aber lästig. Wenn wir in Google nach dem Problem suchen, kommen wir schnell mal auf folgende Seite: http://support.microsoft.com/kb/2494389/en-us

Bringen tut die Lösung auf dieser Seite den wenigsten etwas, denn die meisten werden das Rollup 3 für Exchange 2010 SP1 schon lange installiert haben.

Erstaunlicherweise ist aber die Lösung des Problems, oder besser die Eliminierung der lästigen Einträge im Eventlog, denkbar einfach. In den einstellungen des virtuellen Verzeichnisses "ECP" ist per default folgende URL angegeben: https://owa.meinefirma.com/ECP

Wenn man nun die Grossbuchstaben durch Kleinbuchstaben ersetzt, verschwinden die Einträge im Eventlog. Irgendwie habe ich wohl verpasst, dass IIS sich seit neustem für Gross- und Kleinschreibung interessiert ;-)

Server 2012 R2 und Exchange

Heute habe ich in diversen Blogs gelesen, dass es nicht zu empfehlen ist Exchange (2010 oder 2013) unter Windows Server 2012 R2 zu betreiben. Soweit ich dies beurteilen kann, gibt es vor allem Probleme wenn man einen In-Place Update des OS unter dem Exchange macht. Danach war bei den meisten die Exchange Power Shell nicht mehr verfügbar und die DBs liessen sich nicht mehr mounten.

Grundsätzlich sollte man aber wissen, dass ein In-Place OS Upgrade eines Exchange Servers schon seit Exchange 2003 nicht mehr supportet ist!

Weiter ist es sicher auch wichtig, dass man sich vor der Installation anschaut, welche OS-Versionen für die Exchange-Version die man verwenden will, supportet ist:
http://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx

Ich betreibe im Moment eine LAB-Umgebung mit Server 2012 R2 und Exchange 2013 CU2. Dies läuft ohne Probleme. Doch ich würde dies nie in einer produktiven Umgebung einsetzen, bevor Microsoft dies nicht offiziell supportet.

Im Übrigen sollte man sich mit der Inbetriebnahme eines DCs unter Server 2012 R2 in einer Domäne mit Exchange Organisation auch noch etwas Zeit lassen, bis Microsoft auch dies offiziell supportet.

Hier noch der Link zum TechNet Blog zu dem Thema: http://blogs.technet.com/b/rmilne/archive/2013/09/17/exchange-support-for-windows-server-2012-r2.aspx

Update: Das SP1, welches im ersten Quartal 2014 erscheinen soll, wird die Unterstützung von 2012 R2 mitbringen.

DB Mounten bei DAG Problemen

Bei Problemen mit der DAG unter Exchange 2010 oder 2013 kann es dazu kommen, dass sich die Mailbox-DBs nicht mehr mounten lassen, weil die DAG nicht funktionsfähig ist. Natürlich sollte das Problem der DAG analysiert und behoben werden. Doch es kann auch der Fall auftreten, dass die DBs so schnell wie möglich wieder gemountet werden müssen und man dann in Ruhe nach dem Problem der DAG suchen kann.
Dies geht aber nicht, weil jede DB einen Master hat. In Umgebungen ohne DAG ist dies der MBX Server auf welchem die DB läuft. Wenn eine DAG erstellt wurde, wird als Master der DB die DAG eingetragen. Darum lassen sich DBs nur mounten, wenn die DAG, welche der Master ist, auch funktionsfähig ist.

Exchange 2013 - Maximale Mailgrösse

Unter Exchange 2013 die maximale Mailgrösse einzustellen sorgt immer wieder für Verwirrung. Viele Administratoren kommen relativ schnell darauf die Einstellungen im Send- und Empfangskonnektor zu suchen. Leider reicht es aber nicht. Die eigentliche Transport-Konfiguration muss ebenfalls angepasst werden.

Anpassen der Transport-Konfiguration

Anzeigen der aktuellen Transport-Konfiguration:

Get-TransportConfig | fl *max*

Die wichtigsten Werte sind  MaxReceiveSize und MaxSendSize. Diese geben die maximale Mailgrösse an.

Exchange 2010: Sofortige Aktualisierung des Offline Address Book

Oft sehen die User die das Outlook im Cache-Modus betreiben neu erstellte Empfängerobjekte erst am nächsten Tag. Mit folgenden Schritten kann die Aktualisierung des OAB forciert werden:

1. In der Exchange Shell:
   Update-OfflineAddressbook <Name des OAB>
2. Neustart des Dienstes "Microsoft Exchange System Attendant" (Deutsch: Microsoft Exchange-Systemaufsicht) auf dem MBX Server der das OAB generiert.
   
3. In der Exchange Shell:
   Update-FileDistributionService  <CASServerName>
   
   Wenn mehrere CAS Server vorhanden sind:
   Get-ClientAccessServer | Update-FileDistributionService

Nun sehen auch Clients im Cache-Modus die aktuellen Informationen im Adressbuch.

Exchange 2010: Schnell wachsende Logfiles

Auf einem Exchange 2010 kommt es immer wieder vor, dass die Logpartitionen voll laufen. Meist liegt es daran, dass  das Backup nicht sauber gelaufen ist und die Logfiles der Mailbox Datenbanken dadurch nicht gelöscht wurden.

Falls das Backup aber sauber gelaufen ist und sich die Logplatte füllt bevor das nächste Backup läuft, ist es von Vorteil wenn man nachsehen kann woher den die unverhältnismässig vielen Logfiles kommen.

Exchange 2010 - Postfächer deaktivieren und wieder anhängen

In Exchange 2010 gibt es die Möglichkeit Postfächer zu deaktivieren. Im Unterschied zu löschen eines Postfaches bleibt beim Deaktivieren das Userobjekt in der AD erhalten. So können Postfächer einem anderen User angehängt werden.

Natürlich gibt es bei so einer Aktion auch noch den Aspekt des Datenschutzes, ich schreibe hier aber einen technischen Blog und keinen Rechtlichen.

Die Postfächer lassen sich am einfachsten über die EMC deaktivieren. Dazu macht man einfach einen Rechtsklick auf das Postfach und wählt "deaktivieren". In der Shell kann folgender Befehl verwendet werden:

Event ID: 2937 Source: MSExchange ADAccess Process w3wp.exe

Nach einer Exchange Migration gibt es immer wieder Fehlermeldungen im Eventlog der neuen Exchange 2010 Server welche besagen, es gäbe in der Konfiguration Verweise auf gelöschte Objekte in der AD:


Log Name:      Application
Source:        MSExchange ADAccess
Event ID:      2937
Task Category: Validation
Level:         Warning
Keywords:      Classic
Description:
Process w3wp.exe () (PID=xxxx). Object [CN=Offline Address Book,CN=Offline Address Lists,
CN=Address Lists Container,CN=MyExcOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,
DC=mydomain,DC=com]. Property [PublicFolderDatabase] is set to value 
[mydomain.com/Configuration/Deleted Objects/Public Folder Database
DEL:7a5cdb55-d5dd-48f5-b9ad-2a4eb4e3a2f5], it is pointing to the Deleted Objects container 
in Active Directory. This property should be fixed as soon as possible.

Hier in diesem Fall handelt es sich um einen fehlerhaften Verweis der das Offline Address Book betrifft. Das Problem lässt sich folgendermassen beheben:

1. ADSIEdit starten und die neue Public Folder DB suchen:
   
   Configuration -> Services > Microsoft Exchange -> Organization name -> Administrative Groups -> Exchange admin groups (xxxxx) ->  databases
   
2. Mit einem Rechtsklick auf das Objekt die Eigenschaften anzeigen lassen und den distinguishedName suchen und kopieren.
   
3. Nun in ADSIEdit auf Configuration -> Services > Microsoft Exchange -> Organization name -> ddress Lists Container -> Offline Address Lists -> Default Offline Address Book wechseln.
   
4. In den Eigenschaften den Wert siteFolderServer suchen. Dort steht nun der falsche Wert drin. Dieser sieht in etwa so aus:
   CN=DOMAIN PFDB\0ADEL:a44bc301-425b-44b1-ad12-419a683affd2,CN=Deleted Objects,CN=Configuration,DC=DOMAIN,DC=local
   
5. Dieser Wert kann nun mit den zuvor kopierten Wert ersetzt werden.

Mobile Device Management mit Exchange 2010

Die Verwaltung von mobilen Geräten ist immer wieder ein Thema und vor allem Sicherheitstechnisch relevant. Schliesslich tragen unsere User ihre möglicherweise sensitiven Daten mit ihren mobilen Geräten permanent mit sich herum und die Gefahr ein solches mobiles Gerät zu verlieren ist sehr hoch. Darum ist es wichtig eine gewisse Kontrolle über die verwendeten mobilen Geräte zu haben.

Exchange 2010 gibt uns hier die Möglichkeit zu bestimmen welche Typen von mobilen Geräten wir in unserer Organisation zulassen wollen und welche nicht. In diesem Beitrag zeige ich wie dies konfiguriert werden kann.