Exchange 2010 SP3 - UR11 installiert sich zu Tode. Was tun?

[PowerShellAdmin 169]

hm...

-Exchange Services manuell ausschalten, im Anschluss den Virenschutz deaktivieren/ unregister.=> Virenschutz vor Neustart der Dienste zuerst wieder aktivieren.

-Hier ist ein Artikel zum älteren Rollup1 - aber die Symptome sind ähnlich und die Fehler im Log. Womöglich treten hier ähnliche Ursachen auf.

https://support.microsoft.com/en-us/kb/981474

-Hier ist auch ein Artikel:https://technet.microsoft.com/de-de/library/ff772434%28v=exchg.80%29.aspx

 

 

Es gibt scheinbar hier und da Probleme, da die Rollups auf PowerShell Routinen zugreifen - diese erfordern entsprechende Execution Policies. Aufgrund von Sicherheitsbeschränkungen können diese hier kollidieren.

Wobei dein Log nicht so aussieht, dass dies die Ursache ist. Die Fehler sollten dann erst im Anschluss zu .ps1 Skripten kommen.

 

 

=> Execution Policy der PowerShell prüfen und notieren, temporär auf unrestricted setzen und die Installation erneut test, im Anschluss wieder wie gewünscht zurücksetzen.

Set-ExecutionPolicy unrestricted

bearbeitet 21. April 2016 von PowerShellAdmin

[toasti 11]

Ausschalten, also nur stoppen oder deaktivieren? Wenn Sie deaktiviert sind läuft das Update nämlich noch nicht mal los.

Virenschutz ist deaktiviert, die ExecutionPolicies stehen alle auf undefined außer LocalMachine - der steht auf "Unrestricted".

 

Mal alle ExecutionPolicies auf Unrestricted setzen?

 

Oder macht es Sinn die vorherigen UpdateRollups zu deinstallieren? Auf meiner Testmaschine kann ich mich ja austoben...

 

Achso, das sind die letzten Zeilen und hier bleibt er stehen. Mit Forefront haben wir eigentlich nichts zu tun...

MSI (s) (78:98) [04:12:52:961]: Note: 1: 2262 2: CustomAction 3: -2147287038 
MSI (s) (78:98) [04:12:52:961]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:961]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:961]: Note: 1: 2262 2: CustomAction 3: -2147287038 
MSI (s) (78:98) [04:12:52:961]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:977]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:977]: Note: 1: 2262 2: CustomAction 3: -2147287038 
MSI (s) (78:98) [04:12:52:977]: Transforming table Binary.

MSI (s) (78:98) [04:12:52:977]: Transforming table Binary.

MSI (s) (78:98) [04:12:52:977]: Note: 1: 2262 2: Binary 3: -2147287038 
MSI (s) (78:98) [04:12:52:977]: Transforming table Binary.

MSI (s) (78:98) [04:12:52:977]: Transforming table Binary.

MSI (s) (78:98) [04:12:52:977]: Note: 1: 2262 2: Binary 3: -2147287038 
MSI (s) (78:98) [04:12:52:977]: Transforming table Binary.

MSI (s) (78:98) [04:12:52:977]: Transforming table Binary.

MSI (s) (78:98) [04:12:52:977]: Note: 1: 2262 2: Binary 3: -2147287038 
CA_SAVEDATA_STOP_SERVICES: Service: Stopping services
Action ended 04:12:52: CA_SAVEDATA_STOP_SERVICES. Return value 1.
MSI (s) (78:98) [04:12:52:977]: Doing action: CA_STOP_FOREFRONT_PROP
Action 04:12:52: CA_STOP_FOREFRONT_PROP. 
Action start 04:12:52: CA_STOP_FOREFRONT_PROP.
MSI (s) (78:98) [04:12:52:992]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:992]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:992]: Note: 1: 2262 2: CustomAction 3: -2147287038 
MSI (s) (78:98) [04:12:52:992]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:992]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:992]: Note: 1: 2262 2: CustomAction 3: -2147287038 
MSI (s) (78:98) [04:12:52:992]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:992]: Transforming table CustomAction.

MSI (s) (78:98) [04:12:52:992]: Note: 1: 2262 2: CustomAction 3: -2147287038 
MSI (s) (78:98) [04:12:52:992]: PROPERTY CHANGE: Adding CA_STOP_FOREFRONT property. Its value is '"C:\Program Files\Microsoft\Exchange Server\V14\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -Version 2.0 -command $serviceName = 'FSCController'
if (Get-Service | where { $_.Name -eq $serviceName })
{
  Stop-Service $serviceName -Force
  $imagePath = (Get-ItemProperty 'HKLM:SYSTEM\CurrentControlSet\Services\FSCController').ImagePath.Trim(34)
  $parentPath = Split-Path $imagePath -Parent
  $cmd = Join-Path -Path $parentPath 'fscutility.exe'
  $parameter = '/disable'
  &$cmd $parameter
}"'.

bearbeitet 21. April 2016 von toasti

[PowerShellAdmin 169]

Ausschalten, also nur stoppen oder deaktivieren? Wenn Sie deaktiviert sind läuft das Update nämlich noch nicht mal los.

Virenschutz ist deaktiviert, die ExecutionPolicies stehen alle auf undefined außer LocalMachine - der steht auf "Unrestricted".

 

Mal alle ExecutionPolicies auf Unrestricted setzen?

 

Oder macht es Sinn die vorherigen UpdateRollups zu deinstallieren? Auf meiner Testmaschine kann ich mich ja austoben...

Ich hatte den Fall, dass ich beim aktiven Rollup mal Zickereien hatte und habe während dessen alle Dienste deaktiviert. Dies ging zumindest.

Soweit das nicht geht, würde ich die Firewall wenigstens schließen - solange der Exchange Virenschutz deaktiviert ist, sollte da nichts  reinlaufen(die Testumgebung ist hier wahrscheinlich nicht betroffen - je nach Setup)...

 

Mein erster Ansatz wäre:

-PS Execution temporär auf unrestricted setzen ( das ist einzahl), kann man aber über mehrere Stellen (mehrzahl)...

https://technet.microsoft.com/de-de/library/ee176961.aspx

-Exchange Virenschutz ausschalten / unregister.

=> Testen

 

Da du wiebeschrieben eine Testumgebung hast -> austoben... Try & Error so ist das manchmal..

 

Wenn du dann nicht vorwärts kommst, bleibt dir immer noch der Support Call bei Microsoft. Hier war meine Erfahrung aber sehr durchwachsen (je größer das Unternehmen - desto schwieriger sind Anfragen...).

 

VG :)

bearbeitet 21. April 2016 von PowerShellAdmin

[toasti 11]

OK. Also unser Virenschutz ist mittlerweile deinstalliert.

 

PS Execution Policy - alle Scopes mal auf unrestricted setzen oder wie?

 

PowerShell Version ist 2.0, Build 6.1.7601.17514 und WSM auf 2.0. Das sollte ja passen, gab ja mit 3.0 mal Probleme wobei das ab SP3 auch kompatibel sein soll.

[PowerShellAdmin 169]

Es reicht aber eigentlich folgendes Setup aus - da du bereits unrestricted hast, sollte es passen.

 

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine    RemoteSigned
 

bearbeitet 21. April 2016 von PowerShellAdmin

[toasti 11]

Er hängt nach wie vor an

MSI (s) (78:98) [04:12:52:992]: PROPERTY CHANGE: Adding CA_STOP_FOREFRONT property. Its value is '"C:\Program Files\Microsoft\Exchange Server\V14\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -Version 2.0 -command $serviceName = 'FSCController'
if (Get-Service | where { $_.Name -eq $serviceName })
{
  Stop-Service $serviceName -Force
  $imagePath = (Get-ItemProperty 'HKLM:SYSTEM\CurrentControlSet\Services\FSCController').ImagePath.Trim(34)
  $parentPath = Split-Path $imagePath -Parent
  $cmd = Join-Path -Path $parentPath 'fscutility.exe'
  $parameter = '/disable'
  &$cmd $parameter
}"'.

Ich bin echt ratlos, das kann doch nicht sein... wahrscheinlich ist es zum Schluss nur ne Kleinigkeit.

Ich deinstalliere mal Rollup 8v2 und schau weiter.

 

EDIT:

So, das Deinstallieren von UR8v2 scheint auch nicht wirklich zu funzen... da ist doch irgendwas Grundsätzliches verbogen was Exchange Updates angeht?! Habt ihr ne Idee was ich dahingehend prüfen könnte?

Irgendwelche Windows-Updates die "stören"? Hab im März 2015 das UR8 installiert, da ging alles super. Am 23.04.2015 habe ich einen ganzen Schlag Sicherheitsupdates und teils normale Updates installiert - gute Frage ob hier was dabei ist das Probleme macht.

Man man...

bearbeitet 21. April 2016 von toasti

[Nobbyaushb 1.471]

Moin,

 

aus meiner Sicht hast du folgende Möglichkeiten:

 

- die Datenbanken in Sicherheit bringen, Maschine Plattmachen, neu mit gleichem Namen / IP hochziehen und mittels /M:Recoverserver mit dem SP3 und dem zuletzt installiertem RU neu installieren.

- einen neuen Exchange hochziehen und eine Swing-Migration fahren, je nach Vertrag dabei gleich auch Exchange 2016 CU1 gehen.

- Call bei MS

 

bearbeitet 22. April 2016 von Nobbyaushb

[toasti 11]

So Leute.... ich hab gerade einen Gedankenblitz gehabt und das wars...

 

Habe im Oktober letztes Jahres ein Profil für Powershell hinterlegt (profile.ps1) das mir direkt eine Verbindung zum Exchange aufbaut.

Da der Exchange aber schon beendet ist zum Zeitpunkt des Updates kann er sich natürlich nicht mehr verbinden und hängt damit in der Luft und da das Update-Script bzw. die versch. Powershell Aufrufe im Hintergrund laufen hat man das natürlich so nicht wahr genommen, auch im Log nicht.

 

Hab das Profil raus genommen und siehe da - es geht!

 

Mich hat es gestern stutzig gemacht, dass nicht mal mehr eine Deinstallation geht und da alles auf PowerShell beruht ging mir das nochmal durchn Kopf...

Bin auch gestern schon drauf gestoßen da ich PowerShell während der Deinstallation starten wollte und es zu Fehlern kam da die EX-Dienste natürlich schon deaktiviert waren.

 

So einfach kanns manchmal sein, man man... ;-)

 

Wieder was dazu gelernt...

 

Danke für eure Unterstützung und schönes WE!

[Nobbyaushb 1.471]

Also alles mal wieder eine Frage der Dokumentation...

 

Was sollte der Zweck des PS Profiles sein?

 

;)

[toasti 11]

Ich hatte das damals für meine geplanten PowerShell Tasks hinterlegt. War so einfacher. Evtl. sollte ich das mal umbauen ;-)

[PowerShellAdmin 169]

Also alles mal wieder eine Frage der Dokumentation...

 

Was sollte der Zweck des PS Profiles sein?

 

;)

So schauts aus,am Ende muss man alle Berührungspunkte durchgehen - hatte eine Webanwendung in der via PS Skript Berechtigungen für einen FTP Zugriff automatisch gesetzt werden.

Problem: Die Webanwendung hatte sporadische Aussetzer, Ursache: Berechtigungen Webanwendung setzen Webanwendung & zeitgleicher Zugriff auf die Webanwendung => App-Pool reset...

Bei größeren Problemen sind es oftmals die nicht so offensichtlichen Punkte ;) Ich hatte den Fehler zum Glück in 2 Stunden intensiver Recherche A-Z gefunden...

 

@Toasti => freut mich das es wieder funzt :)

bearbeitet 26. April 2016 von PowerShellAdmin

[toasti 11]

Ja, die gute Dokumentation... da habt ihr Recht!

 

Es sind leider so oft im Kleinigkeiten die einen so lange beschäftigen, schon crazy manchmal. Mit 2h wäre ich auch glücklicher gewesen, aber Hauptsache ich hab den Grund gefunden.

 

Hab nun vorgestern Nacht das Update erfolgreich auf dem Live-System eingespielt, alles butter weich. :-D