BOfH_666

Wow. Respekt. Also bei der Reaktionszeit - und nicht nur da - macht Euch echt absolut niemand etwas vor. Ein riesengroßes Dankeschön für euren Einsatz.

OK, dann versuche ich mal, das Ganze in Prosa zusammenzufassen: Ihr habt eine Software, die für jeden Nutzer einzeln eine Datei irgendwohin verschickt, die für einen Validierungsprozess benötigt wird. Als Antwort für die einzeln verschickten Dateien, erhaltet ihr eine zusammengefasste Antwort-Datei, die die gesammelten "Antwort-Datensätze" für die einzelnen Anwender enthält. Diese zusammengefasste Antwort-Datei muss jetzt in einem manuellen, externen, aufwändigen Prozess so aufbereitet werden, dass sie von den einzelnen Anwendern wieder als Abgleich verwendet werden und vom Programm eingelesen werden kann. Ist das erforderliche Format irgendwie dokumentiert? Hab ich das soweit richtig verstanden? Habt Ihr für die Software Geld bezahlt? Falls ja, würde ich entweder auf Minderung des Preises oder auf Nachbesserung bestehen. ... mal ernsthaft, wenn das so ist, kann das nicht im Sinne des Erfinders sein. Achso ... wenn CSV-Dateien nicht gehen, änderst Du einfach die Endung auf txt und hängst die Datei so an. Mal so aus Neugier an einen Mod (falls einer mitliest): warum sind CSV-Dateien nicht erlaubt?

Neeee ... ob der Abgleich bei den Usern manuell erfolgt. Wenn die Anwender die XML-Datei einfach öffnen und mit ihren eigenen Äuglein reinschauen, um den Abgleich durchzuführen, dann wäre es meiner Meinung nach fast besser, wenn es keine XML-Dateien wären. XML-Dateien sind nicht für Menschen gemacht. (höchstens für Sadisten und Masochisten )

... und meine erste Frage?

Bitte nicht falsch verstehen ... ich bin nicht unwillig, oder so zweifle Deinen angestrebten Workflow an. Ich finde die Arbeit mit XML und Powershell nur alles andere als intuitiv und einfach und versuche deshalb, für mich so weit wie möglich zu vermeiden, wirklich mit XML arbeiten zu müssen ... also sorry dafür. Tut er das manuell? Also öffnet der User die Datei und schaut für den Abgleich hinein? Wenn das so ist, muss es ja nicht zwingend eine valide XML-Datei sein, oder? Es würde eine Text-Datei genügen, die die nötigen Informationen enthält. Was würde passieren, wenn man nur eine Datei zum validieren versenden würde? Vielleicht kann man das Aufsplitten in einzelne User-Dateien ja vermeiden, wenn man dem Validator nur einzelne User-Dateien verfüttert!? Und diese Zuordnung von User zu Nummer liegt nur in einer XLS-Datei vor? Eine CSV-Datei wäre für Powershell ein wenig einfacher zu verarbeiten.

hmmm ... ok, und was macht der User dann damit? Nimmer er einen Editor und schaut rein? Wer erstellt die XML-Files zur Validierung? Warum kommt nur eine Response-Datei zurück und nicht für jeden User eine? Woher kommen die Nummern für jeden User? ... vielleicht aus dem AD?

Hmmm ... das hatte ich verstanden, aber wozu? Was willst Du mit den neu erzeugten Dateien anstellen? Genau genommen brauchst Du die Schleife bei Powershell nicht mal. Wenn Du die ID's nur ausgeben willst, reicht auch das hier: $StatXmlData.SctiesFincgRptgTxStatRpt.TradData.ChildNodes

Ich bin weit davon entfernt XML wirklich zu verstehen. Und ich bin noch viel weiter davon entfernt, ein Fan von XML zu sein. Wenn irgendwie möglich mache ich einen riesengroßen Bogen um XML. So ... da das XML-Schnipselchen, welches Du gepostet hast, kein valides XML ist und man es so nicht verwenden kann, hab ich es mal auf etwas Benutzbares eingekürzt. <?xml version="1.0"?> <SctiesFincgRptgTxStatRpt> <TradData> <Stat> <TechRcrdId>ERTHUTDREPxxSCDxxSFTRxxSFTxx487331</TechRcrdId> </Stat> <Stat> <TechRcrdId>WKTHUTDREPxxSCDxxSFTRxxSFTxx487335</TechRcrdId> </Stat> <Stat> <TechRcrdId>KRTHUTDEKDxxSCDxxSFTRxxSFTxx487339</TechRcrdId> </Stat> </TradData> </SctiesFincgRptgTxStatRpt> Angenommen, wir haben das in der Datei D:\sample\test.xml gespeichert, können wir mit folgendem Code die einzelnen TechRcrdId's auslesen. $StatXmlData = [xml](Get-Content D:\sample\test.xml) $node = $StatXmlData.SctiesFincgRptgTxStatRpt.TradData.ChildNodes foreach ($entry in $node){ $entry } Was möchtest Du denn mit den extrahierten Daten anstellen? Hier noch ein bissl Lektüre zum Thema XML mit Powershell: https://www.petri.com/creating-custom-xml-net-powershell oder hier: https://searchwindowsserver.techtarget.com/tip/Using-PowerShell-to-create-XML-documents oder hier noch was vom Dr. Tobias: https://www.powershellmagazine.com/2013/08/19/mastering-everyday-xml-tasks-in-powershell/

.... is so.

Hmmm ... ich kann Dir nicht sagen, wie Du das mit dem Skript hinbekommst, aber ich kann Dir sagen, dass Du GPOs auch zum Dateien kopieren benutzen kannst ... ganz ohne Skript. Computer Configuration -> Preferences -> Windows Settings -> Files oder User Configuration -> Preferences -> Windows Settings -> Files

Hmmm .... das sollte mit einer VM genau so gehen, wie mit einem physischen Server. Du kannst dann nur nicht mehr per RDP drauf zugreifen. Du solltest aber vom Hypervisor eine "Konsolen-Session" starten können und so darauf zugreifen können.

Hmmmm ... das glaube ich nicht. Ohne die Option /MT läuft robocopy im Single Thread Modus. Mit Option /MT aber ohne Angabe einer Anzahl werden 8 Threads bentutzt. Mit der Option /MT mit einer Zahl zwischen 1 und 128 werden die angegebenen Threads benutzt. Jedenfalls laut der robocopy Hilfe.

Ist der Performance-Gewinn durch die /MT Option denn wirklich so hoch, dass ihr darauf nicht verzichten könnt/wollt?

Hast Du denn verifiziert, dass es auch wirklich an robocopy liegt? Hast Du mal versucht, die betroffenen Dateien mit einem anderen Tool - notfalls einfach mit dem Windows-Explorer - zu transferieren? Es ist ziemlich unwahrscheinlich, dass robocopy nur einen bestimmten Dateityp nicht korrekt kopiert. Hast Du die Dateien in Quelle und Ziel mal per Check-Summe geprüft/verglichen? Mit Powershell Get-FileHash brauchst Du nicht mal ein externes Tool.

Hier noch mal der Tipp, den Code etwas einfacher lesbar zu machen ... $CredPassword = ConvertTo-SecureString "aaaaa" -AsPlainText -Force $cred = New-Object System.Management.Automation.PSCredential "bbbbb", $CredPassword $SenMailParams = @{ To = '1234@5678.de' Subject = 'HyperV-Replica Alarm' Body = Get-Content $Info_Datei | Out-String SmtpServer = 'ddddd' From = 'Admin@ccccc' Credential = $cred } Send-MailMessage @SenMailParams Der Code macht das Gleiche wie Dein Code ... es ist, wie ich glaube, nur einfacher zu lesen. Der SMTP-Port ist im Standard sowieso 25. Den musst Du nur angeben, wenn er NICHT 25 ist. Kannst Du diesen Schnipsel denn von dem Rechner aus erfolgreich ausführen, von dem das Script laufen soll?

Das hättest Du in Deiner initialen Anfrage gern mit erwähnen dürfen. Es macht meistens schon Sinn, wenn die Helfer wissen, worum es eigentlich geht. z.B. Wenn Du anfragst, ob jemand eine Idee hat, warum sich Deine Auto so langsam bewegt. So eine Forumsanfrage würde bestimmt wahnsinnig viele Rückfragen und Vermutungen produzieren. Wenn Du aber gleich mitgeschrieben hättest, dass Du Dein Auto bisher nur von außen schiebst, weil Du nicht weißt, wie man das richtig macht und auch schon Freunde gebeten hattest, Dir beim Schieben zu helfen, hättest Du vermutlich viel schneller die Antwort erhalten, dass man sich in ein Auto auch reinsetzen kann und sich das dann quasi von alleine bewegt.

Dann haben unsere Firmen wohl eine sehr unterschiedliche Clientel. ... und das "nicht viele" ist dann aber auch eher "Deine Wahrnehmung". Davon gibt es ne Menge. ... das wär ja auch langweilig, oder?

So lange es vom Hersteller nicht supportet ist, bleibt Dir sowieso nur Ausprobieren und Daumen drücken. ... aber selbst wenn es im Großen und Ganzen funktionieren sollte, bist Du bei Problemen doch wieder auf Dich gestellt. Der Hersteller wird mit hoher Wahrscheinlichkeit den Support verweigern. Ich bin eher in Umgebungen unterwegs, wo die Anwender sowieso mit "Fat-Clients" unterwegs sind und eine gut funktionierende Softwareverteilung existiert und das Arbeiten vom "Nicht-Firmen-Client" sowieso nicht erlaubt wäre. Deshalb packt die ganze RDS-Geschichte meiner Meinung nach eine riesen Schippe Komplexität oben drauf, die ich für eher nicht erstrebenswert halte.

... ist aber in "freier Wildbahn" Gang und Gäbe und funktioniert üblicherweise für alle Applikationen, die aktuellen Programmierparadigmen entsprechen und die ihre "Userdaten" auch im Userprofil ablegen. Was ich mich immer frage, warum ich Applikationen per RDS zur Verfügung stellen möchte und nicht, wie vom Hersteller vorgesehen auf einem Client installiere ... im Idealfall per Softwareverteilung verteilt!?

Die eigentliche Antwort auf diese Frage, hat Dir Jan ja schon gegeben, aber sind denn in diesem Fall überhaupt zwei separate Abfragen nötig? Ich hab keine VMWare-Umgebung zur Verfügung aber es sieht für mich, danach aus, als sollte folgender Schnipsel genügen ... Get-VM XYZ* | Select-Object Name, PowerState, @{ N = "ToolsVersion"; E = { $_.Config.Tools.ToolsVersion } }, @{ N = "ToolStatus"; E = { $_.Guest.ToolsVersionStatus }}

Auch wenn das Thema hier off topic ist ... ich gehe mal davon aus, dass Du die Dateinamen geändert hast, richtig? Und diese Änderungen zeigt dieser dumme Mediapayer jetzt nicht an, richtig? Hast Du schon mal was ID3-Tags oder MP3-Tag gehört? Lad Dir mal bitte das kleine Progrämmchen https://www.mp3tag.de runter - lies die Doku - lies die Doku nochmal - und dann kannst Du die gewünschten Änderungen durhcführen. Viel Spaß und n' netten Sonntagabend noch!

... wie immer ... es kommt darauf an. Was kann denn schon groß schiefgehen, richtig? Die Microsoft-Produkte und eingebauten Features sind mit hoher Wahrscheinlich eher unkritisch, aber wenn 3rd-Party-Software und Treiber im Spiel sind, ist ausgiebiges Testen sehr empfehlenswert. Was kostest es Dich/Deine Firma, wenn nach dem Upgrade irgendwas für Euer Business Essenzielles crasht? So lange alle eingesetzte Hard- und Software noch vom jeweiligen Hersteller supported wird und die gewünschten/vom Business geforderten Funktionalitäten liefert, spricht Nichts gegen einen Weiterbetrieb. Übrigens: der Support für Server 2012R2 endet in 2023.

Hmmm .... na klar sagt Microsoft, dass Du das Betriebssystem von 2012R2 auf 2019 upgraden kannst. Microsoft kann Dir aber bestimmt nicht garantieren, dass danach alles (was vielleicht auch nicht alles Microsoft stammt) genau so läuft, wie man sich das wünscht. Mit der Evaulierungsversion solltest Du einen Test-Server erstellen und mit diesem dann alles das testen, was auf dem alten System läuft - dafür ist eine Evaulierungsversion da. Wenn das alles läuft, kannst Du Dir eine Lizenz und ein entsprechendes Installationsmedium besorgen und das "richtige" Upgrade druchführen ... und Daumen drücken, dass dann immernoch alles so läuft, wie man sich das wünscht.

Du möchtest also Deinen produktiven Server 2012R2 mit einer Evaluierungsversion upgraden?

hmmmm ....