Exchange 2019 CU11 Update fehlgeschlagen > danach Probleme

[mts1 10]

Hallo zusammen,

 

schwitze hier gerade ganz schön!

Ich wollte gestern das CU11 installieren (momentan sind wir auf CU10 mit neusten Updates). Während der Installation kam es zu einer Fehlermeldung:

Zitat

Fehler:
Fehler beim Installieren des Produkts H:\exchangeserver.msi. Schwerwiegender Fehler bei der Installation. Fehlercode: 1603. Letzter vom MSI-Paket ausgegebener Fehler: 'Error writing to file: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Current2\version\debug\scripts\Microsoft.Owa.TriageActions.js.   Verify that you have access to that directory.'.
 

Habe dann den Pfad kontrolliert und musste feststellen, dass dieser während der Installation gelöscht wurde (der gesamte debug Order war nicht mehr da).

 

Jetzt du meinem eigentlichen Problem...

Da es schon spät war und ich keine Lust hatte mich damit auseinanderzusetzen wollte ich das Problem vertagen und bin auf einen System-Snapshot zurückgesprungen, den ich direkt VOR der Installation angelegt hatte.

Ich dachte damit sollte eigentlich wieder alles gut sein... Leider nicht.

Ich vermute das Setup hat schon Änderungen am AD vorgenommen welches ich nicht zurückgesetzt habe.

 

Aktueller Status:
1) HealthCheck zeigt:

Server Role: Mailbox
        DAG Name: Standalone Server
        AD Site: Default-First-Site-Name
        MAPI/HTTP Enabled: True
        Internet Web Proxy: Not Set
        Exchange Server Maintenance
                Component: 'ServerWideOffline' is in Maintenance Mode
                Component: 'HubTransport' is in Maintenance Mode
                Component: 'FrontendTransport' is in Maintenance Mode
                Component: 'Monitoring' is in Remote Maintenance Mode only
                Component: 'RecoveryActionsEnabled' is in Remote Maintenance Mode only
                Component: 'AutoDiscoverProxy' is in Maintenance Mode
                Component: 'ActiveSyncProxy' is in Maintenance Mode
                Component: 'EcpProxy' is in Maintenance Mode
                Component: 'EwsProxy' is in Maintenance Mode
                Component: 'ImapProxy' is in Maintenance Mode
                Component: 'OabProxy' is in Maintenance Mode
                Component: 'OwaProxy' is in Maintenance Mode
                Component: 'PopProxy' is in Maintenance Mode
                Component: 'PushNotificationsProxy' is in Maintenance Mode
                Component: 'RpsProxy' is in Maintenance Mode
                Component: 'RwsProxy' is in Maintenance Mode
                Component: 'RpcProxy' is in Maintenance Mode
                Component: 'XropProxy' is in Maintenance Mode
                Component: 'HttpProxyAvailabilityGroup' is in Maintenance Mode
                Component: 'MapiProxy' is in Maintenance Mode
                Component: 'EdgeTransport' is in Maintenance Mode
                Component: 'HighAvailability' is in Maintenance Mode
                Component: 'SharedCache' is in Maintenance Mode
                Component: 'MailboxDeliveryProxy' is in Maintenance Mode
                Component: 'RoutingUpdates' is in Maintenance Mode
                Component: 'RestProxy' is in Maintenance Mode
                Component: 'DefaultProxy' is in Maintenance Mode
                Component: 'Lsass' is in Maintenance Mode
                Component: 'RoutingService' is in Maintenance Mode
                Component: 'E4EProxy' is in Maintenance Mode
                Component: 'CafeLAMv2' is in Maintenance Mode
                Component: 'LogExportProvider' is in Maintenance Mode
                For more information: https://aka.ms/HC-ServerComponentState

 

2) Diverse Fehler:

Error 10004: Failed to discover Ews Url for mailbox 'LegacyDn: /o=nucleus/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients ...

Error 5016: Microsoft Exchange could not discover any route to connector CN= ...

Error 5016: Microsoft Exchange could not discover any route to connector CN=Text Messaging Delivery Agent Connector ...

Warning 2937:
Process edgetransport.exe (Transport) (PID=18212). Object [CN=4vad,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=nucleus,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=nucleusnet,DC=local]. Property [HomeMtaServerId] is set to value [nucleusnet.local/Configuration/Deleted Objects/Microsoft MTA
DEL:c1360a03-84ea-4989-b835-c86927d41943], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

...

 

Womit fange ich jetzt am besten an um das System wieder zum Laufen zu bringen.

Ich habe schon versucht ServerWideOffline wieder auf Active zu setzten, jedoch tut sich nichts. Ich bekomme keine Fehlermeldung, aber er bleibt auf InActive.

[NorbertFe 1.812]

Ich würde eine recoverinstallation empfehlen. Und dann die aktuellste dB und logfiles verwenden.

Warum jemand mit snapshots bei datenbabkbasierten Systemen und erst recht bei exchange hantiert wird sich mit nie erschließen. ;)

[mts1 10]

Xen nutzt VSS Snapshots, welche eigentlich kein Problem bei Datenbanken verursachen.

Habe die Module jetzt wieder auf Active bekommen. Mal sehen was jetzt noch für Fehler auftreten.

[cj_berlin 1.150]

vor 19 Minuten schrieb mts1:

Xen nutzt VSS Snapshots, welche eigentlich kein Problem bei Datenbanken verursachen.

https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/virtualization?view=exchserver-2019 :

Und bitte das Wording beachten: nicht "reverting a VM to a snapshot isn't supported", sondern "making snapshots isn't supported"...

[mts1 10]

Mag sein. Aber das ist jetzt schon eine recht pauschale Aussage.

 

Zitat

Quiesced snapshots

Quiesced snapshots take advantage of the Windows Volume Shadow Copy Service (VSS) to generate application-consistent point-in-time snapshots. The VSS framework helps VSS-aware applications (for example Microsoft Exchange or Microsoft SQL Server) flush data to disk and prepare for the snapshot before it is taken. Quiesced snapshots are therefore safer to restore, but can have a greater performance impact on a system while they are being taken. They may also fail under load, so more than one attempt to take the snapshot may be required.

 

P.S. Die gleiche Technik nutzt doch auch jedes Backup-Utility. 

[cj_berlin 1.150]

Bei Exchange sollte man nicht diskutieren, sondern einfach nur die Docs beachten. Dafür sie die so ausführlich.

vor 7 Minuten schrieb mts1:

P.S. Die gleiche Technik nutzt doch auch jedes Backup-Utility. 

Nicht ganz richtig. VSS BACKUP und VSS SNAPSHOT sind zwei verschiedene Befehle und bewirken unterschiedliche Dinge.

Und übrigens: Nicht jede Backup Utility, die meint, Exchange zu unterstützen, ist auch *von Exchange* unterstützt.

[mts1 10]

offensichtlich, aber ich bin kein Freund von "das steht da so, also ist das so".

Wie gesagt, dann könnte man auch kein Backup von einem laufendem Exchange machen.

[cj_berlin 1.150]

vor 1 Minute schrieb mts1:

offensichtlich, aber ich bin kein Freund von "das steht da so, also ist das so".

Wie gesagt, dann könnte man auch kein Backup von einem laufendem Exchange machen.

Wie gesagt, 

a. bei Exchange ist es so. Und Eigeninitiative in Produktion endet immer in Tränen.

b. VSS-Backup != VM-Snapshot, selbst wenn der Virtualisierungshersteller "VSS-Unterstützung" zusichert. Das sieht man bei Interesse übrigens auch in den Event Logs.

[NorbertFe 1.812]

vor 1 Stunde schrieb mts1:

Xen nutzt VSS Snapshots, welche eigentlich kein Problem bei Datenbanken verursachen.

Doch. Abgesehen davon, dass der Snapshot üblicherweise im laufenden Betrieb durchgeführt wird und man bis zum Ende des setups durchaus Datenverlust in Kauf nimmt, wenn man zum Snapshot zurückkehrt. (Kann man kaum verhindern).

vor 59 Minuten schrieb mts1:

offensichtlich, aber ich bin kein Freund von "das steht da so, also ist das so".

Und hilft dir das in deiner Situation jetzt? ;)