Heute gibt es wieder neue Updates für Exchange Server 2007, Exchange Server 2010 und Exchange Server 2013:
Kumulatives Update 7 für Exchange Server 2013 (KB2986485)
UM-Sprachpakete für Exchange Server 2013 CU7
Updaterollup 8 für Exchange Server 2010, Service Pack 3 (KB2986475)
Updaterollup 15 für Exchange Server 2007 Service Pack 3 (KB2996150)
Bisher gibt es noch keine Übersicht welche konkreten Probleme behoben wurden. Allerdings wird das AD Schema bei Exchange 2013 angehoben.
Mit der Sophos UTM 9.2 WAF in Verbindung mit Exchange 2013 bin ich nicht richtig warm geworden. Meiner Meinung nach gab es dort zu viele Dinge die nicht wie ich erwartet hab funktionierten. Aber es gibt jetzt die Sophos UTM 9.3, also ist es Zeit für einen neuen Test. Die Umgebung ist fast unverändert:
Es handelt sich hier um meine Standard Testumgebung, 2 Exchange 2013 CU7 (CAS + MBX) Server, 1 Domain Controller und Sophos UTM 9.3 (9.303-2)
Exchange und Domain Controller sind auf Server 2012 R2 installiert. Alle Systeme sind als VM installiert. Die Sophos UTM dient als Standard Gateway für die VMs und ist Mitglied des Active Directorys. Für diesen Test gibt es zusätzlich einen Windows 8.1 Client mit Outlook 2013, der nicht Mitglied des Active Directorys ist und Outlook Anywhere nutzen möchte.
Als Zugriffspunkt für Outlook Anywhere möchte ich den DNS-Namen “outlook.frankysweb.de” verwenden, daher ist dieser Name als interner und externer Hostname konfiguriert:
Hinweis: Ich habe mich dazu entschieden nur 2 Hostnamen zu verwenden. Autodiscover.frankysweb.de für Autodiscover und outlook.frankysweb.de für Outlook Anywhere, OWA und ActiveSync. Es gibt ein paar HowTo’s die alle Dienste mittels eigenen Hostnamen und entsprechenden Regeln trennen. Wenn aber gekaufte Zertifikate verwendet werden, können viele Hostnamen schnell teuer werden, oder aber die externen IPs werden knapp. Ich möchte also alle Exchange Dienste mit 2 Hostnamen und 1 externen IP nutzen können.
Mit Exchange 2013 ist es Best-Practise für internen und externen Zugriffpunkt den gleichen Hostnamen zu verwenden. Bei Exchange 2010 lautete die Empfehlung noch dieses zu trennen. Ich verwende also intern, wie extern den DNS-Namen “outlook.frankysweb.de
Meine Exchange Server haben IPs aus dem Netz 172.16.100.X, da es sich um eine Testumgebung handelt, habe ich am externen Interface der UTM einen Rechner mit Windows 8.1 gehangen, der nicht Mitglied der Domain ist. der Rechner hat eine externe IP aus dem Netz 172.16.200.X. Im nächsten Screenshot wird es etwas deutlicher:
Die DNS Einträge für autodiscover.frankysweb.de und outlook.frankysweb.de zeigen jeweils auf die externe IP der UTM. In meinem Fall also auf die 172.16.200.1.
Nun aber zur Konfiguration der UTM WAF. Zuerst das entsprechende Zertifikat importieren:
Hier kann das Zertifikat hochgeladen werden
Nach dem Upload sollte es wie folgt aussehen:
Das Zertifikat welches ich verwende kommt von einer internen CA, es kann natürlich auch jedes gekaufte Zertifikat verwendet werden, wenn es die korrekten Hostnamen enthält. In meinem Fall also “outlook.frankysweb.de und “autodiscover.frankysweb.de”. Hier mein Zertifikat zur Veranschaulichung:
Sobald das Zertifikat hochgeladen ist, können wir ein Firewall Profile anlegen:
Ich habe mein Profil “Exchange” genannt und die folgenden Einstellungen aktiviert:
Die oben gezeigten Einstellungen haben in meiner Testumgebung bestens funktioniert. Daher habe ich es erst einmal so belassen und werde gegebenenfalls weiter verfeinern. Jetzt können die “Real Servers” angelegt werden:
Hinter “Host” verbirgt sich nur die IP des Exchange Servers.
Ich habe beide Exchange Server als Real Server angelegt:
Und zum Schluss wird noch der Virtual Server angelegt:
Die Einstellungen für den Virtual Server sind wie folgt:
Das war alles…
…und das Beste: Es funktioniert sogar. Die Probleme die ich noch mit der UTM 9.2 hatte treten nicht mehr auf. Autodiscover funktioniert sauber, neues Outlook Konto einrichten ohne das der Client vorher in der Domain war. Sogar NTLM funktioniert:
Super, so habe ich mir das vorgestellt. Keine Workarounds mehr an Exchange und Active Directory, es läuft einfach. Zum Abschluss noch einmal die Outlook Ersteinrichtung, wenn der Client nicht im AD ist:
Die Abfrage der Anmeldedaten ist normal. Outlook versucht sich mit dem Benutzer administrator@frankysweb.de anzumelden. Mein AD Benutzer heißt aber frankysweb\administrator. Das wird in den meisten Umgebungen so sein.
Ich werde diesen Artikel noch etwas verfeinern. Ich freue mich aber, das es mit UTM 9.3 endlich so funktioniert, wie ich es mir wünsche. Da kann man den kleinen TLS Bug ja schon fast vergessen…
Das gestern veröffentlichte Updaterollup 8 für Exchange Server 2010 SP3 scheint Probleme für Outlook zu bereiten. Die Meldungen häufen sich das Kalendereinträge nicht mehr gespeichert werden können, oder der Zugriff auf Gesendete Elemente und Posteingang nicht mehr funktioniert. OWA scheint davon nicht betroffen zu sein. Wer das Update bereits installiert hat und Probleme bemerkt, kann es wieder deinstallieren.
In den Client Access Logs unter “C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access” tritt unter Umständen vermehrt diese Fehlermeldung auf:
“[IndexOutOfRangeException] Index was outside the bounds of the array.”
Wer das Update noch nicht installiert hat, sollte am besten noch warten.
Das fehlerhafte Update Rollup 8 für Exchange 2010 SP3 wurde in einer bereinigten Version wieder veröffentlicht. In meiner Testumgebung konnte ich die Fehler nicht mehr nachvollziehen. Wer auf Nummer sicher gehen will, wartet aber besser noch ein paar Tage. Hier geht es zum Download:
http://www.microsoft.com/de-DE/download/details.aspx?id=45225
Hier findet sich eine Liste mit den korrigierten Problemen:
Viele Mails die mich erreichen, drehen sich immer wieder um Zertifikate. Daher habe ich ein kleines Tool erstellt, das einem ein bisschen Arbeit mit den Zertifikaten abnimmt. Es sucht sich automatisch die entsprechenden DNS-Namen, fordert das Zertifikat von einer Windows CA an und installiert es auf allen Exchange 2013 Servern. Ganz ohne etwas Handarbeit geht es allerdings nicht:
Auf dem Exchange Server auf ExchangeCertificateAssistant ausgeführt wird, muss das ActiveDirectory Modul für die PowerShell installiert sein, das Modul lässt sich im Servermanager nachinstallieren:
Damit der Assistent Zertifikate anfordern kann, muss es neben einer Zertifizierungsstelle auch eine Zertifikatsvorlage geben. Wie eine Zertifizierungsstelle installiert und konfiguriert wird, habe ich hier beschrieben:
Wenn es schon eine installierte und konfigurierte Zertifizierungsstelle gibt, muss nur eine neue Vorlage erstellt werden. Dazu in der MMC der Zertifizierungsstelle die Zertifikatsvorlagenkonsole öffnen:
Die Vorlage “Webserver” muss dupliziert werden
Im neuen Fenster unter dem Reiter Allgemein den Vorlagenanzeigenamen festlegen und merken (wird von ExchangeCerttificateAssistant abgefragt)
Auf dem Reiter Anforderungsverwaltung müssen die Haken bei “Vom Antragssteller zugelassene symmetrische Algorithmen einbeziehen” und “Exportieren von privaten Schlüssel zulassen” gesetzt werden
Auf dem Reiter Sicherheit wird die Gruppe “Exchange Trusted Subsystem” mit den Rechten “Lesen” und “Registrieren” hinzugefügt
Jetzt kann mit “OK” bestätigt werden und die Zertifikatsvorlagenkonsole geschlossen werden. Die neue Vorlage muss dann nur noch veröffentlicht werden
Nachdem die Vorlage erstellt und veröffentlicht wurde kann der Assistent aus der Exchange Management Shell gestartet werden
Hinweis: ExchangeCertificateAssistant benötigt Server 2012 R2, PowerShell 4, Exchange 2013 und das ActiveDirectory Modul für die Powershell. Der oder die Exchange Server müssen bereits vollständig konfiguriert sein, für die Konfiguration kann der Exchange Configurator genutzt werden.
.\ExchangeCertificateAssistant.ps1
Der Assistent fragt nach dem Vorlagennamen, hier muss der eben vergebene Vorlagenanzeigename eingetragen werden
Der Rest sollte selbsterklärend sein. Bevor das Zertifikat ausgestellt wird, besteht noch die Möglichkeit weitere DNS-Namen hinzuzufügen, die nicht in Exchange konfiguriert wurden:
Das Zertifikat wird dann ausgestellt und an die Exchange Dienste gebunden, außerdem wird es unter c:\Zertifikat auf dem Exchange Server gespeichert, der den Assistent ausgeführt hat. Das Kennwort ist wählbar, somit lässt sich das Zertifikat auf Loadbalancer oder Firewalls übertragen.
Download:
APIPA-Adressen (169.254.x.x) im Mail Header sind etwas unschön, dieses Problem tritt in einer Exchange DAG auf und kann durchaus an dem ein oder anderem SPAM Filter zu einem Problem führen. Hier der Teil eines Mail Headers:
Ursache ist eine falsche Reihenfolge der Netzwerkverbindungen. Die APIPA Adresse gehört zu dem “Microsoft Failover Cluster Virtual Adapter”, der auf Mitgliedern eines Failover Clusters, also auch einer DAG, installiert wird:
Mit dem Tool nvspbind, lässt sich die Adapter Reihenfolge ändern. Nvspbind kann hier runtergeladen werden:
https://gallery.technet.microsoft.com/Hyper-V-Network-VSP-Bind-cf937850
Nicht wundern: Ursprünglich wurde das Tool für Hyper-V entwickelt. Hyper-V Cluster basieren wie auch die Exchange DAG auf dem Windows Feature Failover Clustering und genau dort setzt das Tool an. Es lässt sich also auch für Exchange DAGs bzw. allen Servern nutzen die auf Failover Clustering zurück greifen.
Mit folgendem Befehl lässt sich zunächst der Name des Netzwerkadapters suchen:
nvspbind.exe /o ms_tcpip
Mit dem diesem Befehl lässt sich dann der Failover Adapter eine Stelle tiefer in der Reihenfolge rücken:
nvspbind.exe /- “LAN-Verbindung* 9″ ms_tcpip
Diese Schritte müssen auf allen Mailbox Servern die Mitglieder einer DAG sind durchgeführt werden. Danach sollte das Problem weg sein.
Die Blacklist AHBL (rhsbl.ahbl.org, dnsbl.ahbl.org, und ircbl.ahbl.org) hat den Betrieb am 01.01.2015 eingestellt. Alle Anfragen an die Blacklisten werden positiv beantwortet, was SPAM-Filter dazu veranlasst die Mail als SPAM zu klassifizieren. Wer also die Blacklist noch eingetragen hat, sollte schnellstens die Konfiguration korrigieren.
Hier geht es zur Info von AHBL:
http://www.ahbl.org/content/last-notice-wildcarding-services-jan-1st
Wie die Sperrlisten für Exchange 2010 konfiguriert werden, ist hier beschrieben:
Das ActiveDirectory Attribut “HomeMTA” wird eigentlich nicht mehr von Exchange 2010 verwendet, trotzdem wird eine Fehlermeldung im EventLog erzeugt, wenn der Eintrag nicht korrekt gesetzt ist. Das Event 2937 tritt meistens nach einer Migration, oder nach dem Abschalten eines Mailbox Servers auf:
EventID: 2937
Quelle: MSExchange ADAccess
Prozess Microsoft.Exchange.RpcClientAccess.Service.exe (PID=10952). Objekt [CN=Zoechling\, Frank,OU=Benutzer,DC=frankysweb,DC=local]. Eigenschaft [HomeMTA] ist auf Wert [frankysweb.local/Configuration/Deleted Objects/Microsoft MTA
DEL:3f13df32-3d90-43ec-831f-3043434e72e7] festgelegt und zeigt auf den Container “Gelöschte Objekte” in Active Directory. Diese Eigenschaft muss so schnell wie möglich korrigiert werden.
Der verantwortliche Eintrag findet sich in den Attributen des Benutzerkontos, hier sollte eigentlich ein gültiger Eintrag für einen Mailbox Server stehen:
Der Befehl “get-mailbox | update-recipient” hat bei mir noch nie funktioniert, daher habe ich ein Script erstellt, welches den Eintrag für das Attribut HomeMTA direkt im ActiveDirectory korrigiert:
$alladusers = Get-ADUser -filter * -Properties homemta | select samaccountname,homemta | where {$_.HomeMTA -match "Deleted Objects"}
foreach ($aduser in $alladusers)
{
$adusername = $aduser.samaccountname
$database = (get-mailbox $adusername | select database).database
$exserver = ((get-mailboxdatabase $database).ActivationPreference | where {$_.value -eq 1}).key.name
[String]$newHomeMTA = "CN=Microsoft MTA," + (get-exchangeserver $exserver).DistinguishedName
write-host "Bearbeite Benutzer: $adusername`t`tHomeMTA: $exserver"
set-aduser $adusername –replace @{homemta="$newHomeMTA"}
}
Das Script kann in der Exchange Management Shell ausgeführt werden und es muss das ActiveDirectory Modul für die Powershell geladen werden:
import-module activedirectory
Das Script sucht dann alle Benutzerkonten dessen HomeMTA Werte auf “Gelöschte Objekte” verweisen und setzt den Mailbox Server als HomeMTA ein, der auch die erste Kopie der Datenbank hält.
Ursprünglich wurde MAPIoverHTTP schon mit dem Update KB2899591 (http://support.microsoft.com/kb/2899591) für Outlook 2010 nachgereicht, das Update wurde allerdings kurze Zeit später wieder zurückgezogen. Microsoft hat nun ein neues Update veröffentlicht. Voraussetzung für das Update ist das Service Pack 2 für Office 2010. Hier kann das Update für Outlook 2010 runtergeladen werden:
http://support.microsoft.com/kb/2878264
MAPIoverHTTP ist ein neues Protokoll für Exchange 2013 SP1, welches einige Vorteile und Verbesserungen gegenüber RPCoverHTTP bietet. Hier gibt es Details zu MAPIoverHTTP:
Am 12.02.2015 endet der Mainstream Support für Exchange 2010 SP3.
Da der Mainstream Support nächsten Monat abläuft, ist es wohl klar das kein weiteres Service Pack für Exchange 2010 mehr erscheinen wird. Auch neue Funktionen wird es nicht mehr geben. Grund zur Sorge besteht aber nicht, der Extended Support läuft noch bis zum 14.01.2020. Microsoft wird also bis 2020 Sicherheitsupdates und Hotfixes liefern:
![clip_image002[7]](http://www.frankysweb.de/wp-content/uploads/2015/01/clip_image0027_thumb.jpg "clip_image002[7]")
Wieder etwas Zuwachs in der *Reporter Familie, der CA-Reporter ist fertig. CA Reporter erstellt ganz ähnlich wie Exchange Reporter einen Bericht über die Zertifizierungsstellen und Zertifikate. Folgende Funktionen sind bisher enthalten:
Vorschläge zu weiteren Funktionen werden gerne entgegen genommen (Bitte Kontaktformular nutzen)
Der CA Reporter kann, wie Exchange Reporter auch, über eine geplante Aufgabe gestartet werden. Eine Installationsanleitung findet sich im .ZIP Archiv.
Folgende Voraussetzungen müssen erfüllt sein:
Hier kann der CA Reporter runtergeladen werden:
Nach einer Neuinstallation von Exchange 2013 könnte folgender Fehler auftreten, der verhindert das ECP und Shell funktionieren:
Quelle: MSExchange RBAC
ID: 23
(Prozess w3wp.exe, PID 13160) “Exchange-AuthZPlugin kann die Methode “GetApplicationPrivateData” aufgrund der Anwendungsausnahme “Microsoft.Exchange.Diagnostics.SetupVersionInformationCorruptException: Die installierte Dateiversion kann nicht anhand des Registrierungsschlüssels ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine’ ermittelt werden.
bei Microsoft.Exchange.Diagnostics.ExchangeSetupContext.get_PSHostPath()
bei Microsoft.Exchange.Configuration.Authorization.InitialSessionStateBuilder.InitializeWellKnownSnapinsIfNeeded(ExchangeRunspaceConfigurationSettings settings, Boolean isPowerShellWebServiceSession)
bei Microsoft.Exchange.Configuration.Authorization.InitialSessionStateBuilder.Build(List`1 allCmdlets, List`1 allScripts, ExchangeRunspaceConfiguration runspaceConfig)
bei Microsoft.Exchange.Configuration.Authorization.ExchangeRunspaceConfiguration.CreateInitialSessionState()
bei Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin.GetInitialSessionStateCore(PSSenderInfo senderInfo)
bei Microsoft.Exchange.Configuration.Authorization.ExchangeAuthorizationPlugin.<>c__DisplayClass4.<GetApplicationPrivateData>b__3()
bei Microsoft.Exchange.Configuration.Authorization.AuthZLogHelper.HandleExceptionAndRetry[T](String methodName, Func`1 func, Boolean throwException, T defaultReturnValue)” nicht beenden.”
Lösung ist es die entsprechenden Registry Keys einzutragen, dazu den folgenden Text in eine .REG Datei kopieren und einfügen:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine] "ApplicationBase"="C:\\Windows\\System32\\WindowsPowerShell\\v1.0" "PSCompatibleVersion"="1.0, 2.0" "RuntimeVersion"="v2.0.50727" "ConsoleHostAssemblyName"="Microsoft.PowerShell.ConsoleHost, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=msil" "ConsoleHostModuleName"="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\Microsoft.PowerShell.ConsoleHost.dll" "PowerShellVersion"="2.0"
Seit dem 29.01.15 gibt es Outlook auch für iOS und Android. Hier ein kurzes Howto zur Einrichtung in Verbindung mit Exchange Server. Bei der Nutzung von Outlook für iOS und Andoid ist allerdings Vorsicht geboten:
Wer Outlook für iOS dennoch nutzen möchte, der möge jetzt weiterlesen:
Die Einführung kann mit dem “X” abgebrochen werden.
Der Kontotyp ist Exchange (auch bei Office 365 und Exchange Online)
E-Mail Adresse und Passwort angeben
Und wenn Autodiscover und die Zertifikate ordentlich konfiguriert wurden, war das schon alles.
Ohne Autodiscover muss der Servername und die Domain angegeben werden:
Die Verbindung zum Exchange Server erfolgt via ActiveSync, wer also ActiveSync, OWA und Outlook Anywhere über unterschiedliche DNS-Namen veröffentlicht, muss hier den Namen angeben über den ActiveSync verfügbar ist.
Zu guter Letzt muss je nach Konfiguration das Gerät am Exchange Server freigegeben werden:
Ein Howto für die Einrichtung von Outlook für iOS habe ich bereits geschrieben. Allerdings nach die App den “kleinen” Nachteil, das Benutzername und Passwort an Microsoft übermittelt werden:
Damit Benutzer die App nicht benutzen können und Passwörter nicht das Unternehmen verlassen, kann am Exchange Server eine ActiveSync Richtlinie erstellen um die App zu blockieren:
New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block
Um herauszufinden ob die App bereits bei Benutzen im Einsatz ist, kann der folgende Befehl verwendet werden:
get-MobileDevice | where {$_.devicemodel -match "Outlook for iOS and Android"} | ft userdisplayname,deviceos
Und um alle ActiveSync Partnerschaften mit der Outlook App zu löschen, kann der folgende Befehl verwendet werden:
get-MobileDevice | where {$_.devicemodel -match "Outlook for iOS and Android"} | Remove-MobileDevice
Kleiner Hinweis: Bei Exchange 2010 heisst es “Get-ActiveSyncDevice” bzw “remove-ActiveSyncDevice”.
Hier mal wieder in kleines Script aus der Quick&Dirty Ecke. Abfragen des Kalenders eines Raumpostfachs per EWS und Powershell. Das Script holt alle Kalendereinträge ab dem aktuellen Zeitpunkt bis 365 Tage in die Zukunft, bzw. maximal 200 Einträge. Die Ergebnisse werden in der Variable $results gespeichert und können dann weiter verarbeitet werden.
$MailboxName = "Besprechungsraum@frankysweb.de" $EWSPath = "C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll" Add-Type -Path $EWSPath $version = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2 $service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService($version) $service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress,$MailboxName); $service.AutodiscoverUrl($mailboxName) $calendar = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar) $calendarView = new-object Microsoft.Exchange.WebServices.Data.CalendarView([System.DateTime]::Now, [System.DateTime]::Now.AddDays(365)) $calendarView.MaxItemsReturned = 200; $calendarView.PropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet([Microsoft.Exchange.WebServices.Data.BasePropertySet]::FirstClassProperties) $results = $calendar.FindAppointments($calendarView) $results | ft subject,start,end
Damit mittels EWS auf ein Raumpostfach zugegriffen werden kann, muss der Benutzer der das Script ausführt Impersonationsrechte haben. Um einem Benutzer Impersonationsrechte zuzuweisen kann der folgende Befehl verwendet werden:
New-ManagementRoleAssignment -Name impersonationAssignmentName -Role ApplicationImpersonation -User EWSServiceAccount
Damit erhält der Benutzer “EWSServiceAccount” Impersonationsrechte auf allen Postfächern, dies lässt sich aber auch weiter eingrenzen:
New-ManagementScope -name Besprechungsraum -RecipientRestrictionFilter {Name –eq "Besprechungsraum"}
New-ManagementRoleAssignment –Name impersonationAssignmentName –Role ApplicationImpersonation –User EWSServiceAccount –CustomRecipientWriteScope Besprechungsraum
Der Befehl oben erzeugt einen neuen Management Bereich der nur den Benutzer “Besprechungsraum” enthält. Die Impersonationsrechte gelten also nur für den Benutzer EWSServiceAccount für das Postfach “Besprechungsraum”.
Gerade habe ich die neue Exchange Monitor Version 2.1 hochgeladen. Die neue Version enthält diverse Bugfixes die von Anwendern berichtet wurden. Vielen Dank an dieser Stelle, an alle die Probleme gemeldet haben. Die Version 2.1 des Exchange Monitors lädt nun die Exchange Snapins aus der normalen PowerShell heraus. Somit sollten Probleme beim Task vermieden werden. Ebenfalls neu ist eine Einstellung in der settings.ini:
Wenn “OnlyCheckIfSMTPPortOpen” auf “Ja” gesetzt wird, wird nur geprüft ob der Port 25 auf den zusätzlichen SMTP Servern geöffnet ist, es wird nicht mehr überprüft ob auch tatsächlich eine Mail verschickt werden kann. Häufig sind SPAM-Filter so eingestellt, dass nur Mail von den Exchange Servern angenommen werden, somit schlägt der Test von einem anderen Rechner aus fehl.
Ebenfalls wurde die Testmail Funktion etwas verbessert, sodass weniger Probleme bei den Tests auftreten sollten.
Auf Wunsch von mehreren Benutzern wird jetzt auch der Status der Datenbanken und ggf. deren Kopien angezeigt. Ich muss allerdings zugeben, dass dieser Test noch verbessert werden kann.
Ebenfalls fehlt mir aktuell an Testumgebungen, daher habe ich diese Version als Beta gekennzeichnet. Wer die Version 2.0 einsetzt, kann das aktuelle Verzeichnis sichern und dann die neue Version in das vorhandene Verzeichnis kopieren. Die Settings.ini muss dann entsprechend angepasst werden.
Es wäre schön wenn, möglichst viel Feedback zu Stande kommt, um die Version weiter zu verbessern. Auch Feature Request werden gerne entgegen genommen (Bitte per Mail). Ich plane in ca. 1 Monat die finale Version online zu stellen.
Hier gibt es die BETA Version:
Exchange Server 2013 (und auch Exchange 2010) stellt eine Funktion bereit um das Verhalten von Standard CMDlets zu beeinflussen.
In diesem kleinen Beispiel wird der Scripting Agent verwendet, um bei allen neu angelegten Postfächern OWA, OWA für Geräte und ActiveSync zu deaktivieren. In der Standard Einstellung sind diese Postfachfunktionen aktiviert, was vieleicht nicht immer gewollt ist. Um den Scripting Agent zu aktivieren und damit das Verhalten von Standard CMDlets anzupassen, sind allerdings ein paar Schritte notwendig:
Konfiguriert wird der Scripting Agent mittels XML Datei, die auf jedem Exchange Server vorhanden sein muss. Eine Beispiel Datei liegt bereits im Exchange Installationsordner:
C:\Program Files\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents
Die Datei “ScriptingAgentConfig.xml.sample” kann als Vorlage benutzt werden, dazu kann einfach das “.sample” entfernt werden. Dieser Schritt muss auf jedem Exchange Server erfolgen. Jeder Exchange Server erhält also die gleiche “ScriptingAgentConfig.xml” Datei:
Für dieses Beispiel hat die Datei “ScriptingAgentConfig.xml” folgenden Inhalt:
Die Datei gibt es hier auch zum Download:
Wie in der Beispiel Datei zu entnehmen ist, enthält die XML Datei etwas PowerShell Code, welcher in diesem Fall ausgeführt wird, wenn das CMDLet “new-mailbox” oder “enable-mailbox” erfolgreich abgeschlossen wurde. Der Teil innerhalb der IF-Anweisung holt sich dann den Alias, des Postfachs welches bearbeitet wurde und deaktiviert die entsprechenden Postfachfeatures.
Sobald die XML-Datei auf den Exchange Servern platziert wurde, muss noch der Scripting Agent aktiviert werden:
Enable-CmdletExtensionAgent "Scripting Agent"
Postfächer die ab jetzt angelegt werden, haben nicht mehr ActiveSync, OWA und OWA für Geräte aktiviert
Durch ein paar Anpassungen an der XML Datei lassen sich auch andere Szenarien umsetzen. UC oder Audit einschalten, Postfach Berechtigungen setzen, Kalender Einstellungen, oder auch eine OWA Signatur, denkbar ist vieles.
Die Sample Datei auf den Exchange Servern ist ebenfalls gut kommentiert, sodass man schnell die entsprechenden Anweisungen findet.
Gerade habe ich die Version 2.1 des Exchange Reporters veröffentlicht. Die wichtigsten Änderungen:
Des weiteren sind diverse Bugfixes eingeflossen, am auffälligsten war wohl das Durcheinander bei den Wochentagen in der Mailübersicht (Schande auf mein Haupt, denn das gab es auch schon mal in einer alten Version)
Zum Download geht es hier:
http://www.frankysweb.de/exchange-reporter-2013/
Bugs, Anregungen, Wünsche, Kritik bitte wie immer per Mail.
Wie angekündigt habe ich einen Monat nach der Beta Version den Exchange Monitor in Version 2.1 veröffentlicht. In die finale Version sind nochmal ein paar Änderungen eingeflossen.
Exchange Monitor 2.1 steht hier zum Download bereit:
http://www.frankysweb.de/exchange-monitor/
Vielen Dank an alle Leser die dabei geholfen haben den Exchange Monitor weiter zu verbessern.
Update: Es hatte sich noch ein Fehler eingeschlichen, der den Start verhindert hat. Dank des Hinweises von Marco ist der Fehler jetzt behoben. Ebenfalls muss nicht mehr zwingend der Parameter “Installpath” angegeben werden.
In diesem Howto wird F5 APM für die Veröffentlichung von Exchange 2013 verwendet. Zunächst ein kleiner Überblick über die Testumgebung:
Ich habe 2 Exchange Server und einen DC im internen Netz, die Server haben die 172.16.100.1 als Default Gateway eingetragen. F5 APM hat 2 Netzwerkkarten, eine ist direkt mit dem Internet verbunden (das Internet stellt bei mir das Netz 172.16.1.0/24) dar. Die zweite Netzwerkkarte hat einen IP im internen Netz. Desweiteren verfügt die F5 über eine dedizierte Netzwerkkarte in einem Management Netzwerk (192.168.30.0/24). Die Basiskonfiguration ist den nächsten Bildern zu entnehmen.
Management Einstellungen:
Netzwerkkarten bzw. VLANs 1.1 (Internal) und 1.2 (external)
Interne und externe Self IPs:
Soweit einmal zur Basiskonfiguration. Für APM wird ein Zertifikat mit den externen Zugriffsnamen benötigt. Da ich alle Exchange Dienste über einen DNS-Namen veröffentlichen möchte, enthält mein Zertifikat nur 2 DNS-Namen:
Wie Zertifikate mit einer eigenen CA erstellt werden können, habe ich hier beschrieben. Das Zertifikat muss zunächst auf der F5 importiert werden:
Die F5 versteht das PFX Format, sodass keine umständliche Konvertierung nötig ist. Zertifikat hochladen, Passwort und Namen eingeben, fertig:
Wer das Provisioning nicht direkt bei der Installation erledigt hat, muss es jetzt nachholen. Bisher ist bei mir nur das Modul LTM provisioniert, daher wähle ich jetzt zusätzlich APM aus:
Beim Provisioning starten die Dienste neu, daher nicht durchführen, wenn es aktive Sessions gibt…
Als nächstes kann das iApp Template installiert werden, die aktuellen iApp Templates können hier runtergeladen werden:
Aus den vielen Templates wird nur das Exchange Template benötigt: f5.microsoft_exchange_2010_2013_cas.v1.4.0.tmpl. Dieses kann jetzt importiert werden:
Template (.tmpl) Datei auswählen und hochladen.
Jetzt kann eine iApp aus dem Template erzeugt werden
Name der iApp und das Template angeben
Das Template fragt jetzt die Einstellungen ab, die erste Bildschirmseite ist selbsterklärend, es wird übrigens ein Benutzer mit Domain Admin Rechten benötigt, bei mir heisst der Benutzer “F5APM”:
Die zweite Seite eigentlich auch. Bei “What is the LDAP tree…” muss der Pfad zur OU (distinguishedName) angegeben werden, in der der F5 Service User gespeichert ist. Bei mir ist das die OU “Benutzer”.
Bei “Which Client certificate/key…) muss das zuvor importierte Zertifikat ausgewählt werden.
Die nächsten Einstellungen sind abhängig von der Umgebung. Die IP Adresse für den Virtual Service lege ich auf 172.16.1.20 fest. Auf diese IP Adresse müssen auch die DNS-Namen outlook.frankysweb.de und autodiscover.frankysweb.de zeigen. Wer möchte kann noch den Zugriff auf das Exchange Admin Center beschränken, somit haben nur noch Mitglieder der Gruppe “Organization Management” Zugriff auf EAC. Hier sind meine Einstellungen:
Auf der letzten Seite müssen noch die Exchange Server angegeben werden, fertig:
Zum Schluss noch die DNS-Einträge auf die IP des Virtual Service setzen:
Die iApps machen es einem bei F5 wirklich einfach schnell zum Ziel zu kommen. Alles funktioniert wie erwartet. Hier gibt es auch einen netten Deployment Guide: