BOfH_666

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

<SCNR> "schick" und "Einzeiler" .... uuuuhhh ... da schüttelt's mich ... </SCNR>

(Select-String -Path 'Pfad zu Deiner Text-Datei' -Pattern '(?<=Phone).+(?=$)' | Select-Object -ExpandProperty Matches).Value

Supi. Markier doch bitte den Code-Schnipsel noch als Lösung. Dann finden andere, die das gleiche oder ein ähnliches Problem haben, die Lösung hoffentlich ein wenig schneller. Danke.

Hallo Puschkin, wir liefern hier üblicherweise keinen gebrauchsfertigen Code auf Anfrage. Du wirst Dir schon selbst ein bissl Mühe geben müssen. Hast Du denn schon mal gesucht, ob Du was Passendes finden kannst. Meistens ist man ja nicht der Erste, der nach einer Lösung sucht. Wofür brauchst Du denn überhaupt so etwas Altertümliches? 2020 sollten doch etwas längere Pfade kein Problem mehr sein.

Du machst es Dir aber auch schwer ... $CimSession = New-CimSession -ComputerName 'Print01' -Credential $Credentials Get-CimInstance -CimSession $CimSession -ClassName Win32_Printer | Select-Object -Property ShareName | Out-File C:\Drucker\Printer_List.txt Remove-CimSession -CimSession $CimSession Um die Probleme zu umgehen, dass es quasi keine einfache Möglichkeit gibt, Credentials sicher für die Benutzung in Scripten zu speichern, könntest Du einfach die Aufgabenplanung benutzen. Du erstellst eine entsprechende Aufgabe mit den nötigen Anmeldedaten und führst diese bei Bedarf aus. Dann lässt Du den ganzen Credentials-Kram im Script einfach weg.

... und Get-WmiObject sollte auch nicht mehr benutzt werden. Es gibt das moderne Get-CimInstance ... meistens auch noch schneller ... und mit dem Parameter -ComputerName kannst Du das auch remote benutzen ... ohne Invoke-Command.

... nur ein kleiner Tipp, um Deinen Code leichter lesbar zu machen. Bei cmdlets, die ziemlich viele Parameter erfordern oder verdauen, liest sich der Code leichter, wenn man Splatting benutzt ... so ungefähr: $SendMailProps = @{ To = 'empfaenger@maildomain.tld' Subject = 'HyperV-Replica Alarm' Body = Get-Content -Path $Info_Datei | Out-String SmtpServer = $Mail_Server From = $Mail_Absender } Send-MailMessage @SendMailProps Hier was zum Nachlesen: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_splatting?view=powershell-7

oooops ... hihihi ... hier ... nimmste das "h" ... und falls in Zukunft mal wieder ewtas fehlt ..... "abcdefghijklmnopqrstuvwxyz" ... nimmste Dir dann, was'de brauchst.

Jaaa .... wenn ein LKW gegen enen flotten offenen Sportwagen antritt, hat er halt mal Pech.

... 'kenn ich auch so. Und wer zuerst kommt und malt zuerst, oder?

Dienste werden doch nicht vom Domänen-Admin gestartet.

Wenn ich die Doku richtig verstehe, liefert es die "Settings" der VM mit dem angegebenen Status. Gib den Befehl doch einfach mal auf der Konsole ein und sieh, was Du als Ausgabe erhältst. Wenn da kein "$true" dabei ist, wird's nix.

Hier noch 'n bissl Extra-Lektüre : Use PowerShell delete a user profile (step-by-step guide) - https://adamtheautomator.com/powershell-delete-user-profile/

hhhmmmm .... warte mal .... aber man kann die Denkfehler im Code manifestieren ...

Du hast Tippfehler und Denkfehler in Deinem Code. foreach ($element in $object) { Invoke-RestMethod -Method Post -Uri $element.url -Body $element.body -Headers $element.header -OutFile .\log_$($element.body).out } Mit diesem Schnipsel schreibst Du jeden einzelnen "output" in eine eigene Datei. Wenn alles in einer Datei landen soll, musst Du diesen Export außerhalb der Schleife erledigen. Du könntest erstmal allen Output in einer Variable einsammeln und das dann gesammelt in eine Datei exportieren ... so ungefähr: $Result = foreach ($element in $object) { Invoke-RestMethod -Method Post -Uri $element.url -Body $element.body -Headers $element.header } $Result | Out-File -FilePath .\log.log