windows 10 anniversary update fehler

[Cdn]

Deine Glaskugel funktioniert ziemlich gut

Ja genau so ist es

[wolfbardo]

Hallo,

Danke für den Hinweis. Wir werden das Paket windows10-upgrade_17.03-1.opsi entsprechend umbauen.

Gruss
Bardo Wolf

[Tobei]

Hi,

kann ich so bestätigen mit einem angemeldeten Benutzer läuft das Upgrade ohne Probleme durch. Gibt es schon Fortschritte seitens UIB, oder lohnt es sich, wenn ich anfange selbst ein Skript zu schreiben?


Gruß Tobias

[r4tzeblitz]

Sowohl beim Update 1511 -> 1607 als auch von 1607 -> 1703 ist ein angemeldeter User notwendig.
Ansonsten bricht das Update irgendwann ab.
Das ergaben jedenfalls meine Tests.

[wolfbardo]

Hallo,

es gibt ein überarbeitetes Script dass technisch funktioniert unter http://download.uib.de/opsi4.0/experime ... .0-13.opsi

Hinweise:

Code: Alles auswählen

- In diesem Script wird ein temporaerer nichtadministrativer lokale Nutzer mit Zufallspasswort temporaer angelegt
- die eigentliche Installtion erfolgt aber über den opsiclientd

Folgenden Einschränkungen

Code: Alles auswählen

- Text und soweiter muss noch aufgehübscht werden
- Innerhalb von Windows 10 sollte das Upgrade inclusive opsiclientd funktionieren
- Bei Upgrades von Windows 7 oder Windows 8.1 nach Windows 10 muss anschliessend der opsi-client-agent ggfs zweimal drüberinstalliert werden

Gruss
Bardo Wolf

[JMS]

Hallo,

zunächst mal ganz herzlichen Dank für das überarbeitete Skript. Ich habe mir das Paket "windows10-upgrade_17.03-13.opsi" gezogen, entpackt und mal durchgelesen.

Folgendes ist mir aufgefallen:

Fehler in "OPSI/control"
Das Property "debug" fehlt

Fehler in "declarations-local.opsiscript"

Code: Alles auswählen

Switch $upgrade-to-version$
    Case "1703"
	set $Setup.exe.version$ = "10.0.15063.0"
        EndCase
    Case "1607" ; KORREKTUR
	set $Setup.exe.version$ = "10.0.14393.0"
        EndCase
    Case "1511"
	set $Setup.exe.version$ = "10.0.10586.0"
        EndCase
    DefaultCase
	comment "minimum version from Windows 10 1507"
	set $Setup.exe.version$ = "10.0.10240.0"
        EndCase
EndSwitch

Mir ist noch nicht ganz klar, warum diese Abfrage erfolgt. Nur um den Fehler abzufangen, wenn per Property "installfiles_dir" die falschen Installationssourcen bereitgestellt werden? Ich meine, das müsste bereits vor dem ersten Boot geprüft werden. Aber: das geht eleganter.... (in dem man auf das Property komplett verzichtet. Weiter unten mehr)

Ansonsten:
Ein paar Dinge scheinen mir nicht ganz schlüssig, zum Beispiel:

1. Warum erfolgt der Abgleich der vorhandenen Version mit der Zielversion nicht schon vor dem ersten Boot? (Also noch bevor die Sourcen nach lokal kopiert werden) Das würde - wenn die gewünschte Zielversion bereits installiert (siehe ReleaseId aus Registry) ist - die Skriptlaufzeit deutlich verkürzen.
2. Warum erfolgt die Prüfung auf $MinimumSpace$ (in setup.opsiscript) erst nach dem ersten Boot? BTW: später noch einmal per login.opsiscript.
3. "Set $WinstRegKey$ = "HKLM\SOFTWARE\opsi.org\winst\"+$ProductId$" statt "Set $WinstRegKey$ = "HKLM\SOFTWARE\opsi.org\winst\"+$Productname$" ist schöner

Was ich noch umbauen werde:
Ich will auf die Property "installfiles_dir" verzichten und mir den Pfad zu den Installationssourcen dynamisch "zusammenrechnen". Die Installationssourcen liegen ja eh - zumindest bei mir - sortiert nach Zielversion / Architektur / Sprache - im Depot.

Code: Alles auswählen

 ├─OS
 │ ├─win10                       
 │ │ ├─1511                      
 │ │ │ ├─32                      
 │ │ │ ├─64                      
 │ │ │ │ ├─stage201607           
 │ │ │ │ ├─winpe                 
 │ │ │ │ └─winpe_uefi            
 │ │ │ ├─kum_updates             
 │ │ │ └─mediacreationtool       
 │ │ │   ├─de                    
 │ │ │   └─es                    
 │ │ ├─1607                      
 │ │ │ ├─32                      
 │ │ │ │ ├─stage20161102         
 │ │ │ │ ├─stage20161111         
 │ │ │ │ ├─winpe                 
 │ │ │ │ └─winpe_uefi            
 │ │ │ ├─64                      
 │ │ │ ├─kum_updates             
 │ │ │ │ ├─32                    
 │ │ │ │ └─64                    
 │ │ │ └─mediacreationtool       
 │ │ │   ├─de                    
 │ │ │   │ ├─boot                
 │ │ │   │ ├─efi                 
 │ │ │   │ ├─x64                 
 │ │ │   │ └─x86                 
 │ │ │   └─es                    
 │ │ ├─1703                      
 │ │ │ ├─32                      
 │ │ │ │ ├─winpe                 
 │ │ │ │ └─winpe_uefi            
 │ │ │ ├─64                      
 │ │ │ │ ├─winpe                 
 │ │ │ │ └─winpe_uefi            
 │ │ │ ├─kum_updates             
 │ │ │ └─mediacreationtool       
 │ │ │   ├─de                    
 │ │ │   │ ├─boot                
 │ │ │   │ ├─efi                 
 │ │ │   │ ├─x64                 
 │ │ │   │ └─x86                 
 │ │ │   └─es                    
 │ │ │     ├─boot                
 │ │ │     ├─efi                 
 │ │ │     ├─x64                 
 │ │ │     └─x86                 
 │ │ └─xxxx_kopiervorlage        
 

Somit kann ich alle Inplace-Upgrades für Windows 10 mit einem Paket abfackeln, auch das in Kürze erscheinende "Creators Fall Update".
Zwar sind die Release-IDs für kommende Versionen nicht bekannt, doch bei Nutzung der Property "upgrade-to-version" und Auswahl "last" (besser "latest") würde ich die 3. Ebene des obenstehenden Verzeichnisbaums abklappern und so die ReleaseID der gewünschten Version ermitteln. Dann erfolgt nur noch der Abgleich des Wertes aus dem Verzeichnisscan und der (aus der Registry ermittelten) ReleaseID.
Nur mal so als Idee...

Außerdem:

Wenn gewünscht stelle ich meine Anpassungen gerne bereit, vielleicht fließen meine Anpassungen ja mit ein?!
Ein Fork weniger

Viele Grüße ... und nochmals DANKE für die Vorlage!!!


JMS

[wolfbardo]

Hallo JMS,

Danke für die Kritik und die Anmerkungen!

Ein aktualisiertes Paket findet sich unter http://download.uib.de/opsi4.0/products ... 03-14.opsi nebst http://download.uib.de/opsi4.0/products ... readme.txt

Übernommen habe ich allerdings erstmal nur die frühere Prüfung der Version der

Code: Alles auswählen

setup.exe

Alles weitere gerne im Rahmen eines bezahlten Supportvertrages

Scherz beiseite. In dem Script stecken viele Iterationen und von daher Altlasten.
Des weiteren ist / war die Testerei sehr zeitaufwendig was wir gerne im Rahmen eines ... das hatten wir ja schon

Nur soviel:

- Da seit Windows 10 1607 ?? das Upgrade leider nur im Systemkontext klappt, so irgendein User angemeldet ist, musste erstmal ein

Code: Alles auswählen

opsi-template-with-user

erstellt werden, um dann für das Upgrade genutzt zu werden (Danke an detlef oertel !!!). Weitere Varianten wurden implementiert (etwa opsi-template-with-admin oder als user_login-script) und wieder verworfen, da noch Sie noch mehr Nachteile hatten als die hiermit implementierte Methode.

- das property installfiles_dir mit entsprechenden pre-postinst-Scripten war mal gedacht um eben mit einem Paket mehrere Win10-Versionen abzufackeln und existiert daher noch als Altlast. In der Regel hat man aber nur ein Upgradeziel. Von daher wurde das Property halb entsorgt.

Zuguterletzt: Wenn man mit opsi alles paketiert hat, so kommt man m.E. mit einer PXE-Installation besser hin,

Gruss
Bardo Wolf

[JMS]

Hallo wolfbardo,

ich habe das Skript an meine Bedürfnisse angepasst und soweit fertig überarbeitet.

Was mir allerdings bei meinen Tests aufgefallen ist:

Auf "deutschen" Systemen - unabhängig von Release und Architektur - läuft das Skript sauber bis zum Ende durch, alles prima!

Auf "nicht-deutschen" System kommt nach dem Logon mit dem temporären User - unabhängig von Release und Archtiektur - "opsiclientd_event_starter_asInvoker.exe" zwar hoch, quittiert aber mit einem Fehler.

Bei der Fehlersuche ist mir aufgefallen, dass der temporäre User nicht in der Gruppe der lokalens Admin ist. In der Vorlage in der Sektion "DosInAnIcon_makeadmin" war dies auch auskommentiert. Das habe ich dann auch "zurück"-geändert und der temporäre User "opsiadmin" war beim nächsten Lauf auch in der Gruppe der lokalen Admins.

Aber: Wenn der temporäre User Adminrechte hat, dann startet "opsiclientd_event_starter_asInvoker.exe" nach dem ExitWindows / ImmediateLogout" nicht (oder bricht sofort ab), obwohl die Angaben unter "Run" in der Registry eingetragen sind und "opsiclientd_event_starter_asInvoker.exe" auf der lokalen Platte am richtigen Platz vorhanden ist. Das komische daran: Auf deutschen System klappt der Start der "opsiclientd_event_starter_asInvoker.exe", auch wenn sich der temporäre User (mit Adminrechten) angemeldet hat!

Spasshalber habe ich den Start von "opsiclientd_event_starter_asInvoker.exe" als "Run" in alle UserProfiles reinschreiben lassen. Die Angaben werden auch in die Registry geschrieben, der Effekt ist jedoch der Gleiche:
Auf deutschen System läuft das Skript auch mit dieser Anpassung, aber auf "nicht-deutschen" Systemen kommt "opsiclientd_event_starter_asInvoker.exe" nicht hoch oder bricht ab.

Kurzum:
Auf "nicht-deutschen" Systemen bleibt die Installation mit angemeldeten (temporären) User stehen. Starte ich dann die "opsiclientd_event_starter_asInvoker.exe" von Hand, dann läuft alles normal weiter und kommt zum erfolgreichen Abschluss.

Ich mache mir keinen Reim darauf und verstehe ich es nicht. Nage seit Tagen daran rum...

Daher die Frage: ist möglicherweise in der "opsiclientd_event_starter_asInvoker.exe" oder in den beiden Libraries irgendwo irgendwas hartverdrahtet, was es nur in deutschen Windows-Versionen gibt?

Viele Grüße


JMS

[wolfbardo]

Hallo JMS,

danke fürs Feedback und die Tests!

Kann das Problem

Was mir allerdings bei meinen Tests aufgefallen ist:

Auf "deutschen" Systemen - unabhängig von Release und Architektur - läuft das Skript sauber bis zum Ende durch, alles prima!

Auf "nicht-deutschen" System kommt nach dem Logon mit dem temporären User - unabhängig von Release und Archtiektur - "opsiclientd_event_starter_asInvoker.exe" zwar hoch, quittiert aber mit einem Fehler.

leider ad hoc nicht nachvollziehen, sprich x64 englisch Upgrade Windows 10 1607 -> Windows 10 1703 klappt hier.

Gruss
Bardo Wolf

[JMS]

Hallo,

also ... ich weiß zwar noch immer nicht, warum "opsiclientd_event_starter_asInvoker.exe" im Kontext des temporären Installationsuser mit Adminrechten nicht hoch kommt, aber ich hab' mein Problem wie folgt gelöst:

Noch vor dem Setzen des ersten Reboot-Flags (setup.opsiscript) macht das Skript die UAC "stumm"...

Code: Alles auswählen

Set $UAC_BKP$ = "REG_DWORD:0x0000000" + GetRegistryStringValueSysNative("[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] EnableLUA")
Set $UAC_NEW$ = "REG_DWORD:0x00000000"
Registry_LUA_Backup /32bit
Registry_LUA_Set /32bit

... und setzt - nach dem der Rebootflag auf 4 gesetzt wird (und immer bei fatalen Fehlern) - die Werte zurück:

Code: Alles auswählen

comment "Restoring UAC"
Set $UAC_NEW$ = "REG_DWORD:" + GetRegistryStringValue32("["+$WinstRegKey$+"] "+"EnableLUA")
Registry_LUA_Set /32bit

Die ergänzten Sektionen in "sections-local.opsicsript" sehen wie folgt aus:

Code: Alles auswählen

[Registry_LUA_Backup]
openKey [$WinstRegKey$]
set "EnableLUA"=$UAC_BKP$

[Registry_LUA_Set]
openKey [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
set "EnableLUA"=$UAC_NEW$

Eigentlich trivial

Hab' jetzt aber ein schönes Paket, dass mir jetzt auch Mails zusendet und etliche mögliche Fehler abfängt.
Jetzt muss ich nur noch die "Message"-Texte anpassen, so dass auch meine Franzacken und Spanier glücklich werden.

Viele Grüße und nochmals Danke für die Vorlage!!


JMS


P.S: "Franzacke" darf ich sagen... bin selber einer