Zwar können die virtuellen Verzeichnisse für die verschiedenen Exchange Webservices über das “Exchange Admin Center” neu erstellt werden, jedoch gibt es Fälle, wo diese Funktion an ihre Grenzen stößt.
Für diesen Artikel habe ich so einen Fehler simuliert. Auch nach dem Zurücksetzen des Verzeichnisses für OWA mit dem Exchange Admin Center funktioniert OWA nicht:
Nicht alles lässt sich eben mit der GUI erledigen.
Einleitung
Exchange 2016 verfügt über zwei Webseiten im IIS. Unter der Webseite “Default Web Site” befindet sich der Client Access Dienst, den es zwar nicht mehr als eigenständige Exchange Rolle gibt, aber immer noch vorhanden ist. Exchange Clients, wie zum Beispiel Outlook und Smartphones, verbinden sich zu den virtuellen Verzeichnissen innerhalb der “Default Web Site”. Die virtuellen Verzeichnisse innerhalb der “Default Web Site” bilden also das Front-End für die Clients/Protokolle.
Das Front-End dient den Clients dabei als Proxy für das “Exchange Back End”, welches seine eigene Webseite innerhalb des IIS besitzt. Im Back-End steckt dabei die eigentliche Logik, das Front-End dient nur als statusloser Proxy. Im folgenden Screenshot sind die beiden Webseiten zu sehen:
Die virtuellen Verzeichnisse lassen sich auch in der Exchange Management Shell anzeigen, der folgende Befehl zeigt zum Beispiel das virtuelle Verzeichnis für OWA:
Get-OwaVirtualDirectory -Server TEX1
Der Befehl zeigt allerdings nur das Front-End an, dies ist am Parameter “Name” zu erkennen: Default Web Site. Damit auch das entsprechende Gegenstück im Back-End angezeigt wird, kann der folgende Befehl verwendet werden:
Get-OwaVirtualDirectory -Server TEX1 -ShowMailboxVirtualDirectories
Um eine Liste aller entsprechenden Befehle für das Auflisten der virtuellen Verzeichnisse zu erhalten, kann der folgende Befehl verwendet werden:
get-command get-*VirtualDirectory
So viel erst einmal zur Theorie. Verschiedene Probleme können es erforderlich machen, dass ein oder mehrere der virtuellen Verzeichnisse neu erstellt werden müssen.
Virtuelle Verzeichnisse neu erstellen
Dieses kleine Beispiel zeigt das Neuanlegen des virtuellen Verzeichnisses für Outlook Web Access (Outlook on the Web, OWA). Um einen Fehler zu simulieren, habe ich für diesen Artikel einfach das virtuelle Verzeichnis für OWA in der “Default Web Site” und in der Webseite “Exchange Back End” gelöscht:
Das Löschen der beiden Verzeichnisse führt dann zum HTTP 404 Fehler:
In meinem Fall muss ich nun also Front-End und Back-End Verzeichnis für OWA neu anlegen. Ich habe allerdings nur die Verzeichnisse im IIS gelöscht. Exchange geht also immer noch davon aus, dass Front-End und Back-End existieren. Dies lässt sich mit folgendem Befehl prüfen:
Get-OwaVirtualDirectory -Server TEX1 -ShowMailboxVirtualDirectories
In diesem Screenshot ist zu erkennen, dass das Verzeichnis OWA im IIS fehlt, aber in der Exchange Shell immer noch angezeigt wird:
Exchange speichert seinen Teil der Konfiguration im Active Directory, wie hier zu erkennen ist:
Damit die OWA Front-End und Back-End neu erstellt werden können, müssen nun zunächst die Verzeichnisse auch aus der Exchange Konfiguration gelöscht werden. Dazu kann der folgende Befehl genutzt werden:
Get-OwaVirtualDirectory -Server TEX1 -ShowMailboxVirtualDirectories | Remove-OwaVirtualDirectory
Im Prinzip könnte man jetzt das Verzeichnis für OWA neu anlegen, wäre da nicht die IIS Metabase. Hier gibt es ebenfalls Einträge, die das Neuerstellen des virtuellen Verzeichnisses verhindern. In der Regel tritt der folgende Fehler auf, wenn versucht wird, das OWA Verzichnis neu zu erstellen und es Reste in der IIS Metabase gibt:
Fehler beim Erstellen des virtuellen IIS-Verzeichnisses ‚IIS://TEX1.frankysweb.local/W3SVC/1/ROOT/owa‘ auf ‚TEX1‘.
+ CategoryInfo : InvalidOperation: (TEX1\owa (Default Web Site):ADObjectId) [New-OwaVirtualDirectory], In
validOperationException
+ FullyQualifiedErrorId : [Server=TEX1,RequestId=a96fe949-f9e2-48b1-977d-e7a5f8cbc600,TimeStamp=18.10.2017 18:43:5
1] [FailureCategory=Cmdlet-InvalidOperationException] 5812692E,Microsoft.Exchange.Management.SystemConfigurationTa
sks.NewOwaVirtualDirectory
+ PSComputerName : tex1.frankysweb.local
Um die Leichen in der IIS Metabase zu bereinigen, kann das ziemlich alte Tool “IIS Metabase Explorer” verwendet werden. Das Tool gibt es hier zum Download:
Der “IIS Metabase Explorer” benötigt .NET Framework 3.5 Funktionen, diese müssen ggf. nachinstalliert werden:
Im IIS Metabase Explorer müssen unter “LM –> W3SVC –> 1 –> ROOT” und “LM –> W3SVC –> 2 –> ROOT” die Einträge “OWA” gelöscht werden:
Hinweis: Der Eintrag unter “LM –> W3SVC –> 1 –> ROOT” steht hierbei für das Front-End, “LM –> W3SVC –> 2 –> ROOT” ist das OWA Back-End.
Beide Einträge für OWA können in der IIS Metabase gelöscht werden:
Jetzt kann das OWA Verzeichnis mit der Exchange Management Shell neu erstellt werden:
New-OWAVirtualDirectory -WebSiteName 'Default Web Site' -Server TEX1
Und auch das Back-End lässt sich jetzt wieder erstellen:
New-OWAVirtualDirectory -WebSiteName 'Exchange Back End' -Server TEX1 -Role "Mailbox"
Die OWA Webseite lädt jetzt bereits wieder:
Allerdings müssen die URLs wieder eingetragen werden:
In meinem Fall ist dies “https://outlook.frankysweb.com/owa”
Auch die restlichen Einstellungen, zum Beispiel für die Authentifizierung müssen entsprechend der Wünsche angepasst werden:
Wie schon eingangs erwähnt, gibt es auch die Möglichkeit die virtuellen Verzeichnisse via EAC zurückzusetzen. Jedoch wird dabei immer nur das Front-End neu erstellt. Sollte es, wie hier beschrieben zu Fehlern im Back-End kommen, hilft der Weg über das Exchange Administrative Center nicht weiter.
Auf dem hier beschriebenen Weg können auch die restlichen Verzeichnisse neu erstellt werden (EWS, Active Sync). Das Vorgehen ist gleich und es müssen nur die entsprechenden CMDLets für die weiteren Verzeichnisse benutzt werden. Eine kleine Ausnahme ist allerdings das PowerShell Verzeichnis. Dies ist im nächsten Artikel an der Reihe.
Hallo zusammen, ich habe einen Exchange 2019 aufgesetzt. Leider habe ich OWA zwar in Betrieb gehabt, allerdings durchgängig mit der Meldung, das keine Verschlüsselung aktiviert ist. ActicSync ging somit auch nicht. Bei meinen Bemühungen dies zu Realisieren habe ich im IIS so viele Anpassungen vorgenommen, das nun gar nichts mehr geht. Somit würde ich den IIS gerne wieder auf „Default“ zurücksetzen. Kann ich auf die obern genannte weise Ab dem Abschnitt in dem die virtuellen Verzeichnisse erstellt werden, diese mit den Standardwerten überschreiben, oder muss ich tatsächlich erst die drei Ordner in allen drei „Ablagen“ entfernen um sie neu zu installieren?
Ich habe nun die Ordner alle immer entfernt und neu erstellt. Das ging bei allen Ordnern gut Problemlos.
ECP, EWS, OAB, Microsoft-Server-ActiveSync. Und zwar im Default, wie auch im Back End
Leider habe ich noch eine Herausforderung. OWA lässt sich im Back End nicht wieder herstellen. Die Seite fehlt in allen drei Ansichten.
Die Fehlermeldung lautet,
„[PS] C:\Windows\system32>New-OwaVirtualDirectory -WebSiteName ‚Exchange Back End‘ -Server meiner.local -Role „Mailbox“
Das Webobjekt ‚Exchange‘ ist bereits vorhanden.
+ CategoryInfo : InvalidArgument: (meiner\owa (Exchange Back End):ADObjectId) [New-OwaVirtualDirectory], WebObjectAlreadyExistsException
+ FullyQualifiedErrorId : [Server=meiner,RequestId=d803c3c0-84f4-477f-86ab-87d66f9bfefe,TimeStamp=09.02.2024 09:43:40] [FailureCategory=Cmdlet-WebObjectAlreadyExis
tsException] 3594AAF0,Microsoft.Exchange.Management.SystemConfigurationTasks.NewOwaVirtualDirectory
+ PSComputerName : meiner.local“
Da ich sonst alle Verzeichnisse sauber weg und hin bekommen habe, kann nicht so viel falsch sein. Server ist ein Exchange 2019 CU13, inkl. aktueller Updates.
Über Hilfe wäre ich sehr dankbar, da ich mit dem Fehler „Das Webobjekt ‚Exchange‘ ist bereits vorhanden.“ nichts anfangen kann. Den Ablauf mit erst im IIS löschen, dann im ADSI-Editor und dann noch im Tool zusammen auf beiden Seiten und dann erst auf der Default Seite und danach auf dem Back End habe ich ebenfalls durchgeführt. Die Default Seite ist auch wieder da. die Back End Seite eben nicht. Dort ist nur der owa Ordner wie auf dem Bild oben.
Hallo!
Ich habe die Anleitung peinlichst genau befolgt um Autodiscover auf Exchange 15.1 2016 neu zu erstellen. Vor dem Neuerstellen habe ich im ADSI Editor und ISS Metabase Editor alles mit Autodiscover entfernt. Leider endet der Befehl zur Neuerstellung wie folgt:
New-AutodiscoverVirtualDirectory -WebSiteName ‚Exchange Back End‘ -Server server -Role „Mailbox
“
Das Active Directory-Objekt für das virtuelle Verzeichnis ‚IIS://Server.WIR.at/W3SVC/2/ROOT/Autodiscover‘
auf ‚SERVER‘ konnte nicht erstellt werden. Möglicherweise ist es bereits in Active Directory vorhanden. Entfernen Sie
das Objekt aus Active Directory, und erstellen Sie es anschließend neu.
+ CategoryInfo : InvalidOperation: (SERVER\Autodiscover (Exchange Back End):ADObjectId) [New-Autodiscover
VirtualDirectory], InvalidOperationException
+ FullyQualifiedErrorId : [Server=SERVER,RequestId=49e3c8b5-fc2d-451c-9366-88c237dc7275,TimeStamp=15.01.2023 08:42
:55] [FailureCategory=Cmdlet-InvalidOperationException] 78C179A1,Microsoft.Exchange.Management.SystemConfiguration
Tasks.NewAutodiscoverVirtualDirectory
+ PSComputerName : server.WIR.at
Ich wäre über jeden Tipp sehr dankbar!
Hallo Daniel, Hattest du das Problem noch beheben können?
Hattest du noch mal im ADIS-Editor geguckt, das der Ordner weg ist?
Bei Autodiscover gibt es wohl noch einen weiteren Wert,
New-AutodiscoverVirtualDirectory -Server „Servername“ -BasicAuthentication $true -WindowsAuthentication $true
Set-ClientAccessServer -Identity „Servername“ -AutodiscoverServiceInternalUrl https://autodiscover.Servername.local/Autodiscover/Autodiscover.xml
Gruß Wolf
Wieder mal großes Lob an Franks Seite – ohne die wären viele Exchange-Admins um einiges schlechter dran auf dieser Welt (und man kann nicht jedem unterstellen, dass er seine Hausaufgaben nicht macht…). Auch mich ereilte der 403 im Browserfenster nach einem Update, und hier erfuhr man doch tatsächlich Hintergründe und eine profunde Lösung.
Was dem Verfasser nicht anzulasten ist, was aber zu stundenlanger Arbeit führt: Stand heute (10/2021) ist bei Microsoft KEIN Resource Toolkit mehr im Download zu bekommen, das sind nur noch DOCs. Da alle Welt nur per Link zu MS verweist, hat man quasi gar keine Chance, das noch herbeizuschaffen. Also zusehen, dass man sich das irgendwie, irgendwo, irgendwann schon mal heruntergeladen und gespeichert hat!
Super ! Herzlichen Dank an dich Alex
Hallo Frank,
tolle Arbeit, die Du hier leistest. Chapeau.
Ich arbeite mich nun schon seit Tagen durch sämtliche Dokus von Dir zur Migration Exchange 2010 zu 2016 und stolpere von einem Problem zum nächsten. Vielleicht kannst du mir helfen ?
Zum Einen fehlt im IIS der komplette „Exchange Backend“ Pfad, bei mir ist nur die Default Web Site vorhanden.
Deshalb bin ich nun auch auf diese Seite Webseite von Dir gestoßen.
Zum Anderen fehlt im DNS der komplette Eintrag: _mcds.server.local, unterhalb der Forward Lookup Zone. Innerhalb der server.local Zone ist _mcds vorhanden.
Im ADSI Editor sind die Einträge auch alle vorhanden. Von extern funktioniert mit autodiscover soweit alles, da hab ich den Test über https://www.testexchangeconnectivity.com/ durchlaufen lassen.
OWA und Active Sync funktinieren ebenfalls produktiv.
Die DNS “ _mcds.server.local“ Eintrag und der IIS „Exchange Backend“ Eintrag sind doch aber für eine erfolgreiche Migration notwendig!
Wie kann ich diese fehlenden Einträge erstellen ?
LG Andi
Hallo Andi,
schreib es doch mal in das neue Forum: https://www.frankysweb.de/community
Gruß,
Frank
Hallo Zusammen,
leider finde ich nirgendwo mehr das „Internet Information Services (IIS) 6.0 Resource Kit Tools“ oder Metabase Explorer !
Hat jemand einen funktionieren Link zum Download oder stell ich mich nur „deppert“ an :-)
Danke !!!!!
Tom aus Augsburg
https://download.cnet.com/Internet-Information-Services-IIS-6-0-Resource-Kit-Tools/3000-2381_4-10735391.html
http://download.microsoft.com/download/7/8/2/782c25d3-0f90-4619-ba36-f0d8f351d398/iis60rkt.exe
aus dem Archive.org gefischt
^^Link Jetzt leider auch down
Nimm diesen Link:
https://web.archive.org/web/20170330222336/http://download.microsoft.com/download/7/8/2/782c25d3-0f90-4619-ba36-f0d8f351d398/iis60rkt.exe
Hallo Frank,
ich schließe mich hier meinem Vorredner ausnahmslos an
Wieder einmal hat mir Deine Seite so ziemlich als Einzige im Web kompetent weitergeholfen!
Es ist einfach sehr traurig, dass Microsoft es anscheinend nicht schafft, ein Exchange CU zu veröffentlichen, ohne dass man sich irgendwas zerschießt… Selbe lässt sich leider auch bei diversen Serverrollen berichten (Stichwort WSUS …).
Von dem her, alle Daumen nach oben für diese Seite hier!
LG, Andy
Vielen lieben Dank!
Musste das ECP Verzeichnis komplett zurücksetzen und dies war die einzigste Anleitung die mir deutlich weiter geholfen hat.
Ich hatte ein paar Tage geschwitzt, und andere Beiträge im Internet haben nicht geholfen, danke, dass du so tief in die Materie gehst!
Großes Lob!!!