Tag-Archiv für » powershell «

27 | 07 | 2019

PowerShell Gallery ansprechen hinter einem Proxy

Geschrieben von um 11:14 Uhr

Es ist kein wirklich neues Ergebnis, aber ich möchte es zur Erinnerung hier festhalten.

Wer sich in der Situation wiederfindet, hinter einem authentifizierungspflichtigen Proxy PowerShell-Module aus der Gallery (oder anderen externen PowerShellGet-Repositories) finden und installieren zu müssen, kann leider nicht darauf bauen, dass man den entsprechenden Cmdlets vermitteln kann, dass ein Proxy im Weg ist.

Stattdessen muss man die gesamte Sitzung zur Nutzung des Proxy befähigen. Das geht mit drei Zeilen Code, die man – je nachdem, wie das Verhältnis zwischen Komfort und ParanoiaSicherheitsbewuisstsein ausgeprägt ist – entweder als Skript aufruft oder in sein PowerShell-Profil schreibt. An Letzteres kommt man mit

Start-Process notepad.exe -ArgumentList $Profile.CurrentUserCurrentHost

oder, falls man VSCode im Standardpfad installiert hat, mit

Start-Process "C:\Program Files\Microsoft VS Code\Code.exe" -ArgumentList $Profile.CurrentUserCurrentHost

Das Profil ist übrigens getrennt für PowerShell.exe und PowerShell_ISE.exe – die Variable $Profile wird unterschiedliche Werte in den beiden hostspezifischen Eigenschaften „CurrentUserCurrentHost“ und „AllUsersCurrentHost“ haben.

Folgender Code gehört also ins Profil:

[system.net.webrequest]::defaultwebproxy = new-object system.net.webproxy('http://proxy.domain.net:3128')
[system.net.webrequest]::defaultwebproxy.BypassProxyOnLocal = $true

Je nachdem, ob der Proxy die PassThrough-Authentifizierung der Windowssitzung nutzt oder eine explizite Authentifizierung verlangt, muss der Aufruf noch durch

[system.net.webrequest]::defaultwebproxy.credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

bzw.

[system.net.webrequest]::defaultwebproxy.credentials = New-Object PSCredential('proxyuser',('proxypassword' | ConvertTo-SecureString -AsPlainText -Force)) 

ergänzt werden.
Happy NuGetting!

Tags » , , «

+

27 | 07 | 2019

Ich werde auf dem PSDAY.UK am 28.09. sprechen

Geschrieben von um 10:45 Uhr

Am 28.09.2019 findet in Birmingham der diesjährige PSDAY.UK statt. Ich habe die Ehre, zu den ausgewählten Speakern zu gehören und den Saal für Richard Siddaway vorzuwärmen.

Übrigens: Es gibt noch Tickets, sowohl PSDAY-Tickets als auch Flugtickets 😉

Tags » , , , , «

+

02 | 04 | 2019

AD User mit ausgeschalteter Vererbung der Rechte finden mit PowerShell – revisited

Geschrieben von um 15:15 Uhr

Vor sieben Jahren habe ich mal hier beschrieben, wie man schnell alle User mit ausgeschalteter Rechtevererbung findet. Damals war das Quest AD-Modul (aus ActiveRoles) das Mittel der Wahl, welches mittlerweile nicht mehr (kostenlos) verfügbar ist. Hier ein Code Snippet, um das gleiche mit dem nativen AD-Modul des Windows Servers zu erreichen:

$users = Get-ADUser -LDAPFilter "(mail=*)"
foreach ($user in $users) {
    $adsu = [ADSI]"LDAP://$($user.DistinguishedName)"
    if ($adsu.PSBase.objectSecurity.AreAccessRulesProtected) {
        $user.DistinguishedName
    }
}

Das Zurücksetzen der Vererbung ist etwas komplizierter als bei Quest und benutzt den AD-Provider aus dem Modul:

$users = Get-ADUser -LDAPFilter "(mail=*)"
foreach ($user in $users) {
    $adsu = [ADSI]"LDAP://$($user.DistinguishedName)"
    if ($adsu.PSBase.objectSecurity.AreAccessRulesProtected) {
        $acl = Get-ACL "AD:\$($user.DistinguishedName)"
        $acl.SetAccessRuleProtection($false,$false)
        Set-ACL -ACLObject $acl -Path "AD:\$($user.DistinguishedName)"
    }
}

Man sollte im Hinterkopf behalten, dass bei Mitgliedern in Admin-Gruppen diese Änderung durch AD wieder zurückgerollt werden wird (Stichwort AdminSDHolder), und bei produktivem Einsatz vielleicht eine Prüfung einbauen.

Happy migrating!

Tags » , , , , , «

+

09 | 03 | 2019

Windows Server User Group Berlin: Die Agenda für 21.03. steht fest

Geschrieben von um 11:43 Uhr

Die Agenda des anstehenden User Group-Treffens am 21. März steht nun fest. Alle Details und Anmeldung wie immer auf Meetup. Es sind noch Plätze frei!

Tags » , , , , , , «

+

19 | 09 | 2018

PSConf.EU 2019 – Call for Papers ist offen!

Geschrieben von um 9:46 Uhr

Ab heute (und bis zum 09.12.2018) können Vorträge für die PowerShell Konferenz 2019 in Hannover eingereicht werden: HIER.

Also los, Community – reicht eure Themen ein, Hannover wartet!

Tags » , , , , «

+

10 | 09 | 2018

PowerShell Quirks: Values aus der Pipeline, Object Edition

Geschrieben von um 17:51 Uhr

Heute gab es mal wieder eine interessante Frage im TechNet-Forum. Das wollte ich mal näher untersuchen. Es ging darum, dass beim Pipen eines Objektes nach New-Item der Inhalt des erstellten Items das gesamte Objekt, aufgedröselt als Hashtable, enthielt. Im Thread war es eine Datei, aber mit dem Registry-Provider funktionierte es genau so. Das interessante am Value-Parameter ist, dass er Argumente nicht nur nach Namen, sondern auch nach dem Wert bindet:

Doch ist es nur eine Eigenart von New-Item oder ist das Verhalten generell so? Schreiben wir mal eine kleine Funktion, die ihre Argumente, falls sie aus der Pipeline angeflogen kommen, ganz regulär nach Namen bindet:

function Get-MyArgs {
    [CmdletBinding()]
    Param(
        [Parameter(ValueFromPipelineByPropertyName=$true)][string]$MyInput,
        [Parameter(ValueFromPipelineByPropertyName=$true)][string]$MyOtherParm
    )
    Write-Host "Value of MyOtherParm:"
    $MyOtherParm
    Write-Host "Value of MyInput:"
    $MyInput
}

Wenn wir der Funktion jetzt ein Objekt verfüttern, das die gewünschten Properties enthält, werden sie auch ordnungsgemäß gebunden:

$x = New-Object PSCustomObject -Property @{
    MyInput="MyInputValue";
    MyOtherParm="MyOtherParmValue";
    ForeignParm="ShouldNotSeeMe"
}
$x | Get-MyArgs

liefert

Value of MyOtherParm:
MyOtherParmValue
Value of MyInput:
MyInputValue

Akzeptieren wir nur die gleichen Parameter, aber nach dem Wert, wartet eine kleine Überraschung auf uns:

function Get-MyArgs {
    [CmdletBinding()]
    Param(
        [Parameter(ValueFromPipeline=$true)][string]$MyInput,
        [Parameter(ValueFromPipeline=$true)][string]$MyOtherParm
    )
    Write-Host "Value of MyOtherParm:"
    $MyOtherParm
    Write-Host "Value of MyInput:"
    $MyInput
}
$x = New-Object PSCustomObject -Property @{
    MyInput="MyInputValue";
    MyOtherParm="MyOtherParmValue";
    ForeignParm="ShouldNotSeeMe"
}
$x | Get-MyArgs

liefert uns

Value of MyOtherParm:
@{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}
Value of MyInput:
@{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}

Und jetzt kommt der Quirk:

Was passiert aber, wenn wir, wie bei Value in New-Item, beide Bindungen zulassen? Also

function Get-MyArgs {
    [CmdletBinding()]
    Param(
        [Parameter(ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)][string]$MyInput,
        [Parameter(ValueFromPipelineByPropertyName=$true,ValueFromPipeline=$true)][string]$MyOtherParm
    )
    Write-Host "Value of MyOtherParm:"
    $MyOtherParm
    Write-Host "Value of MyInput:"
    $MyInput
}
$x = New-Object PSCustomObject -Property @{
    MyInput="MyInputValue";
    MyOtherParm="MyOtherParmValue";
    ForeignParm="ShouldNotSeeMe"
}
$x | Get-MyArgs

Anders als bei New-Item, erhalten wir nur die String-Werte der beiden benannten Parameter!
Eine Untersuchung mit

Trace-Command -Name ParameterBinding -Expression {$x | Get-MyArgs} -PSHost

fördert die folgenden Schritte zu Tage:

BIND PIPELINE object to parameters: [Get-MyArgs]
    PIPELINE object TYPE = [System.Management.Automation.PSCustomObject]
    RESTORING pipeline parameter's original values
    Parameter [MyOtherParm] PIPELINE INPUT ValueFromPipeline NO COERCION
    BIND arg [@{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}] to parameter [MyOtherParm]
        Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
            result returned from DATA GENERATION: @{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}
        BIND arg [@{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}] to param [MyOtherParm] SKIPPED
    Parameter [MyInput] PIPELINE INPUT ValueFromPipeline NO COERCION
    BIND arg [@{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}] to parameter [MyInput]
        Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
            result returned from DATA GENERATION: @{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}
        BIND arg [@{MyInput=MyInputValue; MyOtherParm=MyOtherParmValue; ForeignParm=ShouldNotSeeMe}] to param [MyInput] SKIPPED
    Parameter [MyOtherParm] PIPELINE INPUT ValueFromPipelineByPropertyName NO COERCION
    BIND arg [MyOtherParmValue] to parameter [MyOtherParm]
        Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
            result returned from DATA GENERATION: MyOtherParmValue
        BIND arg [MyOtherParmValue] to param [MyOtherParm] SUCCESSFUL
    Parameter [MyInput] PIPELINE INPUT ValueFromPipelineByPropertyName NO COERCION
    BIND arg [MyInputValue] to parameter [MyInput]
        Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
            result returned from DATA GENERATION: MyInputValue
        BIND arg [MyInputValue] to param [MyInput] SUCCESSFUL
MANDATORY PARAMETER CHECK on cmdlet [Get-MyArgs]

Bei New-Item ist das Value-Argument allerdings kein [string], sondern ein [object[]] (danke an Martin Binder für den Hinweis, dass dieser Test noch aussteht!). Ändert man das im obigen Beispiel, dann ist das Verhalten so wie bei New-Item auch, und zwar unabhängig davon, ob ein einzelnes [object] oder ein Array davon erwartet wird – es wird in beiden Fällen das ganze Objekt gebunden, sobald ValueFromPipeline=$true auftaucht.
Happy argument-passing!

Tags » , , , «

+

16 | 07 | 2018

PowerShell Quirks: Beware of collections, die N+1.

Geschrieben von um 23:31 Uhr

Ich habe ja schon des öfteren über Eigenarten von Sammlungen aller Art in PowerShell berichtet. Heute ein Beispiel aus der Active Directory-Administration.

Nehmen wir einfach mal an, wir haben ein mehrwertiges Attribut und wollen zu diesem einen zusätzlichen Wert hinzufügen. Für diese Beispiel nehme ich msExchExtensionCustomAttribute1, da kann man nichts kaputt machen.

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=@("A","B","C")}
$user = Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1
$a1 = $user.msExchExtensionCustomAttribute1
Write-Host "Unser Attribut msExchExtensionCustomAttribute1:"
$a1.GetType()
$a1

Nun wollen wir zu $a1 ein viertes Element hinzufügen. IntelliSense in ISE bietet folgendes an:

Auch wenn’s bei nativen PowerShell-Arrays nicht funktioniert, ist Add doch vielversprechend. Probieren wir’s aus:

$a1.Add("D")
Write-Host "`r`nNach dem Add:"
$a1.GetType()
$a1

liefert

Sieht doch super aus, richtig? Der Typ ist derselbe, alle vier Elemente sind wie erwartet da. Nun bleibt also die neue Sammlung zurück in das Attribut zu schreiben und das Ergebnis zu überprüfen:

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=$a1}
Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1

Doch das Ergebnis ist leider nicht ganz das, was wir erwartet haben:

Das soeben beschriebene Attribut ist leer. Hmmm.

Machen wir das gleiche Spiel und nehmen statt der Methode .Add das PowerShell-eigene Anfügen:

$a1 += "D"

so ist das Ergebnis wie erwartet:

Der alles entscheidende Unterschied ist anscheinend, dass die Operation += die ADPropertyValueCollection in ein System.Array konvertiert. Und dieses wird offenbar von Set-ADUser korrekt interpretiert, sein nativer Datentyp hingegen nicht!

Happy updating!

Tags » , , , , , «

+

07 | 10 | 2017

Great news: VSCode beherrscht nun den #region Tag!

Geschrieben von um 16:55 Uhr

Ein Grund weniger, VSCode nicht zu nutzen: Mit der aktuellen Version 1.17 beherrscht #VSCode nun auch den #region / #endregion Markup!

Details hier: http://tommymaynard.com/visual-studio-code-regions-2017/

Happy scripting!

Tags » , , «

+

23 | 08 | 2017

PowerShell: Wie schnell sind Arrays?

Geschrieben von um 11:13 Uhr

Die Herausforderung

Neulich im TechNet Forum: Jemand hat eine Liste, die sehr viele Einträge enthält, die sich oft wiederholen. In diesem Fall ging es um IP-Adressen. Wenn er versucht, die eindeutigen Werte mit

$list | select -Unique

zu generieren, dauert das sehr lange. Da er das normale PowerShell-Array verwendet hat, war es wenig überraschend. Im Forum-Thread kam natürlich sofort der (berechtigte) Hinweis auf den ArrayList-Typ, aber auch ein paar ausgefallenere Sachen. Da wollte ich natürlich genau wissen, wie sich das tatsächlich auswirkt.

Die Testmethodik

Da ich auf die Schnelle keine Quelle mit vielen IP-Adressen zur Hand hatte, habe ich beschlossen, einfach mit Strings zu arbeiten. Um die ursprüngliche Herausforderung zu simulieren, generieren wir einige (viele) Male eine Zufallszahl. Wenn der Bereich der Zufallszahlen deutlich kürzer ist als die Anzahl der Versuche, werden garantiert viele Dubletten auftreten.

Für die Generierung der Listen verwenden wir die folgende Logik:

$passes = 100000 # Anzahl der Durchläufe
$maxval = 10000 # Länge des Zufallszahlen-Bereiches
$a = <Initialisierung des jeweiligen Listentyps>
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    <$r wird an $a angefügt, evtl. mit Prüfung>
}
$s1 = $timer.Elapsed.TotalMilliseconds # das ist die Zeit der Listen-Erstellung
$a = $a | select -Unique
$s2 = $timer.Elapsed.TotalMilliseconds # das ist die Gesamtzeit

Bei den Methoden, wo von vornherein nur eindeutige Elemente auf die Liste kommen, entfällt natürlich der Teil mit Select und die „Zwischenzeit“. Diese Methodik führt zu den folgenden Skripten:

Methode 0: PowerShell-Array mit Select

Das ist die primitivste Methode. Das komplette Skript dieht wie folgt aus:

$passes = 100000
$maxval = 10000
$a = @()
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    $a += $r
}
$s1 = $timer.Elapsed.TotalMilliseconds
$a = $a | select -Unique
$s2 = $timer.Elapsed.TotalMilliseconds
"Zeit zum erstellen: $s1, Gesamtzeit: $s2"

Methode 1: ArrayList mit Select

Wie wir alle wissen, kann man die Bestückung von Arrays deutlich beschleunigen, wenn man statt des PowerShell-Array den .Net-Typ System.Collections.ArrayList verwendet. Nicht nur erweitert sich solch ein Array dynamisch, sondern man kann Elemente auch nachträglich löschen. Und schneller ist es obendrein. Das folgende Skript wird uns zeigen, wie sehr:

$passes = 100000
$maxval = 10000
$a = New-Object System.Collections.ArrayList
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    $a.Add($r) > $null
}
$s1 = $timer.Elapsed.TotalMilliseconds 
$a = $a | select -Unique 
$s2 = $timer.Elapsed.TotalMilliseconds 
"Zeit zum erstellen: $s1, Gesamtzeit: $s2"

Methode 2: ArrayList mit -notcontains

Ich nehme ein Ergebnis schon mal vorweg: der Teil mit Select dauert eine Weile. Das war auch das, was den ursprünglichen Thread ausgelöst hat. Es liegt daher natürlich nahe, vor dem Hinzufügen von Elementen zu checken, ob sie nicht schon drin sind, statt hinterher zu filtern. PowerShell hatt dafür den Operator -notcontains im Angebot:

$passes = 100000
$maxval = 10000
$a = New-Object System.Collections.ArrayList
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    if ($a -notcontains $r) { $a.Add($r) > $null }
}
$s2 = $timer.Elapsed.TotalMilliseconds 
"Gesamtzeit: $s2"

Methode 3: ArrayList mit .Contains()

Wir haben schon oft gehört, dass .Net-Methoden von Klassen schneller sein können als PowerShell-Äquivalente. Und da wir mit ArrayList arbeiten, können wir zur Prüfung auch auf die .Contains()-Methode zurückgreifen:

$passes = 100000
$maxval = 10000
$a = New-Object System.Collections.ArrayList
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    if (!($a.Contains($r))) { $a.Add($r) > $null }
}
$s2 = $timer.Elapsed.TotalMilliseconds 
"Gesamtzeit: $s2"

Methode 4: Hashtable

Schon bald im Thread kam der Einwurf, man könnte doch eine Hashtable verwenden, wenn die Werte eindeutig sein sollen. Das wäre ein Stück weit „mißbräuchliche Nutzung“, da wir nur den Key verwenden würden, aber nicht den Value. Aber sei’s drum, wenn es ans Ziel führt, ist jedes Mittel recht. Beim Versuch, einen bereits vorhandenen Key-Wert einzufügen, generiert die Hashtable eine Ausnahme. Diese fangen wir ab und… machen nichts weiter:

$passes = 100000
$maxval = 10000
$a = @{}
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    try {$a.Add($r,"") > $null} catch {}
}
$s2 = $timer.Elapsed.TotalMilliseconds 
"Gesamtzeit: $s2"

Methode 5: Hashtable mit Prüfung

Ausnahmen sind natürlich häßlich und in ordentlicher Programmierung zu vermeiden. Zum Glück kann man in einer Hashtable bestimmen, ob ein Key bereits vorhanden ist, nämlich mit der Methode .ContainsKey(). Ob es schneller ist als Ausnahme, wird der Test zeigen:

$passes = 100000
$maxval = 10000
$a = @{}
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    if (!($a.ContainsKey($r))) { $a.Add($r,"") > $null }
}
$s2 = $timer.Elapsed.TotalMilliseconds 
"Gesamtzeit: $s2"

Methode 6: Hashset

Zum Schluss hatte Denniver Reining noch das Hashset ins Gespräch gebracht. Das ist eine eindimensionale Liste, deren Mitglieder stets eindeutig sind, ohne das Ausnahmen generiert werden – vorhandene Werte werden einfach nicht hinzugefügt:

$passes = 100000
$maxval = 10000
$a = New-Object System.Collections.Generic.HashSet[object]
$timer = [System.Diagnostics.Stopwatch]::StartNew()
(1..$passes) | foreach {
    $r = (Get-Random -Minimum 1 -Maximum $maxval).ToString().PadLeft(15,'0')
    $a.Add($r) > $null
}
$s2 = $timer.Elapsed.TotalMilliseconds 
"Gesamtzeit: $s2"

Die Ergebnisse

Die obigen Skripte könnt ihr euch hier herunterladen und selbst Messungen vornehmen. Bei $passes = 100000 und $maxval = 10000 (also im Schnitt 10 Dubletten pro Eintrag) erhalten wir folgende Ergebnisse:

MethodeZeit gesamt (sek.)davon sortieren (sek.)
Baseline (Schleife und Generierung der Zufallszahlen)6,5-
PowerShell Array und select -unique51590
ArrayList und select -unique9590
ArrayList mit -notcontains58-
ArrayList mit .Contains()11-
Hashtable mit Exception21-
Hashtable mit .ContainsKey()7,5-
Hashset6,8-

Erhöhen wir die Werte auf $passes = 400000 und $maxval = 20000 (damit verdoppelt sich sowohl die Länge der eindeutigen Liste als auch die durchschnittliche Anzahl der Dubletten), ändern sich die Ergebnisse wie folgt:

MethodeZeit gesamt (sek.)davon sortieren (sek.)
Baseline (Schleife und Generierung der Zufallszahlen)27,8-
PowerShell Array und select -unique6280768
ArrayList und select -unique762734
ArrayList mit -notcontains520-
ArrayList mit .Contains()57-
Hashtable mit Exception86-
Hashtable mit .ContainsKey()32-
Hashset28,6-

Man sieht also sehr deutlich, dass die Bestückung eines Hashset auch bei einer größeren Menge an Ergebnissen kaum Zeit in Anspruch nimmt!

Das Fazit

Die „Ausbeute“ aus diesen Zahlen ist wie folgt:

  1. Das Erweitern eines PowerShell-Array mit $array += $item ist extrem langsam
  2. Die .Contains()-Methode ist viel schneller als der Operator -contains
  3. Beim Hinzufügen zu einer Hashtable ist es deutlisch schneller, vorher die Existenz des Key abzuprüfen als eine Ausnahme zu generieren.
  4. Will man von vorhnherein eindeutige Werte auf der Liste haben, ist ein Hashset optimal. Der Geschwindigkeitsgewinn gegenüber Hashtable mit Prüfung ist zwar nicht mehr weltbewegend, aber er ist da, man benutzt die Typen richtig und mißbraucht den Key nicht als Datenspeicher…

Also: Wenn lange Listen generiert und verarbeitet werden müssen, lohnt es sich auf jeden Fall, das bequeme Konstrukt des PowerShell-Arrays zu verlassen und sich fortgeschritteneren Typen von Sammlungen zuzuwenden.

Happy listing!

Tags » , , , , , , «

+

12 | 08 | 2017

PowerShell Quirks: New-PSDrive und der Speicherplatz

Geschrieben von um 11:26 Uhr

Wenn man in einer PowerShell-Sitzung mit

New-PSDrive -Name Z -Root "\\SERVER\SHARE" -PSProvider FileSystem

ein Netzlaufwerk mappt, stellt man fest, dass die Spalten „Used Space“ und „Free Space“ leer sind:

Möchte man die Werte haben, funktioniert es mit dem Argument -Persist:

Ich hätte sogar eine theoretische Erklärung dafür, aber Gernot Meyer hat im TechNet-Forum eine Beobachtung zitiert, die diese Erklärung widerlegt, daher halte ich mich mal zurück und recherchiere weiter.

Happy drive mapping!

Tags » , , , , «

+