Es wurden neue Updates für Exchange Server 2007, 2010 und 2013 veröffentlicht. Hier geht es direkt zum Download:

Kumulatives Update 8 für Exchange Server 2013 (KB3030080)
Updaterollup 9 für Exchange Server 2010, Service Pack 3 (KB3030085)
Updaterollup 16 für Exchange Server 2007 Service Pack 3 (KB3030086)

Hier gibt es eine Liste mit den Änderungen:

Kumulative Update 8 für Exchange Server 2013
Updaterollup 9 für Exchange Server 2010 Servicepack 3
Update-Rollup 16 für Exchange Server 2007 Servicepack 3

Angesichts der letzten Probleme mit Updates, ist es ratsam noch etwas zu warten bis die Updates in die produktive Umgebung eingespielt werden.

Ab dem 01.01.2016 wird Microsoft SSL Zertifikate mit SHA1 als Hashalgorithmus für ungültig erklären. Webserver oder Dienste die Zertifikate mit SHA1 nutzen, lösen also Zertifikatswarnungen im Browser bei den Benutzern aus. Daher sollte langsam aber sicher damit begonnen werden, SHA1 Zertifikate auszutauschen. Damit eine interne CA Zertifikate mit SHA256 (SHA2) ausstellen kann, muss die CA von SHA1 auf SHA2 umgestellt werden. Hier gibt es das entsprechende Howto:

Hier sieht man das der Hashalgorithmus der CA auf SHA1 steht. Die CA kann somit auch nur Zertifikate mit SHA1 ausstellen.

Als Beispiel hier ein IIS Webserver der sein Zertifikat von der CA mit SHA1 bezogen hat. Auch hier ist der Hashalgorithmus SHA1

Um die CA auf SHA256 (SHA2) umzustellen, muss der folgende Befehl auf der Kommandozeile ausgeführt werden:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

Wenn die Ausgabe wie oben ausschaut, muss die CA neugestartet werden, also einmal stoppen und wieder starten:

Ob SHA256 als Hashalgorithmus genutzt wird, lässt sich wieder in den Eigenschaften der CA prüfen

Somit haben wir den Hashalgorithmus der CA auf SHA-256 geändert. Zuvor ausgestellte Zertifikate behalten ihre Gültigkeit, natürlich ändert sich nichts an den Zertifikaten, wie hier noch einmal im Beispiel des IIS

Erst neue oder erneuerte Zertifikate werden mit SHA-256 signiert. Über die Zertifikate-SnapIn in der MMC können Zertifikate erneuert werden:

Nachdem das Zertifikat erneuert wurde, wurde es mit SHA256 durch die CA signiert:

Und hier noch einmal das Beispiel mit dem IIS, alles gültig, mit SHA256:

Das Root-Zertifikat enthält natürlich auch noch SHA1 als Hashalgorithmus, denn es wurde bisher nicht erneuert. Es besteht allerdings nicht unbedingt die Notwendigkeit bis 2016 das Root-Zertifikat zu erneuern, den Zertifizierungsstellen Zertifikate behalten auch mit SHA1 ihre Gültigkeit.

Auch hier lässt sich das Zertifikat entsprechend erneuern (Achtung: der Assistent hält die CA an):

Nachdem das Zertifikat erneuert wurde enthält es ebenfalls SHA256:

Und hier noch einmal zum Vergleich das Beispiel IIS, alte und neue Zertifikate behalten Ihre Gültigkeit.

Natürlich müssen alte SHA1 Zertifikate erneuert werden, damit ab 2016 keine Zertifikatswarnungen auftauchen, allerdings sollte kein größeres Problem darstellen, außer etwas Fleißarbeit.

Netter Fehler bei der Exchange 2013 Installation:

[03.26.2015 17:17:52.0050] [0] [ERROR] Es wurde versucht, eine Assembly von einer Netzwerkadresse zu laden, was in früheren Versionen von .NET Framework zum Ausführen der Assembly als Sandkastenassembly geführt hätte. In dieser Version von .NET Framework wird die CAS-Richtlinie standardmäßig nicht aktiviert, dieser Ladevorgang kann daher gefährlich sein. Wenn Sie nicht beabsichtigen, durch diesen Ladevorgang eine Sandkastenassembly zu erstellen, aktivieren Sie den loadFromRemoteSources-Schalter. Weitere Informationen finden Sie unter “http://go.microsoft.com/fwlink/?LinkId=155569″.

[03.26.2015 17:17:52.0206] [0] Finished loading screen InitializingSetupPage.

[03.26.2015 17:20:10.0034] [0] Der Registrierungsschlüssel “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\V15\Setup” wurde nicht gefunden.

[03.26.2015 17:20:10.0034] [0] CurrentResult setupbase.maincore:396: 1

[03.26.2015 17:20:10.0034] [0] End of Setup

Ist doch immer wieder nett, wenn Fehlermeldungen eingedeutscht werden Lösung ist übrigens, Exchange 2013 nicht von einem Netzlaufwerk zu installieren.

Nachdem man einen Account hat, landet man im Office 365 Dashboard. Unter dem Punkt “Setup” kann die Grundkonfiguration erfolgen:

Schritt 1: Domain hinzufügen.

Ich verwende “frankysweb.com” zum Testen:

Meine Domain hostet Strato, da Strato in der Liste für die Schrittanweisungen nicht aufgeführt ist, wähle ich “Allgemeine Anweisungen” aus. Die Domain muss validiert werden, daher wird ein TXT Eintrag und alternativ ein MX Eintrag angezeigt um die Domain zu validieren. Ich verwende den TXT Eintrag:

Um die Domain zu bestätigen wird also jetzt nur der TXT Record angelegt. Bei Strato funktioniert das ganz einfach:

Einstellungen speichern und fertig

Die Domain wird anhand des TXT Records erfolgreich validiert:

Die gerade hinzugefügt Domain wird jetzt unter dem Punkt “Domänen” angezeigt:

Als nächstes wird der Nachrichtenfluss zwischen dem lokalen Exchange Server und Exchange Online Protection (EOP) konfiguriert. Dazu wird im Office 365 Dashboard auf “Online Protection for Exchange” geklickt

Es öffnet sich ein neues Fenster mit dem Exchange Admin Center, auch hier sollte bereits die eben hinzugefügt Domain angezeigt werden, die Domain kann doppelt angeklickt werden um die Einstellungen zu öffnen:

Da die E-Mails von EOP zu Exchange weitergeleitet werden sollen, wird der Typ der Domain auf “Internes Relay” umgestellt:

Jetzt werden 2 Connectoren benötigt, die unter dem Punkt Connectors hinzugefügt werden.

Der erste Connector ist für den Empfang der Nachrichten vom lokalen Exchange Server zuständig. Also wird bei “Von” die Einstellung “E-Mail Server ihrer Organisation” und bei “An” die Einstellung “Office 365″ vorgenommen:

Der Connector benötigt einen sprechenden Namen, wie beispielsweise Exchange-to-EOP

Im nächsten Schritt wird die externe IP-Adresse des Exchange Servers angegeben. In kleinen Umgebungen dürfte es sich dabei wahrscheinlich um die WAN IP handeln. In meiner Testumgebung ist es meine öffentliche WAN IP:

Zum Schluss wird noch eine Zusammenfassung angezeigt und der erste Connector ist angelegt

Der zweite Connector ist für das Weiterleiten der Nachrichten an den lokalen Exchange Server. Also wird bei “Von” die Einstellung “Office 365″ und bei “An” die Einstellung “E-Mail Server ihrer Organisation” vorgenommen:

Auch hier wieder einen sprechenden Namen eingeben, beispielsweise “EOP-to-Exchange”

Im nächsten Dialog werden die entsprechenden Domains hinzugefügt, für die der lokale Exchange Server zuständig ist. Bei mehreren Domains mit mehreren Exchange Servern, werden entsprechend mehrere Connectoren angelegt. In meinem Fall ist es aber nur “frankysweb.com”:

Jetzt muss wieder die externe IP-Adresse des Exchange Servers angegeben werden, damit die Mails von EOP zu dem lokalen Exchange Server geschickt werden können:

Da ich ein selbst signiertes Zertifikat verwende, welches für EOP nicht vertrauenswürdig ist, wähle ich die Einstellung TLS mit allen Zertifikaten:

Auch hier wird wieder eine Zusammenfassung angezeigt, es geht allerdings noch einen Schritt weiter:

Der Connector wird im letzten Schritt überprüft, ob EOP in der Lage ist Mails an den lokalen Exchange Server zu senden. An dieser Stelle muss also eine Verbindung auf Port 25 (SMTP) zu dem lokalen Exchange Server möglich sein. Hier reicht normalerweise simples DNAT aus, welches so eingeschränkt wird, das nur EOP Mails einliefern darf. Bei meiner Sophos UTM habe ich also einen DNAT Eintrag (oder auch SNAT genannt) erzeugt und den entsprechend eingeschränkt:

Die Gruppe bei “Datenverkehrsquelle” enthält dann alle EOP-IPs bzw. die EOP Netzwerke. Welche IPs von Microsoft derzeit verwendet werden, ist hier dokumentiert:

https://technet.microsoft.com/library/dn163583(v=exchg.150).aspx

Damit der Connector erstellt werden kann, muss eine E-Mail Adresse für den Test angegeben werden, in meinem Fall ist das administrator@frankysweb.com:

Nach dem Klick auf “Überprüfen” startet der Test:

Der Test sollte erfolgreich verlaufen:

In Exchange Admin Center “sollten” nun 2 Connectoren angezeigt werden:

Seltsamer Weise ist bei mir der Connector EOP-to-Exchange nach kurzer Zeit aus dem EOP-Portal verschwunden. Der Connector ist ist aber weiterhin vorhanden. Ob die Connectoren vorhanden sind lässt sich mittels PowerShell prüfen:

Get-InboundConnector | ft –AutoSize
Get-OutboundConnector | ft -AutoSize

Eine Verbindung zu EOP via Powershell wird wie folgt aufgebaut:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

Eine Liste der verfügbaren CMDLets findet sich hier:

https://technet.microsoft.com/de-de/library/dn621038(v=exchg.150).aspx

Nachdem der Nachrichtenfluss konfiguriert ist, können die Benutzer angelegt werden. In den meisten Fällen bietet es sich an, die Synchronisation automatisch erledigen zu lassen. Um das lokale ActiveDirectory mit EOP (bzw Azure AD) zu synchronisieren, muss es eingerichtet werden:

Schritt 1: Verzeichnissynchronisierung vorbereiten

Im ersten Schritt gibt es einen wichtigen Punkt: Wenn das lokale ActiveDirectory einen Namen verwendet der nicht gleich der E-Mail Domain ist, dann muss die E-Mail Domain als alternativer UPN-Suffix hinzugefügt werden. Beispiel:

• Interner AD-Name: frankysweb.local
• E-Mail Domain: frankysweb.com

Der UPN für Benutzer Frank lautet also frank@frankysweb.local, daher muss dem Benutzer Frank der alternative UPN-Suffix frankysweb.com zugewiesen werden, damit das Zuordnen von lokalem Benutzer zu EOP Benutzer funktioniert.

Das alternaive UPN wird in der Konsole “Active Directory-Domänen und Vertrauensstellungen” hinzugefügt:

Damit die Benutzer zugeordnet werden können, muss bei jedem Benutzer der UPN geändert werden, am Einfachsten funktioniert das über die PowerShell (siehe Hinweis!!!). Hier gibt es ein entsprechendes Script:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/08/13/add-user-principal-names-in-active-directory-via-powershell.aspx

Aber Vorsicht: Das Ändern des UPN für die Benutzer, sollte sorgfältig geplant werden. Es könnte sonst im Chaos enden, wenn sich kein Benutzer mehr anmelden kann…

Für einzelne Benutzer lässt es sich händisch umstellen:

Wer den UPN nicht verändern möchte oder kann, kann die Benutzer auch mittels CSV-Datei oder auch per Powershell importieren. Schritt 2 kann normalerweise übersprungen werden. Also kann es mit Schritt 3 weitergehen:

Nach dem Klick auf Aktivieren, sollte der Status angezeigt werden und die beiden Tools können runtergeladen werden:

Die beiden Tools werden auf einem Domain Controller benötigt. Das Tool ldfix kann dazu verwendet werden Probleme bei der Synchronisation vorab zu beheben:

In meiner Umgebung sind keine Probleme aufgetreten:

Daher kann das Tool dirsync installiert werden

Nachdem das Tool installiert wurde, am besten das Häkchen bei “Konfigurations-Assistenten jetzt starten” abwählen und vor der Konfiguration den Benutzter abmelden und wieder anmelden:

Der Assistent kann nach dem Anmelden über das Startmenü oder über die Desktop Verknüpfung gestartet werden. Im ersten Dialog muss der EOP Benutzer angegeben werden:

Im nächsten Dialog muss ein Benutzer mit Domain Administrator Rechten angegeben werden, zusätzlich muss der Benutzer Mitglied der Gruppe “FIMSyncAdmins” sein, die bei der Installation erstellt wurde:

Der Modus “Hybride Bereitstellung” erlaubt es, dass auch Änderungen von EOP in das lokale AD synchronisiert werden können, der Modus ist aber nicht zwingend erforderlich:

Auch die Kennwortsynchronisation mit Azure AD ist nicht zwingend nötig:

Die Konfiguration sollte ohne Fehler abgeschlossen werden:

Abschließend kann das lokale AD mit Azure synchronisiert werden:

Der Synchronisationsvorgang kann mit dem Synchronization Service Manager überwacht werden. Das Tool findet sich unter folgendem Pfad:

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe

Nachdem die Synchronisation abgeschlossen wurde, werden die Benutzer im Office 365 Portal unter “Aktive Benutzer” angezeigt. Bei Benutzern mit geänderten UPN funktioniert die Zuordnung (rot), bei Benutzern ohne geänderten UPN nicht (blau)

Hinweis: Das lokale AD wird alle 3 Stunden mit Azure AD synchronisiert. Der Intervall lässt sich über folgende Datei anpassen:

C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config

Hier das Beispiel für 1 Stunde:

Nach dem Anpassen der Datei, muss der Dienst “Windows Azure Active Directory Sync Service” neugestartet werden. Die Synchronisation lässt sich auch manuell anstoßen, dazu kann ein PowerShell SnapIn aus folgendem Verzeichnis geladen werden:

C:\Program Files\Windows Azure Active Directory Sync\DirSync

Import-Module .\DirSync.psd1
Start-OnlineCoexistenceSync

Die EOP Konfiguration ist jetzt soweit abgeschlossen, es fehlt noch eine kleine Exchange Konfiguration und das Umstellen der MX Records.

Zuerst den lokalen Exchange Sendeconnector anlegen, damit ausgehende Mails über EOP geleitet werden:

New-SendConnector -Name "Exchange-To-EOP" -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn "outlook.frankysweb.de" -RequireTLS $true -SmartHosts frankysweb-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

Der Befehl muss etwas angepasst werden:

-fqdn: gibt den externen Namen des Exchange Servers an, normalerweise ist das der HELO Eintrag, der auch auf dem Zertifikat steht

-smarthosts: Domain-TLD.mail.protection.outlook.com. Domain und TLD werden durch Bindestrich getrennt

Der alte Sende Connector kann zunächst deaktiviert oder direkt gelöscht werden

Zum Schluss noch den MX Record beim Provider umstellen (in meinem Fall wieder Strato):

Normalerweise ist der MX Reocrd auch domain-tld.mail.protection.outlook.com. Der MX lässt sich aber auch unter dem Punkt “Domänen” mit einem Klick auf “DNS verwalten” anzeigen:

Hier werden neben dem MX auf die SPF Einträge angezeigt, die konfiguriert werden sollten, wenn der Provider dies unterstützt:

Strato Konfiguration für SPF:

Fertig, zumindest mit der grundlegenden Konfiguration…

Einen ersten Blick auf die kommende Exchange Version (Exchange 2016) wird es auf der Microsoft Ignite geben. Auf dem Exchange Team Blog, sind bereits ein paar Informationen zu Exchange 2016 verfügbar. Geplant ist die Veröffentlichung von Exchange 2016 dieses Jahr in der zweien Jahreshälfte. Die Ignite Session zu Exchange 2016 wird voraussichtlich ab dem 07.05. online zur Verfügung stehen.

Hier die Infos die bereits auf dem Exchange Team Blog zu Exchange 2016 veröffentlicht wurden:

• A new approach to document collaboration that makes it easy to send links and collaborate without versioning issues of attachments
• Faster and more intelligent search, to help users quickly find what they need in their mailboxes and calendars
• Significant improvements to eDiscovery search performance and reliability
• Better extensibility, including new REST-based APIs for Mail, Calendar, and Contacts that simplify web and mobile development

In den nächsten Wochen werden wohl immer mehr Informationen veröffentlicht, also abwarten

Alle Zertifikate haben ein Ablaufdatum, welches meist noch weit in der Zukunft liegt. Wer erinnert sich schon noch an ein Zertifikat welches vor 2 Jahren oder noch länger gekauft wurde? Manche CAs versenden Erinnerungsmails, aber nicht alle. Für interne CAs kann vieleicht der CA-Reporter weiterhelfen. Wer nur wenige gekaufte Zertifikate hat, kann die mittels Excel und ein bisschen PowerShell verwalten, einfach Daten in die Liste eintragen, Geplante Aufgabe für die Powershell erstellen und schon ist es fertig:

Das PowerShell Script kann die Excel Datei einlesen und Erinnerungsmails an einen zentralen Ansprechpartner, sowie an die E-Mail Adresse des Antragstellers versenden.

Um eine Mail zu verschicken müssen nur die ersten 5 Zeilen in der Datei “Zertifikatsverwaltung.ps1″ angepasst werden:

$Filepath ="C:\Einfache Zertifikatsverwaltung\Zertifikatsverwaltung.xlsx"
$MailanAntragsteller = "ja"
$smtpserver = "192.168.10.1"
$sender = "cert@frankysweb.de"
$recipient = "certadmin@frankysweb.de"

Das Script und die Excel Datei müssen nicht im gleichen Ordner liegen, auch ein Netzlaufwerk kann angegeben werden. Auf dem Rechner der die PS1 Datei ausführt, muss Excel installiert sein. Die PS1 Datei kann per Aufgabenplanung einmal am Tag gestartet werden, damit Erinnerungsmails verschickt werden. Für die Aufgabenplanung genügt eine ein einfacher Task der die Powershell.exe mit der Angabe der PS1 Datei startet:

Programm:

Powershell.exe

Argumente:

-Command “& ‘C:\Einfache Zertifikatsverwaltung\Zertifikatsverwaltung.ps1′”

Download:

Einfache Zertifikatsverwaltung 12.65 KB

Download

Zertifikate von einer Active Directory integrierten Zertifizierungsstelle lassen sich einfach per MMC anfordern. Wer aber ein Zertifikat kaufen möchte, benötigt eine Zertifikatsanforderung die bei der CA eingereicht werden kann. ECP bietet leider wenige Möglichkeiten um die Anforderung und das spätere Zertifikat zu konfigurieren. Der Weg über die Exchange Shell funktioniert deutlich besser. Der Befehl ist etwas länger, daher eine kleine Erklärung dazu:

New-ExchangeCertificate –Server "Servername" –GenerateRequest –FriendlyName "Exchange Zertifikat" –PrivateKeyExportable $true –SubjectName "c=LÄNDERCODE, s=BUNDESLAND, l=STADT, o=FIRMA, ou=ORGANISATIONSEINHEIT, cn=ALLEGMEINERNAME" –DomainName  outlook.frankysweb.de,autodiscover.frankysweb.de –RequestFile "\\SERVERNAME\C$\Anforderung.csr"

-Friendlyname ist der Anzeigename des Zertifikats in ECP, der Name ist frei wählbar

-SubjectName bestimmt die Eigenschaften des Zertifikats:

• “c” steht für den Ländercode, beispielsweise “DE”
• “s” steht für das Bundesland
• “o” steht für die Firma
• “ou” steht für die Organisationseinheit (IT, Exchange, EDV..)
• “cn” steht für den allgemeinen Namen, der allgemeine Name sollte den FQDN für OWA enthalten

-DomainName: Hier werden alle alternativen Namen für das Zertifikat eingetragen, sowie auch der allgemeine Name, im Normalfall werden hier nur Autodiscover und eben der Zugriffsname für Outlook, OWA, ECP, ActiveSync etc benötigt:

• outlook.frankysweb.de
• autodiscover.frankysweb.de

-Requestfile: Eine Freigabe auf der die Anforderung gespeichert werden kann

Die Anforderung kann jetzt bei einer CA eingereicht werden. Sobald das Zertifikat von der CA ausgestellt wurde, kann die Anforderung abgeschlossen werden:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certificate.cer -Encoding byte -ReadCount 0))

Zum Abschluss muss das neue Zertifikat den Exchange Diensten zugewiesen werden, entweder der Thumbprint des eben hinzugefügten Zertifikats wird für das CMDlet “enable-ExchangeCertificate” verwendet, oder es wird bequem das EAC verwendet. Hier der Weg über die Shell:

Enable-ExchangeCertificate -Thumbprint "thumbprintvonimport" -Services POP,IMAP,SMTP,IIS

Die erste öffentliche Preview von Office 2016 wurde veröffentlicht.

Office 2016 Preview kann hier runtergeladen werden:

https://products.office.com/en-us/office-2016-preview

Grund genug einen ersten Blick auf das kommende Outlook 2016 zu werfen

Beim ersten Start von Outlook 2016 hat sich optisch nicht viel getan, zunächst wird das Konto eingerichtet

Nach dem Einrichten des Kontos, präsentiert sich Outlook meiner Ansicht nach etwas aufgeräumter wie der Vorgänger:

Erinnert sehr stark an Outlook Web App 2013 Ich finde es lässt sich alles etwas besser lesen, aber das wird wohl Geschmackssache sein

Große Veränderungen, abgesehen vom Design, kann ich bisher nicht feststellen

Ganz nett finde ich ja die Feedback Funktion, auch wenn Sie in der finalen Version wohl nicht mehr zu finden ist.

Ich werde mal ein bisschen rumspielen. Die Highlights gibt es dann hier.

Auf dem Exchange Team Blog wurden Informationen zur neuen Exchange Server 2016 Architektur veröffentlicht. Eine der größten Änderungen ist wohl der Wegfall der Client-Access Rolle. Somit gibt es also nur noch eine Rolle, damit wird das Deployment also ziemlich einfach. Die Client Access Rolle wurde nun ebenfalls in die Mailbox Rolle integriert, Interessant ist, dass Microsoft dort eine Rolle Rückwärts vollzieht, denn auch schon bei Exchange 2003 gab es nur eine Rolle die alle Funktionen bereit gestellt hat. Mit Exchange 2007 wurden dann die Rollen getrennt, zunächst in Hub-Transport, Client Access und Mailbox. Dieses Konzept wurde auch bei Exchange 2010 beibehalten. Mit Exchange 2013 begann dann wieder die Konsolidierung, es gibt nur Mailbox und Client Access Rolle. Mit Exchange 2016 haben wir also wieder nur ein System welches alle Funktionen übernimmt.

Das Konzept der DAG wird beibehalten, aber verbessert. Laut Exchange Team Blog wurde die Datenbank Failover Zeit um 33% gesenkt. Für die Hochverfügbarkeit wird weiterhin ein Loadbalancer verwendet. Die Anforderungen an den Loadbalancer sind wie bei Exchange 2013 gering.

Das neue Standard Protokoll ist nun MAPI/HTTP, welches mit Exchange 2013 SP1 eingeführt wurde. Eine Unterstützung für die MAPI/CDO wird es nicht geben. Alte Anwendungen die die CDO nutzen müssen also auf EWS umgestellt werden.

Scheinbar wird auch die Migration von Exchange 2013 zu Exchange 2016 direkt ab Veröffentlichung unterstützt, sogar ein Mischbetrieb aus Exchange 2013 und Exchange 2016 soll möglich sein.

Die Spannung steigt also

Microsoft hat die Timeline für die Veröffentlichung von Exchange 2016 bekannt gegeben, demnach wird ein eine Öffentliche Beta bereits im Sommer geben. Die RTM Version ist dann für den Winter 2015 angekündigt:

Ebenfalls wurde erste Informationen veröffentlicht, was benötigt wird um das neue Feature “Document Collaboration” zu verwenden. Demnach wird neben Exchange 2016, auch SharePoint 2016 und Office Web Apps Server 2016 benötigt. Es ist also davon auszugehen, das diese Version zeitlich nah beieinander veröffentlicht werden.

Gerade habe ich den Exchange Reporter 2.2 veröffentlicht. Diesmal gibt es einige neue Module und mehrere Fehlerkorrekturen

Hier die Zusammenfassung der Änderungen:

• Neues Modul
  • careport.ps1 – Informationen zur Zertifizierungsstelle und Zertifikaten
  • pfreport.ps1  – Informationen zur Öffentlichen Ordnern
  • dgreport.ps1 – Listet ungenutzte Verteilerlisten auf
  • HPiLOReport.ps1 – Liest Information zu HP Servern aus
• Bugfix: Rechtschreibfehler behoben
• Bugfix: -Installpath Parameter wird nicht mehr zwingend benötigt, das Script ermittelt den Pfad selbst
• Änderungen an mailreport.ps1
  • Top 10 Sender/Empfänger nach Volumen
• Änderungen an mbxreport.ps1
  • Funktion für Postfächer nahe dem Sendelimit verbessert
• Änderungen an redirectreport.ps1
  • Alphabetische Sortierung (Danke Daniel!)
• Änderungen an dbreport.ps1
  • Farbliche Kennzeichnung wenn Backup älter als 7 Tage (Danke Daniel!)
• Dokumentation überarbeitet (allerdings noch nicht perfekt)

Exchange Reporter 2.2 kann hier runtergeladen werden, Feedback ist wie immer erwünscht.

Exchange Reporter 829.53 KB

Exchange Reporter

Vielen Dank an Daniel K. der mich auf Probleme hingewiesen hat und sogar Verbesserungen mit eingebracht hat (siehe oben)

Mittlerweile sind 69 Sessions der Ignite rund um Exchange und Themen rund um Exchange zum anschauen verfügbar. Anschauen lohnt sich!

Hier der der Link:

https://myignite.microsoft.com/#/videos/4af86b2a-0a95-e411-b87f-00155d5066d7

Das finde ich ja nett, Microsoft bietet das Upgrade auf Windows 10 kostenlos an:

Gibt es das auch für Server? Ich mache mal lieber ein Image und reservier mir mal das Upgrade…

Gerade habe ich die Version 2.3 des Exchange Reporters veröffentlicht. Hier die Änderungen:

• Erweiterung Exchange Reporter um 3rd Party Modul Kompatibilität
  • Neues (Erstes) 3rd Party Modul von Igmar Brückner
    • Auditreport.ps1 – Informationen zu Änderungen an der Exchange Konfiguration
• Neues Modul
  • rightsreport.ps1 – Informationen über Postfachberechtigungen
• Überarbeitung mbxreport.ps1
  • Anzeige von inaktiven Postfächern

Vielen Dank an Igmar Brückner von der Dresden IT GmbH, er hat das Modul Auditreport beigesteuert, welches Informationen zu Konfigurationsänderungen an Exchange anzeigt.

Wer selbst ein Modul veröffentlichen möchte, kann es gerne zuschicken. Vorschläge über neue Funktionen nehme ich aber auch gerne an.

Hier geht es zum Download:

Exchange Reporter 785.40 KB

Exchange Reporter

Das Update mit der Nummer KB3062157 behebt eine kritische Lücke in Exchange 2013 CU8 und SP1, die es ermöglicht höhere Berechtigungen zu erlangen. andere Versionen sind scheinbar nicht betroffen. Hier gibt es nähere Informationen:

https://technet.microsoft.com/library/security/MS15-064

Ein Neustart des Servers ist nicht erforderlich, allerdings werden die Exchange Dienste neugestartet. Hier geht es zum Download des Updates:

• Exchange 2013 CU8
• Exchange 2013 SP1

Das Update sollte schnellst möglich eingespielt werden.

Es wurden neue Updates für Exchange Server 2007, Exchange Server 2010 und Exchange Server 2013 veröffentlicht. Hier geht es zum Download

• Exchange Server 2013 CU9 (http://www.microsoft.com/de-DE/download/details.aspx?id=47679)
• UM-Sprachpakete für Exchange Server 2013 CU9 (http://www.microsoft.com/de-DE/download/details.aspx?id=47678)
• Exchange Server 2010 SP3 UR 10 (http://www.microsoft.com/de-DE/download/details.aspx?id=47676)
• Exchange Server 2007 SP3 UR 16(http://www.microsoft.com/de-DE/download/details.aspx?id=47677)

Hier ist eine Beschreibung der Fixes:

• Exchange 2013 CU9 (https://support.microsoft.com/en-us/kb/3049849)
• Exchange 2010 UR10 (https://support.microsoft.com/en-us/kb/3049853)
• Exchange 2007 UR17 (https://support.microsoft.com/en-us/kb/3056710)

Es ist wahrscheinlich ratsam etwas zu warten bis die Updates eingespielt werden, vieleicht gibt es ja wieder eine Rückrufaktion…

Falls Ihr auch häufiger DNS Abfragen zu den MX Records bzw. SPF und Reverse Einträgen machen müsst, hilft vieleicht dieses kleine Script:

Test-MXSettings.ps1

Das Script verfügt über ein paar Parameter, welches schnell alle Exchange akzeptierten Domains prüfen kann, oder auch eine beliebige Domain, auch ein DNS Server für die Abfrage lässt sich angeben. Folgende Parameter sind möglich:

-Testdomain <Domainname>: Überprüft eine Domain

-DNSServer <IP>: verwendet einen bestimmten DNS Server für die Abfrage (Standard ist der in Wndows eingestellte)

-TestExchangeDomains (True/False): Bei True werden alle vom Exchange Server akzeptierten Domains überprüft, dazu muss das Script von der Exchange Management Shell ausgeführt werden. Die Angabe von –Testdomain kann dann nicht verwendet werden.

Hier kann das Script runtergeladen werden:

Test-MXSettings 0.93 KB

Download

Hier gibt es ein Video zu Exchange 2016 von der Ignite mit vielen Informationen zur Migration, ich finde es sehr sehenswert:

video.ch9.ms/sessions/ignite/2015/BRK3129-mobile.mp4

Und hier ist noch ein gutes Video zur Architektur:

Exchange Server Preferred Architecture

Manche Programme benötigen ein anonymes Relay um Mails abliefern zu können, um anonymes Relay mit Exchange 2013 einzurichten, sollte ein neuer Connector erstellt werden, der die entsprechenden Berechtigungen und Einschränkungen für IP-Adressen besitzt:

In diesem Bespiel wird der neue Connector „Relay“ erstellt:

Der Connector kann entweder auf allen IP-Adressen des Exchange Servers horchen oder nur auf bestimmten. In den meisten Fällen werden es wohl alle verfügbaren Adressen sein.

Jetzt wird der Connector entsprechend eingeschränkt, damit nur bestimmte IP-Adressen anonymes Relay nutzen können. Hier sollten auf keinen Fall zu große IP-Kreise eingetragen werden. Besser ist hier nur explizit die Systeme einzutragen, die den Connector auch nutzen sollen.

Die Sicherheitseinstellungen des Connectors:

Damit der Connector auch Mails von jedem Absender an nimmt, muss noch die enstprechende Active Directory Berechtigung gesetzt werden.

Get-ReceiveConnector "Relay" | Add-ADPermission -User "NT-Autorität\Anonymous-Anmeldung" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Hier gibt es einen kleinen Stolperstein:

• Bei deutschen Servern heißt es „NT-Autorität\Anonymous-Anmeldung“
• Bei englischen Servern heißt es „NT AUTHORITY\ANONYMOUS LOGON“

Der Connector ist jetzt aktiv und nimmt Mails anonym von jedem Absender zu jedem Empfänger, aber nur von den entsprechend freigeschalteten IPs entgegen. Falls es sich um Systeme handelt die ein hohes Mail aufkommen produzieren, können noch ein paar Sicherhietseinstellungen abgeschaltet werden um den Durchsatz des Connectors zu erhöhen:

Set-ReceiveConnector -identity "Relay" -TarpitInterval 00:00:00
Set-ReceiveConnector -identity "Relay" -ConnectionTimeout 00:30:00
Set-ReceiveConnector -identity "Relay" -ConnectionInactivityTimeout 00:20:00
Set-ReceiveConnector -identity "Relay" -MaxAcknowledgementDelay 00:00:00
Set-ReceiveConnector -identity "Relay" -MaxInboundConnection 10000
Set-ReceiveConnector -identity "Relay" -MaxInboundConnectionPerSource unlimited

Gerade habe ich den Exchange Reporter aktualisiert, die Liste der Änderungen ist ein wenig länger und es sind auch zwei neue Funktionen hinzugekommen. Ihr könnt den Report jetzt auch als PDF ab die E-Mail anhängen lassen, schaut dazu bitte ins Handbuch, denn dazu muss eine Voraussetzung erfüllt sein.Außerdem  gibt es mit dem Modul „esareport.ps1″ jetzt auch eine rudimentäre Unterstützung für die Ironport (Cisco EMail Security Appliance). Hier eine Liste aller Änderungen:

• Report als PDF an Mail anhängen
• mbxreport.ps1: Anzeigen von getrennten Postfächern
• spacereport.ps1: MountPoints werden jetzt angezeigt
• Bugfixes
• Nur noch die Bilder für die aktivierten Module werden an die mail angehangen
• Darstellungsprobleme bei Clientinfo.ps1 behoben
• pfreport.ps1: DateTime Problem behoben
• rightsreport.ps1: Problem mit englischen Exchange Servern behoben, Send-As und Send-on-Behalf Rechte werden angezeigt
• Funktion der Exchange Versionserkennung verbessert
• dgreport.ps1: Fehler mit Variablen Name behoben
• 3rdParty Demo Modul hinzugefügt (3rdPartyDemo.ps1)
• Neues Modul
  • esareport.ps1: Zeigt Informationen zur Cisco Email Security Appliance (Ironport) an
• Dokumentation erweitert

Und hier geht es direkt zum Download:

https://www.frankysweb.de/exchange-reporter-2013/