Zum Hauptinhalt wechseln

Consulting-Team-Blog

Startet die Suche
Homepage
  

SharePoint 2010 Versionsnummern (Update)

Die ersten kummulativen Update Pakete für SharePoint 2010-Produkte sind veröffentlicht worden.

Nun beginnt also auch hier die Zeit, in der es nicht schaden kann, den Überblick über die entsprechenden Versionsnummern zu behalten.

Prüfen kann man die eigenen Versionnummern wie folgt (via Todd Klindt):

  • Farm
    Central Administration > System Settings > Manage servers in this farm
    (/_admin/FarmServers.aspx)
  • Komponenten
    Central Administration > Upgrade and Migration > Check Product and patch installation status
    (/_admin/PatchStatus.aspx)
  • Datenbanken
    Central Administration > Upgrade and Migration > Review database status
    (/_admin/DatabaseStatus.aspx)
Version Updatepaket Links
SharePoint Foundation SharePoint Server Project Server
​14.0.7102.5004 Cumulative Update (CU) June 2013,
Mark 2
KB2817552 KB2817527 KB2817530
14.0.7102.5000 Cumulative Update (CU) June 2013,
Mark 1
KB2817392 KB2817363 KB2817368
14.0.7015.1000 Service Pack (SP) 2 KB2687464 KB2687453 KB2687452
14.0.7011.1000 ​Service Pack (SP) 2, Public Beta - - -
14.0.6137.5000 Cumulative Update (CU) April 2013 KB2794728 KB2775353 KB2775426
14.0.6134.5003 Critical On Demand Fix (COD) February 2013 - KB2767795 -
14.0.6134.5000 Cumulative Update (CU) February 2013 KB2760791 KB2767793 KB2767794
14.0.6131.5003 Cumulative Update (CU) December 2012 - KB2596955 KB2596956
14.0.6131.5001 Cumulative Update (CU) December 2012 KB2596957 - -
14.0.6129​.5003 Cumulative Update (CU) November 2012 - KB2687564 -
14.0.6129.5000 Cumulative Update (CU) October 2012 KB2687566 - KB2687615
14.0.6126.5002 Cumulative Update (CU) August 2012 - - KB2687354
14.0.6126.5000 Cumulative Update (CU) August 2012 KB2687355 KB2687353 -
14.0.6123.5002 Cumulative Update (CU) June 2012 KB2598373 KB2598354 KB2598355
14.0.6120.5006 Cumulative Update (CU) April 2012,
Mark 2
KB2598321 KB2598151 KB2598152
14.0.6117.5002 Cumulative Update (CU) February 2012 KB2597132 KB2597150 KB2597152
14.0.6114.5000 Cumulative Update (CU) December 2011 KB2597058 KB2597014 KB2597015
14.0.6112.5000 Cumulative Update (CU) October 2011 KB2596508 KB2596505 KB2596506
14.0.6109.5002 Cumulative Update (CU) August 2011 KB2553048 KB2553049 KB2553050
14.0.6106.5002 Cumulative Update (CU) June 2011 KB2536601 KB2536599 KB2536600
14.0.6029.1000 Service Pack (SP) 1 Liste aller Pakete
14.0.5138.5001 Cumulative Update (CU) April 2011 KB2512804 KB2512800 KB2512801
14.0.5136.5002 Cumulative Update (CU) February 2011 KB2475880 KB2475878 KB2475879
14.0.5130.5002 Cumulative Update (CU) December 2010 KB2459125 KB2459257 KB2459258
14.0.5128.5000 Cumulative Update (CU) October 2010 KB2394323 KB2394320 KB2394322
14.0.5123.5000 Cumulative Update (CU) August 2010 KB2352346 KB2352342 KB2352345
14.0.5114.5003 Hotfix Packages June 2010 KB2028568 KB983497, KB2281364, KB2204024 KB2075990
14.0.4762.1000
14.0.4763.1000
Release to manufacturing (RTM) SharePoint Foundation 2010
SharePoint Server 2010 Trial
Short-URL zu diesem Beitrag: http://bit.ly/sp2010builds
Database Availability Group (DAG) in Exchange 2013
 

Dieser Blog beschreibt die Funktionen aus der Preview von Exchange 2013. Es kann also gut sein, dass einige Änderungen mit der endgültigen Version noch folgen werden.

Hintergrund

DAG ist seit Exchange 2010 die Clustertechnologie in Exchange. Damit wurden alle vorherigen Lösungen für die Hochverfügbarkeit der Mailbox-Rolle abgelöst. In einer DAG können bis zu 16 Server Mitglied sein, die dann bis zu 100 Mailbox-Datenbanken zwischen diesen Mitgliedern replizieren (Seeding). Ein Server hält dann immer die aktive Kopie der Mailbox-Datenbank, die anderen Mitgliedsserver halten eine Kopie. Fällt jetzt ein Server aus, wird eine der passiven Kopien zur aktiven Kopie, ohne das ein Eingriff seitens der Administration erforderlich ist (Switchover/Failover). Ist der ausgefallene Server wieder verfügbar, findet automatisch ein Reseeding statt.  Diese Komponente die das alles steuert nennt sich Active Manager und ist auf jedem DAG Server vorhanden.

DAG setzt den Windows-Cluster als Unterbau ein, deshalb müssen Sie mit Windows Server 2008 R2 die Enterprise Version als OS einsetzen.

Was ändert sich nun mit Exchange 2013

Exchange 2013 unterstützt als OS Windows Server 2008 R2 (SP1) und nun natürlich auch Windows Server 2012. Da es keine Enterprise Version in Windows Server 2012 mehr geben wird, reicht also zukünftig die Standard Version aus, da sie das Failover Clustering Feature schon mitbringt. Da die Anzahl möglicher Nodes bei Windows Server 2012 von 16 auf 64 angehoben wurde, stellt sich natürlich die Frage, ob mit Exchange 2013 die Anzahl der DAG Mitgliedsserver auch angehoben wurde. In den bisher vorliegenden Informationen seitens Microsoft sieht es nicht so aus (siehe auch http://technet.microsoft.com/en-us/library/dd979799(v=exchg.150).aspx). Dort wird weiterhin von max. 16 möglichen Mailbox-Servern gesprochen.

Einige Änderungen haben im Untergrund stattgefunden, so wurde z. B. der Dienst “Microsoft Exchange Information Store” komplett neu geschrieben und nennt sich jetzt “Managed Store”. Nicht verwirren lassen, in den Diensten steht weiterhin Information Store.

image

Der Managed Store arbeitet mit den “Microsoft Exchange Replication” Dienst zusammen, um die Mailbox-Datenbanken zu verwalten. Diese Datenbank-Engine beruht weiterhin auf Extensible Storage Engine (ESE). Auch hier wurden signifikante Änderungen am Datenbankschema vollzogen, die besonders ein schnelleres Datenbank-Failover und ein besseres Handling im Falle eines Plattenfehler (Disk Failure) ermöglichen sollen. In Exchange 2013 läuft jede Datenbank in einem eigenen Prozess, was eine Isolation ermöglicht. Ein Fehler in einer Datenbank wirkt sich also nicht auf andere Datenbanken aus.

Die neue Ära der Administration

Mit Exchange 2013 hat die alte Exchange Management Console (EMC) ausgedient. Zur Administration steht nur noch das Exchange Administration Center (EAC) oder die Powershell zur Verfügung. Aufgerufen wird das ganze über einen Browser (https://servername/ECP). Das bedeutet das EAC benutzt das schon unter Exchange 2010 vorhandene Exchange Control Panel (ECP) und erweitert es durch die benötigten Funktionen zur Administration:

image

Die EAC benutzt die neue Metro-Style-Oberfläche (oops, heißt ja jetzt Windows-8-Style), die auch bei der neuen Outlook Web App (OWA) benutzt wird. Dort finden wir unter der Rubrik Server alle Funktionen zur Erstellung und Administration einer DAG.

image

Es mag nun Geschmackssache sein, ob einen das Fehlen der EMC stört oder nicht. Ich selber vermisse zwei Dinge:

  • In der EMC war es möglich sich die auszuführenden Powershell-Befehle anzeigen zu lassen. Damit konnten Administratoren sich an die Syntax gewöhnen um später darauf aufbauend selber Scripts zu entwerfen. In der neuen GUI werden diese Befehle nicht mehr angezeigt.
  • Mit der EMC war es möglich sich sehr schnell einen Überblick über den Gesundheitszustand der DAG zu bekommen. In der neuen GUI ist das nicht mehr ganz so offensichtlich:

image

Ist aber kein so großes Problem, da sich der Zustand besser über den Powershell-Befehl Get-MailboxDatabaseCopyStatus anzeigen lässt.

 

Erstellen einer DAG mit der EAC

Das Erstellen der DAG funktioniert nicht anders als in Exchange 2010. Loggen Sie sich in EAC ein, gehen Sie zu Server und wählen Sie Database Availability Group aus. Durch einen Klick auf “+” erstellen wir die DAG:

image

In nächsten Fenster definiert man den Namen der DAG und den Zeugenserver (Witness), zusätzlich kann man noch eine IP für die DAG vergeben. Geben Sie kein Zeugenverzeichnis an, versucht Exchange eine Freigabe auf dem Zeugenserver unter C:\DAGFileShareWitness zu erstellen. Üblicherweise wird als Zeugenserver ein weiterer Exchange Server verwendet. Ist der Server kein Exchange Server müssen Sie die Gruppe “Exchange Trusted Subsystem” der lokalen Administrator Gruppe hinzufügen, ansonsten sind keine Rechte vorhanden um dieses Share zu erstellen.

image

image

Als nächstes fügen wir Mitgliedsserver der DAG hinzu:

image

Damit wird der Cluster gebaut und das Windows Failover Clustering Feature auf den Mitgliedsservern installiert. Dieser Schritt kann einen Moment dauern.

image

Als nächstes sollte man die Option “Database Availability Group-Netzwerke konfigurieren” aktivieren, um das Verhalten der Netzwerke zu konfigurieren:

image

 

Jetzt sieht man, dass Exchange versucht hat selbst DAG Netzwerke anhand der vorhandenen Netzwerke zu erstellen und zuzuordnen. In unserem Fall haben wir ein Netzwerk für das Server-Netzwerk (MapiDagNetwork) und ein Netzwerk, dass später ausschließlich für die Replikation der Mailbox-Datenbanken benutzt werden soll (ReplicationDagNetwork).

image

Wenn wir jetzt die Replikation auf dem MapiDagNetwork entfernen wollen, klicken wir auf “Replikation deaktivieren”

image

Abschließend müssen wir nun entweder einer neuen oder einer bestehenden Datenbank eine Datenbankkopie hinzufügen:

image

image

 image

Erstellen einer DAG mit Powershell

Folgende Befehle sind notwendig um die oben aufgeführten Schritte per Powershell Kommandos auszuführen:

New-DatabaseAvailabilityGroup –Name “DAGName” –WitnessServer “Witness Servername” – DatabaseAvailabilityGroupIPAddresses “IP Adresse”

Add-DatabaseAvailabilityGroupServer –Identity “DAGName” –MailboxServer “Name of Memberserver 1”

Add-DatabaseAvailabilityGroupServer –Identity “DAGName” –MailboxServer “Name of Memberserver 2”

Set-DatabaseAvailabilityGroupNetwork –Identity “MapiDagNetwork” -ReplicationEnabled $false

Add-MailboxDatabaseCopy –Identity “DAGName” –MailboxServer “Name of Memberserver”

Monitoren der DAG

Wie schon angedeutet, ist die GUI nicht mehr die erste Wahl beim monitoren der DAG. benutzen Sie deshalb die Commandlets:

Get-MailboxDatabaseCopyStatus –identity “DagName”

image

Zum Testen der Datenbank Replikation benutzen Sie

Test-ReplicationHealth

image

 

Fazit

Microsoft hat in den Tiefen des Systems getunt. So ist mir in der freien Wildbahn schon des Öfteren eine defekte Datenbankkopie begegnet, welche neu angelegt werden musste. Ist die Datenbank sehr groß, dauert ein erneutes Seeding entsprechend lange. Mit Exchange 2013 soll die Stabilität und die Zeit für eine erneute Replikation verbessert worden sein. An der Bedienung hat sich bis auf die neue Administrations-GUI nicht viel geändert und wie bei allen neuen Produkten ist meist die Powershell als Administrationstool der GUI vorzuziehen.

Bereitstellen von Office Web Apps in SharePoint 2013 (Preview)

Die Preview von SharePoint 2013 und vielen weiteren Produkten der Wave 15 sind seit kurzem verfügbar und es gibt viel Neues zu entdecken. Eine dieser Neuerungen sind die komplett überarbeiteten Office Web Apps, die nun als eigenständiges Server-Produkt installiert werden. In diesem Blogbeitrag zeige ich, wie man Office Web Apps bereitstellt und in SharePoint 2013 einbindet.

 

Installation von Office Web Apps

Als Umgebung für die Installation habe ich eine SharePoint 2013 Single Server Farm auf dem Server SRV-1, auf dem meine Webanwendung http://intranet.litware.com läuft. Zusätzlich gibt es den Server SRV-WAC, der unter der Url http://wac.litware.com die Office Web Apps bereitstellen soll.

Ein Überblick über diese kleinste mögliche Architektur:

image

Hier zeigt sich nun auch schon die wohl größte Änderung der Office Web Apps. Office Web Apps sind ein eigenes Server-Produkt und können nicht auf einem SharePoint Server installiert werden. Wer es dennoch probiert wird eine entsprechende Meldung auf den Bildschirm bekommen:

image

Also auf zur Installation auf meinem brandneuen Server SRV-WAC. Ohne weitere Vorbereitung wird mich auch hier von eine Fehlermeldung von der Installation der Office Web Apps abhalten:

image

Das sind sozusagen Systemvoraussetzungen, die erst erfüllt werden müssen, bevor die Office Web Apps 2013 installiert werden können. Leider gibt es an dieser Stelle keinen Prerequisites Installer, wie es ihn zum Beispiel für SharePoint gibt. Es müssen also alle Komponenten einzeln heruntergeladen und installiert werden. Zusätzlich zu den genannten Punkten müssen in meinem Windows 2008 R2 SP1 das  Windows Update KB2592525 und einige Features installiert werden.

Hier die Links zu den benötigten Paketen:

.NET Framework 4.5 RC

Windows PowerShell 3.0

KB2592525

Die zusätzlichen Features können über die Windows PowerShell hinzugefügt werden:

“Add-WindowsFeature Web-Server, Web-WebServer, Web-Common-Http, Web-Static-Content, Web-App-Dev, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Includes, Web-Security, Web-Windows-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, Web-Mgmt-Console, Ink-Handwriting, IH-Ink-Support”

Mit dem Hinzufügen der benötigten Features sind nun alle Voraussetzungen für die Installation auf dem Server SRV-WAC erfüllt und mit dem Start der setup.exe aus dem Installationsordner der Office Web Apps kommt nach dem Begrüßungsbildschirm direkt die Lizenzvereinbarung.

clip_image001

Mit dem Akzeptieren der Lizenzvereinbarung geht es weiter zur Auswahl des Installationsverzeichnisses. Für produktive Umgebungen sollte hier ein Datenlaufwerk ausgewählt werden.

clip_image002

Nach der Auswahl des Installationsverzeichnisses und einem Klick auf “Install Now” kann man für eine recht kurze Zeit dem Fortschrittsbalken zuschauen.

clip_image003

Im Erfolgsfall gibt es nach wenigen Minuten nur noch folgendes Fenster zu sehen und damit sind die Office Web Apps auf diesem Server installiert.

clip_image004

 

Konfiguration der Office Web Apps

Mit Abschluss der Installation, kann nun die Konfiguration von Office Web Apps gestartet werden. Dazu wird die PowerShell auf unserem Office Web Apps Server benötigt.

“New-OfficeWebAppsFarm -InternalURL http://wac.litware.com -AllowHttp –EditingEnabled”

image

Mit diesem CmdLet erstellt man eine Office Web Apps Farm auf dem Server mit der angegebenen Url, ohne SSL-Verschlüsselung und mit der Möglichkeit, dass Dokumente bearbeitet werden können. Durch die Farm-Konfiguration bleibt die Möglichkeit, bei Bedarf weitere Server zur Farm hinzuzufügen. Auch die Parameter können den Bedürfnissen weiter angepasst werden, in dem beispielsweise auch eine externe Url mit SSL-Verschlüsselung erstellt wird oder die Bearbeitung deaktiviert wird, so dass diese Farm im lizenzfreien Lesemodus betrieben wird.

Zur Überprüfung der Farm kann nun mit http://wac.litware.com/hosting/discovery der Discovery-Dienst aufgerufen werden. Das sollte etwa so aussehen:

image

Zwei weitere CmdLets sind an dieser Stelle noch empfehlenswert:

New-OfficeWebAppsMachine - Ermöglicht auf weiteren Servern das Hinzufügen zur Farm

New-OfficeWebAppsHost – Legt Domänen fest, in der Server sein müssen, die den Office Web Apps Dienst nutzen dürfen. Im Standard dürfen Server jeder beliebigen Domäne angehören, sobald dieser Parameter gesetzt wird, erstellt man damit eine Art Whitelist.

 

Einbindung von Office Web Apps in SharePoint

Damit sind alle Schritte für eine funktionierende Office Web Apps Farm gemacht. Nun kann diese Farm in SharePoint 2013 eingebunden werden. Auch das geschieht wieder über CmdLets in der SharePoint PowerShell.

New-SPWOPIBinding -ServerName wac.litware.com –AllowHTTP

image

Set-SPWopiZone –zone “internal-http”

Das erste der beiden CmdLets erstellt eine Bindung an die Office Web Apps Farm. Dabei werden die Einstellungen von der Office Web Apps Farm, insbesondere die verfügbaren Dokumententypen, abgerufen. Anschließend wird noch die Zone festgelegt, so dass SharePoint bei der Konfiguration mit mehreren Urls auf der Office Web Apps Farm immer nur eine bestimmte Url anspricht bzw. an die Benutzer weiter gibt.

Nun sind alle Schritte getan, um Office Web Apps in SharePoint zu nutzen. So lassen sich nun verschiedene Dokumente direkt in einer Dokumenten Bibliothek erstellen.

image

Es gibt eine Vorschau in der Bibliothek…

image

…und auch die SharePoint 2013 Suche wird um eine Vorschaufunktion erweitert.

image

Das war’s mit Office Web Apps und SharePoint 2013 Preview und ich wünsche viel Spaß beim Nachbauen.

Hochverfügbarkeit unter Exchange 2010/2013

Unternehmen legen Ihre “lebenswichtigen” Systeme immer hochverfügbar aus. Damit sind Systeme gemeint, ohne die das Unternehmen arbeitsunfähig wäre. Dazu gehört wohl heutzutage unbestritten das Mailsystem. Unter hochverfügbar versteht man dabei, dass beim Ausfall eines Systems ein anderes die Aufgaben möglichst unterbrechungsfrei übernehmen kann. Der Endbenutzer bekommt im Idealfall von dem Ausfall eines Systems nichts mit.

In diesem Artikel möchte ich mich auf die Hochverfügbarkeit von Exchange ab der Version 2010 beschränken. Damit meine ich das redundante Auslegen der Exchange-Serverrollen. Es gibt auch andere Möglichkeiten einen Exchange Server redundant auszulegen (z. B. Betreiben einer virtuellen Maschine in einem Failover Cluster).

Wie wird Exchange 2010 hochverfügbar?

Will man also Exchange 2010 hochverfügbar betreiben, muss man zuerst einen Blick auf die Serverrollen werfen und diese sind unter Exchange 2010:

  • Hub-Transport-Server (HUB)
  • Client-Access-Server (CAS)
  • Mailbox-Server (MBX)

Ich möchte nicht verschweigen, dass es auch noch die Rollen Unified Messaging (UM) und Edge-Transport gibt. Diese sind aber nicht Bestandteil dieser Betrachtung.

HUB-Serverrolle:

Diese Rolle ist für die Übertragung der Nachrichten in der gesamten Exchange Organisation zuständig. Deshalb findet hier auch die Nachrichtenhygiene (Anti-Virus, Anti-Spam), sowie die Anwendung von Transportregeln statt.

Um die Hub-Transport-Serverrolle hochverfügbar auszulegen, genügt es auf einem weiteren Exchange Server diese Rolle zu installieren. Sie müssen anschließend nur noch die Sende- und Empfangsconnectoren konfigurieren, damit diese Connnectoren alle Server benutzen können auf denen die HUB-Serverrolle installiert ist.

CAS-Serverrolle:

Alle Clients verbinden sich über die CAS-Serverrolle zu einem Exchange Server. Diese Rolle leitet sozusagen die Clients zu dem entsprechenden Datenbankserver weiter, auf dem sich die Mailbox des Benutzers befindet.

Die Auslegung dieser Rolle kann auf zwei Arten geschehen: mit Hardware oder Software. Um die CAS-Serverrolle mittels Software hochverfügbar auszulegen, ist die Konfiguration des Netzwerklastenausgleichs (Network Load Balancing=NLB) erforderlich. Dazu bedarf es zweier Exchange Server mit installierter CAS-Serverrolle über die dann das NLB gespannt wird. Da es im Betrieb in einem Unternehmen immer mal wieder zu Problemen mit NLB kommt, empfiehlt Microsoft selber neuerdings eher den Einsatz von Hardware-Loadbalancern (näheres siehe auch http://www.stevieg.org/2010/11/exchange-team-no-longer-recommend-windows-nlb-for-client-access-server-load-balancing/).

Bei beiden Varianten kommt immer ein sogenanntes Clientaccessarray (CAS-Array) zum Einsatz. Dabei wird eine virtueller Name mit einer eigenen IP geschaffen und dafür gesorgt, dass alle Clients diesen virtuellen Namen ansprechen.

MBX-Serverrolle:

Mit Einführung von Exchange 2010 gibt es nur noch eine Möglichkeit die MBX-Serverrolle hochverfügbar zu gestalten. Dazu wurde die Database Availibility Group (DAG) eingeführt. Dabei wird eine Mailbox-Datenbank (DB) erstellt und anschließend eine Kopie dieser DB auf einem anderen Exchange Server mit installierter MBX-Serverrolle repliziert. Dadurch entsteht eine aktive und eine passive Kopie der Datenbank, die ständig repliziert wird um auf dem aktuellen Stand zu sein. Hier wird das Windows Cluster Feature verwendet, weshalb beim Einsatz auf einem Windows Server 2008 R2 eine Enterprise Version notwendig ist.

image

DAG und NLB zusammen auf zwei Servern wird nicht von Microsoft supportet. Deshalb sieht die kleinst mögliche hochverfügbare Installation mit Windows-Mitteln vier Exchange-Server vor, während Sie beim Einsatz eines Hardware-Loadbalancers mindestens zwei Exchange-Server benötigen und natürlich zusätzlich die Loadbalancer Hardware (die Sie ja aus Gründen der Hochverfügbarkeit auch redundant auslegen):

image

Kostenmäßig dürften die Variante mit den Loadbalancern vorne liegen und damit teurer sein. Man darf aber dabei nicht vergessen, dass Sie mit den Hardware-Loadbalancern nicht nur Exchange hochverfügbar machen, sondern diese Hardware auch für andere Dienste (Sharepoint, Websites, etc.) benutzen können.

Wie sieht es jetzt zukünftig unter Exchange 2013 aus?

Zukünftig wird die Anzahl der Rollen verkleinert, d. h. es wird nur noch die Serverrollen Mailbox und Client Access geben. Besser beschreibt Frontend und Backend diese Architektur.

image

(http://technet.microsoft.com/en-us/library/aa996349(v=exchg.150).aspx)

Mailbox-Serverrolle:

Diese Rolle ist jetzt nicht nur für die Mailbox-Datenbanken zuständig, sondern beherbergt zusätzlich auch einen Teil der Transport-Dienste. Genauer gesagt den Hub Transport Service (zuständig für den Transportweg Front End Transport Service von und nach Mailbox Transport Service) und den Mailbox Transport Service (zuständig für den Transportweg Hub Transport Service von und nach Mail Transport Service). Die HUB-Transportrolle wird also in drei Dienste aufgeteilt.

Client Access-Serverrolle:

Der Client Access Server ist nichts weiter als ein intelligenter Reverse-Proxy, der die Anfragen der Clients an den Backend-Server weiterleitet auf dem die aktive Datenbank des Benutzers liegt. Jeglicher Client Traffic wird also lediglich nach der Authentifizierung an den aktiven Backend-Server weitergeleitet. Diese Komponente speichert keinerlei Daten. Neu ist hierbei, dass der Zugriff für Clients nur noch über RPC over HTTPS (Outlook Anywhere) möglich ist, MAPI entfällt. Hört sich zuerst nachteilig an, ist aber ein Vorteil, da der RPC Client Access Service eine Affinität benötigte. Hatte man keine statischen Ports für MAPI festgelegt, wurden diverse Verbindungen im High-Port Bereich aufgebaut, ein Greul für jeden Firewall-Admin. Selbst wenn statische Ports definiert wurden, musste sichergestellt werden, dass die Verbindungen eines Clients alle über den gleichen Server liefen. Ein weiterer Vorteil ist auch, dass https Verkehr sich gut über Proxies leiten lässt.

Zu der Client Access Rolle gehört auch ein Teil der Transport Dienste, nämlich der Front End Transport Service. Nachrichten passieren diesen Dienst auf dem Weg vom Front End Transport Service zum Mailbox Transport Service.

In einer Exchange-Organisation müssen pro Active Directory Site beide Rollen installiert sein. Beide Rollen können auf einen Server installiert werden, können aber auch getrennt installiert werden. Die Clients verbinden sich also gegen einen oder mehrere CAS-Server (Clientaccessarray) und der Client Access Server leitet die auf Port 443 ankommenden Daten zum Mailbox Server auf Zielport 444 weiter.

Wie werden diese neuen Rollen jetzt hochverfügbar gemacht?

Da ändert sich in der Denkweise nicht so viel. Die Transportschicht ist größtenteils zur Mailbox-Rolle gewandert und benötigt außer dem mehrmaligen Vorhandensein keine weiteren Installationen (nur Konfigurationen) um hochverfügbar zu sein.

Für die Mailbox-Rolle selbst gibt es weiterhin die DAG. Die DAG wurde hinsichtlich eines schnelleren Failovers optimiert. Auch wurden Verbesserungen eingeführt, wenn man eine DAG über mehrere Standorte spannen möchte (Enhanced Site Resiliency).

Will man die Client Access Rolle hochverfügbar auslegen, bestehen auch hier die gleichen Möglichkeiten wie schon unter Exchange 2010. In Frage kommen also NLB oder Hardware-Loadbalancing. Da der Hardware-Loadbalancer nicht mehr so hohe Anforderungen wie noch unter Exchange 2010 benötigt (Stichworte SSL-Offloading, komplexe Affinität), muss er nicht mehr so leistungsfähig sein und das wird sich im Preis bemerkbar machen. Insofern ist ein Hardware-Loadbalancer einem NLB vorzuziehen.

Einer meiner nächsten Blogs wird sich deshalb mit der Einrichtung eines solchen Hardware-Loadbalancers befassen.

Exchange Transportregeln und Änderungen in Exchange 2013

Einleitung

Viele Unternehmen sind gezwungen aufgrund von Gesetzesvorgaben, oder sei es auch nur durch eigene auferlegte Vorschriften, Richtlinien durchzusetzen die den Sinn haben den gesamten Mailtransport (intern, extern) zu beschränken oder zu filtern. Als Beispiel führe ich hier folgende Punkte auf (diese Aufzählung ist natürlich nicht abschließend):

  • Hinzufügen von Text-Bausteinen (Disclaimer, Signatur, etc.)
  • Nachverfolgen oder Archivieren von Nachrichten
  • Verhindern, dass unangemessene Inhalte empfangen oder versendet werden
  • Umleiten von Nachrichten

Dazu können diverse Hilfsmittel herangezogen werden. Betreiben Sie Exchange ab der Version 2007 lokal, können Sie dazu die Transportregeln verwenden.

Der Transportregel-Agent

In den Exchange Versionen 2007 und 2010 ist für den Transport von Nachrichten die sogenannte Hub-Transport-Rolle zuständig. Der Transportregel-Agent verarbeitet Transportregeln auf Hub-Transport-Servern und wird beim Transportereignis OnRoutedMessage ausgelöst. Alle Nachrichten in einer Exchange Organisation durchlaufen mindestens einen Hub-Transport-Server, deshalb ist hier die richtige Stelle wo solch eine Regel greifen sollte, denn hier müssen alle Nachrichten durch. Die wirkliche Arbeit verrichtet der Transportregel-Agent, der auf allen Hub-Transport-Servern in der Organisation installiert ist. Die auf einem Hub-Transport-Server gespeicherten Transportregeln werden im Active Directory in der Konfigurationspartition gespeichert. Dadurch wird gewährleistet, dass ein einheitlicher Regelsatz verwendet wird.

image

 

Dabei fragt jeder Hub-Transport-Server die aktuelle Transportregelkonfiguration ab und wendet dann diese Regeln auf die zu verarbeitenden Nachrichten an.

Ich möchte nicht verschweigen, dass es auf Edge-Servern auch einen Edge-Regel-Agent gibt. Dieser ist jedoch nicht Bestandteil dieser Betrachtung.

Transportregelkomponenten

Transportregeln können Sie sich vorstellen wie servergespeicherte Outlook-Regeln, nur mit anderen Möglichkeiten. Genau wie bei Outlook Regeln ist es möglich Bedingungen, Aktionen und Ausnahmen zu definieren.

  • Bedingungen:  Damit versucht man die Nachrichten zu bestimmen, auf denen die Transportregel angewendet werden soll. Die Auswahl erfolgt anhand von Prädikaten. Eine vollständige Liste aller verfügbaren Prädikate findet sich unter http://technet.microsoft.com/de-de/subscriptions/dd638183(v=exchg.140).aspx.
  • Aktionen: wirken sich auf die Nachrichten aus die unter Bedingungen definiert wurden und nicht durch die Ausnahmen von der Verarbeitung ausgeschlossen wurden. Damit lassen sich diverse Aktionen vollziehen, vom Hinzufügen weiterer Empfänger, Umleiten von Nachrichten bis zum Löschen von Nachrichten. Viele weitere Aktionen sind verfügbar: http://technet.microsoft.com/de-de/subscriptions/aa998315(v=exchg.140).aspx
  • Ausnahmen: Hier gelten die gleichen Prädikate wie bei den Bedingungen und bestimmen die Nachrichten auf welche die Transportregeln nicht angewendet werden sollen.  
Erstellung von Regeln

Wie bei fast alles in Exchange gibt es immer zwei Möglichkeiten zum Ziel zu kommen. Entweder Sie benutzen die Exchange Management Console (EMC) oder Sie benutzen die Powershell. Sie finden in der EMC den Bereich für die Erstellung und Bearbeitung von Transportregeln unter Organisationskonfiguration > Hub Transport > Transportregeln:

image

Wollen Sie mit der Powershell arbeiten sind folgende Kommandos wichtig:

Get-Command –Noun *TransportRule*

image

Abarbeitung der Regeln

Transportregeln werden anhand ihrer Priorität abgearbeitet, wobei mit der niedrigsten Priorität begonnen wird. Alle Transportregeln werden somit nacheinander auf eine Mail angewendet.

Praxistipps

  • Die Regeln sind nicht erweiterbar. Das bedeutet, Sie können keine eigenen Aktionen oder Bedingungen definieren.
  • Mails werden nur einmal auf dem Transportweg verarbeitet. Nach der Verarbeitung erfolgt eine Kennzeichnung mit einem internen Header, so dass  andere Hub-Transport-Server diese Mail nicht nochmal verarbeiten.
  • Sie können keine Regeln definieren die sich auf ein Postfach auswirken (z. B. Ablegen in Unterordner eines Postfaches).
  • In Office 365 lassen sich maximal 100 Transportregeln erstellen.
  • Regeln lassen sich auch deaktivieren. So müssen Sie die Regeln nicht immer neu erstellen, falls Regeln nur in einem bestimmten Zeitraum erforderlich ist (z. B. Weiterleitung von Mails während einer Urlaubsvertretung).

Was ändert sich in Exchange 2013

Bearbeitung

Da es keine EMC in Exchange 2013 mehr gibt, werden die Regeln im neuen Exchange Administration Center (EAC) bearbeitet. Diese Konsole ist nun webbasiert, so dass es nicht mehr notwendig ist Management Tools zu installieren. Um zur EAC zu gelangen, navigieren Sie zu https://<servername>/ecp. Sie finden die Transportregeln dann unter Nachrichtenübermittlung > Regeln:

image

Die Commandlets wurden nicht erweitert:

image

Auch gab es eine Veränderung in den Serverrollen, so wurde die Hub-Server-Rolle entfernt und in 3 Teile aufgegliedert:

  • Front-End Transport Service (FET)

  • Hub Transport Service (HT)

  • Mailbox Transport Service (MT)

Das bedeutet, dass es in Exchange 2013 nur noch zwei Serverrollen (ClientAccess und Mailbox) gibt. An dieser Stelle ist wichtig zu wissen, dass das Anwenden von Transportregeln im Hub Transport Service stattfindet. Diese Rolle gehört jetzt zur Mailbox-Rolle.

Unterstützung für Data Loss Prevention (DLP) Policys

DLP ist ein Regelwerk das verhindern soll, dass sensible Daten das Unternehmen verlassen. Dazu lassen sich Transportregeln so definieren, dass Nutzer beispielsweise eine Warnung bekommen, wenn sie sensible Daten des Unternehmens an nicht befugte Personen senden oder weitergehend auch darin gehindert werden. Dazu stehen vordefinierte Vorlagen zur Verfügung. Als Beispiel dient hier eine Mail, in der eine Kreditkartennummer eingegeben wurde. Dazu erstellen wir zuerst die Transportregel:

image

image

Definieren der vertraulichen Information:

image

Aktion hinzufügen:

image

Testmail mit Kreditkartendaten:

image

Ergebnis: Die Mail wird nicht zugestellt!

image

 

Neue Bedingungen wurden hinzugefügt
  • MessageContainsDataClassifications: Wird benutzt um sensitive Informationen in der Nachricht oder Anhängen zu erkennen (bereits oben beschrieben).
  • HasSenderOverride: Wird benutzt um Nachrichten zu erkennen in denen der Sender DLP Policys überschrieben hat.
  • SenderIPRanges: Wirkt auf einen zu definierenden IP-Adressraum.

image

image

  • AttachmentExtensionMatchesWords: Wirkt auf Anhänge mit zu definierenden Erweiterungen (Extensions).

image

  • MessageSizeOver: Wirkt auf Nachrichten deren gesamte Größe gleich oder größer ist einem definierbaren Wert ist.

image

image

 

Neue Aktionen wurden hinzugefügt
  • NotifySender: Kontrolliert wie ein Absender, der gegen DLP Policys verstößt, benachrichtigt wird. Wählbar ist informieren und trotzdem versenden oder informieren und abweisen der Nachricht.

image

  • StopRuleProcessing: Verhindert, dass nachfolgende Regeln angewendet werden. Vorher wurden immer alle Regeln auf eine Mail angewendet.

image

  • RouteMessageOutboundRequireTLS: Verlangt eine TLS Verschlüsselung, wenn Nachrichten außerhalb der Organisation geroutet werden. Kann TLS nicht verwendet werden, wird die Nachricht nicht ausgeliefert.

image

  • ReportSeverityLevel: Legt den Schweregrad für einen Sicherheits-Report fest. Mögliche Werte sind Informational, Low, Medium, High, und Off.

image

  • GenerateIncidentReport: Erstellt eine Vorfallsmeldung und versendet diesen an eine SMTP-Adresse. Dabei kann gewählt werden, ob die Original-Nachricht inkludiert wird oder nicht.

image

image

So sieht ein Report aus:

image

Andere Änderungen in Transportregeln
  • Support for extended regular expression syntax: Regular Expression wird unterstützt.
  • Transport rules agent invocation: Der Transportregel-Agent triggert nicht mehr auf onRoutedMessage sondern auf onResolvedMessage. Das erlaubt neue Aktionen, wie z.B. das Erzwingen von TLS.
  • Detailed Transport rule information in message tracking logs: Detaillierte Informationen über Transportregeln werden jetzt in die Message Tracking Logs geschrieben. Man kann dort sehen, welche Regel auf eine bestimmte Mail angewendet wurde und welche Aktion daraufhin ausgeführt wurde.
  • New rule monitoring functionality: Exchange 2013 kann Verzögerungen erkennen die Transportregeln auslösen und dafür Berichte erstellen.
  • Zeitliche Abhängigkeit: Genau wie bei Outlook Regeln kann man einen Start- und Endzeitpunkt angeben (tageweise):

image

Fazit

Transportregeln waren schon unter Exchange 2010 ein oft genutztes Werkzeug für Administratoren und werden durch die vielen Erweiterungen in Exchange 2013 noch öfter zum Einsatz kommen.

Änderung der Tastatureinstellungen hat keine Auswirkung auf den Windows-Anmeldebildschirm

Insbesondere in Virtualisierungsumgebungen können vorgefertigte Windows-Images und –Templates sehr hilfreich sein. Problematisch kann es jedoch werden, wenn die vorgegeben Tastatureinstellungen nicht dem Tastaturlayout der verwendeten Tastatur entsprechen und viele Zeichen nicht auf den gewohnten Tasten zu finden sind. Dabei ist die Änderung des Tastaturlayouts von Englisch auf Deutsch schnell erledigt. Jedoch hat diese Umstellung nicht immer die gewünschte Auswirkung auf den Anmeldebildschirm von Windows. Bei Kennwörtern mit Sonderzeichen kann man dann schon mal zur Verzweiflung getrieben werden, doch schon seit Windows Vista bzw. Windows Server 2008 gibt es eine scheinbar recht unbekannte Abhilfe.

Hier gibt es, im Gegensatz zu älteren Windows Versionen, in den Einstellungen für Region und Sprache nun einen zusätzlichen Reiter „Administrative“.

clip_image001

Durch einen Klick auf „Copy settings…“ öffnet sich eine Maske, mit der man die Einstellungen des aktuellen Benutzers (Current User), des Anmeldebildschirms (Welcome screen) und für neue Benutzerkonten (New User Accounts) einsehen kann.

clip_image002

Durch das Aktivieren der Checkboxen im unteren Bereich lassen sich die Einstellungen des aktuellen Benutzers auf den Anmeldebildschirm und/oder neue Benutzerkonten übertragen.

Hintergrund des Ganzen ist, dass Regions- und Spracheinstellungen benutzerbezogene Einstellungen sind. Im Anmeldebildschirm ist jedoch kein Benutzer angemeldet und somit muss auf Standardwerte zurückgegriffen werden. Gleiches gilt natürlich für das Erstellen neuer Benutzerkonten im System, auch hier werden zunächst die Standardwerte übernommen, bis der Benutzer diese Einstellungen ändert. Sowohl die Einstellungen des Benutzerkontos, mit dem man gerade angemeldet ist, als auch die Standardwerte findet man in der Windows Registry.

Für das eigene Benutzerkonto sind die Werte in den Registry-Pfaden [HKEY_CURRENT_USER\Control Panel\International] und [HKEY_CURRENT_USER\Control Panel\Keyboard] zu finden. Die Standardwerte gibt es in der Registry in der Sektion HKEY_USERS, genauer in den Pfaden [HKEY_USERS\.DEFAULT\Control Panel\International] und [HKEY_USERS\.DEFAULT\Keyboard Layout\Preload].

Im Pfad [HKEY_USERS\.DEFAULT\Keyboard Layout\Preload] befindet sich dabei die Einstellung für das Tastaturlayout, welches auch im Anmeldebildschirm verwendet wird. Dort existiert in der Regel mindestens ein Eintrag mit dem Namen „1“ und beispielsweise dem Wert „00000409“ für das englische Tastaturlayout. Ändert man diesen Wert auf „00000407“, wird das im Anmeldebildschirm verwendete Tastaturlayout auf Deutsch umgestellt. Gibt es mehrere Einträge, kann auch im Anmeldebildschirm mit Alt+Shift zwischen den Tastaturlayouts gewechselt werden.

clip_image003

Mit der passenden Einstellung sollten Logins und Kennwörter mit Sonderzeichen also kein Problem mehr sein. Da ich als Administrator jedoch nicht immer wieder manuell die gleiche Arbeit tun möchte, gibt es für Windows 7 und Windows 2008 R2 auch die Möglichkeit, das Ganze mit der Windows PowerShell zu lösen:

New-PSDrive HKU Registry HKEY_USERS
Set-ItemProperty -Path "HKU:\.DEFAULT\Keyboard Layout\Preload\" -Name "1" -Value "00000407"

Mit diesen beiden Cmdlets wird zunächst der Hauptschlüssel HKEY_USERS als PowerShell-Drive zur Verfügung gestellt. Im zweiten Schritt wird dann der Wert des Schlüssels mit dem Namen 1 auf den mit „-Value“ definierten Wert gesetzt, hier auf „Deutsch“.

Weitere Sprach-IDs kann man den Webseiten des Microsoft Technets entnehmen:

http://technet.microsoft.com/en-us/library/dd744319%28v=ws.10%29

Daten-Deduplizierung in Windows Server 8 (Beta)

Daten-Deduplizierung ist an sich nichts Neues. Viele Third-Party-Hersteller von Storage- und Backup-Lösungen bieten diese Funktion seit Jahren an, allerdings ist der Einsatz solcher Systeme häufig mit sehr hohen Kosten verbunden.

Windows Server 8 liefert erstmals eine native, in das Betriebssystem integrierte Deduplizierungslösung. Die grundlegende Funktionsweise beruht dabei auf der effizienten Verwaltung von Daten auf Blockebene mit einer variablen Blockgröße von 32 bis 128 KByte. Redundante Datenblöcke werden in einen von Windows verwalteten Blockspeicher im System-Volume-Information-Abschnitt der Festplatte kopiert. Dies geschieht gewöhnlich im Leerlaufprozess des Servers, so dass die Leistungsfähigkeit des Systems kaum beeinträchtigt wird.

Durch Anwendung dieser Technologie verspricht sich Microsoft eine Deduplikationsrate von 30 – 90% und somit einen enormen Zugewinn an Speicherressourcen. Das gilt es im Folgenden zu überprüfen.

Um dies zu tun, installiert man zunächst den zur Rolle „File Services“ zugehörigen Rollendienst „Data-Deduplication“ hier auf einem Windows Server 8 Datacenter per GUI oder Power Shell.

image

Anschließend aktiviert man die Deduplizierungs-Funktion für jedes geeignete Volume separat mittels Server Manager im Bereich „File and Storage Services“. Das für den Test vorgesehene Volume hat eine Gesamtgröße von 832 GB. 51,8 GB der Gesamtkapazität sind mit Image-Files bzw. VHDs belegt. Die Daten sind nicht komprimiert.

image

In diesem Zusammenhang muss beachtet werden, dass die Deduplizierungsfunktion momentan nur von NTFS und nicht vom ebenfalls neu eingeführten Resilient File System (ReFS) unterstützt wird. Zudem kann diese Funktion nicht bei System- bzw. Boot-Volumes angewendet werden.

image

Neben der eigentlichen Aktivierung der Deduplizierung für das entsprechende Volume, kann man weitere Optionen festlegen (Mindestalter der zu deduplizierenden Dateien, von der Optimierung auszuschließende Dateierweiterungen und Ordner). Anschließend hat man die Möglichkeit über „Set Deduplication Schedule“ die Deduplizierung des ausgewählten Volumes zu planen.

image

Dabei kann man festlegen, die Deduplizierung im Hintergrund (mit niedriger Priorität, zu Niedriglastzeiten) oder zu festgelegten Zeiten (mit normaler Priorisierung und Ressourcenkonsum) durchlaufen zu lassen. Es besteht ebenfalls die Möglichkeit, die Planung übergreifend für alle Volumes eines Servers festzulegen.

image

Dazu navigiert man in die Serverübersicht und wählt dort „Deduplication Schedule“ aus. Die oben beschriebenen Einstellungen für die einzelnen Volumes kann man auch global für den kompletten Server setzen, so dass nicht jedes Volume separat konfiguriert werden muss.

Wie bei allen Rollendiensten kann man auch hier PowerShell zur Administration und Einrichtung der Deduplizierungsfunktion nutzen und somit das Handling vereinfachen.

Hier die wichtigsten Befehle im Überblick:

  • Aufzählung aller verfügbaren Dedup cmdlets:

help Dedup

  • Aktivierung der Deduplizierung für ein Volume:

Enable-DedupVolume <vol: Or Mount path>

  • Festlegen des Mindestalters der Dateien (hier: 0 = sofortige Optimierung):

Set-DedupVolume <vol: Or Mount path> -MinimumFileAgeDays 0

  • Sofortiges Starten der Deduplizierung:

Start-DedupJob <vol: Or Mount path> –Type Optimization

  • Statusansicht aktueller Optimierungs-Jobs:

Get-DedupStatus

  • Rückführen der bereits optimierten Daten in den Ursprungszustand:

Start-DedupJob -Volume <vol: Or Mount path> -Type Unoptimization

Soweit so gut, aber wie sieht nun das Resultat der Deduplizierung für das gewählte Volume aus?

image

Das Ergebnis ist bemerkenswert. Bei einer erreichten Deduplikationsrate von 84% ergibt sich eine effektive Einsparung von 27,7 GB auf dem Volume. Durch die Art der verwendeten Daten war zwar ein guter Komprimierungsgrad absehbar, das erzielte Ergebnis übertraf die Erwartungen jedoch deutlich. Zusammenfassend kann man feststellen, dass die Konfiguration der Windows Server Deduplizierung sehr einfach gehalten ist und zu massiven Speicherplatzeinsparungen bei NTFS-Volumes führen kann.

Kontakte nicht auswählbar mit Lync

In vielen Exchange Organisationen werden besonders oft benötigte externe Ansprechpartner als Kontakte angelegt. Das kann so weit gehen, dass Firmen die viel zusammen arbeiten Ihr ganzes Adressbuch miteinander synchronisieren. Damit sind diese Ansprechpartner direkt aus dem Adressbuch auswählbar. Wenn jetzt beide Firmen eine Lync Server 2010 Infrastruktur betreiben, werden sie sich vielleicht wundern, dass sie diese Kontakte mit dem Lync Client zwar anrufen können, ein Verbindungsaufbau per Lync Client z. B. per Chat ist aber nicht möglich. Die entsprechenden Felder sind nicht aktiviert, also “ausgegraut”:

image

Dagegen sollte ein Benutzer, den sie mit Lync erreichen können so aussehen:

image

 

Lösung:

Diese Kontakte haben keine SIP-Adresse hinterlegt. Es reicht nicht eine Emailadresse zu definieren. Die SIP-Adresse wird im Active Directory (AD) über das Attribut “msRTCSIP-PrimaryUserAddress” festgelegt. Die SIP-Adresse ist in vielen Fällen gleich der Emailadresse, muss es aber nicht. Vergeben Sie dieses Attribut also für die entsprechenden Benutzer entweder:

  • über die AD-MMC auf der Registerkarte “Attribute Editor” (Hinweis: Advanced Features muss unter Ansicht aktiviert sein) in der Form “sip:SIP-Adresse”

image

  • oder mit der Powerhell. Die Power Shell macht sich natürlich leichter, falls sie viele Kontakte ändern müssen. Tipp: Sollte die Emailadresse und die SIP-Adresse identisch sein, lesen sie die Emailadresse aus und übergeben diesen Wert mit Hilfe eines Scripts.
  • Nutzen Sie einen sog. Verzeichnisabgleich für die Erstellung der Kontakte (z. B. Galsync) nehmen sie das Attribut “msRTCSIP-PrimaryUserAddress” in die Synchronisation mit auf.
Möglichkeiten des Verbundes von Exchange Organisationen (Exchange 2010)

Dieser Artikel soll die Möglichkeiten des Verbundes von Exchange Organisationen beschreiben. Mit dem Verbund von Exchange Organisationen werden meistens zwei Aufgaben zusammengefasst:

  1. Aufrufen des externen Kontaktes direkt aus dem Globalen Adressbuch und
  2. Einsehen der Frei- und Gebucht Zeiten

Aufrufen des externen Kontaktes aus dem Globalen Adressbuch

Voraussetzung dafür ist, dass sich dieser Kontakt in Ihrem Globalen Adressbuch befindet. Nur damit ist es möglich Benutzer anderer Exchange Organisationen aus dem Globalen Adressbuch (GAL) aufzurufen. Dafür bieten sich Mailkontakte oder Mail Benutzer an. Der Unterschied ist, dass Kontakte sich nicht lokal an Ihrem Active Directory (AD) anmelden können, Mail Benutzer aber schon.

TIPP: Haben Sie später mal vor die Exchange Organisationen zusammenzuführen, nehmen Sie gleich Mail Benutzer. Ein Kontakt lässt sich nicht in einem Mailbox Benutzer umwandeln und müsste gelöscht werden und dann als neuer Benutzer angelegt werden. Stattdessen lässt sich ein Mail Benutzer leicht in einen Mailbox Benutzer umwandeln.

Wie kommen diese Objekte jetzt ins AD? Mehrere Wege sind möglich: Unterscheidungen bei den aufgeführten Lösungen gibt es in der Funktion und natürlich beim Aufwand und den Kosten. So kommen mehrere Ansätze in Betracht, die ich hier kurz beschreiben möchte und dabei auf Vor- und Nachteile hinweise (diese Aufstellung erhebt nicht den Anspruch auf Vollständigkeit):

 

  • Sind es nur wenige Objekte legen Sie diese per Hand an. Wichtig: Das AD Attribut “targetAddress” muss mit der externen Emailadresse gefüllt werden, also z. B. smtp:Kontakt@firma.de.

image

Vorteil: keine Kosten für Software, kein Trust zwischen den Exchange Organisationen erforderlich

Nachteil: macht nur Sinn bei einigen wenigen Objekten, ansonsten hoher Arbeitsaufwand

  • Power Shell. Haben Sie Programmiererfahrung? Dann haben Sie vielleicht schon alle Werkzeuge in der Hand die Sie benötigen. Seit Windows 2008 R2 und mit der Powershell ist es möglich eigene Scripte zu entwickeln oder verfügbare Scripte zu verwenden. Ein richtiger Verzeichnisabgleich ist aber keine triviale Angelegenheit. Zu berücksichtigen sind Änderungen an Objekten, Löschungen, Konfliktbehandlung, etc.

Vorteil: keine Kosten für Software

Nachteil: Programmierkenntnisse erforderlich, kein Support, hoher Einarbeitungsaufwand, Trust zwischen den Exchange Organisationen ist hilfreich und vereinfacht die Umsetzung

  • Active Directory Migration Toolkit (ADMT). Das ist das Universalwerkzeug von Microsoft, eigentlich gedacht zur Umstrukturierung von Domänen.

Vorteil: keine Kosten für Software

Nachteil: Hoher Einarbeitungsaufwand, zusätzliche Hardware erforderlich, SQL Datenbank erforderlich, Trust zwischen den Exchange Organisationen erforderlich.

Vorteil: keine Kosten für Software, relativ einfache Konfiguration, kein Trust zwischen den Exchange Organisationen erforderlich

Nachteil: zusätzliche Maschine erforderlich, SQL Datenbank erforderlich

  • Galsync, ein kostenpflichtiges Tool der Firma Netsec (www.netsec.de). Die Art des Austauschs der zu synchronisierenden Daten kann dabei ausgewählt werden. Möglich ist der Abgleich per Mail, FTP, Fileshare oder manuell über den Import einer Datei. Die Einrichtung ist schnell erledigt.

Vorteil: sehr einfache Konfiguration, kein Trust zwischen den Exchange Organisationen erforderlich, keine zusätzliche Hardware erforderlich, Support erhältlich

Nachteil: Kostenpflichtig

  • Microsoft Forefront Identity Manager (FIM). Für diesen Zweck eher unterfordert, aber eigentlich das von Microsoft vorgesehene Produkt für diese Aufgabe.

Vorteil: Support erhältlich

Nachteil: Kostenpflichtig, zusätzliche Hardware erforderlich, hoher Einarbeitungsaufwand

Schon an dieser Stelle müssen Sie sich also entscheiden, wollen Sie den schnellen Erfolg oder verfügen Sie über genug Zeit zur Einarbeitung und Durchführung. Denken sie daran, dass auch Ihre Arbeitszeit Geld kostet.

 

Einsehen der Frei- und Gebucht Zeiten

Gerade die Bereitstellung von Frei- und Gebucht Zeiten ist für viele Firmen ein Thema, sei es beispielsweise bei Firmenzusammenschlüssen oder bei Kooperationen. Darunter zu verstehen ist z. B. die Möglichkeit bei Besprechungsanfragen gleich einzusehen, ob der Besprechungspartner zu einem geplanten Termin überhaupt verfügbar ist.

Das Vorhandensein der Kontakte im eigenen AD ist bei den folgenden Lösungen Voraussetzung für das Einsehen der Frei- und Gebucht Informationen. Es ist weiterhin eine Vereinfachung für den Benutzer, denn er kann direkt aus dem Adressbuch den Kontakt (z. B. in Outlook oder Outlook Web App) auswählen.

Auch hier möchte ich Ihnen einige Möglichkeiten vorstellen und Vor- bzw. Nachteile auflisten:

Konfigurieren des Verfügbarkeitsdienstes für Cross-Forest Topologien

In Exchange 2010 kann man den Verfügbarkeitsdienst so konfigurieren, dass eine andere Exchange Organisation über die Exchange Web Services (EWS) Zugriff auf die Frei- und Gebucht Informationen erhält. Nähere Informationen zur Konfiguration erhalten Sie im Technet http://technet.microsoft.com/de-de/library/bb125182.aspx. Dabei wird zwischen vertrauenswürdigen und nicht vertrauenswürdigen Gesamtstrukturen unterschieden.

  • Nicht vertrauenswürdige Gesamtstrukturen. Hier kann der Verfügbarkeitsdienst nur so konfiguriert werden, dass alle Benutzer der anderen Exchange Organisation Zugriff auf die Frei- und Gebucht Informationen erhalten. Sie können keinen Benutzer der externen Organisation einschränken, so wie Sie es mit Benutzern Ihrer internen Organisation tun können und es werden immer nur die Frei- und gebucht Zeiten ohne Details angezeigt:

image

Der Verfügbarkeitsdienst kann nur über die Exchange Power Shell konfiguriert werden. Diese Schritte müssen in beiden Exchange Organisationen ausgeführt werden. Erstellen Sie weiterhin dazu einen Service Account. Folgende Befehle sind für die Konfiguration des Verfügbarkeitsdienstes notwendig:

Set-AvailabilityConfig -OrgWideAccount "Contoso.com\Service-Account"

$a = get-credential  (Eingabe der Credentials des erstellten Service-Accounts in der Form contoso.com\Service-Account)

Add-AvailabilityAddressspace -Forestname Contoso.com -Accessmethod OrgWideFB -Credential:$a

  • Vertrauenswürdige Gesamtstrukturen. Hier können Sie den Verfügbarkeitsdienst auf Benutzerbasis konfigurieren. Damit ist es möglich detaillierte Informationen über die Frei- und Gebucht Informationen zu erhalten. Für diese Konstellation ist aber ein sog. Forest Trust notwendig. Es wäre möglich, dass diese erweiterten Rechte nicht gewünscht sind.

Galsync

Dieses bereits erwähnte (kostenpflichtige) Tool bietet auch die Möglichkeit des Abgleich der Frei- und Gebucht Zeiten. Die Besonderheit ist hier, dass dazu Öffentliche Ordner herangezogen werden und nicht die EWS benutzt werden, deshalb kann es auch ohne weitere Voraussetzungen in Exchange Organisationen benutzt werden, die noch ältere Versionen als Exchange 2010 einsetzen. Das bedeutet aber, dass eine Öffentliche Ordner Datenbank vorhanden sein muss. Zu erwähnen bleibt, dass bei dieser Lösung keine detaillierten Informationen der Frei- und Gebucht Zeiten zur Verfügung stehen, da diese Informationen in der Öffentliche Ordner Datenbank nicht vorhanden sind.

 

Exchange Federation

Eine gewisse Sonderstellung stellt eine Exchange Federation dar. Sie ist unabhängig von dem Abgleich der GAL und benötigt keinen Trust zwischen den Organisationen. Nur wenn Sie die Empfänger direkt aus dem Adressbuch auswählen wollen, benötigen Sie weiterhin die Synchronisierung der GAL. Ansonsten geben Sie einfach die Emailadresse z.B. bei einer Besprechungsanfrage ein. Auch ist es hier möglich den Detailgrad der Frei- und Gebucht Zeiten zu konfigurieren.

image

Zuerst wird über einen speziellen (kostenfreien) Dienst von Microsoft, dem sog. Microsoft Federation Gateway (MFG) eine Federation aufgebaut. Dabei fungiert das MFG wie ein Vermittler und erhält ein Token. In der anderen Exchange Organisation muss ebenfalls diese Federation zum MFG aufgebaut werden. Mit diesem Token geht Exchange dann zu dem Exchange Server der anderen Organisation. Da die andere Exchange Organisation dem Token vertraut, da es ja dem MFG vertraut, kann der Token zur Authentifizierung genutzt werden. Es müssen einige Vorbedingungen erfüllt sein, damit die Einrichtung gelingt: z. B. muss Autodiscover und EWS korrekt konfiguriert sein und es muss die Domain-Eigentümerschaft der eigenen Emaildomain dem MFG bestätigt worden sein (z. B. über TXT Einträge im öffentlichen DNS). Die gesamte Kommunikation ist mit SSL verschlüsselt. Zur eigentlichen Konfiguration können Sie den “New Federation Trust Wizard” benutzen. Näheres im Technet unter http://technet.microsoft.com/de-DE/library/dd335047.aspx.

Sobald die Federation mit dem MFG aufgebaut ist, sind sie in der Lage mit jeder anderen Organisation die ebenfalls eine Federation mit dem MFG betreibt, Frei- und Gebucht Zeiten einzusehen bzw. Kalenderabfragen durchzuführen.

Exchange Federation können auch in Exchange Organisationen aufgebaut werden, in denen es Exchange Versionen vor Exchange 2010 gibt. Voraussetzung ist allerdings das Vorhandensein eines Exchange 2010 Client Access Servers (CAS) in der Exchange Organisation, der dann die EWS bereitstellt.

 

Sollte Sie weitere Nachfragen zu diesem Thema haben oder falls Sie Hilfe bei der Implementierung benötigen, können Sie sich gerne an uns wenden!

VMware ESXi speichert die Konfiguration nicht

Bei meiner letzten ESXi 5.0 Installation hatte ich folgendes Problem:

Nach jedem Reboot verlor der Host seine Netzwerkeinstellungen. Damit ist der Host schlimmstenfalls über Netzwerk gar nicht mehr erreichbar. Vielleicht hätte eine feste DHCP Reservierung geholfen, aber oft kommt eine Reservierung gar nicht in Frage.

Lösung:

Alle Einstellungen werden in der sog. Bootbank-Partition gespeichert. Einmal in der Stunde läuft ein Cron-Job der die aktuelle Konfiguration abspeichert. Anscheinend lief dieser Job noch nicht oder versagte. Warum diesen Job also nicht per Hand starten? Dafür an der Konsole oder per SSH folgenden Befehl ausführen:

/sbin/auto-backup.sh

Danach startete der ESXi mit den gespeicherten Konfigurationseinstellungen.

1 - 10 Weiter

 ‭(Ausgeblendet)‬ Administratorhyperlinks

Neues aus unseren Blogs
Deploymenttechnologien: Beiträge
Reinstall der Rolle Windows Server Update Services
[16.12.2013]
Holger Schweitzberger
Windows Server 2008
Deploymenttechnologien: Beiträge
Reports in ConfigMgr 2012
[06.12.2013]
Holger Schweitzberger
Configuration Manager 2012
Deploymenttechnologien: Beiträge
Patchen eines Windows 7 Offline Images
[13.11.2013]
Holger Schweitzberger
SCCM 2007
Database Availability Group (DAG) in Exchange 2013
[02.10.2012]
Michael Sahr
Exchange 2013
Bereitstellen von Office Web Apps in SharePoint 2013 (Preview)
[28.08.2012]
René Dalkowski
SharePoint
Exchange Transportregeln und Änderungen in Exchange 2013
[12.08.2012]
Michael Sahr
Exchange 2013
Öffentliche Ordner unter Exchange Server 2013
[08.08.2012]
Malte Pabst
Exchange 2013
Outlook Web App (OWA)– Offline Verfügbarkeit
[07.08.2012]
Malte Pabst
Exchange 2013
Erste Schritte mit Exchange 2013 (Installation)
[30.07.2012]
Malte Pabst
Exchange 2013