Archive for the ‘Powershell V3’ Category

Für Powershell .Net Framework Tracing aktivieren

13 Dezember 2014

Manchmal ist nicht klar warum etwas nicht funktioniert. Da Powershell stark auf das .Net Framework angewiesen ist, kann man auch dessen Trace-Möglichkeiten nutzen, um eine tiefergehende Fehleranalyse zu ermöglichen. Hilfreich ist das Tracing z. B. in Verbindung mit der Netzwerkkommunikation.

Unter .Net kann man das Netzwerktracing wie in diesem Artikel beschrieben aktivieren: http://msdn.microsoft.com/en-us/library/ty48b824(v=vs.110).aspx. Damit der Trace-Mitschnitt in Powershell aktiviert werden kann, muss die in der betreffenden Powershellversion die Datei Powershell.exe.config angelegt, bzw. bearbeitet werden. Dabei ist von Bedeutung, ob man mit Powershell 32-Bit oder 64-Bit arbeitet. Zum Thema Powershell 32-/64-Bit siehe hier: https://newyear2006.wordpress.com/2012/06/20/prfen-ob-eine-powershell-sitzung-in-einer-32bit-oder-64bit-prozess-umgebung-luft/.

Kurz: Unter einem 64-Bit System findet man die 64-Bit Powershell-Version unter C:\WINDOWS\SYSTEM32\WINDOWSPOWERSHELL\V1.0 und die 32-Bit Powershell-Version unter C:\WINDOWS\SYSWOW64\WINDOWSPOWERSHELL\V1.0. Auf einem reinen 32-Bit-System ist der Pfad wieder wie bei der 64-Bit Fassung.

Wenn man nun also seine Powershell.exe.config, die so aussieht

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

   <system.diagnostics>

        <sources>

            <source name="System.Net">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

            <source name="System.Net.Sockets">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

        </sources>

        <switches>

            <add name="System.Net" value="Verbose" />

            <add name="System.Net.Sockets" value="Verbose" />

        </switches>

        <sharedListeners>

            <add name="System.Net"

                type="System.Diagnostics.TextWriterTraceListener"

                initializeData="System.Net.log"

                />

        </sharedListeners>

        <trace autoflush="true" />

    </system.diagnostics>

</configuration>

im Verzeichnis C:\Windows\System32\WindowsPowershell\V1.0\ angelegt hat, kann man anschließend Powershell starten. Wichtig, die Einstellungen wirken sich erst aus, wenn eine neue Powershell.exe gestartet wird.

Man bekommt nun in der Datei System.Net.Log die Trace-Daten gespeichert. Die System.Net.Log wird in dem Verzeichnis der Powershell.exe gespeichert.

Möchte man die Trace-Möglichkeit in Powershell-ISE nutzen, muss man natürlich die Datei Powershell_ise.exe.config bearbeiten.

Das Format der Trace-Daten ist kurz hier angerissen: http://msdn.microsoft.com/en-us/library/46fcs6sz(v=vs.110).aspx.

Lambdas in Powershell

5 Dezember 2014

Ein sehr guter Artikel wie man Lambdas in Powershell nachbilden kann: http://www.powershellmagazine.com/2013/12/23/simplifying-data-manipulation-in-powershell-with-lambda-functions/

Im Prinzip wird ein einfacher Scriptblock verwendet. Der im Artikel beschriebene Ansatz verwendet gleichzeitig den ab Powershell 3.0 verfügbaren Abstract Syntax Tree um Parameter der übergebenen Lamda-Ausdrücke zu prüfen. Der Call-Operator & erlaubt dann das Ausführen der Lambda-Ausdrücke.

Fehlende Cmdlets in Powershell durch Polyfills nachbilden

17 November 2014

In der HTML5-Welt sind Polyfills ein fester Begriff. Es geht um das Nachrüsten von Funktionen, die in bestimmten Browsern nicht vorhanden sind. Die Definition stammt von Remy Sharp einer der Größen in der HTML5/Javascript-Welt https://remysharp.com/2010/10/08/what-is-a-polyfill.

Was hat das mit Powershell zu tun? Auch in Powershell haben wir das Problem, dass Microsoft es wegen Menpowerproblemen oder strategischen Gründen nicht geschafft hat, Cmdlets aus Windows 8 zurückzuportieren für Windows 7. Ein Beispiel ist Rename-Printer. http://technet.microsoft.com/en-us/library/hh918360.aspx. Oder ein neues kommendes Cmdlet ist Expand-Archive aus Windows 10, welches sicher auch auf alten Windows Versionen benötigt wird.

Polyfills, sogenannte Drop-in Polyfills, wie im Buch “Building Polyfills” von Brandon Satrom definiert, prüfen, ob eine bestimmte Funktion vorhanden ist, wenn diese fehlt, wird diese nachimplementiert. Ist die Funktion bereits vorhanden, so wird die bestehende native Funktion verwendet. In Powershell kann man genau dieses verhalten nachbilden.

Zunächst muss man herausfinden, ob ein bestimmtes Cmdlet verfügbar ist. Zunächst sollte dazu das zugehörige Modul geladen werden. Als zweites sollte dann mittels Get-Command abgefragt werden, ob das betreffende Cmdlet vorhanden ist.

Die Prüfung, ob Rename-Printer vorhanden ist, sieht z. B. so aus:

if (-not (Get-Command Rename-Printer -ErrorAction SilentlyContinue))
{
       # Rename-Printer ist nicht vorhanden
}

Wichtig dabei ist der Parameter –ErrorAction SilentlyContinue, der dafür sorgt, dass wenn das Cmdlet nicht vorhanden ist, keine Fehlermeldung erscheint.

Wie könnte nun ein konkreter Nachbau von Rename-Printer aussehen? Früher hatte man so etwas über WMI gelöst, demzufolge kommen diese Zeilen dem Ziele nahe:

$Filter = "Name=’$($Name)’"
$prn = Get-WMIObject Win32_Printer -Filter $Filter
$res = $prn.RenamePrinter($NewName)
#res.ReturnValue -eq 5 wenn Access Denied, bei 0 OK

Nun möchte man ja aber im Skript konkret das Cmdlet Rename-Printer nutzen, ohne jedesmal per if-Abfrage in Erfahrung zu bringen, ob das Cmdlet vorhanden ist oder ob die alternative Implementierung aufgerufen werden soll. Dazu definiert man in einem Scriptblock das fehlende Cmdlet und führt diesen über den & Call-Operator aus.

$polyfill = {Function Rename-Printer() {"Ersatz für Rename-Printer"}}
&  $polyfill

Wenn man nun unter Windows 7 versucht diesen Aufruf auszuführen passiert nichts, denn Rename-Printer wird nicht gefunden, da die definierte Funktion nur in einem reduzierten Scope zu sehen ist. Um dieses Problem zu lösen, verwendet man explizit den globalen Scope:

$polyfill = {Function Global:Rename-Printer() {"Ersatz für Rename-Printer"}}
&  $polyfill

Nach diesem Aufruf steht nun Rename-Printer zur Verfügung.

Nun gilt es nur noch obige Dinge zu kombinieren, dann erhält man folgendes Cmdlet Polyfill für Powershell um z. B. Rename-Printer nachzubauen:

# Rename-Printer geht nur unter Win8 oder höher, benötigt Admin-Rechte

if (-not (Get-Command Rename-Printer -ErrorAction SilentlyContinue)) {

# damit die Function verfügbar wird, muss sie mittels & ausgeführt werden und mit dem Scope global: versehen werden

&{

Function global:Rename-Printer ($Name, $NewName) {

$Filter = "Name=’$($Name)’"

# anstatt Name doch DeviceID?

$prn = Get-WMIObject Win32_Printer -Filter $Filter

$renres = $prn.RenamePrinter($NewName)

# renres.ReturnValue == 5 wenn Access Denied, bei 0 erfolgreich

}

}

}

Als Template kann man dieses Skelett sehen:

if (-not (Get-Command CmdletName -ErrorAction SilentlyContinue)) {
  &{ Function global:CmdletName ($Parameter) {
             # CmdletName – Nachbau
        }
    }
}

Durch Powershell Polyfills erreicht man bessere und schönere Skripte, da nur zu Beginn notwendige evtl. nicht vorhandene Cmdlets nachgebaut werden müssen. Ein Skript, welches unter Windows 8 läuft, kann somit ohne umschreiben auch direkt auf Windows 7 laufen. Selbst wenn später ein Update doch noch die Unterstützung für das betreffende Cmdlet auf Windows 7 bringen sollte, so wird automatische das dann nativ zur Verfügung stehende Cmdlet verwendet.

Windows Drucker will nicht mehr und beim Versuch eine Testseite auszudrucken erscheint Fehlernummer 0x00000006

23 Juli 2014

Ein Kunde meldet sich und meint, sein Drucker druckt nicht mehr. Jetzt kann dies wie immer viele Ursachen haben aber diese ist mal wieder typisch Microsoft. Der Kunde hat ein kleines Netzwerk und somit eine Domäne. Der Drucker wird vom Server verwaltet und ist per Netzwerk dem Client zugeordnet.

Wie gesagt druckt der jetzt nicht mehr. Also die übliche Prozedur mit zunächst Windows-Testseite drucken, um rauszufinden, ob es ein Windows bzw. Treiberproblem ist oder von der Anwendung herrührt.

Mmhh. Windows-Testseite drucken meldet:

[Window Title]

Druckereigenschaften

 

[Main Instruction]

Die Testseite konnte nicht gedruckt werden. Soll die Druckproblembehandlung angezeigt werden? Der Vorgang konnte nicht abgeschlossen werden (Fehler 0x00000006).

 

[Ja] [Nein]

Dasselbe nochmal als Admin probiert half auch nichts. Nett wie Windows ist, bietet es einem die Druckproblembehandlung an. Aber alles was die fabriziert ist: Der Drucker ist nicht der Standarddrucker, soll dies geändert werden? Was hat dies mit dem Fehler zu tun? Nichts! Also wie immer ignorieren und selber den Fehler ausfindig machen.

Zunächst war der Gedanke, vielleicht liegt es am Druckertreiber, also Druckerwarteschlange neu gestartet aber wieder nichts. OK, vielleicht der Treiber selber, Rechner neu gestartet, brachte auch nichts. OK, dann vielleicht mal direkt am Server eine Testseite ausdrucken. Klappt!

Na toll. Der Drucker druckt vom Server aber nicht von der betreffenden Station. Also Netzwerkproblem aber welches?

Also mal Powershell aufgerufen und Test-ComputerSecureChannel probiert:

PS C:\Windows\system32> Test-ComputerSecureChannel

Test-ComputerSecureChannel : Der lokale Computer ist keiner Domäne beigetreten,

 oder die Domäne kann nicht kontaktiert werden.

Bei Zeile:1 Zeichen:27

+ Test-ComputerSecureChannel <<<<

    + CategoryInfo          : NotSpecified: (:) [Test-ComputerSecureChannel],

   ActiveDirectoryObjectNotFoundException

    + FullyQualifiedErrorId : System.DirectoryServices.ActiveDirectory.ActiveD

   irectoryObjectNotFoundException,Microsoft.PowerShell.Commands.TestComputer

  SecureChannelCommand

 

Aha, also ein Problem mit der Domänenkommunikation. Zur Bestätigung noch ein w32tm /monitor abgesetzt:

GetDcList ist fehlgeschlagen mit Fehlercode: 0x8007054B.
Beendet mit Fehler 0x8007054B

 

OK.

 

Übrigens ist das Cmdlet Test-ComputerSecureChannel die optimale Hilfe um Probleme mit der Vertrauensstellung zur Domäne (trust relationship) herauszufinden. Nichts mehr wie früher mit NETDOM, wo man zuerst immer schauen musste, wo man es herbekommt. Test-ComputerSecureChannel ist ab PS 2.0 enthalten, also quasi überall. http://technet.microsoft.com/en-us/library/hh849757.aspx.

 

Grund

Ein Vergleich der Uhrzeit zwischen Server und Client offenbarte dann auch schnell den Grund. Der Client hinkte 7 Minuten hinterm Server her!

Ja dann ist ja die Lösung einfach. Zeit gesetzt und Rechner gebootet, neu angemeldet und immer noch der Fehler. Mist.

Wieder Powershell angeworfen und Reset-ComputerMachinePassword probiert:

PS C:\Windows\system32> Reset-ComputerMachinePassword -Server server
Reset-ComputerMachinePassword : Der lokale Computer ist keiner Domäne beigetret

en, oder die Domäne kann nicht kontaktiert werden.

Bei Zeile:1 Zeichen:30

+ Reset-ComputerMachinePassword <<<<  -Server server

    + CategoryInfo          : NotSpecified: (:) [Reset-ComputerMachinePassword

   ], ActiveDirectoryObjectNotFoundException

    + FullyQualifiedErrorId : System.DirectoryServices.ActiveDirectory.ActiveD

   irectoryObjectNotFoundException,Microsoft.PowerShell.Commands.ResetCompute

  rMachinePasswordCommand

Komisch immer diese Fehlermeldungen. In einem anderen Fall hatte dies problemlos zum Erfolg geführt, warum hier nicht? Auf dem anderen Rechner war allerdings Powershell 3.0, in diesem Fall war nur 2.0 installiert.

Lösung:
Also noch Powershell 4.0 von http://www.microsoft.com/de-de/download/details.aspx?id=40855 installiert. Danach war alles gleich viel freundlicher:

PS C:\Windows\system32> Test-ComputerSecureChannel
False
PS C:\Windows\system32> Reset-ComputerMachinePassword -Server server –Credential (Get-Credential)
Cmdlet Get-Credential an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
Credential
PS C:\Windows\system32> Test-ComputerSecureChannel
False

So jetzt nochmal einen Neustart und alles war gut:

PS C:\Windows\system32> Test-ComputerSecureChannel
True
PS C:\Windows\system32> w32tm /monitor
SERVER.thiel.local *** PDC ***[192.168.16.1:123]:

    ICMP: 0ms Verzögerung

    NTP: +0.0000000s Offset von SERVER.thiel.local

        RefID: (unbekannt) [0xCE383741]

        Stratum: 3

[Warnung]

Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht

korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von

NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet.

PS C:\Windows\system32>

Fazit: Es ist halt immer wieder dasselbe Spiel, sobald Zeitdifferenzen größer 5 Minuten passieren, dann geht das Vertrauen verloren und es kommen die verrücktesten Fehlermeldungen zustande.

Noch ein paar Links mit weiteren Hinweisen:

http://www.techiesweb.com/repair-broken-windows-trust-relationship-between-domain-controller-and-client-machine/

http://www.implbits.com/about/blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/default.aspx

http://blog.joeware.net/2012/06/05/2508/

http://www.cievo.sk/2012/02/21/reset-computer-accounts-in-active-directory-domain/

Windows Server 2012 (R2) Server Manager um eigene Powershell Skripte erweitern

19 Mai 2014

Seit Windows Server 2012 hat Microsoft bei den GUI-Verwaltungen der alten MMC den Kampf angesagt. Alle neuen Tools werden immer weiter in den neuen Server-Manager integriert. Führt man über das Toolsmenü einen Befehl aus, läuft im Hintergrund ein Powershell-Skript ab.

Das Toolsmenü kann man um eigene Powershell-Skripte erweitern, dazu muss man nur das Powershell-Skript in das Verzeichnis

%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Administrative Tools

verlinken. Dabei kann man auf alle im Dashboard bekannten Server zurückgreifen, indem man diese Datei ausliest:

%APPDATA%\Microsoft\Windows\ServerManager\ServerList.XML

Näheres beschreibt dieser Artikel: http://blogs.technet.com/b/keithmayer/archive/2013/11/20/step-by-step-extending-server-manager-in-windows-server-2012-and-2012-r2.aspx

Domainjoin mittels Powershell bei Small Business Server SBS

28 April 2014

Um einen Rechner mittels Powershell in eine Domäne aufzunehmen, hilft diese Zeile:

add-computer -domain domain.local -credential domain\domainadmin -oupath "OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Domain,DC=Local" –Restart

Weitere Infos zum Cmdlet gibt es hier: http://technet.microsoft.com/en-us/library/hh849798.aspx

Beim Versuch Windows Updates vom WSUS zu holen, gibts am Anfang evtl. Probleme und man bekommt eine Fehlermeldung 0x800B0001 angezeigt. Die Hintergründe sind hier schön beschrieben: http://selekta77.blogspot.de/2013/04/windows-update-fehler-800b0001-beheben.html

Wenn man aber überprüft, ob man das passende Serverzertifikat in der Computerzertifikaten hat, passt alles. Man kann also statt mit WSUS herumdoktern gleich prüfen, ob man eine Verbindung hat.

http://WSUS-SERVER/selfupdate/wuident.cab

Klappt der Download, kann man mit

wuauclt /detectnow

die Updates anschieben.

Zugriff auf WWAN Profile unter Windows 8 per Powershell

26 November 2013

Mit Windows 8.1 sind zwar nochmals einige Powershell Cmdlets hinzugekommen allerdings für WWAN, also Breitbandverbindungen wie LTE, HSDPA, UMTS und GSM war noch nichts dabei. Hier ist also Handarbeit angesagt.

Da die Windows Runtime von Windows 8 auch unter Powershell nutzbar ist, kann dort auf alle verfügbaren APIs zugegriffen werden, die für “desktop apps” gekennzeichnet sind, wie z. B. NetworkInformation: http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.connectivity.
networkinformation.aspx

Dabei sorgt der Aufruf von

[void][Windows.Networking.Connectivity.NetworkInformation,Windows, ContentType=WindowsRuntime]

dass die betreffende Assembly geladen wird, worauf dann dieser Aufruf möglich ist:

[Windows.Networking.Connectivity.NetworkInformation]:: GetConnectionProfiles()

Anstatt GetConnectionProfiles kann man auch GetInternetConnectionProfile() aufrufen, welches dann das aktuelle Internetverbindungsobjekt zurück gibt. Dieses kann man nun mittels GetConnectionCost zum NetworkCostType befragen. Die möglichen Werte sind dann hier beschrieben: http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.connectivity.networkcosttype.aspx.

Weitere Infos zu den Möglichkeiten stehen hier:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/08/02/more-messing-around-with-wireless-settings-with-powershell.aspx

Wenn es Probleme genereller Natur gibt, helfen evtl. die Loggingmöglichkeiten weiter: http://msdn.microsoft.com/en-us/library/windows/hardware/dn423925(v=vs.85).aspx

Für WinRT mit Asnyc-Aufrufen und Powershell, gilt es dies zu beachten: http://rkeithhill.wordpress.com/2013/09/30/calling-winrt-async-methods-from-windows-powershell/

Alles zusammenkombiniert kann man mittels GetNetworkUsageAsync() auch herausfinden, wie viel MB pro Tag, pro Stunde, pro Minute oder insgesamt die letzten 60 Tage über die Leitung gingen!

http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.connectivity.
connectionprofile.getnetworkusageasync.aspx

Powershell 4.0 und 3.0 Versionsdurcheinander unter Windows 8.1 und Server 2012 R2

12 November 2013

Ladet man eine spezifische Powershell 3.0 Version bekommt man Version 4.0! Dieser Artikel verdeutlicht die Geschichte nochmal: http://p0w3rsh3ll.wordpress.com/2013/10/22/powershell-version-loading-on-windows-8-1-2012-r2/

Nochmal zum Thema 16-Bit-Programme unter Windows 8.1 32-Bit und wie verhält es sich mit FONDUE.EXE und den Legacykomponenten?

15 September 2013

Nachdem das Thema im vorhergehenden Artikel https://newyear2006.wordpress.com/2013/09/15/16-bit-programme-unter-windows-8-es-muss-zuerst-die-16-bit-anwendungsuntersttzung-aktiviert-werden/ schon ausführlich beschrieben wurde, folgt hier nun die Fortsetzung speziell auf Windows 8.1 bezogen.

Die Microsofties scheinen für die Zukunft Großes zu planen und gehen immer mehr in die Richtung nur die Komponenten einzusetzen, die wirklich benötigt werden. Mein Vorschlag: Powershell verwenden und auf den ganzen GUI-Käse verzichten Smiley. Spaß beiseite, wenn man unter Windows 8.1 bei Windows-Features aktivieren oder deaktivieren schaut, fällt einem bei der 32-Bit Version NTVDM auf, unter 64-Bit gibt es nur Directplay. Profis wissen, NTVDM das ist die DOS-Maschine unter Windows NT Anno dazumal.

Im oben genannten Artikel wurde der Dialog beschrieben der beim Aufruf von 16-Bit-Programmen erscheint. Unter Windows 8.1 sieht dieser nun so aus:

image

Deutlich professioneller, fast wäre man geneigt “Modern App”-Like zu sagen! Aber die Funktion ist die Gleiche wie beim alten Dialog. Es wird die NTVDM-Umgebung eingerichtet, damit die alten 16-Bit-Programme aufgerufen werden können.

Um in Setupskripten diese Komponenten automatisch einrichten zu können, kann man DISM.EXE verwenden.

So aktiviert diese Zeile die Unterstützung für 16-Bit:

dism /online /enable-feature /all /featurename:NTVDM

diese schaltet sie wieder ab:

dism /online /disable-feature /featurename:NTVDM
dism /online /disable-feature /featurename:LegacyComponents

Diese Zeilen entsprechen quasi den RUNDLL32-NTVDMCPL.DLL-Aufrufen vom letzten Artikel.

Apropos, da ich oben Powershell genannt hatte, hier noch die Kommandos in Powershell:

Enable-WindowsOptionalFeature –Online –FeatureName NTVDM –All

Zum Ausschalten:

Disable-WindowsOptionalFeature –Online –FeatureName NTVDM
Disable-WindowsOptionalFeature –Online –FeatureName LegacyComponents

Und noch die Abfrage, ob das Feature aktuell aktiv ist oder nicht:

(Get-WindowsOptionalFeature –Online) | where FeatureName –eq NTVDM

dies gibt dann ein BasicFeatureObject zurück:

Feature Name: NTVDM
State              : Disabled

Wenn man den State direkt abfragen möchte, sieht das noch professioneller aus:

(((Get-WindowsOptionalFeature –Online) | where FeatureName –eq NTVDM).State) –eq [Microsoft.Dism.Commands.FeatureState]::Enabled

Dies liefert dann wirklich ein Boolean mit $true oder $false zurück, mit dem man dann arbeiten kann. Für alle Scriptschreiber beachten: Der FeatureState kann noch weitere Werte annehmen:

[Enum]::GetNames([Microsoft.Dism.Commands.FeatureState])

ergibt:

Disabled
DisablePending
Enabled
EnablePending
Superseded
PartiallyInstalled
DisabledWithPayloadRemoved

Schön, so haben wir hier einen Legacy-Artikel der den Bogen von 16-Bit-MS-DOS-Programmen in die wunderbare Welt der Monads mit Powershell schlägt.

Stopp, ich hatte in der Überschrift noch FONDUE.EXE erwähnt, das wollte ich jetzt nicht unterschlagen. Wer die im vorhergehenden Artikel beschriebene Variante zum Aufruf der Einstellungen für 16-Bit-Anwendungsprogramme in der Systemsteuerung probiert, der bekommt FONDUE.EXE zu Gesicht. FONDUE ist jetzt nichts zum Essen sondern steht eher für FeatureOnDemand, wo auch immer das U herkommt. Mmmh, vielleicht wenn man UE für UserExperience setzt. Ja, in Zeiten von Modern UI muss es so sein. Merken wir uns FONDUE steht für Feature On Demand User Experience! Siehe da, schon im August 2011 hat die BILD.DE darüber berichtet!!! http://www.bild.de/digital/internet/windows-betriebssysteme/windows-8-vorabversion-kurzt-test-c_b-19363404.bild.html. Erinnert mich an: Bild sprach mit dem Toten…

Powershell Update-Help meldet kryptischen Fehler

25 August 2013

Profis sind in der Eingabeaufforderung aktiv! Diesen Satz kann ich zu jeder Zeit unterstreichen. Wer den Blog öfters liest, wird erkannt haben, dass mir eine Lösung mittels Commandline lieber ist, als stupides Rumgeklicke. Damit lassen sich eben Dinge besser automatisieren. Blöd nur, wenn man sich aus Bequemlichkeit dazu hinreisen lässt, doch eine GUI zu benutzen.

Die Powershell ISE ist so eine nette Geschichte. Immer verfügbar, schnell und tut was sie soll. Sie hilft beim schnellen Erstellen von kleinen Skripten.

Aber hin und wieder stößt die Powershell ISE einem mit komischen Fehlermeldungen vor den Kopf. Aktuelles Beispiel:

Update-Help

Fehler:

Update-Help : Der angegebene Schlüssel war nicht im Wörterbuch angegeben.
In Zeile:1 Zeichen:1
+ Update-Help *
+ ~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Help], KeyNotFoundException
    + FullyQualifiedErrorId : System.Collections.Generic.KeyNotFoundException,Microsoft.PowerShell.Commands.UpdateHelpCommand

Jau alles klar!

Danke ihr Pfeifen von MS, mal wieder eine wunderbare Meldung. Es ist sofort klar, dass die Hilfe nur von einer echten Powershell Eingabeaufforderung upgedatet werden will!

Moment, es geht ja noch weiter. Wenn man sich mit dem Thema weiter beschäftigt, dann findet man in about_updatable_help: http://technet.microsoft.com/en-us/library/hh847735.aspx, dort steht geschrieben:

 UPDATE HELP IN WINDOWS POWERSHELL ISE
     You can also update help by using the "Update Windows PowerShell
     Help" item in the Help menu in Windows PowerShell Integrated
     Scripting Environment (ISE). 

     The "Update Windows PowerShell Help" item runs an Update-Help 
     command without parameters.

Aha, so so. OK, wenn die ISE es also doch kann, dann machen wir die DAU-Methode: Klick auf Help, Klick auf “Windows Powershell-Hilfe aktualisieren” und? Hä hä, MS halt:

Update-Help : Der angegebene Schlüssel war nicht im Wörterbuch angegeben.

In Zeile:1 Zeichen:1

+ Update-Help *

+ ~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Update-Help], KeyNotFoundException

    + FullyQualifiedErrorId : System.Collections.Generic.KeyNotFoundException,Microsoft.PowerShell.Commands.UpdateHelpCommand

Ja, war ja klar!

Über die verkorkste Powershell-Hilfe gäbe es noch so viel mehr… Aber lassen wir das.