toasti

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

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

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!

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...

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.

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 }"'.

Hallo zusammen, wollte nochmal meinen alten Thread ausgraben, bei UR13 hatte ich neue Hoffnung es könnte klappen, aber irgendwas stimmt einfach nicht. Hier ein Schnippsel aus dem Debug-Log: MSI (s) (78:98) [04:12:53:039]: Executing op: CustomActionSchedule(Action=CA_CUSTOMER_PATCH_ROLLBACK,ActionType=1345,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Program Files\Microsoft\Exchange Server\V14\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -Version 2.0 -command . 'C:\Program Files\Microsoft\Exchange Server\V14\\scripts\customization\CustomPatchInstallerActions.ps1' PatchRollbackActions") MSI (s) (78:98) [04:12:53:039]: Executing op: ActionStart(Name=CA_CUSTOMER_PREPATCH_INSTALL,,) Action 04:12:53: CA_CUSTOMER_PREPATCH_INSTALL. MSI (s) (78:98) [04:12:53:055]: Executing op: CustomActionSchedule(Action=CA_CUSTOMER_PREPATCH_INSTALL,ActionType=1089,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Program Files\Microsoft\Exchange Server\V14\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -Version 2.0 -command . 'C:\Program Files\Microsoft\Exchange Server\V14\\scripts\customization\CustomPatchInstallerActions.ps1' PrePatchInstallActions") MSI (s) (78:98) [04:12:53:055]: Creating MSIHANDLE (17) of type 790536 for thread 920 MSI (s) (78:D4) [04:12:53:055]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI30F.tmp, Entrypoint: CAQuietExec MSI (s) (78:B4) [04:12:53:055]: Generating random cookie. MSI (s) (78:B4) [04:12:53:055]: Created Custom Action Server with PID 652 (0x28C). MSI (s) (78:54) [04:12:53:101]: Running as a service. MSI (s) (78:54) [04:12:53:101]: Hello, I'm your 32bit Impersonated custom action server. MSI (s) (78!74) [04:13:11:415]: Creating MSIHANDLE (18) of type 790531 for thread 884 CAQuietExec: Error 0x80070001: Command line returned an error. MSI (s) (78!74) [04:13:11:415]: Closing MSIHANDLE (18) of type 790531 for thread 884 MSI (s) (78!74) [04:13:11:415]: Creating MSIHANDLE (19) of type 790531 for thread 884 CAQuietExec: Error 0x80070001: CAQuietExec Failed MSI (s) (78!74) [04:13:11:415]: Closing MSIHANDLE (19) of type 790531 for thread 884 CustomAction CA_CUSTOMER_PREPATCH_INSTALL returned actual error code 1603 but will be translated to success due to continue marking MSI (s) (78:D4) [04:13:11:415]: Closing MSIHANDLE (17) of type 790536 for thread 920 MSI (s) (78:98) [04:13:11:415]: Executing op: ActionStart(Name=CA_ROLLBACK_SAVEDATA_STOP_SERVICES,,) Action 04:13:11: CA_ROLLBACK_SAVEDATA_STOP_SERVICES. MSI (s) (78:98) [04:13:11:415]: Executing op: CustomActionSchedule(Action=CA_ROLLBACK_SAVEDATA_STOP_SERVICES,ActionType=1281,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Program Files\Microsoft\Exchange Server\V14\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -Version 2.0 -command . 'C:\Program Files\Microsoft\Exchange Server\V14\\bin\servicecontrol.ps1' AfterPatch") Insbesondere CAQuietExec: Error 0x80070001: Command line returned an error. CAQuietExec: Error 0x80070001: CAQuietExec Failed CustomAction CA_CUSTOMER_PREPATCH_INSTALL returned actual error code 1603 but will be translated to success due to continue marking lies mich hoffen etwas dazu zu finden was hilft, aber nichts... Hab mir gestern einen unserer DCs und den Exchange geklont und in einem abgetrennten Netz laufen lassen - das UR13 lief die ganze Nacht, nichts ging vorwärts. Das Log stand noch unverändert so wie ich gestern das Büro verlassen habe. (Log oben stammt vom "richtigen Exchange", nicht wundern über die Zeit... hatte bisl Nachtschicht eingelegt...) Hab das Update wieder über eine als Admin ausgeführte CMD gestartet. Kein Erfolg. Danach Aufruf per Powershell probiert und vorher ExecutionPolicy auf "unrestricted" gesetzt da ich das in ein paar Foren so gelesen hatte - nichts. Alle nicht Microsoft-Dienste hatte ich vorher deaktiviert und neu gestartet. Temp-Ordner vorher ebenfalls geleert. In C:\Windows\Installer sind ein Haufen alter Installationsdateien, auch von den ganzen Update-Versuchen - kann man das Verzeichnis bedenkenlos aufräumen? Sind da evtl. noch Schnippsel drin die stören? Hab außerdem nochmals meine Rechte geprüft, auch das sollte passen. Andere URs vorher konnte ich ja auch schon installieren. Derzeit ist SP3 UR8v2 der letzte Stand. Oh man, was für ein Käse. Vielleicht habt ihr noch Ideen? Achso, wegen Zwischenupdate - kann gut sein, dass wir mal ein Hotfix installiert haben.

D.h. es ist wirklich nur rein die Anzeige verkehrt und alles gut? Trotzdem ziemlich unschön...

Ich verstehe nicht ganz... Wie gesagt, ich habe ja versch. GPOs - pro Office-Version eine! Allerdings sind die administrativen Vorlagen ja für jede Version grundsätzlich in einer GPO sichtbar sobald sie im zentralen Speicher liegen. Ändere ich in der GPO für 2007 die Einstellung für die Automatisicherungssicherheit wird mir später in der Übersicht "Office 2013" statt 2007 angezeigt und das macht mich eben stutzig. Wenn ich doch gar nicht die administrative Vorlage für 2013 anfasse, warum zeigt er mir dann Office 2013 in der Einstellungsübersicht der GPO für Office 2007 an? @daabm: Grundsätzlich leuchtet das ein, dass es bei dieser Einstellung keinen speziellen Pfad für die Version gibt, aber warum zeigt er dann grundsätzlich "Office 2013" in der Übersichtsseite an?

Hallo zusammen, ich habe hier ein Phänomen welches ich mir nicht erklären kann... Ich habe 3 GPOs, jeweils eine für Office 2007, 2010 und 2013. Die ADMX + passende ADMLs Dateien für jede Office Version sind im entsprechenden Verzeichnis und werden zentral abgerufen. Nun ändere ich in der GPO für 2007 und der entsprechenden administrativen Vorlage die Einstellung unter Sicherheit für "Automatisierungssicherheit" auf "Standardmäßig deaktiviert". Wenn ich nun das Bearbeitungsfenster schließe und die Ansicht aktualisiere sehe ich nicht "Office 2007\Sicherheit\Automatisierungssicherheit", sondern "Office 2013\Sicherheit\Automatisierungssicherheit". Wenn ich nun diese Richtlinie erneut öffne und schau in die administrativen Vorlage für 2013 wurde diese tatsächlich umgestellt - in der Policy für 2007! Jetzt kommts: Wenn ich jetzt die Einstellung wieder raus nehme für 2013, wird auch die Einstellung für 2007 raus genommen. Es muss irgendwas mit den Vorlagen für 2013 zu tun haben, denn das passiert auch bei der 2010er Richtlinie wo ich ebenso natürlich nur für Office 2010 die Einstellung mache. Könnt ihr euch das irgendwie erklären? Ich bin bisl ratlos.

Jemand noch eine Idee?

So, das ist nun wirklich komisch. Es wurde kein neues Log angeleg, nur die 3 Dateien "ServiceControl.log", "ServiceStartupMode.xml" und "ServiceState.xml" wurden geändert und um Inhalt ergänzt - sonst nichts. Die Installation wieder stehen geblieben, kein Fortschritt. Danach dachte ich versuchst mal UR9, da wir bisher ja nur auf SP3 sind - dachte ich.Habe dann per Outlook Verbindungsstatus die Version kontrolliert: 14.3.224.4002. Update Rollup 8v2 war 14.3.224.2, die nächst höhere V9 14.3.235.1. Also genau zwischendrin, komisch. Ist auf dem Exchange mal ein bestimmtes Update drauf gekommen was die Installation blockt? Irgendeine komische "Zwischenversion"? Ich bin bisl ratlos.

Morgen versuche ich das Update nun erneut. Ich bin gespannt und melde mich sobald ich Neuigkeiten habe.

OKidoki, du meinst aber das Log in C:\ExchangeSetupLogs oder? Weil direkt auf C: liegt keins. Dann werde ich mir nochmal ein Wartungsfenster schaffen und erneut versuchen. Kann allerdings nicht sagen ob das diese Woche noch klappt.

Genau, alle vorangegangenen Exchange URs für das entsprechende SP. Windows Updates fehlen derzeit 5 Sicherheitsupdates, 4 x Windows, 1 x IE 11. Ausgeblendet sind keine, allerdings installiere ich auch nicht unbedingt jedes Windows Update. Sicherheitsupdates ja, alle anderen nach Bedarf.