Archive for the ‘Powershell’ Category

Informationen zu installierten Codecs unter Windows abfragen

16 Juli 2015

Dieses Thema kann schnell ausarten und kompliziert werden. Aber die einfachste Art sich dem Thema zu nähern ist WMI.

So listet dieser Powershellbefehl alle verfügbaren Codecs auf einem Windows-System auf:

(get-item (gwmi win32_codecfile).name).VersionInfo.filedescription

Unter Windows 10 Pro (Build 10158) erhält man diese Auflistung:

IMA ADPCM CODEC für MSACM
Toshiba Video Codec
Microsoft GSM 6.10 Audio CODEC für MSACM
Intel Indeo(R) Video YUV Codec
Microsoft CCITT G.711 (A-Law und u-Law) CODEC für MSACM
MPEG Layer-3 Audio Codec for MSACM
Microsoft RLE Compressor
Microsoft Video 1-Komprimierungsprogramm
Microsoft UYVY Video Decompressor
Microsoft ADPCM CODEC für MSACM

Bessere Infos gibt es hiermit:

(get-item (gwmi win32_codecfile).name).VersionInfo | select -Property fileversion, filen*, filed*

FileVersion                               FileName                         FileDescription
———–                               ——–                         —————
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\IMAADP32.ACM IMA ADPCM CODEC für MSACM
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\MSRLE32.DLL  Microsoft RLE Compressor
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\IYUV_32.DLL  Intel Indeo(R) Video YUV Codec
1, 9, 0, 0401                             C:\WINDOWS\system32\L3CODECA.ACM MPEG Layer-3 Audio Codec for MSACM
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\MSG711.ACM   Microsoft CCITT G.711 (A-Law und u-Law) C…
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\MSGSM32.ACM  Microsoft GSM 6.10 Audio CODEC für MSACM
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\MSYUV.DLL    Microsoft UYVY Video Decompressor
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\MSADP32.ACM  Microsoft ADPCM CODEC für MSACM
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\MSVIDC32.DLL Microsoft Video 1-Komprimierungsprogramm
10.0.10158.0 (fbl_impressive.150625-1753) C:\WINDOWS\system32\TSBYUV.DLL   Toshiba Video Codec

Wer zu viele Codecs hat oder nur an einer bestimmten Gruppe an Codecs interessiert ist, der kann auch einen Filter setzen:

(get-item (gwmi win32_codecfile -Filter ‘group="audio"’).name).versioninfo.filedescription

hier werden dann nur die Audiocodecs angezeigt. Und warum nun der ganze Aufwand? Mich interessierte ob Windows 10 vielleicht schon den neuen Opus Audio Codec mitbringt, der scheinbar alles vom Platz fegen soll, was seither so angesagt war. Außerdem wird er von WebRTC.

Leider ist der Opus Codec in obiger Auflistung bei Windows 10 nicht enthalten. Schade. Hier mehr Infos zum Opus Codec und dessen Qualitäten: http://opus-codec.org/comparison/. Das beste ist er hat ein eignes RFC und ist Open Source und Roalty Free: http://tools.ietf.org/html/rfc6716.

Temporäre Dateien in Powershell erzeugen

30 April 2015

Lange hat es gedauert aber jetzt ist sie da. Microsoft hat in der April 2015 Preview für Powershell 5.0 eine Funktion für temporäre Dateien implementiert. New-TemporaryFile erzeugt eine temporäre Datei und gibt dessen Dateinamen in Form eines FileInfo-Objekt zurück.

Leider gibt es New-TemporaryFile nicht bei alten Versionen. Aber es gibt ja Polyfills. Hintergründe wie man Polyfills in Powershell erzeugen kann, kann man hier nachlesen: https://newyear2006.wordpress.com/2014/11/17/fehlende-cmdlets-in-powershell-durch-polyfills-nachbilden/.

Auf dieser Basis kann man mittels dieses Scripts die fehlende Funktion nachrüsten:

if (-not (Get-Command New-TemporaryFile -ErrorAction SilentlyContinue)) {
  &{ Function global:New-TemporaryFile ($Parameter) {
            [System.IO.FileInfo][System.IO.Path]::GetTempFileName()
        }
    }
}

Somit kann man bei älteren Powershell-Skripte bereits Funktionen nutzen, welche noch nicht verfügbar sind.

DER Einführungsartikel in WMI/CIM/OMI und Remoting mit Powershell

28 April 2015

Unten stehender Link sollte für jeden Pflicht werden, der irgendwie etwas mit Powershell anfängt. Denn der Artikel bringt die Microsoft Begriffssuppe mit den Dingen DCOM, WMI, CIM, OMI, WS-Man, WS-Management, WinRM usw. alles klar und deutlich in die richtige Perspektive, vor allem auch in Bezug WS-Man.

http://powershell.org/wp/2015/04/24/management-information-the-omicimwmimidmtf-dictionary/

Malware-Plage und jetzt auch noch Superfish

22 Februar 2015

Es wird immer schlimmer und keiner blickt mehr richtig durch. Das ganze TLS und Zertifikatsgedöns ist nicht nur kompliziert, sondern kann auch schön ausgehebelt werden. Aktuelles Beispiel Visual Search bzw. Visual Discovery von Superfish.

Nicht nur, dass es Leute gibt, die sich bewusst oder unbewusst irgendwelche schrottigen Onlinevergleichstools auf den Rechner laden und dadurch massiv ausspioniert werden bzw. tolle Werbeeinblendungen bekommen, nein jetzt werden auch noch Rechner ab Werk mit solchen Programmen ausgeliefert.

Heise Online meldet:

Ab sofort können sich Cyber-Gangs online gegenüber Besitzern von vielen Lenovo-Laptos mit einer beliebigen Identität ausweisen und gefährliche Man-in-the-Middle-Angriffe tätigen.
http://www.heise.de/newsticker/meldung/Lenovo-Laptops-Sicherheitsluecke-erreicht-kritisches-Stadium-2555934.html

Die Vorgehensweise, die Sache ausnutzen zu können ist dabei recht einfach. Robert Graham zeigt mit einfachsten Mitteln, wie es geht. http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html. Er startet einfach die Malware und erzeugt mittels Procdump von Sysinternals einen Speicherdump des Prozesses. Danach holt er sich wiederum mittels Sysinternals-Tool Strings alle Strings aus dem Dump. Schwupps hat er den privaten Schlüssel des Zertifikats. Normalerweise müsste man nun das Passwort für den privaten Schlüssel brutforcen. Aber das kann dauern. Also geht er einfach her und verwendet eine Dictionary-Attacke. Doch zunächst ohne Erfolg. Dann denkt er sich, vielleicht ist das Passwort ja im Stringdump enthalten und schwupps hat er es: “komodia”.

Warum ist dies nun alles so gefährlich? Ein schöner einleitenden Artikel bringt wiederum Robert Graham: http://blog.erratasec.com/2015/02/some-notes-on-superfish.html. Die Quintessenz daraus ist, auch wenn man die Malware deinstalliert, dass Stammzertifikat bleibt immer noch auf dem Rechner und erlaubt später problemlos “Man in the middle”-Attacken.

Damit nicht alles graue Theorie bleibt, geht wiederum Robert Graham zum Beweis über und bastelt mittels Raspberry Pi ein plastisches Beispiel. Mittels eines Pi für 40€, einem WLAN-Modul für 15€, einer Speicherkarte für 5€ bastelt er einen Man in the Middle Proxy. dazu verwendet er SSLSplit und die Zertifikate und Passwörter von Superfish und kann nun problemlos seine verschlüsselte TLS-Kommunikation mitlesen. http://blog.erratasec.com/2015/02/exploiting-superfish-certificate.html. Natürlich muss es nicht ein Pi sein, sondern kann jede x-beliebige Maschine sein, es geht nur darum deutlich zu machen, dass so ein kleines Stück Hardware für solche Attacken nicht teuer sein muss.

Ach und aus Erfahrung kann ich sagen, dass Rechner, bei denen so eine Spionagesoftware mal nicht richtig funktioniert, massiv Probleme mit ihrer Internetverbindung haben und der unbedarfte Benutzer ständig komische Fehlermeldungen zwecks Proxy und so Gedöns an den Latz geknallt bekommt.

Hier noch ein paar Powershell-Befehle mittels derer man das Superfish-Zertifikat ermitteln kann:

dir cert:\ -Recurse| where {$_.Subject -match "Superfish"}

oder direkt per Fingerprint:

dir cert:\ -Recurse| where {$_.Thumbprint -eq "C864484869D41D2B0D32319C5A62F9315AAF2CBD"}

Wer braucht da noch nen Staatstrojaner, wenn die Computerhersteller bereits alles dafür tun, die Geräte mit Malware auszustatten. Interessant in diesem Zusammenhang ist noch dieses: http://blog.fefe.de/?ts=aa16d2ff. Der große Bruder lässt grüßen…

Format-Hex für Powershell

28 Dezember 2014

Soviel man mit Powershell auch machen kann eine entscheidende Funktion die fehlt ist Format-Hex, um z. B. eine Datei oder ein Bytearray als Hexdump ausgeben zu können.

Aber wie immer gibt es Lösungen im Internet. So hat Lee Holmes die Funktion bereits gebaut. Die Version ist gut aber besser ist die etwas erweiterte und fehlerbereinigte Version, die hier zu finden ist: https://gist.github.com/newyear2006/aae98d1c9c2fbdaba179.

Damit kann man ganz einfach Dinge machen wie z. B.

"Hallo Welt"| Format-Hex

Was dann zur Ausgabe hat:

          0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F

00000000 48 00 61 00 6C 00 6C 00 6F 00 20 00 57 00 65 00  H.a.l.l.o. .W.e.
00000010 6C 00 74 00                                      l.t.
          

Mit dem Paramter –NoHeader sieht es dann so aus:

00000000 48 00 61 00 6C 00 6C 00 6F 00 20 00 57 00 65 00  H.a.l.l.o. .W.e.
00000010 6C 00 74 00                                      l.t.
          

Mit zusätzlicher Angabe von –NoCounter siehts so aus:

48 00 61 00 6C 00 6C 00 6F 00 20 00 57 00 65 00  H.a.l.l.o. .W.e.
6C 00 74 00                                      l.t.
          

Aber man ist nicht begrenzt auf die Ausgabe von Strings, sondern kann auch Bytearrays ausgeben:

$text = "Hallo Wörld!"
$bytes = [System.Text.Encoding]::UTF8.GetBytes($text)
$bytes | Format-Hex -NoHeader -NoCounter

sieht dann so aus:

48 61 6C 6C 6F 20 57 C3 B6 72 6C 64 21       Hallo Wörld!

Hier sieht man nun deutlich die Umwandlung des ö in zwei Bytes bei UTF8 mittels C3 B6.

Hier gibts noch weitere Powershell Hex-Funktionen: https://newyear2006.wordpress.com/2011/06/20/powershell-und-byte-array-sowie-hex-funktionen/

Zertifikatsdialoge aus Powershell heraus anzeigen

28 Dezember 2014

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

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.

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.

Geblockte Dateien von Downloads zulassen

7 Oktober 2014

Wenn man Dateien unter Windows aus dem Internet lädt, werden diese mit dem sogenannten Zone.Identifier in einem Alternate-Data-Stream erweitert. Ist der Zone.Identifier vorhanden und ein Eintrag unter der Sektion [ZoneTransfer] mit ZoneID=3 gesetzt, reagieren viele Windows Programme anders. Bei EXE-Dateien erscheint immer zusätzlich eine Rückfrage, ob die Datei geöffnet werden soll.

Im Explorer lässt sich die Information entfernen, wenn man die Eigenschaften der Datei mittels Rechtsklick öffnet und Zulassen anklickt.

In der Eingabeaufforderung wird die Sache etwas schwieriger. Es sei denn man hat Powershell 3.0 oder höher. Dort gibt es den Befehl Unblock-File.  http://technet.microsoft.com/en-us/library/hh849924.aspx

Wer das Problem hat, nur Powershell 2.0 zur Verfügung zu haben, der wird sich über diese Powershell-Funktion freuen: http://andyarismendi.blogspot.de/2012/02/unblocking-files-with-powershell.html.

Allgemein zum Thema: http://stackoverflow.com/questions/1617509/unblock-a-file-with-powershell. Weitere Möglichkeiten: http://www.robvanderwoude.com/amb_filestreams.php

Von Sysinternals gäb es auch noch was: Streams: http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx

Protokoll zu Alternate Data Streams: http://msdn.microsoft.com/en-us/library/dd433166.aspx

Drucker mittels Powershell in Windows 8.1 kopieren

30 September 2014

Leider gibt es seit Jahren unter Windows keine einfache Möglichkeit einen Drucker zu kopieren. Gemeint sind die Drucker die nach Aufruf von

Control Printers

angezeigt werden.

Dank Powershell ist dies nun unter Windows 8.1 mit den Drucker-Cmdlets  sehr einfach möglich.

Man ruft einfach

Get-Printer | Out-GridView -Title "Quelldrucker auswählen" -PassThru | foreach {Add-Printer -DriverName $_.DriverName -Name "$($_.Name) Kopie" -PortName $_.PortName}

auf und bekommt eine Auswahl der installierten Drucker angezeigt, kann den gewünschten auswählen und klickt auf OK. Man bekommt den neuen Drucker mit dem Namen des alten und dem Anhängsel Kopie angelegt.

Wie immer gibt es aber eine Ausnahme: Leider funktioniert obige Methode nicht bei Druckern die von einem anderen Rechner kommen, die also über die Variante \\Server\Freigabe angesprochen werden. Wird solch ein Drucker versucht zu kopieren, erscheint diese Fehlermeldung:

Add-Printer : Der angegebene Anschluss ist nicht vorhanden. Verwenden Sie "add-printerport", um einen neuen Anschluss hinzuzufügen, oder geben Sie einen vorhandenen
Anschluss an.
In Zeile:1 Zeichen:81
+ Get-Printer | Out-GridView -Title "Quelldrucker auswählen" -PassThru | foreach { …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Add-Printer], CimException
    + FullyQualifiedErrorId : HRESULT 0x80070704,Add-Printer

Wenn man man einen Drucker kopiert hat, fällt auf, dass dieser nicht unbedingt direkt zu sehen ist. In diesem Fall ist dieser Artikel interessant: https://newyear2006.wordpress.com/2014/07/09/gruppierung-bei-windows-druckern-aufheben/

Leider werden bei obiger Methode noch nicht die Einstellungen des zu kopierenden Druckers mitübertragen. D. h. die Kopie des Druckers hat immer die Standardeinstellungen, wie nach einer Neuinstallation des Druckertreibers. Dazu aber ein anderes Mal mehr…


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.