Zertifikatsdialoge aus Powershell heraus anzeigen

Beim beschäftigen mit Zertifikaten in Powershell wäre es manchmal hilfreich ein Zertifikat in der üblichen Darstellung unter Windows angezeigt zu bekommen. Dank der nahen Anbindung zum .Net Framework ist dies recht einfach möglich.

Hier ein Beispiel, es wird ein beliebiges Zertifikat zu Demonstrationszwecken ermittelt:

$c=dir cert:\CurrentUser\My| select –First 1

Das Zertifikat in $c kann nun mittels dieses Aufrufs im üblichen Windows Dialog angezeigt werden:

[System.Security.Cryptography.X509Certificates.X509Certificate2UI]
::DisplayCertificate($c)

Beide Zeilen gehören direkt aneinander in eine Zeile!

Aber es geht noch besser. Man kann auch einen Auswahldialog öffnen, mit einer Auswahl von Zertifikaten und dann dem Benutzer einen Dialog anzeigen, wo er das passende Zertifikat auswählen kann.

Zunächst brauchen wir ein paar Zertifikate:

$cs=dir cert:\CurrentUser\My

Leider handelt es sich bei $cs nun um ein Array von Zertifikaten. Damit der Auswahldialog funktioniert, muss eine Zertifikatkollektion vom Typ X509Certificate2Collection übergeben werden. Diese erhält man aber ganz einfach, durch diesen Schritt:

$col=[System.Security.Cryptography.X509Certificates.
X509Certificate2Collection]::new($cs)

Bei obiger Zeilen muss wieder alles in eine Zeile hintereinander geschrieben werden.

Nun hat man auf jeden Fall eine Zertifikatskollektion in $col. Damit kann man nun diesen Aufruf durchführen:

$c=[System.Security.Cryptography.X509Certificates.
X509Certificate2UI]::SelectFromCollection($col,"Überschrift", "Hinweistext", [System.Security.Cryptography.X509Certificates.
X509SelectionFlag]::SingleSelection)

Man bekommt nun alle Zertifikate in $col angezeigt und kann sogar noch die Überschrift und einen Hinweistext beeinflussen. Nach der Auswahl bekommt in $c das ausgewählte Zertifikat zugewiesen.

Hier noch die API-Links:
DisplayCertificate:
http://msdn.microsoft.com/de-de/library/ms223201(v=vs.110).aspx
SelectFromCollection:
http://msdn.microsoft.com/de-de/library/ms223189(v=vs.110).aspx
X509Certificate2Collection:
http://msdn.microsoft.com/de-de/library/system.security.cryptography.x509certificates.
x509certificate2collection(v=vs.110).aspx

Für Powershell .Net Framework Tracing aktivieren

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.

Source Code von MS-DOS 2.0 veröffentlicht

Yuppiee! Der erste Schritt ist gemacht. Nach über 30 Jahren wird der Source Code von MS-DOS 2.0 veröffentlicht. Bis wir den Source Code von Windows 8.1 und nachfolgend sehen werden, wird es sicherlich nicht mehr ganz so lange dauern. http://www.heise.de/newsticker/meldung/Quelltexte-von-MS-DOS-und-Word-for-Windows-veroeffentlicht-2154723.html

Hier zum Source von MS-DOS: http://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code/, falls nicht wieder die Guru Meditation wegen Überlastung kommt.

MS-DOS 2.0 das war das Betriebssystem, welches damals auf den ersten IBM-XT-PCs lief, dem Nachfolger des ersten als solches benannten Personal Computer, dem IBM PC. Da gab es auch schon Festplatten mit 10MB und so, ach und die flexiblen Scheiben, die 5 1/4 Zoll großen, ähm – ah ja – Floppy Disks! So ein PC war damals richtig schwer und heute tragen wir um 100 ja sogar 1000fach leistungsfähigere Geräte in der Hosentasche. Wer das alte Feeling nochmal erleben möchte, hier der Link zum MS-DOS 2.0 Emulator im Browser: http://jsmachines.net/configs/pc/machines/5160/cga/256kb/demo/

Warum es bei Windows 8.1 keine 30 Jahre bis zur Source Code Veröffentlichung dauern wird? Na weil das .Net Framework 4.5.1 bereits in seiner reinsten Form einsehbar ist: http://referencesource.microsoft.com/. Auch sind weite Teile von ASP.NET bereits unter Open Source verfügbar.

Schließlich wird Microsoft irgendwann gezwungen sein allen Source Code zu veröffentlichen, da keiner mehr den ganzen Müll warten will, den die da über die Jahre angehäuft haben. Denen gehen ja jetzt schon die ganzen Techniker aus, die sich mit dem ganzen Zeugs beschäftigen wollen bzw. die da überhaupt noch durchblicken. Man sieht dies ganz deutlich in vielen Microsoft moderierten Foren. Was da teilweise für Antworten von MS-Mitarbeitern kommen. Oder wie oft fehlt es an technischen Beschreibungen in der Knowledge Base oder Technet. Alles klare Anzeichen, dass die letzten Jahre viel in die falsche Richtung lief. Aber die Cloud soll es ja retten. Mal sehen, was nächste Woche auf der Build der neue Oberindianer von sich gibt.

Microsoft .Net Framework 3.5 unter Windows 8 offline nachinstallieren

Zum Glück sind die nötigen Dateien auf der Windows 8 DVD enthalten, somit geht es schnell:

Dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:D:\sources\sxs /LimitAccess

Im obigen Beispiel ist das DVD-Laufwerk unter D: zu finden.

Wers bebildert braucht, wird hier fündig: http://support.microsoft.com/kb/2785188

In den Niederungen von SecureString mittels Powershell

Im ersten Blogbeitrag zu SecureString bin ich auf die allgemeine Anwendung von SecureStrings in Powershell und indirekt im .Net-Framework eingegangen. https://newyear2006.wordpress.com/2012/12/30/spa-mit-net-securestring-und-powershell-oder-sicheres-speichern-und-einlesen-von-passwrtern/

Wenn man mit den SecureStrings herumspielt, fällt einem schnell auf, dass diese quasi immer einen gleichen Header verwenden. Dieser beginnt immer mit der folgenden Zeichenfolge:

01000000d08c9ddf0115d1118c7a00c04fc297eb

Ab hier wird es nun interessant. Wenn man Google bemüht, kommen nicht all zu viele Treffer bei raus: https://www.google.de/search?q=01000000d08c9ddf0115d1118c7a00c04fc297eb. Aber unter den wenigen Treffern, sind wahre Perlen dabei! Denn es geht um nichts anderes als um eine eindeutige Kennung für DPAPI BLOBs welche von Windows seit Windows 2000 verwendet werden um Passwörter sicher in der Registrierung, Festplatte und Speicher abzulegen. DPAPI steht für Data Protection API. http://msdn.microsoft.com/en-us/library/ms995355.aspx.

Bleiben wir zunächst bei Powershell. Michal Grzegorzewski hat auf seiner Seite die Einträge mittels Debugger auseinandergenommen, hier die englische Übersetzung mittels Google: http://translate.googleusercontent.com/translate_c?depth=1&hl=de&prev=_dd&rurl=translate.google.de&sl=auto&tl=en&u=http://zine.net.pl/blogs/mgrzeg/archive/2011/03/11/dpapi-internals-a-securestring-w-powershellu.aspx&usg=ALkJrhhOdJ83W5rHYAcEnuML-v-KZ1KqNw. Dabei hat er festgestellt, dass Powershell die Methode Protect aus der ProtectedData Klasse aus dem .Net-Framework verwendet. http://msdn.microsoft.com/de-de/library/system.security.cryptography.protecteddata.protect.aspx. Protect verwendet wiederum CryptProtectData aus Crypt32.dll. http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.110).aspx. Ein Punkt der bei Powershells ConvertFrom-SecureString und ConvertTo-SecureString zu kurz kommt, ist die Sache dass es sich um benutzerbezogene Verschlüsselungen handelt. D. h. ein Passwort welches mittels ConvertFrom-SecureString als verschlüsselter Standardstring konvertiert und gespeichert wurde, kann nur von dem selben Benutzer auf dem ursprünglichen Rechner wieder gelesen und verwendet werden! Um die Sache dann noch weiter zu komplizieren, sei noch darauf hingewiesen, dass das verwendete Passwort des Benutzers auch noch eine Rolle spielt, was wiederum beim Zurücksetzten von Passwörtern wichtig werden kann: http://support.microsoft.com/kb/309408. Zu welchen Probleme das benutzerbezogene Speichern führen kann, schildert schön dieser Artikel: http://blog.codeassassin.com/2012/05/17/powershell-remoting-user-profiles-delegation-and-dpapi/.

Im zweiten Bereich seines ersten Blogeintrags unter “DAPI Internals” streift Grzegorzewski noch die Geschichte von Masterkeys und dass auf jedem Windows immer die vorhergehenden Keys gespeichert sein müssen, um auf ältere, verschlüsselte Daten zurückgreifen zu können. Thema CREDHIST. Aber das Thema lassen wir außen vor. Im zweiten Blog-Artikel geht er dann noch näher auf die Internas von DAPI Blobs ein http://translate.google.de/translate?hl=de&sl=auto&tl=en&prev=_dd&u=http%3A%2F%2Fzine.net.pl%2Fblogs%2Fmgrzeg%2Farchive%2F2011%2F03%2F30%2Fdpapi-internals-a-securestring-w-powershellu-cz-2.aspx. Dort nennt er Picod and Bursztein, welche das Tool libDPAPIck.dll, zu finden unter http://dpapick.com/ entwickelt haben. Das Tool erlaubt das Lesen von EFS-verschlüsselten Laufwerken von Linux oder anderen Offlinesystemen aus.

So nach dem kleinen Ausflug, wieder zurück zum Thema SecureStrings und Powershell. Im ersten Artikel https://newyear2006.wordpress.com/2012/12/30/spa-mit-net-securestring-und-powershell-oder-sicheres-speichern-und-einlesen-von-passwrtern/ wurde ja schon gezeigt, wie man ein Passwort wiederherstellen und sichtbar machen kann. Nun wollen wir die von Grzegorzewski verwendete Methode mittels Powershell auf den verschlüsselten Standardstring anwenden.

Wir haben also aus unserem ersten Artikel die Zeichenfolge

01000000d08c9ddf0115d1118c7a00c04fc297eb01000000d13e0b3adb59f6469325c229ee5b0d520000000002000000000003660000c0000000100
00000d57efc5b5ccd1e52e71296ec9b91a3530000000004800000a0000000100000006b946cd8b1c877db8c8ae6f39f4932bd10000000858fb31747
0ef57f405d954a5857409a14000000e2154da0885013dc5dbf21097c61c1d429f1e8ce

Dabei handelt es sich um einen Hexstring. Für den Aufruf von Unprotect http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.unprotect wird als Parameter ein Bytearray benötigt. Dazu benötigen wir als erstes eine Hilfsfunktion, welche den verschlüsselten Standardstring in ein ByteArray umwandelt, diese gibt es hier: http://www.sans.org/windows-security/2010/02/11/powershell-byte-array-hex-convert und nennt sich Convert-HexStringToByteArray. Also los gehts:

# $es enthält obigen String
Import-Module .\HexHelper.PS1
$eb=Convert-HexStringToByteArray $es
$mb=[System.Security.Cryptography.ProtectedData]::Unprotect($eb,$null,"CurrentUser")
[System.Text.Encoding]::Unicode.GetString($mb)

Zurück bekommen wir dann das ursprüngliche “Hallo”.

Dabei gibt es noch ein paar Dinge zu beachten. Der Aufruf von Unprotect funktioniert erst, wenn davor ConvertFrom-SecureString bereits benutzt wurde! Falls dies nicht der Fall ist, bekommt man die Fehlermeldung

Der Typ [System.Security.Cryptography.ProtectedData] wurde nicht gefunden: Vergewissern Sie sich, dass die Assembly, die diesen Typ usw…

Zum Warmlaufen kann man diesen Befehl vorher verwenden:

Read-Host – AsSecureString | ConvertFrom-SecureString

Wie oben bereits geschrieben, die Strings sind immer benutzerbezogen, wenn man also den String auf einer anderen Maschine versucht zu verarbeiten, erhält man die Meldung:

Ausnahme beim Aufrufen von "Unprotect" mit 3 Argument(en):  “Schlüssel ist im angegebenen Status nicht gültig."

Spaß mit .Net SecureString und Powershell oder sicheres Speichern und Einlesen von Passwörtern

Wer sich per .Net dem Thema SecureString annähert wird sich irgendwann fragen: “Warum bekomm ich den hinterlegten String nicht einfach zurück?”. Tja die Sache liegt in der Natur des SecureString selber. Er soll sicher sein!

Fangen wir mal mit einer einfachen Geschichte an, man möchte ein Passwort sicher eingeben:

PS> $pw=Read-Host –AsSecureString
*****
PS>

Sieht schon mal gut aus. Meine Passworteingabe lautete Hallo und es wurden aber nur Sternchen angezeigt. Wer jetzt denkt, man bekommt bei Abfrage von $pw das Passwort der täuscht sich:

PS> $pw
System.Security.SecureString

OK, dann halt über ein Property?

PS> $pw | Get-Member

   TypeName: System.Security.SecureString

Name         MemberType Definition
—-         ———- ———-
AppendChar   Method     void AppendChar(char c)
Clear        Method     void Clear()
Copy         Method     securestring Copy()
Dispose      Method     void Dispose(), void IDisposable.Dispose()
Equals       Method     bool Equals(System.Object obj)
GetHashCode  Method     int GetHashCode()
GetType      Method     type GetType()
InsertAt     Method     void InsertAt(int index, char c)
IsReadOnly   Method     bool IsReadOnly()
MakeReadOnly Method     void MakeReadOnly()
RemoveAt     Method     void RemoveAt(int index)
SetAt        Method     void SetAt(int index, char c)
ToString     Method     string ToString()
Length       Property   int Length {get;}

Na supi! Nur Length ist als Property vorhanden. Na dann vielleicht ToString()?

PS> $pw.ToString()
System.Security.SecureString

Nene, das Ding soll ja sicher sein!

Übrigens was gibt Length zurück?

PS> $pw.Length
5

Das würde passen, “Hallo” hat genau fünf Buchstaben. Kurz gesagt, es gibt keine direkte Möglichkeit den String zurückzubekommen.

Wofür braucht man nun das Ding? Die aktuelle Beschreibung auf MSDN (V4.5), gibt keinen Tipp. http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx

Also mal etwas recherchiert:

• Bei Kryptographie-Provider: http://msdn.microsoft.com/en-us/library/system.security.cryptography.cspparameters.aspx kennt einen Konstruktor, welcher einen SecureString entgegennehmen kann:
  http://msdn.microsoft.com/en-us/library/ms148034.aspx
• Auch bei Zertifikaten kann ein SecureString angewendet werden: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.aspx
• Beim Starten von Prozessen: http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx
• Unter WPF mit einer sicheren Passworteingabe: http://msdn.microsoft.com/en-us/library/system.windows.controls.passwordbox.aspx

Sicher gibt es noch mehr Stellen, aber die kleine Auswahl sollte erst mal reichen.

OK, der Anwendungszweck gegeben, aber was kann ich damit anfangen? Vor allem im Zusammenhang mit Powershell? Ein erster Hinweis steht in der SecureString Doku auf MSDN:

Note that SecureString has no members that inspect, compare, or convert the value of a SecureString. The absence of such members helps protect the value of the instance from accidental or malicious exposure. Use appropriate members of the System.Runtime.InteropServices.Marshal class, such as the SecureStringToBSTR method, to manipulate the value of a SecureString object.

Aha, man muss also in die Niederungen der InteropServices absteigen. Dann legen wir gleich mal los:

PS> $BSTR=[System.Runtime.InteropServices.marshal]::SecureStringToBSTR($pw)
PS> $BSTR
39018744
PS> $pws = [System.Runtime.InteropServices.marshal]::PtrToStringAuto($BSTR)
PS> $pws
Hallo
PS> [System.Runtime.InteropServices.marshal]::ZeroFreeBSTR($BSTR)

Hier findet nun die ganze Show statt. Zuerst holt man sich mittels SecureStringToBSTR die ursprüngliche Eingabe und einen Pointer auf die Stelle, wo der String nun temporär abgelegt wird. Bei PtrToStringAuto wird der temporäre String ausgelesen, zurückgegeben und in $pws gespeichert. Mit ZeroFreeBSTR wird der temporäre String wieder freigegeben, bzw der temporäre Speicherplatz mit Nullen überschrieben (Secure!). Blöd nur, dass wir das Passwort nun in $pws haben, denn ab nun ist die Sache nicht mehr sicher!!

Hier noch der Link zu SecureStringToBSTR: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.securestringtobstr.aspx

Damit schließt sich der Kreis. Aber Moment, da geht noch mehr.

Passwörter in Dateien speichern
Es gibt nämlich die tollen Funktionen ConvertTo-SecureString und ConvertFrom-SecureString. Wer glaubt, damit ließe sich obige Prozedur abkürzen, der täuscht sich. Denn diese dienen nur dazu den SecureString zu serialisieren bzw. in einen Standard-String zu wandeln, um ihn z. B. in einer Datei speichern zu können.

Machen wir genau dies und speichern unseren String mal in einer Datei, dazu wandeln wir ihn zuerst, lassen ihn ausgeben und prüfen ob es ein String ist:

PS> $pwe = ConvertFrom-SecureString –SecureString $pw
PS> $pwe
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000d13e0b3adb59f6469325c229ee5b0d520000000002000000000003660000c0000000100
00000d57efc5b5ccd1e52e71296ec9b91a3530000000004800000a0000000100000006b946cd8b1c877db8c8ae6f39f4932bd10000000858fb31747
0ef57f405d954a5857409a14000000e2154da0885013dc5dbf21097c61c1d429f1e8ce
PS> $pwe.GetType()

IsPublic IsSerial Name                                     BaseType
——– ——– —-                                     ——–
True     True     String                                   System.Object

PS> Set-Content –Value $pwe –Path pwenc.txt
PS> type .\pwenc.txt
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000d13e0b3adb59f6469325c229ee5b0d520000000002000000000003660000c0000000100
00000d57efc5b5ccd1e52e71296ec9b91a3530000000004800000a0000000100000006b946cd8b1c877db8c8ae6f39f4932bd10000000858fb31747
0ef57f405d954a5857409a14000000e2154da0885013dc5dbf21097c61c1d429f1e8ce

Perfekt. Damit hat man eine saubere Möglichkeit gefunden Passwörter sicher abzuspeichern. Um sicher zu gehen, dass dem so ist, muss man die Sache natürlich auch wieder rückwärts machen können.

SecureString-Passwörter aus Dateien auslesen
Die Geschichte ist einfach erzählt

PS> $pw=Get-Content pwenc.txt | ConvertTo-SecureString

Damit kann man $pw wieder bei SecureStringToBSTR, wie oben gezeigt anwenden und bekommt das gespeicherte Passwort im Klartext zurück.

Fehlermeldungen bei Installation von Programmen die das .Net Framework 3.5 unter Windows 8 oder Windows Server 2012 benötigen

Wenn es Probleme bei der Installation einer Anwendung gibt, die dass .Net Framework 3.5 benötigt, so könnten aktuell drei verschiedene Fehlernummern auftauchen. In allen drei Fällen gibt es unterschiedliche Gründe warum es nicht klappt. Sei es der Download funktioniert nicht oder die Dateien sind im hinterlegten Pfad nicht zu finden.

0x800F0906 – CBS_E_DOWNLOAD_FAILURE

0x800F081F – CBS_E_SOURCE_MISSING

0x800F0907 – CBS_E_GROUPPOLICY_DISALLOWED

Wie man das Problem löst und wie man am besten vorgeht, beschreibt dieser Artikel: http://support.microsoft.com/kb/2734782/en-us

Weitere Infos hält auch dieser Artikel parat: http://msdn.microsoft.com/library/windows/hardware/hh975396

MSBuild.EXE ist im Extended .Net Framework 4.0 enthalten

Um bestimmte Build-Skripte auf einem Rechner laufen zu lassen, die auf MSBUILD.EXE der Version 4 beruhen, wird das Extended .Net Framework 4.0 benötigt. Es reicht nicht die Client Version.

http://www.microsoft.com/downloads/de-de/details.aspx?familyid=0a391abd-25c1-4fc0-919f-b21f31ab88b7&displaylang=de

oder für Core Server:

http://www.microsoft.com/downloads/de-de/details.aspx?familyid=c2794455-274d-4363-ade6-e69008a24d8a&displaylang=de

Top Einführung in PNRP per NETSH

Was man mit den Clouds von PNRP bei IPv6 alles anstellen, zeigt sehr einfach dieser Screencast: http://channel9.msdn.com/Blogs/SlickThought/Peer-to-Peer-Series-Part-1-Intro-to-PNRP

Daneben wird auch die komplette Programmierung über das .Net-Framework gezeigt:
http://channel9.msdn.com/Blogs/SlickThought/Peer-to-Peer-Series-Part-2-Registering-Names-with-PNRP-API

COPY CON unter Powershell

Leider funktioniert COPY CON unter Powershell nicht, da CON nicht mehr als Eingabekonsole erkannt wird. Es gibt nun aufwendige Geschichten, wie z. B. http://www.nivot.org/nivot2/post/2008/04/02/HowToCopyConTexttxt
InPowerShellUpdated.aspx.

Aber wenn man mal auf die schnelle auf einem anderen Rechner ein paar Befehle speichern muss, dann hilft folgendes:

[System.Console]::in.ReadToEnd() > meineDatei.ps1

Am Ende wird wie gewohnt mit F6 oder STRG+Z abgeschlossen.

Etwas spannender, vor allem kürzer ist die Variante:

PS C:\temp> ‘
>>Mein Text
>>’ > test.txt
>>

Entscheidend ist das einfache obere Anführungszeichen, danach kann man beliebig viele Zeilen schreiben. Abgeschlossen wird wieder mit oberem Anführungszeichen. Gespeichert wird dann durch das Weiterleiten mit > an die Datei test.txt. Am Ende um >> los zu werden, muss noch einmal Return eingegeben werden.

In beiden Varianten stehen mit den Pfeiltasten die Eingabehistorie ganz normal zu Verfügung.