chibisuke
Goto Top

Exchange 2013 CU6 setup auf 2012R2: New-OABVirtualDirectory schlägt fehl

Moin zusammen,

gut 4 Jahre nach unserem letzten Desaster mit Exchange versuch ich mich momentan daran Exchange 2013 auf Server 2012R2 zum Laufen zu bekommen, aber schon die Installation scheitert... Einige kleinere Macken, vor allem "Tippfehler" bzw. falsch platzierte Sonderzeichen in der applicationhost.config des IIS bzw. den Config-Files von Exchange selbst (enablef statt enabled, securit{ statt security...), konnte ich schon selbst ausbügeln, aber an einer Stelle komm ich einfach nicht weiter.

Kurz zur Umgebung: Domäne (Funktionslevel 2008) lief bisher mit Server 2008R2 als DC und Ex2010 auf Server 2012 (nicht R2), jetzt kamen 2 frisch installierte 2012R2 dazu. Einer ist schon als DC eingerichtet, der andere soll Exchange laufen lassen wenn die Installation mal klappen würde.

Der riesige Knackpunkt momentan: der Installer versucht in der Default Web site das OAB-VD anzulegen und scheitert damit. Der Setup-Schritt heißt "Clientzugriffsrolle: Clientzugriffs-Front-End-Dienst" und meldet den Fehler:
Der folgende Fehler wurde generiert, als "$error.Clear(); 
          $InternalOabUrl = "https://" + $RoleFqdnOrName + "/OAB";
          new-OabVirtualDirectory -Role ClientAccess -DomainController $RoleDomainController -InternalUrl $InternalOabUrl;
          get-OabVirtualDirectory -server $RoleFqdnOrName -DomainController $RoleDomainController | set-OabVirtualDirectory -OAuthAuthentication:$true;
        " ausgeführt wurde: "System.InvalidOperationException: Fehler beim Erstellen des virtuellen IIS-Verzeichnisses 'IIS://mailserver.domäne.local/W3SVC/1/ROOT/OAB' auf 'mailserver'. ---> System.Runtime.InteropServices.COMException: Die Daten sind unzulässig. (Ausnahme von HRESULT: 0x8007000D)
   bei System.DirectoryServices.DirectoryEntry.CommitChanges()
   bei Microsoft.Exchange.Management.Metabase.CreateVirtualDirectory.Execute()
   bei Microsoft.Exchange.Management.SystemConfigurationTasks.NewExchangeVirtualDirectory`1.CreateToMetabase()
   bei Microsoft.Exchange.Management.SystemConfigurationTasks.NewExchangeVirtualDirectory`1.InternalProcessRecord()
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target, Boolean reThrow, String helpUrl)
   bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
   bei Microsoft.Exchange.Management.SystemConfigurationTasks.NewExchangeVirtualDirectory`1.InternalProcessRecord()
   bei Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
   bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".

Ruf ich das Kommando in der EMS auf sieht es so aus:
[PS] C:\Windows\system32>New-OabVirtualDirectory -Role ClientAccess -InternalUrl https://mailserver.domäne.local/OAB -DomainController DC
Fehler beim Erstellen des virtuellen IIS-Verzeichnisses 'IIS://mailserver.domäne.local/W3SVC/1/ROOT/OAB' auf 'mailserver'.
    + CategoryInfo          : InvalidOperation: (mailserver\OAB (Default Web Site):ADObjectId) [New-OabVirtualDirectory], Inv
   alidOperationException
    + FullyQualifiedErrorId : [Server=mailserver,RequestId=bca87025-47b7-4fe6-aa60-3fd9efa95b17,TimeStamp=18.11.2014 08:13:29
   ] [FailureCategory=Cmdlet-InvalidOperationException] B9C0A1A4,Microsoft.Exchange.Management.SystemConfigurationTas
  ks.NewOabVirtualDirectory
    + PSComputerName        : mailserver.domäne.local

In beiden Fällen wird das VD zwar im IIS angelegt aber nicht im AD eingetragen. Hab in der EMS schon beide DCs durch probiert, Meldung ist die selbe. Ein grundsätzliches AD-Problem sollte es eigentlich nicht sein, immerhin hat es der Installer ja auch geschafft etliche andere VDs in der default web site und "exchange back end" zu registrieren.

Hab schon einiges recherchiert, man findet nur leider sehr wenig dazu. Die meisten "Treffer" beziehen sich auf das OWA-VD und/oder auf Exchange 2010, hab hier aber bisher keine brauchbaren Ansätze gefunden. Per ADSIedit sehe ich dass keine verwaisten Einträge vorhanden sind, und der IIS metabase explorer (aus dem IIS6 ressource kit) zeigt auch keine Reste wenn ich das VD händisch aus dem IIS lösche.

Habt ihr noch eine Idee woran das liegen könnte? Bin für jeden Tipp dankbar.

Content-Key: 255131

Url: https://administrator.de/contentid/255131

Ausgedruckt am: 28.03.2024 um 12:03 Uhr

Mitglied: Chibisuke
Chibisuke 19.11.2014 um 18:54:19 Uhr
Goto Top
N'Abend zusammen,

Problem nicht gelöst aber "umschifft"... Hab Ex2013 auf der Maschine mittels Konsole und setup.exe /mode:uninstall soweit möglich wieder vom System gekratzt. Er meckerte mitten drin dass er den Server auf unserem DC nicht mehr finden kann und brach ab, per ADSI-Edit konnte ich sehen dass alle Exchange-relevanten Einträge aus dem AD getilgt sein sollten. Hab die Maschine danach auf einen (glücklicherweise vorhandenen) Snapshot der vor den ersten Installationsversuchen lag zurückgesetzt und sie wird jetzt anderweitig verwendet, stattdessen hab ich die Installation dann auf einer anderen VM (2008R2) angestoßen und gehofft dass es hier weniger Probleme gibt. Und siehe da, der Installer lief in einem Rutsch durch und alles scheint auf Anhieb zu funktionieren... Also entweder hat die 2012R2-VM einen gewaltigen Knacks (was ich weniger glaube da ich sie schon 2mal neu aufgesetzt hatte) oder Ex2013 verträgt sich einfach nicht mit 2012R2...

Falls letzteres der Fall sein sollte bin ich heilfroh dass einer unserer Kunden der auch kürzlich auf Ex2013 umgestiegen ist noch bei 2008R2 geblieben ist, will nicht wissen das was für ein Theater gegeben hätte wenn es bei der Installation auch solche Probleme aufgetreten wären...