OWA ohne https und /owa aufrufen mit TMG

Ein bekanntes Problem ist, dass beim Aufruf von OWA vom User am Anfang der Adresse jeweils ein https:// und am Ende ein /owa getippt werden muss. Dies ist nicht sehr Benutzerfreundlich. Es wäre doch sehr viel angenemer für die User, wenn sie einfach nur die URL des OWA angeben könnten.

Also anstatt https://owa.mydomain.ch/owa  kann einfach nur owa.mydomain.ch in der Adresszeile des Browsers eigegeben werden. Wenn die Exchange Umgebung über ein TMG Server veröffentlich wurde, lässt sich dies mit einer zusätzlichen Regel im TMG erreichen.

Die Regel für diese Funktion muss wie folgt konfiguriert werden:

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

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


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

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

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

Exchange 2013 in einer .local Domäne

Exchange 2010 oder 2013 arbeiten bekanntlich mit SAN-Zertifikaten. Dies sind Zertifikate die mehrere URLs enthalten. Üblicherweise enthalten die Zertifikate für Exchange 2013 / 2010 folgende Namen:
- owa.mydomain.com
- autodiscover.mydomain.com
- FQDN aller Exchange Server
- smtp.mydomain.com

Wenn ich nun eine .local-Domäne habe, also meine interne Domäne auf .local oder eine andere nicht offizielle Endung endet, muss ich als FQDN des Exchange Servers auch meinechange.meineinternedomain.local im Zertifikat haben.

Ab dem Jahr 2015 wird es nicht mehr erlaubt sein nicht offizielle URLs in einem öffentlichen Zertifikat zu integrieren. Das heisst, wenn ich heute ein offizielles Zertifikat bestelle dürfen keine nicht offiziellen URLs (oder solche die ich nicht besitze) mehr im Zertifikat enthalten sein.

Mobile Device Management mit Exchange 2010

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

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

Installation SCVMM 2012 SP1

Ich installiere SCVMM 2012 mit SP1 auf einem Windows Server 2012. Die minimalen Systemanforderungen könnt ihr hier nachlesen:

http://technet.microsoft.com/en-us/library/gg610562.aspx

Folgendes ist auch noch zu beachten:

• Der Server muss Mitglied der Domäne sein
• Der Computername darf nicht länger als 15 Zeichen sein und darf den String SCVMM nicht beinhalten.
• Wenn ihr den SCVMM 2012 SP1 auf einem Windows Server 2008 R2 installieren wollt, müsst ihr den Windows Remote Management (WinRM Service) auf automatischen Start umstellen. Unter Windows Server 2012 ist der Service schon auf automatischen Start eingestellt.
• Wenn ihr den SCVMM 2012 SP1 auf einem Windows Server 2008 R2 installieren wollt, benötigt ihr das .NET Framework 3.5 mit SP1 oder neuer. Auf dem Server 2012 ist das .NET Framework 4.0 schon installiert.

Gemischte Exchange 2007 / 2010 Umgebung und TMG

Während einer Migration von Exchange 2007 auf Exchange 2010 wird oft eine Koexistenz der beiden Exchange Versionen aufgebaut, damit die Postfächer in Ruhe auf den neuen Exchange 2010 verschoben werden können.

Durch die CAS Proxy Funktionalität ist dies auch kein Problem. Wenn die externen Zugriffe auf die Exchange Organisation durch einen TMG abgesichert ist kommt es aber oft zu Problemen mit der Konfiguration des TMG Servers. Stimmt diese nicht, kann es vorkommen das die User ihre Anmeldedaten für den Zugriff auf das OWA zwei mal angeben müssen.

Dies geschieht, wenn ein User, dessen Postfach noch auf dem Exchange 2007 liegt, über OWA auf sein Postfach zugreifen will und die SSO Konfiguration auf dem TMG nicht korrekt ist.

Microsoft Exchange Server 2013 Preview als Download

Microsoft bietet einen Ausblick auf die nächste Version des Exchange Servers. Herunterladen könnt ihr dies hier:

http://technet.microsoft.com/de-de/evalcenter/hh973395.aspx?wt.mc_id=TEC_116_1_33