EmmKay

Das leuchtet ein. Daran hatte ich nicht gedacht.

Da war ich schreibfaul. Das Netzwerk: 10.50.215.0/24 Kannst Du mir es erläutert, warum es falsche Sicherheit vorgaukelt? Vorerst habe ich es so gelöst, dass ich die IP-Adressbereiche angegeben habe, für die diese Regel gelten soll. Das Schlüsselwort Internet scheint nicht zu funktionieren. Vielleicht funktioniert es nur mit klassischen privaten Netzen.

@All Für einige Systeme möchte ich den ausgehenden Verkehr ins Internet per Gruppenrichtlinie blockieren. Für diese Zwecke habe ich in einer Gruppenrichtlinie eine ausgehende Regel definiert, die alle Protokolle und Ports für den Bereich Internet blockiert. Sobald die Regel aktiv ist, hat das System keine Verbindung mehr zu Domäne. Der Domänencontroller befindet sich im selben Netz wie die betreffende Systeme. Lt. FW_ADDRESS_KEYWORD stellt das Schlüsselwort FW_ADDRESS_KEYWORD_INTERNET eine Sammlung von Adressen dar, die sich derzeit nicht im lokalen Intranet oder Remote-Intranet des Computers befinden. Wie sollte die Regel formuliert werden, dass die Kommunikation im lokalen Netzwerk funktioniert, aber der Verkehr für bestimmte Computer ins Internet blockiert wird? Das Netzwerk: 10.xxx.xxx.0/24

Vielen Dank für die schnelle Lösung. Auf das Naheliegendste bin ich nicht gekommen.

Leider habe ich bisher keine Cmdlets bzw. Möglichkeit gefunden, wie ich die Gruppenmitgliedschaften von gruppenverwaltetene Dienstkonten (gMSA) ermitteln kann. Ist die einzige Lösung in allen Gruppen nach dem gMSA zu suchen?

Unter Typsisien verstehe ich, dass ich der Variable bzw. dem Paramteter den korrekten Datentypen zuweise. In der Regel mache ich mir die Mühe, den "richtigen" Datentypen zu ermitteln. Hierfür verwende ich die Eigenschaft <Object>.GetType().Fullname oder schaue in die Online-.NET Dokumentation nach. Mir ist es schon wichtig den "richtigen" Datentypen zu verwenden. GPO-Objekt an eine Funktion übergebe, die einen [String] erwartet, und das übergebene GPO-Objekt fehlerfrei in eine Zeichenkette konvertiert werden konnte, dann fehlen mir alle Eigenschaften und Methoden des GPO-Klasse und ich habe "nur" noch eine Zeichenkette.

Ich dachte immer, dass es ein Muss ist, die Input-Parameter zu typisieren. Ich glaube, dass ich noch nie ein Beispiel ohne Parametertypisierung gesehen habe. Vielen Dank. Die using-Anweisung kannte ich nur im Zusammenhang, um eine lokale Variable in einem Remotebefehl zu verwenden.

@cj_berlin Vielen Dank für Deine ausführliche Erklärung. Man merkt sehr gut, dass bei der Entwicklung von PowerShell darauf geachtet wurde, Administratoren und Entwickler gleicher Maßen anzusprechen. Also muss ich als Entwickler der Funktion sicherstellen, dass der/die richtige(n) Rückgabetype(n) bei OutputType angegeben wird/werden. Eine Überprüfung findet (leider) durch den PowerShell-Interpreter nicht statt. Da ich in unserem Team der Einzige bin, der PowerShell nutzt, möchte ich möglichst viele Best Practice umsetzen und den Code möglichst sicher machen. Zum Beispiel typisiere ich bereits alle Variablen. Was leider etwas zur Lasten der Lesbarkeit geht, wenn die Typennamen besonders lang sind. Da muss ich noch einen vernünftigen Mittelweg finden.

Zur Zeit lese ich das Buch Building Better PowerShell Code. Im Kapitel 9 schreibt der Autor, dass man immer den Ausgabetypen einer Funktion definieren soll. Der tatsächliche Ausgabetyp kann sich doch von meiner Definition unterscheiden. Deshalb verstehe ich absolut nicht, warum diese Vorgehensweise empfohlen wird. Mich verwirrt es eher anstatt das es hilft, weil der Rückgabewert ein anderer sein kann als den ich erwarte. Vielleicht kann mir jemand erklären, warum die Definition eines Outputtyps zu den Best Practice gehört. Siehe auch Function Structure Beispiel aus dem Buch function Get-File { [OutputType([System.String])] param( [Parameter()] [string]$FilePath ) Get-Item -Path $FilePath } (Get-File -FilePath C:\foo.txt).GetType().FullName # Output: System.IO.FileInfo (Get-Command Get-File).OutputType.Name # Output: System.String (Get-File -FilePath C:\foo.txt).<tab> # Tabvervollständig listet die Eigenschaften und Methoden der Stringklasse auf

Danke für den Hinweis: Das hatte ich auch schon in Betracht gezogen.

Peinlicherweise habe ich den Fehler gefunden; Internet Explorer Enhanced Security Configuration war aktiviert. Zum Deaktivieren von Internet Explorer ESC habe ich bisher keine Einstellung in den Gruppenrichtlinien gefunden. Es doch richtig, dass ich die entsprechende Registierungseinträge per GPP setzen muss? Danke nochmal für Eure Hilfe.

Und wirkt sie auch? Dazu Internet Explorer starten, eine beliebige Datei auf dem Share öffnen (txt oder Dummy-html) und in den Eigenschaften nachschauen, in welche Zone die einsortiert wurde. Ist der einfachste mir bekannte Weg... Die Werte unterhalb von HLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings werden entsprechend gesetzt. Zusätzlich habe ich in der Gruppenrichtlinie den Einstellung Sicherheitszonen: Nur Computereinstellungen verwenden aktiviert. (Der Wert Security_HKLM_only i.d. o.g Schlüssel wurde auf 1 gesetzt.) Leider alles ohne Erfolg. Die geöffnete Dummyhtmlseite von NETLOGON wurde der Zone Internet zugeordnet. Nachdem ich die Gruppenrichtlinie wieder deaktiviere habe, um die Domäne manuell zur Zone Lokales Intranet hinzufügen, wird das Skript anstandslos ausgeführt und die Dummyhtmlseite auch der Zone Lokales Intranet zugeordnet. Der Dienst Application Identity läuft nicht. Ja. Das war ein Tippfehler im Forum. Vielen Dank.

Lt. Hilfetext zum GPO-Einstellung Liste der Site zu Zonenzuweisungen ist Intranet die Zone 1. Aber auch damit funktioniert es nicht bei mir.

Bei funktioniert es leider nicht. FQDN der Domäne (meine_domäne.de) mit dem Wert 2 in die Gruppenrichtlinie eingetragen. Die Zonenzuweisung wurde erfolgreich auf dem Testsystem aktualisiert. Evtl. hilft dieser Eintrag aus dem Anwendungs- und Dienstprotokoll Microsoft/Windows/PowerShell weiter: Wo wurde festgelegt, dass das Skript nicht ausgeführt werden kann. Ist damit die Ausführungsrichtlinie gemeint? Vielen Dank.

Ja. Das verwirrt mich immer wieder. Ich dachte immer, dass Get-ExecutionPolicy ohne Parameter die effektive Ausführungsrichtlinie anzeigt. Leider funktioniert es nicht. Die Domäne hatte ich bereits in der Zonenzuweisung eingetragen. Es ist doch richtig unter Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Internet-Explorer\Internetsystemsteuerung\Sicherheitsseite\Liste der Site zu Zonenzuweisungen Vielleicht sind die Einträge verkehrt? Dort steht: \\meine_domäne.de -> 1 file://meine_domäne.de -> 1 \\server -> 1 file://server -> 1 Danke schon mal.

@ALL Per Aufgabenplanung möchte ich ein PowerShell-Skript ausführen, welches in der NETLOGON-Freigabe abgelegt und zusätzlich signiert ist. Die Aktion der Aufgabe habe ich ich wie folgt angegeben. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NoExit -ExecutionPolicy ByPass -File \\meine_domäne.de\netlogon\myscript.ps1 -Path \\server\freigabe (Parameter -NoExit NUR für Testzwecke) Die PowerShell-Konsole gibt mir folgende Sicherheitswarnung aus: Führen Sie ausschließlich vertrauenswürdige Skripts aus. Skripts aus dem Internet .... Wenn Sie diesem Skript vertrauen, lassen Sie mit dem CmdLet "Unblock-File" die .... Möchten Sie "\\meine_domäne.de\netlogon\myscript.ps1" ausführen? .... Unblock-File habe ich für das Skript ausgeführt. Get-Item myscript.ps1 -Stream 'zone.identifierr' -ErrorAction SilentlyContinue gibt mir auch nichts zurück. Die Auflistung der Ausführungsrichtlinien für die unterschiedlichen Bereiche sieht wie folgt aus: MachinePolicy -> Unrestricted UserPolicy -> Undefined Process -> ByPass CurrentUser -> Undefined LocalMachine -> RemoteSigned Die effektive Ausführungsrichtlinie wäre dem nach Unrestricted. Wie kann ich das Skript per Aufgabenplanung aus der NETLOGON-Freigabe ohne Bestätigungsaufforderung ausführen? Für eine Lösung wäre ich sehr dankbar.

Einfach getraut, die o.g. Einstellung auf einem Testsystem mit einem Testbenutzer anzuwenden. Die o.g. Registry-Einträge werden zurückgesetzt und verweisen wieder auf den lokalen Pfad. Das hat aber leider einen Seiteneffekt zur Folge: Die Startmenüeinträge werden jetzt mit Neu beschriftet. Wie kann diese Beschriftung unterdrückt werden? Eine Gruppenrichtlinieneinstellung habe ich bisher nicht gefunden.

Erledigt

Kurze Verständnisfrage: Um die Ordnerumletung rückgängig zu machen. muss ich folgende Einstellung setzen, richtig? Müssen die Einträge Administrative Tools, Programs, Start Menu und StartUp in dem Registrierungsschlüssel HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders noch besonders behandelt werden, oder reicht die obige Einstellung? Vielen Dank für Eure Hilfe.

Vielen Dank. Dein Beitrag ist sehr aufschlussreich. Bei uns werden die Startup- und Login-Skripte nur in Ausnahmenfällen eingesetzt und benötigen keine zusätzlichen Informationen aus Active Directory. Grundsätzlich werden in unserer Umgebungen die Einstellungen per Group Policy Preferences konfiguriert. Aber Du hast recht, dann würde ich entweder das COM-Objekt ADSystemInfo oder die System.DirectoryServices-Klassen im Skript verwenden. So eine große Umgebung haben wir nicht. Höchstens 300 Rechner. Die AD-RSAT sind sich nur auf die Admins-Clients installiert.

Bei der Verwendung der CmdLets habe ich nie auf Geschwindigkeit geachtet. Da muss ich mir mal einen Test überlegen. Die nativen Array finde ich auch eher umständlich und habe mich deshalb regelmäßig an Klassen aus dem System.Collections-Namespace bedient. Ich dachte, dass Klassen aus dem System.DirectoryServices-Namensraum nur die ADSI-COM-Objekte kapseln und (leider) nur allgemeine Klasse wie DirectoryEntry oder DiretoryEntries zurückliefern und dass das ActiveDirectory-Modul hier Abbhilfe schafft. Ein Get-ADUser liefert mir erwartungsgemäß auch ein ADUser-Objekt zurürck. Den einzigen Vorteil bei der Verwendung von DirectoryServices-Klassen sah ich nur darin, dass ich Remote Server Administration Tools nicht installiert musste. In der Regel ist die ADSI-COM-Komponete überall installiert. Ich hatte auch eher verstanden, dass diese CmdLets schlecht implementiert sind. Zum Glück gibt es in unserer Umgebung nichts, was performancekritisch ist. Was meinst Du mit Komplementärdisziplin und Portabilität? Gibt es PowerShell-Bücher, die die zugrundeliegenden .NET-Techniken tiefer erklären oder muss ich ein Buch über das .NET-Framework lesen? Könnt Ihr mir weiterführende Literatur empfehlen?

In seinem Beitrag 7 Mythen über PowerShell 7 behauptet Herr Butz, dass der Filesystem Provider Schrott ist und deshalb die Hardcore User andere Methoden verwenden. Warum ist der Dateisystemanbieter Schrott und welche Alternativen werden verwenden? Kann die Aufgabe mit nativen PowerShell-Befehle und -Techniken gelöst werden, sollen laut PURE-01 Use native PowerShell where possible keine COM- oder .NET-Klassen verwenden werden. Außer es wird gemäß PURE-03 Document why you haven't used PowerShell dokumentiert, wenn man von der Empfehlung PURE-01 abweicht. Gerne möchte ich PowerShell über mein Einstiegsniveau verstehen und anwenden. Vielen Dank für Eure Erklärung.

Die Option musst natürlich ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL heißen. Danke für den Hinweis. Vielen Dank auch für den TIpp mit der Protokollierung der Installation. Die Protokolle hatte ich mir nie so genau angeschaut, weil bisher jede Installation problemlos durchlief und ich bisher noch keine Transformdaeien eingesetzt habe. Es ist sehr interessant, was bei der Installation so passiert. Leider verstehe ich noch nicht alles und werde mich da weiter reinknien. Wie kann ich mir nur die Differenz beider Protokolldateien gezielt anzeigen lassen? Beide Dateien, jeweils fast 10.000 Zeilen, habe ich manuell durchsucht. Für jeden TIpp bin ich dankbar.

@Community Unhängig von dem Beitrag Warum PowerShell? möchte ich gerne die Installation von PowerShell mittels einer Transformdatei (*.mst) anpassen. Leider werden ncht alle Einstellungen gesetzt oder ich weiß nicht, wie ich die Einstellung überprüfen kann. Mir ist bekannt, dass die Einstellungen als Parameter an die Installationsroutine übergeben werden kann. Die Optionen sollen aber per mst-Datei gesetzt werden. Folgende Einstellungen möchte ich anpassen und habe die fehlenden Einstellungen in der Tabelle Property hinzugefügt: Nach der Installation mit der Transform-Datei .... Der Einstellung ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL wird nicht umgesetzt. Auch habe ich keine Ahnung wie ich die Einstellungen für die Optionen Enable updating PowerShell throught Microsoft Update (ENABLE_MU) und Use Microsoft Update when I check for update (USE_MU) überprüfen kann. Anbei findet Ihr meine Transform.Datei. Bitte diesen Beitrag gerne verschieben, wenn er an einen anderen Stelle besser aufgehoben ist. Danke für Eure Hilfe. Transform.mst.txt

Ein sehr interessanter Beitrag. Was jetzt vielleicht doch für die Installation von PowerShell spricht ist, dass man manche mitglieferten Module in Windows PowerShell nutzen kann. Das war mir vorher nicht bewu8t.