Jump to content

Samoth

Members
  • Content Count

    302
  • Joined

  • Last visited

Community Reputation

10 Neutral

1 Follower

About Samoth

  • Rank
    Member
  1. Gibt nix zu entschuldigen. Wenn das deine Ansicht ist, respektiere ich die . Ich könnte aus diesem einen Satz auch gar nicht genau sagen, inwiefern das jetzt Kritik ist und ob die uns gilt. Ich sammle momentan noch Vorschläge von den Usern hier und werde daraus dann eine Mail formulieren mit der Bitte, diese vor Ort umzusetzen. SAP gibt u. a. den Parameter %ERRORLEVEL% mit, mit dem man genauere Infos erhalten könnte. Wird auch in meiner Mail stehen. Wo kann ich die Rückgabewerte bei der Nutzung von "$setupPID..." denn nachschauen? Erscheinen die im Event-Log oder an welcher Stelle? Es gibt bei SAP auch div. Hinweise mit Problembeschreibungen zur Installation unter Windows 10. Die sind wir (soweit passend zur Version) auch durchgegangen - bisher ohne Erfolg. Ich sprach heute Vormittag auch noch mit einem IT-Dienstleister hier bei uns in der Gegend und der Kollege meinte, dass sich die Berechtigungen von Win7 nach Win10 geändert haben. Daher könnten vll. auch die Probleme bei der Ausführung vom Setup.exe unter Win10 stammen. Evtl. kommen wir über die Logs dann an die genaue Ursache. Viele Grüße erst mal Samoth
  2. Herauszufinden, warum die Installation under W7 genauso läuft wie wir es und vorstellen und warum das bei W10 nicht so stressfrei geht OK - jetzt hab ich den Wink verstanden Auch auf die Gefahr hin mich zu wiederholen: Wir hatten ja von Anfang an die Installation per Share (wie eingangs beschrieben) oder SCCM zur Auswahl. Soweit uns mitgeteilt wurde, braucht der SCCM auch vorbereitete Pakete. Mit dieser Info und der Bestätigung vom Kunden, dass die Installation der SAPGUI unter W7 Ruckzuck erledigt war, haben wir den Ansatz SCCM verworfen. Dass es dann bei W10 herausfordernder wird, war damals für uns nicht abzusehen.
  3. Ich habe mit dem Thema an sich leider sehr wenig Berührungspunkte. Daher kann ich es auch nicht einschätzen. Der Anpfiff kam auch nicht vom Kunden Ich verwies dann darauf, dass ich mein Problem hier geschildert habe und keiner der User sich zur Vorgehensweise negativ geäußert hat. So schlimm kann es also nicht sein... Der Kunde hätte noch SCCM an der Hand. Aber wie gesagt, das wollten wir erst mal nicht angehen, weil Installation vom Share easy going usw.
  4. Leider nicht. Die müssten wir in der Tat selbst erstellen - und rate mal, welcher Tutorial-Websites hier gerade schon offen sind? SAP bietet einen SAPGUI-Installationsserver, mit dem man Pakete erstellen kann. Das wäre dann auch Alternative #2, die wir aber erst mal nicht umsetzen wollten, weil die Installation von einem Share aus ja so einfach ist... Aber würdest du der Aussage von oben zustimmen? Installation macht man nicht mehr so, weil... "aus Gründen", unsicher, etc.
  5. 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?
  6. 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.
  7. 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
  8. 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
  9. 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
  10. Kann ich leider nicht sagen. Würde der die Anmeldung dann auf diese Art und Weise unterbinden? Es ist auch so, dass die Anmeldung mit anderen Usern an Servern der Domäne funktioniert.
  11. Hallo zusammen, vielleicht habt ihr noch Ideen zu folgendem Problem: Ich möchte mich an einerm 2012 R2 Applikationsserver (kein DC, kein TS) mit einem Domänen-Account anmelden. Wenn ich mich im internen Netz per MSTSC von einem beliebigen anderen Server auf den ApplServer verbindune klappt das problemlos. Nun sitze ich jedoch, über ein VPN angebunden, außerhalb und erhalte bei der Anmeldung am ApplServer die Meldung: "To sign in remotely, you need the right to sign in through Remote Desktop Services. By default members of the Administrators group have this right. If the group you're in does not have the right, or if the right has been removed from the Administrators group, you need to be granted the right manually." Wie gesagt: Intern geht es mit dem gleichen User, nur von außen nicht. Ich komme ja auch zum Server selbst und sehe die Anmeldemaske. Habe bereits div. Google-Tipps durchprobiert, also die Gruppe Remote Desktop Users entsprechend geprüft und auch in der Local Security Policy den Punkt "Allow log on through Remote Desktop Services" entsprechend behandelt. Was meint ihr? Grüße Samoth
  12. Hi Tektronix, ich müsste den Senior mal fragen Habe aber wenig Hoffnung, dass da noch was übrig ist. Ich bat ihn schon darum, alles was er hat einzupacken. Habe nur Notebook, Netzteil und Maus bekommen... Mittlerweile ist das Image zurückgespielt, Windows aktuell, Office installiert,... Werde jetzt noch den Rest machen, dann auf jeden Fall ein Image anlegen *räusper* und im Anschluss die persönlichen Daten wieder zurückkopieren. Danke euch für die Unterstützung am Woende! Grüße Samoth
×
×
  • Create New...