BOfH_666

Ich denke auch, dass das nicht passieren wird und es ist auch nicht angekündigt oder so. Es hat aber niemand behauptet, dass der Code für Powershell kürzer wäre. Es ist sogar meistens eher das Gegenteil. Und das Meiste an diesem Beispiel ist der robocopy-Befehl und der muss ja in beiden Versionen quasi gleich sein. Durch die ausführlicheren Befehle ist der Powershell-Code aber für Menschen auch einfacher zu lesen und zu verstehen. Bei einem Befehl "Get-Content" oder "Get-Process" oder "Get-Service" braucht niemand raten, was die Befehle wohl machen könnten. Bei CMD/Batch-Befehlen die nur 2 Buchstaben lang sind, ist das schon ein bissl kniffliger. Und wenn es dann mit Optionen und Schaltern weitergeht, hat man meistens nur noch einen Buchstaben und Sonderzeichen machen es auch nicht besser ... also z.B. "/D %%t" ... wenn DU ehrlich bist, musst Du zugeben, dass das alles andere als intuitiv und verständlich ist - wenigstens am Anfang.

Du machst es Dir aber auch schwer. Wenn ich Dich richtig verstanden habe, möchtest Du eine IP-Range scannen und die antwortenden Computer mit deren Namen irgendwie weiterverarbeiten, richtig? Anstatt administrativ auf jeden Computer zuzugreifen und ihn dazu zu bringen, seinen eigenen Namen rauszurücken, wie beim Durchzählen beim Morgenappell, würde ich mir die in einem AD üblicherweise zur Verfügung stehende Infrastruktur zu nutze machen. Mit einem "nslookup <IP-Adresse>" löst Du per DNS die IP-Adresse zu einem Namen auf - also ein Reverse Lookup . Du müsstest die Info dann nur noch aus der Textausgabe "rausparsen"/"raus-greppen" ... In Powershell wäre das in diesem speziellen Fall etwas einfacher - ja ich weiß, das hörst Du nicht gern - da kann man auf die Attribute der von der Powershell zurückgelieferten Objekte zugreifen: 2..254 | ForEach-Object { $IP = "192.168.1.{0}" -f $_ if(Test-Connection -ComputerName $IP -Quiet -Count 1){ [PSCustomObject]@{ IP = $IP ComputerName = [System.Net.Dns]::GetHostEntry($IP).HostName } } } Probier's einfach mal - vielleiciht hilft's ja. ... und nicht wundern - je na Menge antwortender Computer in der angegebenen Range, dauert es eine Weile. Vielleicht machst Du zum Testen die Range einfach ein bissl kleiner ... also z.B. nicht 2..254 sonder nur 10..20 wenn Du weißt, dass es Computer gibt, die im letzten Oktett etwas zwischen 10 und 20 haben. Edit: Eine weitere Möglichkeit wäre es, einfach das AD abzufragen. Vorausgesetzt, das erforderliche Modul ist auf Deinem Administrationsrechner installiert (RSAT), kannst Du mit Get-ADComputer -Filter * -Properties IPv4Address | Select-Object Name,IPv4Address alle Computer mit ihren IP-Adressen auslesen.

Um bei Deiner Analogie zu bleiben: Ein geübter Holzfäller schafft es ganz leicht, sich mit seiner frisch geschärften Axt ein Brötchen zu schmieren. Schaffst Du es, mit einem Brotmesser einen Baum zu fällen? foreach ($Element in (Get-Content -Path .\local.txt)){ robocopy "$ENV:USERPROFILE\AppData\Local\$Element" "$PSScriptRoot\set\profile\$ENV:USERNAME\AppData\Local\$Element" /PURGE /B /E /R:0 /ZB>nul 2>&1 } Die Powershell ist am Ende des Tages ja trotzdem immernoch eine normale Shell und für einfache Aufgaben sind die Unterschiede zwischen den Shells nicht soo groß. Der Punkt - für mich - ist, dass die CMD/Batch bei komplexeren Aufgaben schnell kryptisch wird und an quasi unüberwindbare Grenzen stößt, wo die Powershell eben weitergeht. Aber so lange Du mit CMD/Batch zufrieden bist und zum Ziel kommst, kannst Du es ja auch weiter nutzen. MS wird Dir vermutlich keine Steine in den Weg legen. Ich glaube, dass ICH Dir die Grundlagen in einer halben Stunde vermitteln könnte.

Hmmm ... ich weiß ja nicht, warum Du Dich so gegen die deutlich modernere Technologie sträubst, aber ich fürchte, Du hast den eigentlichen Vorteil von Powershell noch nicht erkannt. Der wirklich nutzbringende Mehrwert von Powershell ist eigentlich gar nicht die "Power", die die Shell gegenüber CMD/Batch hat, sondern die sehr sehr viel flachere Lernkurve. Die Powershell ist nicht für Programmierer gemacht, sondern für Administratoren. Gerade für solche - nicht abfällig gemeint - Pille-Palle-Aufgaben wie hier in diesem Thread, brauchst Du keine krude gehirnverrenkende Syntax aus dem letzten Jahrtausend beherrschen. Die Grund-Idee von Powershell hast Du Dir innerhalb einer halben Stunde draufgeschafft und von da an geht es nur noch steil bergauf. Jeder, der ansatzweise der englishen Sprache mächtig ist, kann auch ohne langes Studium die Syntax von Powershell sehr einfach verstehen. Und wenn man dann erstmal die Grundlagen drauf hat, dann geht der Spaß erst richtig los, weil man sich jetzt mit der gleichen einfachen Syntax die richtig kniffligen Aufgaben vornehmen kann. Und nicht zuletzt bekommt man bei Problemen mit Powershell-Code schneller und mehr und meistens auch bessere Hilfe, weil sich auch viel mehr Menschen damit beschäftigen und sich mehr damit auskennen.

Mir fällt dazu auch nix Intelligentes ein, aber ich hätte eine Frage: Warum erstellst Du nicht einfach eine neue VM mit W10 quasi neben der W7 VM? Bei einem physischen Rechner verstehe ich ja noch den Wunsch nach dem Upgrade, auch wenn ich kein großer Fan davon bin, aber bei einer VM sollte es doch einfacher sein, oder?

Na ma kukn wer zuletzt lacht. ... irgendwann kommst Du an die Grenze, über die Du mit CMD nicht drüber kommst.

Hmmm ... verstehe ich das richtig - diese beiden Zeilen $result = Invoke-RestMethod -Method Get -Uri $url -ContentType "application/json ; charset=utf-8" -Headers $header -DisableKeepAlive $result = $result | Select-Object -ExpandProperty attr -Property URL erzeugen also ein Objekt mit den Properties "ip","prefixLen" und "url"? Wenn dem so ist, ist eine einfache Möglichkeit, eine weitere Property hinzuzufügen, eine sogenannte "calculated property" zu verwenden (erklärt in der Hilfe zu Select-Object Example #10). Um bei Deinem Beispiel mit dem Zufall zu bleiben .... $result = $result | Select-Object -ExpandProperty attr -Property URL, @{Name = 'ID'; Expression = { get-random -Minimum 1 -Maximum 100}} Ein besseres Beispiel ist vermutlich sowas hier: $result = $result | Select-Object -ExpandProperty attr -Property URL, @{Name = 'capitalizedURL'; Expression = { $($_.URL).toUpper()}} Du benutzt also einfach das aktuelle Pipeline-Element ($_), um damit in einem Scriptblock etwas anzustellen. Wenn's was komplexeres sein soll, lohnt sich's vermutlich, vorher dafür eine entsprechende Funktion zu bauen.

Wie erzeugst Du denn Dein Object? Zeig bitte Deinen Code. ... und wie willst Du die ID "berechnen"?

Im Zweifel ... auch wenn's 'n bissl schmerzt ... neu installieren. Mit der richtig Technik ist das in weniger als 30 Minuten erledigt. Die Störungssuche dauert gern mal deutlich länger.

Sind das bei Dir andere 64 bit?

Google findet das in weniger als einer Sekunde ... about_remote_troubleshooting

... oder Du steigst auf eine aktuellere und von allen Seiter besser unterstützte Scripting Technologie um .... Powershell.

... den User schon mal auf einem anderen System angemeldet? .... User-Profil schon mal erneuert?

Danke. Ich hatte irgendwie den Eindruck, dass MS bei solchen Fragen/Antworten fast nie ein Thema ist. Mein Kunde nutzt es noch nicht soo lange, aber bisher kamen auch noch keine Klagen.

Nur mal aus Neugier: Nutzt eigentlich niemand sonst die quasi integrierte Lösung von Microsoft - Exchange Online Protection?

Hmmm ... sieht bei mir ein bissl anders aus ... NAME Remove-LocalGroupMember SYNTAX Remove-LocalGroupMember [-Group] <LocalGroup> [-Member] <LocalPrincipal[]> [<CommonParameters>] Remove-LocalGroupMember [-Name] <string> [-Member] <LocalPrincipal[]> [<CommonParameters>] Remove-LocalGroupMember [-SID] <SecurityIdentifier> [-Member] <LocalPrincipal[]> [<CommonParameters>] ALIASE rlgm HINWEISE Die Hilfedateien für dieses Cmdlet können von "Get-Help" auf diesem Computer nicht gefunden werden. Es wird nur ein Teil der Hilfe angezeigt. -- Sie können die Hilfedateien für das Modul, das dieses Cmdlet enthält, herunterladen und installieren, indem Sie "Update-Help" verwenden. -- Wenn Sie das Hilfethema für dieses Cmdlet online anzeigen möchten, geben Sie Folgendes ein: "Get-Help Remove-LocalGroupMember -Online", oder gehen Sie zu "http://go.microsoft.com/fwlink/?LinkId=717989". ... ist in meinem Fall ein deutscher Windows Server 2016 Standard. Die Online-Hilfe sieht auch anders aus als bei Dir ... Remove-LocalGroupMember. ... sehr verdächtig ... Kann es sein, dass auf Deinem Server eine entsprechende Function nachinstalliert wurde, die die eingebaute quasi ersetzt?

Very strange! Dann schau doch bitte mal in die Hilfe: Get-Help Remove-LocalGroupMember

OK, dann lautet der korrekte Befehl ganz einfach Remove-LocalGroupMember -Group Administratoren -Member 'zu entfernende Gruppe oder zu entfernendes Kono'

Hmmm ... 'möchte nicht unhöflich sein, aber ... antwortest Du auch mal auf Nachfragen?

OK, das ist die Antwort zum zweiten Teil meiner Antwort. Was ist mit dem ersten Teil meiner Antwort? Kannst Du uns vielleicht den - um sensible Informationen bereinigten - Teil Deines Scriptes zeigen, der die Probleme verursacht? Ist es ein englischer Server oder ein deutscher?

Also laut doku heißt der Parameter vom cmdlet Remove-LocalGroupMember nicht -GroupName sondern -Group. Ausserdem ist es von Bedeutung, ob Du das cmdlet auf einem englishen oder deutschen Server startest - die Namen der Administrator-Gruppen unterscheiden sich in so einem Fall. "Administrators" <- vs. -> "Administratoren". Davon unabhängig - wenn die Administrator-Gruppe per GPO konfiguriert wird, kommt doch die Gruppe sowieso wieder rein, oder? Dann scheint mir die Aktion sowieso überflüssig. ... und die Fehlemeldung sieht danach aus, als würdest Du das cmdlet Remove-LocalGroupMember gar nicht benutzen.

<scnr> Das ist der allerneuste Schei? ... nennt sich "nested Virtualization" !!! </scnr>

Kommt da jetzt noch eine Scripting-Frage? Wenn nicht, ist das hier Off Topic. Mag mal ein Mod verschieben, bitte?

OK.