Cross-Site Silent Redirection in Exchange 2010 SP2

Mit dem SP2 für Exchange 2010 wurde das Cross-Site Silent Redirection verbessert. Nunmehr geschieht das Redirection auf das Postfach automatisch und bedarf keinen manuellen klick auf die Redirection URL.


Weitere Informationen:
Exchange Team Blog

Hochverfügbarkeit - TOP 10 Irrtümer

Es gibt leider noch sehr viel Missverständnisse zum Thema Hochverfügbarkeit. Aus diesem Anlass hier die TOP 10 Irrtümer:

 

1. Hochverfügbarkeit ist nicht 99,5 Prozent

7 x 24-Stunden-Dauerbetrieb erlaubt bei einer Verfügbarkeit von 99,5 Prozent eine durchschnittliche Ausfallzeit von über 43 Stunden pro Jahr. Für unternehmenskritische Aufgaben ist dies zu wenig. Hier muss ein Verfügbarkeitsniveau von mindestens 99,99 Prozent – mit einer durchschnittlichen Ausfallzeit von etwa 52 Minuten pro Jahr - erreicht werden.

2. Hochverfügbarkeit ist nicht Disaster Recovery

Disaster Recovery ist Katastrophenschutz für die IT: Unternehmen schützen damit ihre Systeme vor Bränden, Erdbeben, Flugzeugabstürzen oder Anschlägen, beispielsweise indem sie Rechenzentren räumlich getrennt platzieren. Hochverfügbarkeit sorgt dagegen für den Schutz der IT bei Betriebsstörungen; beide Aspekte sind in einem Sicherheitskonzept berücksichtigen.

3. Hochverfügbarkeit ist nicht Stand-By

Bei redundanten Systemen sind durch Umschalten und Übergabe der Prozesse Ausfallzeiten technisch unvermeidlich. Die Konsistenz von Daten und Transaktionen muss daher separat sichergestellt werden. Auch wenn es dafür Softwarelösungen gibt, ist auf diese Weise eine Verfügbarkeit von höchstens 99,5 bis 99,9 Prozent erreichbar, was einer max. ungeplanten Downtime von 8,7 bis 43 Stunden pro Jahr entspricht.

 

4. Hochverfügbarkeit ist nicht RAID

Mit RAID-Systemen werden Datenspeicher vor Ausfällen geschützt. Hochverfügbarkeit sorgt dagegen für einen ausfallsicheren Betrieb der Server. In kritischen Umgebungen muss daher immer beides implementiert sein.

5. Hochverfügbarkeit ist nicht Backup

Backup-Lösungen sichern wichtige Unternehmensdaten vor Verlusten, sind für einen professionellen IT-Betrieb unverzichtbar und müssen für alle, nicht nur für hoch verfügbare Systeme erstellt werden.

6. Hochverfügbarkeit ist nicht USV

Keine USV kann Server-Abstürze verhindern oder abfangen. Für Hochverfügbarkeit ist der Betrieb einer USV daher zwar eine Voraussetzung, aber keineswegs ausreichend.

7. Hochverfügbarkeit ist nicht ein zweites Netzteil

Netzteile sind störungsanfällig, deshalb verbessert ein zweites Netzteil die Verfügbarkeit eines Servers. Doch damit lassen sich nicht andere Hardware-Fehler, etwa in der CPU oder im RAM, abfangen. In fehlertoleranten Servern sind alle wichtigen Komponenten, auch CPU und RAM, doppelt vorhanden. Auf diese Weise lässt sich Hochverfügbarkeit realisieren.  

8. Hochverfügbarkeit ist nicht Virtualisierung

Die Verfügbarkeit wird durch die Virtualisierung von Servern sogar verschlechtert, weil hier ein einziger defekter physischer Server eine ganze virtuelle Server-Gruppe lahm legt. Für jedes System müssen dann mehr oder weniger aufwändige Maßnahmen zur Wiederherstellung des Betriebs vorgenommen werden. Auch wenn diese Maßnahmen mit Software-Unterstützung automatisch ablaufen, so muss dafür stets eine gewisse Zeitspanne einkalkuliert werden. Daher müssen gerade virtuelle Server mit unternehmenskritischen Applikationen auf einer hoch verfügbaren Hardware-Plattform betrieben werden, beispielsweise fehlertoleranten Systemen.

9. Hochverfügbarkeit ist nicht teuer

Natürlich kostet eine IT-Lösung mehr, wenn sie hoch verfügbar ist - schließlich muss Hochverfügbarkeit durch einen zusätzlichen technischen Aufwand hergestellt werden. Diese Kosten müssen jedoch im Verhältnis zum möglicherweise entstehenden Schaden gesehen werden. Eine einzige Stunde Server-Ausfall kann heute mehr kosten als eine komplette Hochverfügbarkeitslösung. Mittlerweile ist Hochverfügbarkeit aber auch für kleinere und mittlere Unternehmen erschwinglich. Fehlertolerante Server kosten unterm Strich sogar weniger als Cluster-Lösungen, weil sie keine zusätzlichen Kosten für Software-Anpassung, zusätzliche Lizenzen oder eine aufwändige Administration verursachen. Lösungen wie Stratus Avance können handelsübliche x86-Server per Software zu einer hoch verfügbaren Plattform verbinden.

10. Hochverfügbarkeit ist nicht Continuous Availability

Für einige Anwendungen ist selbst echte Hochverfügbarkeit nicht mehr ausreichend, beispielsweise in der Kraftwerkssteuerung, für Notfallsysteme in Krankenhäusern oder in der Produktionssteuerung. Hier muss eine Verfügbarkeit von 99,999 oder sogar bis zu 99,9999 Prozent ("Six Nine") erreicht werden, was eine durchschnittliche Ausfallzeit von etwa 5 Minuten beziehungsweise einer halben Minute pro Jahr gewährleistet. Diese Werte sind auch von Cluster-Systemen nicht erreichbar; Anwender kommen hier nicht an fehlertoleranten Systemen vorbei.

Echte Hochverfügbarkeit ist erst ab einem Verfügbarkeitsniveau von mindestens 99,99 Prozent gegeben. Hier beträgt die durchschnittliche Ausfallzeit höchstens 52 Minuten pro Jahr. Fehlertolerante Server, die komplett redundant aufgebaut sind, erreichen auf Basis von Standard-Technologien eine Verfügbarkeit von mehr als 99,999 Prozent. Da sie dem Anwender als "Black-Box" gegenübertreten, lassen sie sich außerdem wesentlich leichter implementieren und administrieren als leistungsmäßig vergleichbare Cluster-Systeme.

"Der Begriff Hochverfügbarkeit wurde in den letzten Jahren aufgeweicht, weil viele Anbieter Hochverfügbarkeit einfach entsprechend der Möglichkeiten ihrer eigenen Systeme definieren", erklärt Timo Brüggemann, Director Business Development EMEA bei Stratus in Eschborn. "Viele Unternehmen glauben daher fälschlicherweise, dass sie hoch verfügbare Server einsetzen, während sie tatsächlich bei Störungen mit nicht unerheblichen Ausfallzeiten rechnen müssen. Im Ernstfall kann sich das als sehr teurer Irrtum erweisen.

Weitere Links:
http://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit

Exchange 2007/ 2010 und Autodiscover

Exchange Autodiscover (AutoErmittlungsdienst)

Autodiscover ist ein Service, der die Konfiguration von Outlook 2007/ 2010 Clients sowie Mobiltelefonen mit Windows Mobile 6.1 oder Höher enorm vereinfacht. Anhand der E-Mail-Adresse und des Kennworts eines Benutzers wird das Outlook Benutzerprofil automatisch eingerichtet.

Folgende Informationen werden bereitgestellt:

• Den Anzeigenamen des Benutzers
  
• Gesonderte Verbindungseinstellungen für interne und externe Verbindungen
  
• Den Speicherort des Postfachservers des Benutzers
  
• Die URLs für verschiedene Outlook-Funktionen, die Funktionen wie Frei/Gebucht-Informationen, Unified Messaging und das Offlineadressbuch regeln.
  
• Servereinstellungen von Outlook Anywhere

  

Prozess /Intern:

1. Client sucht das Active Directory-Objekt Service Connection Point (SCP) um die  Konfiguration zu erhalten. 

2. Autodiscover Service liefert URL Exchange Funktionen zurück:

https://<SMTP-Domäne>/autodiscover/autodiscover.xml

https://autodiscover.<SMTP-Domäne>/autodiscover/autodiscover.xml

3.Client baut HTTPS Verbindung zu ClientAccess Server auf.

4. Exchange Services werden bereitgestellt.

Prozess /Extern:

 

1. Client versucht sich mit dem Active Directory-Objekt Service Connection Point (SCP) zu verbinden. Vorgang fehlgeschlagen!

2. Client versucht sich mit der Autodiscover URL zu verbinden:

https://<SMTP-Domäne>/autodiscover/autodiscover.xml

https://autodiscover.<SMTP-Domäne>/autodiscover/autodiscover.xml

 Vorgang erfolgreich!

3.Client baut HTTPS Verbindung zu ClientAccess Server auf.

4. Exchange Services werden bereitgestellt.


Fortsetzung folgt in Kürze...

 

Exchange Server 2010 SP2 - Verfügbar auch für Hosting

• Download
  http://go.microsoft.com/fwlink/?LinkID=232843
• Neuigkeiten
  http://go.microsoft.com/fwlink/?LinkID=228135
• Release Notes
  http://go.microsoft.com/fwlink/?LinkId=235234
• Voraussetzungen
  http://go.microsoft.com/fwlink/?LinkID=194324

Hosting:

http://blogs.technet.com/b/exchange/archive/2011/12/06/exchange-2010-service-pack-2-and-hosting.aspx

Rollup 6 für Exchange Server 2010 SP1

Eine neue Runde vom Exchange Server Rollup steht zum Download bereit.

TU Inhalte:

• 2627769  Some time zones in OWA are not synchronized with Windows in an Exchange Server 2010 environment
• 2528854  The Microsoft Exchange Mailbox Replication service crashes on a computer that has Exchange Server 2010 SP1 installed
• 2544246 You receive a NRN of a meeting request 120 days later after the recipient accepted the request in an Exchange Server 2010 SP1 environment
• 2616127  "0x80041606" error code when you use Outlook in online mode to search for a keyword against a mailbox in an Exchange Server 2010 environment.
• 2549183  "There are no objects to select" message when you try to use the EMC to specify a server to connect to in an Exchange Server 2010 SP1 environment

• For general DST related information please see: http://www.microsoft.com/time

Rollup 5 für Exchange Server 2010 SP1

Inhalte des Rollup 5:

• 2275156 (http://support.microsoft.com/kb/2275156/ ) The inline contents disposition is removed when you send a "Content-Disposition: inline" email message by using EWS in an Exchange Server 2010 environment
• 2499044 (http://support.microsoft.com/kb/2499044/ ) You cannot save attachments in an email message by using OWA if the subject line contains special characters in an Exchange Server 2010 environment
• 2509306 (http://support.microsoft.com/kb/2509306/ ) Journal reports are expired or lost when the Microsoft Exchange Transport service is restarted in an Exchange Server 2010 environment
• 2514766 (http://support.microsoft.com/kb/2514766/ ) A RBAC role assignee can unexpectedly run the Add-ADPermission command on an Exchange Server 2010 server that is outside the role assignment scope
• 2529715 (http://support.microsoft.com/kb/2529715/ ) Slow network or replication issues after you change the number of virus scanning API threads in Microsoft Exchange Server 2010
• 2536704 (http://support.microsoft.com/kb/2536704/ ) Mailbox users who are migrated by using ILM 2007 cannot use the Options menu in OWA in an Exchange Server 2010 environment
• 2537094 (http://support.microsoft.com/kb/2537094/ ) French translation errors occur when you edit a response to a meeting request by using OWA in an Exchange Server 2010 SP1 environment
• 2555800 (http://support.microsoft.com/kb/2555800/ ) You cannot use the GetItem operation in EWS to retrieve properties of an email message in an Exchange Server 2010 environment
• 2555850 (http://support.microsoft.com/kb/2555850/ ) You cannot delete a mailbox folder that starts with a special character in its name by using Outlook in an Exchange Server 2010 environment
• 2556096 (http://support.microsoft.com/kb/2556096/ ) The columns in the .csv logging file are not lined up correctly when you perform a discovery search on a mailbox in an Exchange Server 2010 environment
• 2556107 (http://support.microsoft.com/kb/2556107/ ) The columns in the .csv logging file are not lined up correctly when you perform a discovery search on a mailbox in an Exchange Server 2010 environment
• 2556133 (http://support.microsoft.com/kb/2556133/ ) A device that uses Exchange ActiveSync cannot access mailboxes in an Exchange Server 2010 environment
• 2556156 (http://support.microsoft.com/kb/2556156/ ) Extra.exe crashes when it performs RPC activity checks against an Exchange Server 2010 server
• 2556352 (http://support.microsoft.com/kb/2556352/ ) "ChangeKey is required for this operation" error message in Outlook for Mac 2011 in an Exchange Server 2010 environment
• 2556407 (http://support.microsoft.com/kb/2556407/ ) Certain client-only message rules do not take effect on email messages that are saved as drafts in an Exchange Server 2010 environment
• 2559926 (http://support.microsoft.com/kb/2559926/ ) "There are no items to show in this view." error message when you try to view a folder by using Outlook in an Exchange Server 2010 environment
• 2572958 (http://support.microsoft.com/kb/2572958/ ) The "Test-OutlookConnectivity -Protocol HTTP" command fails with an HTTP 401 error in an Exchange Server 2010 environment

Hochverfügbarkeit Exchange 2010

Was ist sind Database Availability Groups?

Die Hochverfügbarkeit in der Vorgängerversion Exchange 2007 Mittels CCR, SCC, SCR und LCR gehört nunmehr der Vergangenheit an. Durch die Database Availability Groups abgekürzt auch DAG genannt, erfolgt der Failover nun pro Datenbank und nicht mehr pro Server. Diese DAG Funktion im Exchange 2010, wird auch als inkrementelle Bereitstellung bezeichnet. Hierbei handelt es sich um die Fähigkeit, die Dienst- und Datenverfügbarkeit für alle Postfachserver und Datenbanken bereitzustellen.

How-To DAG:

1. Anforderungen
2. Netzwerk
3. Einrichtung
4. Proof of Conecpt

Funktionsweise:

Jeder Server in einer Datenbankverfügbarkeitsgruppe kann als Host für eine Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der Datenbankverfügbarkeitsgruppe fungieren. Wenn einer Datenbankverfügbarkeitsgruppe ein Server hinzugefügt wird, wird dieser mit den anderen Servern in der DAG eingesetzt, um eine automatische Wiederherstellung nach Fehlern zu bieten, die Postfachdatenbanken betreffen, z. B. Datenträger- oder Serverfehler.

DAG Alle Server Online:

DAG mit einem Server der zur Wartung offline geschaltet wurde und einem ausgefallenen Server: 

1. Anforderungen

Allgemeine Anforderungen:

- DNS (Domain Name System) muss laufen.
- Jeder Postfachserver in einer Database Availability Groups muss ein Mitgliedsserver in erselben Domäne sein.
- DAG Mitglied und gleichzeitig File Server ist nicht unterstützt.
- Der DAG Name muss ein gültiger, verfügbarer und eindeutiger Computername mit maximal 15 Zeichen sein.


Hardwareanforderungen:

- Grundsätzlich gibt es keine besonderen Hardwareanforderungen an das DAG. Die Anforderungen müssen gemäß Exchange 2010 Hard- und Softwarevoraussetzung erfüllt werden.

Softwareanforderungen:
- Das DAG ist in Exchange 2010 sowohl in der Standard als auch in der Enterprise Edition verfügbar.

Netzwerkanforderungen:
- Jedes DAG Mitglied muss min. einen Netzwerkadapter besitzen, der mit Allen anderen DAG Mitgliedern darüber kommunizieren (Protokollversand /Seeding) kann.



2. Netzwerk Konfiguration

Netzwerkverbindungen:
Wie in jeder Hochverfügbarkeit Strategie, ist ein Single Point of Failure tunlichst zu vermeiden. Deshalb sind zwei Netzwerkarten für physikalische/ logische Separation zwischen LAN (MAPI-Netzwerk) und DAG (Replikationsnetzwerk) mit deren Operationen zwingend erforderlich.

Adapter/ Bindungen:

Auch hier ist DNS ein sehr wichtiger Bestandteil . Damit die Server sich untereinander via die DNS auflösen können, so ist im den Ersten Schritt auf eine saubere DNS-Konfig zu sorgen. Damit die DNS-Anfragen schnellstmöglich abgearbeitet werden, ist neben der Allgemeinen Konfiguration des Netzwerkadapters s.h. unten auch die Verbindungsreihenfolge wichtig. Hierzu wird die entsprechende Verbindung nach oben gesetzt, die auch im gleichen Subnetz mit dem o.g. DNS Server steht. In diesem Fall “LAN“ Verbindung.

Netzwerk Konfiguration – LAN/ DNS:

Netzwerk Konfiguration – DAG:

Damit es nicht zu Konflikten oder gar zu Beeinträchtigungen kommt, sollte das DAG Netzwerksegment stets ein eigenständiges sein. Dieses Segment wird für die Kommunikation der Server untereinander sowie für das Failover-Handling genutzt.

3. Einrichtung

Hinweis: Sofern kein Data Center Betrieb angedacht (max. 16 Server) ist, reicht ein Zeugenserver (WitnessServer) völlig aus. Der Zeugenserver muss min. ein Windows Server 2003 SP2 oder höher sein und darf auf keinen DAG Mitglied-Server laufen. Empfehlung, legt das FSW auf einen der CAS/HUB oder DC's. Das ist leider noch nicht Alles. Des Weiteren muss die Gruppe “Exchange Trusted Subsystem“ auf dem Zeugenserver Mitglied der Lokalen Administratoren sein. In einigen Projekten habe ich gesehen, dass diese Berechtigung durch das DAG automatisch gesetzt wurde. Verlassen sollte man sich hierauf aber nicht und sollte der Sache stets nachgehen.

New-DatabaseAvailabilityGroup -Name DAG-1 -WitnessServer DC01 -WitnessDirectory C:filesharewitness - AlternateWitnessDirectory C:filesharewitness -AlternateWitnessServer DC02

Verwaltung - DAG:

 


Get-DatabaseAvailabilityGroup | fl

Name : DAG-1
Servers : {SRVEX01}
FileShareWitnessShare : \DC01FileShareWitness
FileShareWitnessDirectory : C:filesharewitness
AlternateFileShareWitnessShare :
AlternateFileShareWitnessDirectory :
NetworkCompression : InterSubnetOnly
NetworkEncryption : InterSubnetOnly
DatacenterActivationMode : Off
StoppedMailboxServers : {}
StartedMailboxServers : {}
OperationalServers :
ControllingActiveManager :
ReplicationPort : 0
NetworkNames : {}
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
Identity : DAG-1
WhenChanged : 29/03/2011 7:22:42
WhenCreated : 29/03/2011 7:22:42
OrganizationId :
OriginatingServer : srvex01.exchangetayfun.com
IsValid : True


Verwaltung - DAG IP-Adresse:

Hinweis: Sofern das DAG über EMC erstellt wird, so steht die Cluster-IP auf per Default auf DHCP. Meine Empfehlung ist, die Cluster-IP bei der DAG Erstellung direkt auf Statisch zu setzen. Dies kann nur aus der Shell mit folgendem Befehl erfolgen:
New-DatabaseAvailabilityGroup -Name DAG-1 -WitnessServer DC01 -WitnessDirectory C:DAGWitnessDAG-1.exchangetayfun.com -DatabaseAvailabilityGroupIPAddresses 10.10.1.102

Nachträglich mit: 

Set-DatabaseAvailabilityGroup -Identity DAG-1 - DatabaseAvailabilityGroupIpAddresses 10.10.1.102

Für GUI Freunde - DAG Statische IP-Adresse Nachträglich:

Mitgliedschaft - DAG:

Im dem folgenden Schritt werden die Server als mit Mitglied in das DAG hinzugefügt.

Add-DatabaseAvailbilityGroupServer -Identity DAG-1 -MailboxServer SRVEX01
Add-DatabaseAvailbilityGroupServer -Identity DAG-1 -MailboxServer SRVEX02

  

Verwaltung – Erstellen Neue Postfachdatenbankkopie:

Nach der erfolgeichen DAG-Mitgliedschaft, kann nun die s.g. Posfachdatenbankankkopie erstellt werden. Hinweis: Die Datenbankkopie wird auf dem DAG-Partner im gleichem Pfad abgelegt wie auf dem Quellserver. Vorab darüber sich Gedanken zu machen, kann einges an Stress und Zeit sparen

Add-MailboxDatabaseCopy -Identity 'DB01' -MailboxServer 'SRVEX01'

Verwaltung – Auswahl Postfachdatenbankkopie Partner:

4. Proof of Concept - DAG:

Nun kann die Verfügbarkeit Next Generation DAG mit Fehler-Simulationen auf Herz und Nieren geprüft werden.
- Get-MailboxDatabaseCopyStatus
- Test-ReplicationHealth
- Move-ActiveMailboxDatabase
- Simulation Systemausfall
o Dismount Postfachfatenbank,
o Mailbox-Knoten Herunterfahren
o Netzwerkarte deaktivieren ...

Fazit:

Durch geschickten Einsatz von DAG kann Hardware- sowie Backupkosten gesenkt werden.