Problem mit OWA nach SP3 RU 14

[MaikHSW 13]

Hey zusammen.

Wir haben ein mittelschweres Problem.

Meine Umgebung:

Windows Server 2008 R2

Exchange 2010 SP 1 RU 14

HUB / CAS und MB getrennt

 

Gestern hat sich aufgrund einer Einstellung meines Vorgängers das RU 14 (kam per Update) installiert und ist dabei fehlgeschlagen.

Es ist aber scheinbar mittendrin fehlgeschlagen, so dass die kompletten Exchange Dienste gestoppt waren.

Ich habe erstmal das RU von MS heruntergeladen und per CMD installiert um den Fehler lokalisieren zu können, da lief es durch.

Danach läuft auch Outlook (RPC über HTTPS) und der Sync mit Handys wieder.

Was nicht läuft ist leider OWA.

 

Um das zu korrigieren habe ich die Einstellungen des OWA mit einer Sicherung verglichen, dort sind keine Abweichungen in der IIS Konfiguration zu finden.

Bei jedem Aufruf von OWA findet sich in den Logs folgende Meldung:

Die Konfiguration konnte vom WSMan-IIS-Modul nicht gelesen werden. Empfangener Fehler: -2144108477: %%-2144108477 
 Die Konfigurations-XML ist nicht gültig. Das XML-Element "Plugin" wurde erwartet, jedoch nicht gefunden..

 Benutzeraktion 
 Stellen Sie sicher, dass sowohl die Schema- als auch die Überprüfungsdatei vorhanden und gültig sind.

Das sagt mir so null....

Das WS Plugin ist im IIS auf oberster Ebene registriert und im Bereich Powershell aktiviert, auch dies habe ich mit der laufenden Konfiguration aus dem Backup verglichen.

Leider gibt mir Google keine zielführenden Hinweise, die web.config unter OWA  habe ich ebenfalls geprüft, dort sehe ich (laienhaft) keine Fehler, sie sieht noch aus wie die aus dem funktionierenden Backup.

 

Hat einer von euch dieses Verhalten schon einmal gehabt und kann mir sagen wo ansetzen?

 

Meine Ideen gehen langsam zur Neige und mein letzter Schritt wäre heute Nacht die CAS Rolle und den IIS zu löschen und neu zu installieren.

Da die Mails auf dem MB Server gelagert werden sollte dies ohne Verluste funktionieren.

Ich bin aber für jeden Weg dankbar der mir die Lösung bringt und nicht die Neuinstallation.

 

 

Vielen Dank.

 

 

Gruß

 

 

 

Maik

Ergänzung:

Ich habe testweise das RU wieder deinstalliert.

Der Fehler bleibt und OWA bleibt weiß:

Die Konfiguration konnte vom WSMan-IIS-Modul nicht gelesen werden. Empfangener Fehler: -2144108477: %%-2144108477 
 Die Konfigurations-XML ist nicht gültig. Das XML-Element "Plugin" wurde erwartet, jedoch nicht gefunden..

 Benutzeraktion 
 Stellen Sie sicher, dass sowohl die Schema- als auch die Überprüfungsdatei vorhanden und gültig sind.

Ideen?

 

 

Gruß

[Nobbyaushb 1.471]

Wenn der wirklich auf SP1 gewesen ist, hätte sich das meiner Meinung nach gar nicht installieren, lassen, das ist ein Security-Update für Exchange 2010 SP mit installiertem RU13

 

Wieso Rollen-Trennung?

 

Wenn keine DAG eingerichtet ist, erhöht das nur die Komplexität, und hat keinerlei Vorteile.

 

Ziehe doch einfach schnell einen Neuen HUB/Transport als VM hoch, gleich mit dem SP3 und RU14 integriert.

 

Dauert 15 min.

 

URL / IP anpassen, fertig.

 

;)

[MaikHSW 13]

Hey Nobby.

Die Rollentrennung ergibt auch aus meiner Sicht keinen größeren Sinn.

Ist aber etwas, was ich übernommen habe und noch auflösen muss.

 

Stand nun:

Ich habe das RU deinstalliert und nun geht es besser.

Ich habe nun wieder eine OWA-Anmeldemaske, meine Accountdaten werden aber als falsch gekennzeichnet.

Und im Log finde ich folgenden Fehler:

Event code: 3008 
Event message: Es ist ein Konfigurationsfehler aufgetreten. 
Event time: 28.06.2016 10:41:03 
Event time (UTC): 28.06.2016 08:41:03 
Event ID: 44c9b20f62cf45e2b4d574977218b75b 
Event sequence: 1 
Event occurrence: 1 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/1/ROOT/Autodiscover-65-131115768631103337 
    Trust level: Full 
    Application Virtual Path: /Autodiscover 
    Application Path: C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover\ 
    Machine name: EXCHANGE 
 
Process information: 
    Process ID: 6688 
    Process name: w3wp.exe 
    Account name: NT-AUTORITÄT\SYSTEM 
 
Exception information: 
    Exception type: HttpException 
    Exception message: Die Datei oder Assembly "Microsoft.Exchange.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover\web.config line 940) 
 
Request information: 
    Request URL: https://exchange.bchn.intern:443/Autodiscover/Autodiscover.xml 
    Request path: /Autodiscover/Autodiscover.xml 
    User host address: 10.20.120.81 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT-AUTORITÄT\SYSTEM 
 
Thread information: 
    Thread ID: 1 
    Thread account name: NT-AUTORITÄT\SYSTEM 
    Is impersonating: False 
    Stack trace:    bei System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()
   bei System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
   bei System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)

Hat das schonmal jemand von euch gehabt?

 

Einen neuen HUB/ Transport / CAS Server hochziehen bedeutet wieder Ausfallzeit, die ich mir derzeit nicht leisten kann.

Das wäre meine Lösung heute Abend nach Geschäftsschluss wenn ich bis dahin keine Alternative habe.

Weil ich weiß nicht sicher bei der gepfuschten Umgebung ob es dann wirklich leicht ist.....

 

 

 

Gruß

 

 

Maik

[Nobbyaushb 1.471]

Warum bedeutet das Ausfall?

 

Das mache ich im laufenden Betrieb, ändere den Namen bzw. die IP im Split-DNS und fertig - das merken die Anwender noch nicht mal.

 

Zertifikat natürlich drauf, und bei den Connectoren die Quellen anpassen, fertig.

 

PS: es gibt ein Script im bin Verzeichnis, das sollte dir helfen:

 

An der Exchange Management Shell

 

cd $exscripts

updatecas.ps1

ausführen (alles aus dem Kopf, ggf. prüfen)

 

;)

 

;)

[MaikHSW 13]

Hey Norbert.

Alternativ  kann man das OWA bzw. den ASP nicht wieder ganz bekommen?

Ich habe die Umgebung recht jung übernommen, meine Vorgänger haben null dokumentiert und "Designentscheidungen" wie eine DAG mit nur einem Member lassen mich an Nachhaltigkeit zweifeln.

Daher glaube ich aus dem Bauch heraus nicht, dass ich so einfach den Server ersetzen kann.

Weil da hängt auch eine 500 GB Platte mit dem Titel Archive dran, das lässt mich schon zweifeln....

Siehst du Alternativen?

 

Ich würde lieber mittelfristig auf eine saubere Umgebung umziehen um die ganzen Sünden los zu werden....

 

 

Gruß

[Nobbyaushb 1.471]

Hey Norbert.

Alternativ  kann man das OWA bzw. den ASP nicht wieder ganz bekommen?

 

Habe ich geschrieben, hilft ggf. - Updatecas

 

Was ist denn auf der Platte mit dem Namen Archive?

 

Namen sind Schall und Rauch, auf den Inhalt kommt es an.

 

Ist das Physik oder VM?

 

Habt ihr Enterprise-CAL oder eine (gesetzlich veoregschríebene...) Archivierung laufen, ggf. Dritthersteller?

 

Und ja, das ist so einfach.

 

;)

[MaikHSW 13]

Hey Norbert.

UpdateCAS hat mich in der Tat weitergebracht, ich habe aber auch nochmal das OWA Verzeichnis per Exchange neubauen lassen.

Das sieht soweit ganz gut aus.

Ich habe ein OWA-Layout und kann auch Benutzernamen / Kennwort eingeben.

Aber ich bekomme immer die Meldung, dass es nicht stimmt.

Das ist aber nicht möglich, da ich die Daten gespeichert habe und auch eine Neueingabe testweise versucht habe.

 

Die Logs sind soweit derzeit fehlerfrei.

Hast du da Ideen zu woran es liegt? Es wirkt auf mich so, als würde er nicht korrekt ins AD fragen und prüfen.

 

Archive:

Dort liegen Daten, für mich sieht das nach Archive Daten von Exchange aus.

Wir haben weder eine Enterprise Lizenz noch eine Archivierung (neue Baustelle).

Meine Vorgänger haben Lizenzen aber auch nicht so eng gesehen....

Daher muss ich gerade aufräumen, habe aber mit russischer gecrackter Software begonnen....

 

Ach, P.S.: Es ist eine VM

 

 

Gruß

Update:

OWA läuft wieder.

Fehlermeldung nach Anmeldung direkt:

 

Outlook Web App konnte nicht initialisiert werden. Falls das Problem weiterhin besteht, wenden Sie sich an Ihr Helpdesk.

 

Url: https://webmail.ggs.de:443/owa/auth/error.aspx
OWA version: 14.3.301.0

 

Leider noch keine Ahnung, aber Ideen sind wie immer gerne willkommen.

 

 

Gruß

bearbeitet 28. Juni 2016 von MaikHSW

[Nobbyaushb 1.471]

Hast du die VM mal durchgetreten?

 

Reboot is always good...

 

;)

[MaikHSW 13]

Hey Nobby,

ich habe es final hinbekommen....

Bislang konnte ich mich mit Vorname.Nachname an unserem OWA anmelden, ohne Domäne.

Nun muss zwar mit Domäne, aber der Schmerz ist erträglich aus meiner Sicht.

In der webconfig.xml war noch der falsche Authentification Type eingestellt nachdem ich den OWA "resettet" habe (per Exchange).

Nun scheint es zu gehen.

 

Nichts desto trotz muss ich das Konstrukt aber dringend überarbeiten und auflösen.

Dazu muss ich mir mal 2016 und best practise reinziehen.

 

Hab Dank für deine Hilfe.

 

 

 

gruß

[NorbertFe 2.034]

Die Authentifizierung kann man doch im Virtuellen Verzeichnis in der ECP konfigurieren. Hast du kontrolliert, dass du da auf "Nur Username" konfiguriert hast?

bearbeitet 28. Juni 2016 von NorbertFe

[MaikHSW 13]

Hey.

Kann ich derzeit nicht prüfen.

Nachdem alles wieder halbwegs läuft habe ich mir mal zeitigen Feierabend gegönnt.

Aber ich werde das natürlich morgen früh gerne kontrollieren.

Wenn auch das wiederhergestellt werden kann wäre ich mehr als dankbar.

Dann gilt es "nur" noch Informationen zu beschaffen welche Version die nächste wird und wie der Migrationspfad aussieht.

Weil so kann es ja nicht bleiben. Und best practises ändern sich.

Wobei ich glaube, dass die Umgebung davon nichts gehört hat oder die best practises längst vergangener Zeit einfach übernommen und nicht hinterfragt wurden.

 

 

Gruß und nochmal vielen Dank