Samoth

vor 1 Stunde schrieb mba:

ändere die Größe der C-Partition

Geht das nicht nur, wenn hinter der Partition noch Speicher frei ist? Bei mir wäre direkt hinter C: noch die D: Partition auf der auch relevante Daten liegen.

vor 43 Minuten schrieb mba:

Welche Platte ist extern und welche intern beim klonen?

 

Empehlung neue Platte intern!

Habe schon beide Möglichkeiten ausprobiert. Aber aktuell folge ich deiner Empfehlung. Habe jetzt beim Klonen auch gleich die Inhalte der beiden HP Positionen (Tools und Recovery) ausgeschlossen. Das läuft jetzt erst mal wieder eine Zeit lang, ich halte euch auf dem Laufenden.

vor 24 Minuten schrieb MurdocX:

Das Tool benötigt übrigens beide Geräte online. Falls du 2 NVMe´s hast, brauchst du noch einen Adapter.

Die eine ist eingebaut, die andere hängt am USB-Adapter. So hab ich auch die ganze Zeit geklont.

vor 24 Minuten schrieb MurdocX:

Ganz ehrlich.. Die würde ich einfach vorher entfernen. 

Das wäre nun auch mein nächster Ansatz, sehe ich wie du. Ich würde die Partition vor dem ersten Boot wegschmeißen und schauen, was Windows daraus macht. Weißt du, ob man die Partition einfach löschen kann? Der Recovery Manager von HP ist nicht mehr installiert und bei HP steht, man kann die Partition löschen - im Normalfall hat sie anscheinend auch keinen Laufwerksbuchstaben.

Danke dir übrigens für den Support am Sonntag

Update bei meiner Analyse: Ich habe festgestellt, dass nach dem Klon die Partiton "HP_Recovery" einen Laufwerksbuchstaben unter Windows zugewiesen bekommen hat. Dort liegt auch eine Datei "bootmgr" - genauso wie auch auf Laufwerk C: Meinst du, es könnte da einen Konflikt geben, weil die Datei auf dem Klon an zwei Stellen verfügbar ist?

Samsung schaue ich mir an. Muss erst mal einen CD-Rohling finden, um ein Boot-Medium zu erstellen.

Danke für den Tipp! Ist da eine Software zum Klonen?

Ja, ist auch wieder eine Samsung. 

Hallo zusammen,

ich hänge hier gerade an einem Problem: Ein HP Probook 4720s soll eine neue SSD bekommen. 256 GB SSD --> 1 TB SSD. Ich habe das System nun mit Acronis und auch mit Paragon HDD Manager geklont. Im Anschluss startet Windows 7 Pro von der neuen SSD ganz normal. Danach wird ein Treiber für die SSD installiert (Meldung rechts unten in der Taskleiste) und ein Neustart wird gefordert.

Dieser zweite Start ist dann nicht mehr möglich. Vor dem Booten erscheint nur noch: "Non-System disk or disk error. Replace and strike any key when ready". Das Verhalten ist beliebig reproduzierbar, ich habe mittlerweile 4 Klone durch.

Das BIOS vom Notebook ist auf der aktuellsten Version.

Freue mich über Hilfe + sage schon mal Dankeschön!

Grüße

Samoth

vor 2 Stunden schrieb speer:

 

Puh, das ist eine richtig heftige Aussage! Da solltet Ihr beim Dienstleister mal auf den Tisch hauen! 

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

vor 4 Minuten schrieb NilsK:

s ist ziemlich sicher nicht der sinnvollste und effizienteste Weg, um die Client-Software zu aktualisieren (was man ja auch an den unnötigen Einträgen unter Programs and Features sieht), aber es sollte kein Schaden entstanden sein.

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.

vor 3 Minuten schrieb Sunny61:

Es gibt ODBC Treiber 11, 13, 13.1 und 17. Wenn du auf der Seite dessen Link du gepostet hast, ganz oben auf ODBC-Treiber herunterladen klickst, kommst Du auf die von mir verlinkte Seite. Andere Versionen vom ODBC Treiber gibt es wohl nicht.

Und genau (und nur) diesen ODBC-Treiber hätte ich aktualisiert - gemäß der SAP-Empfehlung.

Besten Dank euch!

Grüße

Samoth

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

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

vor 1 Stunde schrieb testperson:

Sorry, aber: Die Wunschvorstellung eures Kunden war vermutlich auch eher einen Dienstleister zu finden, der ansatzweise weiß was er tut. 

 

Hat irgendwer mal versucht, die Tipps hier aus dem Thread umzusetzen?

Evtl. mal die "setup.exe /?" oder "setup.exe /h" gestartet? Findet sich da evtl. etwas zu einem Parameter fürs Logging?

Hat der Hersteller evtl. einen Tipp zum Logging?

Das Setup tatsächlich einmal "$setupPID = Start-Process -FilePath "<Pfad zur >\setup.exe" -Arguments "/Product:"SAPGUI" /silent" -PassThru (evtl. auch mit -Wait)" so gestartet und sich dann die Rückgabewerte angsehen?

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?

vor 1 Stunde schrieb MurdocX:

Wenn ich über das Thema nochmal so nachdenke, dann kommt mir, dass ich die SAP-Gui immer lokal kopieren musste, weil der Installer Probleme mit Netzwerkdateien hatte.

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

Gerade eben schrieb NorbertFe:

Easy Going halt. :P

Haha, ja... das war die Wunschvorstellung :-/

vor 2 Stunden schrieb NorbertFe:

Was war noch mal der Grund für diesen Thread hier? 

Herauszufinden, warum die Installation under W7 genauso läuft wie wir es und vorstellen und warum das bei W10 nicht so stressfrei geht

vor 22 Minuten schrieb Sunny61:

Wenn Du einen SCCM zur Verfügung hast, dann ist das deine erste Anlaufstelle. Ohne wenn und aber.

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.

vor 1 Minute schrieb testperson:

Jetzt mal ehrlich: Ernsthaft?!

Verstehe ich nicht, sorry.

Gerade eben schrieb NorbertFe:

Wenns aber kein msi Paket gibt? :)

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

vor 1 Minute schrieb testperson:

Dann stelle ich doch jetzt mal die Frage, wie du denn das MSI Paket verteilen / installieren willst?

Ich erahne die Antwort schon und sage direkt: Nein, nicht per GPO! ;)

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.

vor 1 Minute schrieb Sunny61:

Kriegst Du denn von SAP eine MSI? Falls nicht, selber machen. 

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.

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?

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.

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

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

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

vor 48 Minuten schrieb tesso:

Gibt es von "extern" evtl. ein RDP Gateway dazwischen?

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.

Genau so melde ich mich in beiden Fällen an.

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