Jump to content

Installation/Update SAPGUI via GPO funktioniert unter W7, scheitert unter W10


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

ich brauche mal euren Support :-)Wir unterstützen gerade ein Unternehmen dabei die SAPGUI (GUI, um eine Verbindung auf SAP-Systeme herzustellen) per GPO auf deren Windows Clients (Win7 und Win 10) zu installieren. Konkret wird ein PowerShell Skript bei der Computer Konfiguration als Startup-Skript hinterlegt. Das Skript startet dann die Installationn bzw. das Update, indem es die Setup.exe mit Switches aufruft, z. B.

 

"setup.exe /Product:"SAPGUI" /silent"

 

Wie gesagt funktioniert das bei Win7 ohne Probleme. Windows 10 macht keine Anstalten die GUI zu installieren. Die User sollen in dem Kontext auf keinen Fall Admin-Rechte bekommen. Letztlich geht es ja "nur" darum, dass die oben genannte Zeile erfolgreich ausgeführt werden soll. Gibt es da bei Windows 10 Einschränkungen?

 

Was meint ihr? Freue mich auf die Diskussion :-)

 

Viele Grüße + Danke

Samoth

 

 

Link zu diesem Kommentar

Hi,

 

dann bau doch als erstes ein wenig Logging in dein Script ein, um zu prüfen, ob das Script startet und an welcher stelle es Probleme gibt. Dann könntest du mittels

$setupPID = Start-Process -FilePath "<Pfad zur >\setup.exe" -Arguments "/Product:"SAPGUI" /silent" -PassThru

noch den ExitCode loggen. Wenn die "setup.exe" dann tatsächlich startet, gibt es sicherlich auch noch einen Parameter, um die "setup.exe" zum loggen zu bewegen. ;)

 

Gruß

Jan

Link zu diesem Kommentar

Möglicherweise starten die Clients einfach zu schnell. In W10 hilft es den Schnellstart abzuschalten, zusätzlich diese beiden Artikel zu lesen und, falls nötig, umzusetzen.

 

https://www.gruppenrichtlinien.de/de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36/

https://www.gruppenrichtlinien.de/de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/

 

Link zu diesem Kommentar

Hallo zusammen,

 

Danke schon mal für die Hilfe! :-)

 

Ich war mir beim Erstellen des Themas nicht sicher, aber ich poste hier mal einige Teile aus dem Mail-Verlauf mit dem Unternehmen zitieren, da ich in dem Gebiet Software-Verteilung/PowerShell/... nicht trittsicher bin. Vielleicht hilft euch das weiter:

 

"Ich konnte die SAPGUI per Gruppenrichtlinie und Computer-Startup-Script auf Windows 7 Clients installieren."

 

"...ich teste mit Clients auf Windows 10 Version 1809. Interaktiv als Admin ausgeführt funktioniert die Installation auch auf Windows 10 ohne Probleme.
Die Herausforderung ist die Installation vor der Windows Anmeldung mit Start-Skript (dann als System-User). Kein User in unserem Haus wird lokale Adminrechte bekommen, deswegen ist das alternativlos. Im Ordner C:\Program Files (x86)\SAP\SapSetup\LOGs landen leider keine Logs zum entsprechenden Zeitpunkt."

 

"Der Inhalt des Skriptes:

 

# UNC path to SAPGUI setup folder
$SapSetupPath = "\\server\NETLOGON\sapgui\BD_NW_7.0_Presentation_7.60_Comp._1_\PRES1\GUI\WINDOWS\Win32\Setup\NwSapSetup.exe"

Copy-Item $SapSetupPath -Destination C:\ -Force
& $SapSetupPath /Product:"SAPGUI" /silent

 

Die Copy-Item-Zeile ist nur mein Test, ob das Skript ausgeführt wird (und ja, die Datei wird immer kopiert, auf Win7 wie 10)."

 

Wir haben auch schon mal intern gesprochen und da gibt es Meinungen, die besagen, dass man die Installation *so* nicht mehr durchführt und auch nicht mit dem System-User, weil... da die Berechtigungen für gewisse Teile der Registry nicht vorhanden sind...

 

Grüße

Samoth

 

 

 

 

Link zu diesem Kommentar

Wenn das Skript mit SYSTEM Berechtigung läuft, dann benötigt schon mal das Computerkonto auf das Share einen "Lesen"-Zugriff. Für die Softwareverteilung sollte man eine eigene Freigabe nutzen! Sobald das passt, würde ich die "LocalMachine"-Richtlinie ( ZUM TEST ) auf Unrestricted setzten.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine

 

Link zu diesem Kommentar

Mal ein paar Gedanken dazu:

1. Warum im Netlogon? Dafür macht man besser einen eigenen (DFS-) Share

2. Wenn es unter Win7 im Systemkontext geht, sollte das auch unter Win10 funktionieren

3. AppLocker ist für SYSTEM irrelevant

4. Unterstützt dieses Setup kein Logfile?

5. Setups rufe ich lieber per CMD auf. Da kann man mit >>logfile 2>&1 so einfach den Output protokollieren. Ist in Powershell nicht ganz so trivial, vor allem wenn eine Exception kommt...

6. Ruf dein Startskript doch mal per psexec -s auf - was passiert dann?

Final: Logging ist alles. Ohne Logging ist alles nichts. :-)

 

Link zu diesem Kommentar

Noch eine Anmerkung:

vor 17 Stunden schrieb Samoth:

# UNC path to SAPGUI setup folder
$SapSetupPath = "\\server\NETLOGON\sapgui\BD_NW_7.0_Presentation_7.60_Comp._1_\PRES1\GUI\WINDOWS\Win32\Setup\NwSapSetup.exe"

Copy-Item $SapSetupPath -Destination C:\ -Force
& $SapSetupPath /Product:"SAPGUI" /silent

Wenn du das Setup schon nach lokal kopierst, was durchaus sinnvoll sein kann, dann starte es auch von lokal. ;)

Link zu diesem Kommentar

Hallo an alle,

 

Danke für die konstruktiven Ratschläge und konkreten Anweisungen :-)! Wir setzen die Verteilung nicht selbst um, sondern haben den Fehler übermittelt bekommen mit der Bitte das mal bei uns nachzustellen. Der Zugriff auf die Systeme bei dem Unternehmen ist leider nur sehr beschränkt möglich.

 

Was mich noch interessiert:

 

 - "Copy-Item $SapSetupPath -Destination C:\ -Force" --> Sorgt dieser Teil im Skript dafür, dass das bei $SapSetupPath hinterlegte Objekt auf den lokalen Rechner auf C: kopiert wird? Das wäre dann ja nur die Datei "NwSapSetup.exe". Der Admin schreibt uns ja, dass er nur die Datei kopiert, um zu kontrollieren, ob das Skript an sich ausgeführt wird. In der letzten Zeile " "$SapSetupPath /Product:"SAPGUI" /silent" wird dann die Variable um das Produkt SAPGUI und die Installationsart "silent" ergänzt. Ist das nicht doch eine Remote-Installation?

 

- Wie ist den der Ablauf bei so einer Remote-Installation wie wir sie gerne durchführen möchten? Auf einem Share liegt offen zugreifbar die "Setup.exe". Diese könnte ich ja auch als User mit Admin-Rechten direkt ausführen und die GUI installieren. Gut, das möchte ich in dem Fall nicht, weil der User keine Admin-Rechte bekommt und letztlich möchte ich den Install-/Update-Zeitpunkt frei wählen. Ich muss also irgendwie von extern triggern, dass dieses Setup silent ausgeführt wird und das auch noch im Admin-Kontext, sodass der User nicht einbezogen wird. Ist unsere Vorgehensweise hier einfach die falsche? Wobei ich mich dann auch frage, warum es unter Win7 sauber läuft...?

 

@daabm

1. Meine Unwissenheit: Macht das einen Unterschied?

4. Logs werden auch unterstützt über die Variable %ErrorLevel%. Gebe dir aber Recht - ohne Logs wird es fummelig. Ich hatte dem Admin eigentlich auch schon die Info geschickt, darauf aber keine Antwort erhalten.

5. Von wo aus? Vom Rechner des Users, um es mal zu testen?

 

Viele Grüße + Danke nochmal! :-)
Samoth

 

Link zu diesem Kommentar
vor 3 Minuten schrieb MurdocX:

Nein, das ist dann eine lokale Installation, wenn es lokal kopiert und dann ausgeführt wird. 

OK. Aber lokal kopieren möchte ich es eigentlich nicht und das Skript kopiert (für mein Verständnis) ja nur die eine Datei, um zu prüfen, ob das Skript überhaupt läuft. Die Installation soll direkt vom Share aus gestartet werden.

Link zu diesem Kommentar
vor 3 Stunden schrieb Samoth:

Installation soll direkt vom Share aus gestartet werden.

Das ist ja was anderes. 

 

Testweise ein installer auf C zu kopieren finde ich genau so daneben, wie unter Netlogon Textdateien anzulegen um zu überprüfen ob die Replikation des AD funktioniert.

 

Ich bin auf der Seite des sauberen loggens und nach dem Fehler die nächsten Schritte zu bewerten. 

Link zu diesem Kommentar
vor 7 Stunden schrieb daabm:

@Samoth Wenn Du das nicht selber ausprobierst, sondern nur Durchlauferhitzer für einen Dritten vor Ort bist, bin ich raus - das wird zu langwierig...

Dank dir trotzdem! :-)

Sagt mal... off topic: Ich durfte mich eben anpfeifen lassen, weil man eine Installation so nicht mehr macht. Man hat dafür gefälligst ein msi-Paket zu verwenden und kein unsicheres Startup-Skript. Wie seht ihr das?

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...