Jump to content

Samoth

Members
  • Content Count

    306
  • Joined

  • Last visited

Community Reputation

10 Neutral

1 Follower

About Samoth

  • Rank
    Member
  1. Ich wollte es eben auch mal thematisieren. Befürchte nur, dass dann eben eine Aussage wie "Macht doch nichts - wir haben ja nun den passenden Versionsstand und das wollten wir doch." Und viel mehr als das Argument "Wir machen es so, weil es in der SAP-Empfehlung steht" hätte ich eben auch nicht. Daher der Meinungsaustausch hier
  2. Top! Danke für die Antwort, Nils So hätte ich es auch eingeschätzt und grundsätzlich bin ich eben kein Freund von unnötigen Installationen. Und genau (und nur) diesen ODBC-Treiber hätte ich aktualisiert - gemäß der SAP-Empfehlung. Besten Dank euch! Grüße Samoth
  3. Hi Squire, doch, doch... wir haben einen Server auf dem exklusiv der Server inkl. DB läuft. Und genau auf dieser Maschine habe ich das SP3 für den SQL-Server eingespielt. Die anderen beiden Maschinen greifen letztlich nur per DB-Client/Netzwerk auf diesen DB-Server zu. Auf diesen Maschinen ist keine DB und auch kein SQL-Server installiert und dort wurde jetzt eben (ohne unsere Kenntnis) das SP3 für SQL-Server eingespielt, obwohl die SAP-Empfehlung anders lautet. Das hat (warum auch immer) funktioniert, aber die Frage ist eben ob das nun eine riskante Aktion war. Das Update muss ja auch nach einer gewissen Testphase in die produktive Umgebung. Grüße Samoth
  4. Guten Morgen zusammen, ich wollte mal auf euer Wissen und Erfahrung zurückgreifen: Wir mussten aufgrund einer Fehlersituation in einem SAP-System (DB-Server, Zentralinstanz und zusätzlicher Applikationsserver = 3 getrennte VMs) das Service Pack für den SQL-Server aktualisieren. Haben wir auf dem DB-Server auch gemacht. Nun gibts von SAP folgende Info: "After applying the Service Pack / Cumulative Update on SQL Server, do I need to run any procedure on the SAP application servers? Yes, you might need to update the client software on every host that runs a Dialog Instance. You can download the most recent SQL Server Native Client or ODBC Driver for SQL Server from Microsoft download website. You can follow up the Microsoft ODBC Driver for SQL Server on Windows page on MSDN." Verlinkt wir dann hier auf die folgende Seite: https://docs.microsoft.com/en-us/sql/connect/odbc/windows/microsoft-odbc-driver-for-sql-server-on-windows?view=sql-server-2017 Ich hätte nun auf den beiden Servern, auf denen nicht die DB läuft, nach dieser Empfehlung gehandelt. Jetzt wurde auf diesen beiden Maschinen jedoch das "SQLServer2014SP3-KB4022619-x64-ENU.exe" (also das Service Pack 3 für SQL Server) installiert. Ich hätte nicht gedacht, dass man das SQL SP auf einer VM ohne SQL-DB installieren kann. Unter "Programs and Features" finden sich nun die drei Punkte mit dem gleichen Versionsstand: - MS SQL Server 2014 Setup (Englisch) - Microsoft ODBC Driver 11 for SQL Server - Service Pack 3 for SQL Server (KB4022619) Frage: Ist es problematisch/kritisch/riskant/... ein SP auf einem Server zu installieren auf dem gar keine DB läuft oder ist es letztlich einfach nur egal? Grüße + Danke euch! Samoth
  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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
  12. 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
  13. 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
×
×
  • Create New...