Abgelaufene Aktivierungen erschweren einem das Leben unter Windows und wie man diese zurücksetzen kann

30 August 2015

Wer viel mit virtuellen Maschinen zu tun hat, der kennt vielleicht das Problem, man macht schnell eine Kopie eine VHD oder VHDX und setzt eine neue Maschine auf um etwas zu testen. Dann gerät die Sache in Vergessenheit und später fragt man sich, um was ging es eigentlich genau. Es ist ja kein Problem das System nochmals hochzufahren und nachzuschauen. Blöd nur, wenn dann auf einmal Microsoft nach der Aktivierung fragt. Noch blöder ist es, wenn man keine Aktivierung durchführen kann, weil man keine ordentliche Internetverbindung zustande bekommt.

Eine Lösung ist seit Windows Vista die Sache mit UTILMAN.EXE. Man benennt UTILMAN.EXE unter WinPE oder WinRE um und kopiert einfach CMD.EXE auf UTILMAN.EXE. Danach kann man am Anmeldebildschirm die Eingabehilfen aktivieren und schwupps öffnet sich die Eingabeaufforderung. Hier eine ausführliche Beschreibung, wie man zum Ziel kommt: https://www.petri.com/bypass-windows-server-2008-activation, hier etwas einfacher: https://www.technibble.com/bypass-windows-logons-utilman/.

Soweit so gut. Aktuell war aber eine Small Business Server 2003 R2 zur Mitarbeit zu überreden. Nur leider funktionierte obige Variante dort nicht. Zum Glück gibt es auch hier eine Alternative, die hier beschrieben steht: https://cyberwaves.wordpress.com/2011/06/20/windows-server-2003-aktivierung-umgehen-circumvent-activation/.

Hier nochmal die wesentlichen Punkte: Beim Aktivierungsassistenten drückt man STRG+L, dann auf Durchsuchen, dort gibt man C:\WIDNOWS\SYSTEM32\*.* ein und sucht dann CMD.EXE, klickt dort mit der rechten Maustaste und wählt “Ausführen als” aus. Man muss zwingend den unteren Eintrag mit der expliziten Anmeldung wählen und seine Anmeldedaten eingeben. Nun öffnet sich eine Eingabeaufforderung.

Leider bleibt diese nicht ewig erhalten, sondern LSASS.EXE sorgt dafür, dass nach einiger Zeit die Shell wieder geschlossen wird. Man kann problemlos wieder eine Shell öffnen. Wenn man etwas mehr Zeit braucht, kann man den Sysinternals Prozessexplorer starten, auch Regedit bleibt dauerhaft erhalten. Warum keine Ahnung, aber scheinbar kann man etwas aktivieren, damit die Programme erhalten bleiben. Durch den Prozessexplorer kann man auch LSASS auf den Suspendstatus setzen allerdings gibt es dadurch später irgendwann stress, durch ungewollte Blockierung.

Hier noch weiteres, interessantes Material: http://blog.didierstevens.com/2006/08/21/playing-with-utilmanexe/

Per Zufall bin ich nun noch auf etwas anderes gestoßen, damit ist die Variante perfekt. Also, wie oben die Eingabeaufforderung öffnen und dann diesen Befehl eingeben:

rundll32.exe syssetup,SetupOobeBnk

Der sorgt dafür, dass nach dem erneuten Start des Servers die Anmeldung ganz normal funktioniert!!

Bilder unter Windows gezielt mit der Windows Fotoanzeige öffnen

30 August 2015

Eine Variante die unter Windows XP – Windows 10 immer verfügbar ist, solange es um übliche Dateiformate wie PNG, BMP, TIFF oder JPG handelt ist die Windows Fotoanzeige. Hier der passende Aufruf:

RunDLL32 "%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll",ImageViewer_Fullscreen C:\temp\test.bmp

Dabei muss der Bilddateiname immer als absoluter Pfad angegeben werden!

Leider kennen die Server Versionen von Windows den Photoviewer nicht.

http://www.autohotkey.com/board/topic/51203-run-rundllexe-photoviewerdll-syntax/

Probleme mit Transportverschlüsselung, Zertifikaten oder Passwörtern bei SMTP-Servern mittels Powershell überprüfen

23 August 2015

Gestern hatte ich schon im Artikel um den Telnet-Client-Ersatz https://newyear2006.wordpress.com/2015/08/22/der-kleine-telnet-client-in-powershell/ ein Beispiel angeführt, wie man einen SMTP-Server anfahren kann. Am entscheidenden Punkt mit dem TLS-Handshake hatte ich aber aufgehört. In der heutigen Zeit, wo im Prinzip alles über ein abgesichertes Transportprotokoll übertragen werden sollte, ein absolutes NoGo. Aus diesem Grund hier die Fortsetzung, wie der TLS-Handshake durchgeführt werden kann.

Vorab noch eines: Die Skripte sind Testskripte um entweder die Funktion oder einen einzelnen Problemfall nachvollziehen zu können. Sie sind nicht dazu gedacht bei irgendwelchen Automationsprojekten eingesetzt zu werden. Denn es fehlen Fehlerabfragen und die ordentliche Freigabe der verwendeten Ressourcen. In diesem Zusammenhang sei auch darauf hingewiesen, wenn mal etwas nicht klappt, einfach das Powershellfenster schließen und ein neues aufmachen, damit die belegten Ressourcen beim Prozessbeenden freigegeben werden. Hier nochmal der Link zum STARTTLS-Kommando und was dabei zu beachten ist: https://tools.ietf.org/html/rfc3207. So nun aber los.

Zunächst nochmal der grundsätzliche Verbindungsaufbau:

# Verbindung zu Web.de aufbauen
$c=Test-NetConnection smtp.web.de -Port 587

# Antwort vom SMTP-Server holen und ausgeben
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# Begrüßung durchführen
$buffer=[System.Text.Encoding]::ASCII.GetBytes("EHLO $Env:Computername`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Antwort vom SMTP-Server holen
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# STARTTLS-Anfrage starten
$buffer=[System.Text.Encoding]::ASCII.GetBytes("STARTTLS`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Bei dieser Antwort sollte 220 rauskommen,
# sonst gibt es ein Problem
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

An diesem Punkt kommt wieder der TLS-Handshake ins Spiel, der nun erfolgen sollte. Wenn man sich so die üblichen Dokus durchschaut, dann würde man meinen, man könnte direkt SslStream-Konstruktor mit dem TcpClientSocket aufrufen. Doch dies klappt leider nicht. Statt dessen muss zunächst ein Networkstream für den Socket erzeugt werden  https://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx. Dieser Punkt ist minimal aber der entscheidende Baustein, denn danach ist alles einfach. Sobald man dann den Socket als SslStream https://msdn.microsoft.com/en-us/library/system.net.security.sslstream.aspx hat, findet man wieder massig Informationen im Netz wie es weitergeht.

# für den weiteren Gang ist entscheidend, dass man einen Stream braucht
# vom Socket erhält man einen Stream, durch Weitergabe an NetworkStream-Klasse
$n=New-Object System.Net.Sockets.NetworkStream $c.TcpClientSocket

# über den Networkstream kann man nun SslStream aktivieren:
$ssl = New-Object System.Net.Security.SslStream $n, $true

Fast geschafft, der eigentliche Handshake https://msdn.microsoft.com/en-us/library/system.net.security.negotiatestream.authenticateasclient(v=vs.110).aspx beginnt hiermit:

# nun kann man den eigentlichen TLS Handshake starten, dazu muss nochmal der Host angegeben werden
$ssl.AuthenticateAsClient($c.ComputerName)

Ab jetzt hat man im Normalfall in $ssl alle Informationen, die man braucht. Somit lässt sich die Verbindung nun grob debuggen. Apropos debuggen, man kann bei Problemen auch das .Net-Tracing-System aktivieren, um mehr Infos bei Problemen zu erhalten, hier hab ich schon mal etwas darüber geschrieben: https://newyear2006.wordpress.com/2014/12/13/fr-powershell-net-framework-tracing-aktivieren/. Wer sich konkret dafür interessiert, was beim TLS-Handshake alles passiert, der möchte diesen Artikel lesen: https://www.simple-talk.com/dotnet/.net-framework/tlsssl-and-.net-framework-4.0/.

Hier nun die Ausgabe von $ssl:

TransportContext          : System.Net.SslStreamContext
IsAuthenticated           : True
IsMutuallyAuthenticated   : False
IsEncrypted               : True
IsSigned                  : True
IsServer                  : False
SslProtocol               : Tls
CheckCertRevocationStatus : False
LocalCertificate          :
RemoteCertificate         : System.Security.Cryptography.X509Certificates.X509Certificate
CipherAlgorithm           : Aes256
CipherStrength            : 256
HashAlgorithm             : Sha1
HashStrength              : 160
KeyExchangeAlgorithm      : 44550
KeyExchangeStrength       : 256
CanSeek                   : False
CanRead                   : True
CanTimeout                : True
CanWrite                  : True
ReadTimeout               : -1
WriteTimeout              : -1
Length                    :
Position                  :
LeaveInnerStreamOpen      : True

Die interessanten Eigenschaften hab ich mal gelb markiert. Hier fällt vor allem auf, dass beim KeyExchangeAlgorithm momentan 44550 steht, welche selbst im .Net-Framework 4.6 nicht dokumentiert ist. Allerdings gibt es eine Erklärung dazu: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d0298622-a7cc-40e8-a4bf-8b74696ff548/sslstreamkeyexchangealgorithm-44550?forum=netfxbcl. Kurz: Beim Wert 44550 handelt es sich um einen ECDH Ephermal. Weitere Infos dazu: https://tools.ietf.org/html/rfc5753#section-3.1.

Weiter wäre zu bemerken, dass die Eigenschaft SslProtocol auf Tls steht, was gleichbedeutend mit TLS 1.0 ist. Aktuell sollte immer TLS 1.2 verwendet werden. Hier stellt sich die Frage, liegt es am Server oder liegt es am Client, sprich in diesem Fall am .Net Framework? Diese Frage wollen wir ein anderes Mal betrachten.

Man kann auch das erhaltene Zertifikat abfragen:

$ssl.RemoteCertificate.ToString($true)
[Subject]
  CN=smtp.web.de, E=server-certs@1und1.de, L=Montabaur, S=Rhineland-Palatinate, OU=WEB.DE, O=1&1 Mail & Media GmbH, C=DE

[Issuer]
  CN=TeleSec ServerPass DE-1, STREET=Untere Industriestr. 20, L=Netphen, PostalCode=57250, S=NRW, OU=T-Systems Trust Center, O=T-Systems Internatio
nal GmbH, C=DE

[Serial Number]
  00A684C2D320436B39

[Not Before]
  21.08.2013 10:35:51

[Not After]
  27.08.2016 01:59:59

[Thumbprint]
  40051058DE6797D8ACFAF55224CF5282F44E0B5D

Falls beim TLS-Handshake etwas schief gehen sollte, dann hat dies meist mit den Zertifikaten zu tun. Wie man diesem Problem auf den Grund gehen kann, habe ich in einem früheren Blogartikel bereits beschrieben: https://newyear2006.wordpress.com/2014/01/04/ssltls-fehler-in-powershell-bzw-wie-man-zertifikatsprobleme-unter-windows-analysieren-kann/.

OK jetzt sind wir schon so weit gekommen, wäre schön, wenn man jetzt noch prüfen könnte, ob der Benutzer tatsächlich seine SMTP-Zugangsdaten kennt. Dazu richten wir einen Reader- und Writer- vom SSL-Stream ein, senden nochmals das obligatorische EHLO und anschließend die gewünschte Authentifizierungsmethode, hier LOGIN:

# für die weitere Kommunikation richtet man sich am besten zusätzliche Streams ein:
$reader = New-Object System.IO.StreamReader $ssl
$writer = New-Object System.IO.StreamWriter $ssl
$writer.AutoFlush = $true

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("EHLO $Env:Computername")
while ($reader.Peek() -gt -1) {
    $reader.ReadLine()
}

$writer.WriteLine("AUTH LOGIN")
$reader.ReadLine()

Nun liefert der Server ein kryptisches VXNlcm5hbWU6, was ganz einfach Base64 kodiert für Username: steht. Man kann dies ganz einfach prüfen, wenn man diesen Befehl ausführt:

[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("VXNlcm5hbWU6"))

Man sollte nun also den Benutzernamen liefern, z. B. so:

$user = "meinewebdeadresse@web.de"
$cred = Get-Credential -UserName $user -Message "Bitte Passwort eingeben"
$pass = $cred.GetNetworkCredential().Password
$userBytes = [System.Text.Encoding]::ASCII.GetBytes($user)
$userBase64 = [System.Convert]::ToBase64String($userBytes)
$writer.WriteLine($userBase64)
$reader.ReadLine()

$passBytes = [System.Text.Encoding]::ASCII.GetBytes($pass)
$passBase64 = [System.Convert]::ToBase64String($passBytes)
$writer.WriteLine($passBase64)
$reader.ReadLine()

Es wird noch mittels UGFzc3dvcmQ6 nach dem Passwort gefragt, welches, wie der Benutzername auch per Base64 Kodierung geliefert wird. Am Ende sollte man ein

235 Authentication succeeded

sehen, dann weiß man, dass alles korrekt ist.

Möchte man die Verbindung ordentlich beenden, schiebt man noch dieses hinterher:

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("QUIT")
$reader.ReadToEnd();

# Streams und Sockets schließen
$ssl.Close()
$n.Close()
$c.TcpClientSocket.Close()

Hier nochmal alles als GIST zur besseren Lesbarkeit, bzw. bei Erweiterungen: https://gist.github.com/newyear2006/2a6a3fb0cea8dc1063ba

Durch all diese Möglichkeiten zum Debuggen erübrigt sich langsam der Griff nach OpenSSL s_client https://www.openssl.org/docs/manmaster/apps/s_client.html zum Testen von SMTP-Verbindungen.

Der kleine Telnet-Client in Powershell

22 August 2015

Bei neueren Windowsversionen wird mittlerweile der Telnet-Client eingespart, man kann ihn zwar selbst unter Windows 10 nachinstallieren aber wer macht das schon, wenn es ein besseres Werkzeug gibt! Wer ihn braucht, kann diese Methode verwenden: https://newyear2006.wordpress.com/2011/10/01/telnet-auf-die-schnelle-aktiveren-bzw-deaktivieren/.

Telnet wird oft dazu verwendet, zu prüfen, ob eine Verbindung zu einem bestimmten Port möglich ist. Seit Windows 8 gibt es Test-NetConnection, welches weitaus mächtiger als Telnet ist, da es Ping und Tracert auch noch gleich eingebaut hat.

Ein guter Artikel der die Möglichkeiten von Test-NetConnection beschreibt ist dieser ab Abschnitt Testing Connectivity: http://blogs.technet.com/b/networking/archive/2013/07/31/new-networking-diagnostics-with-powershell-in-windows-server-r2.aspx.

Der wichtigste Punkte aus dem Artikel ist aber dieser:

3. When using TNC to test TCP connectivity, if the connection succeeds, you can access the TCP socket using the TCPClientSocket property. This provides the connected .NET socket for further scripting.

OK, dann gleich mal versucht dies umzusetzen. Zunächst testet man die Verbindung, dann reserviert man die für eine Antwort nötigen Bytes eines Puffers, dann ruft man die verfügbaren Bytes ab und gibt diese aus:

$c=tnc www.myserver.de -Port 21
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer, $c.TcpClientSocket.Available, [System.Net.Sockets.SocketFlags]::None)
[System.Text.Encoding]::UTF8.GetString($buffer)

Als Ergebnis erhält man:

220 Microsoft FTP Service

Genauso wie gegen einen FTP-Port kann man den Test auch gegen einen SMTP-Server laufen lassen, man muss nur Port 25 oder 587 angeben.

Man kann das Thema nun aber auch ausbauen und kann die gesamte Kommunikation skripten:

# Verbindung zu Web.de aufbauen
$c=tnc smtp.web.de -Port 587

# Antwort vom SMTP-Server holen und ausgeben
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# Begrüßung durchführen
$buffer=[System.Text.Encoding]::ASCII.GetBytes("EHLO $Env:Computername`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Antwort vom SMTP-Server holen
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# STARTTLS-Anfrage starten
$buffer=[System.Text.Encoding]::ASCII.GetBytes("STARTTLS`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Bei dieser Antwort sollte 220 rauskommen,
# sonst gibt es ein Problem
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

Jetzt wäre der TLS Handshake dran, den sparen wir uns für ein anderes Mal auf…

Hier noch das STARTTLS-RFC-Dokument: https://tools.ietf.org/html/rfc3207

Wer einen interaktiven Powershell-Telnet-Client benötigt, der wird hier fündig: http://uglygizmo.blogspot.de/2013/10/a-telnet-client-written-in-powershell.html.

Neue Parameter für New-SelfSignedCertificate

21 August 2015

Per Zufall bin ich heute über eine interessante Sache gestoßen. Bereits mit Windows 8 wurden die PKI-Powershell Cmdlets eingeführt. Mit enthalten ist New-SelfSignedCertificate. Das Problem dabei war, dass das Anwendungsgebiet des Cmdlets wegen fehlender Paramater ziemlich limitiert war.

Als ich heute unter Windows 10 New-SelfSignedCertficate verwendete und mittels TAB-Taste die Parametervervollständigung nutzte, wunderte ich mich nicht schlecht, als auf einmal eine Fülle von unbekannten Parametern auftauchte. Darunter waren so Dinge Extension, KeyUsage, KeyProtection.

Durch die Fülle der Parameter war ich etwas überfordert und mich interessierte vor allem eine komplette Auflistung der Parameter. Wie in Powershell üblich verwendet man dazu Get-Help:

PS > get-help New-SelfSignedCertificate

NAME
    New-SelfSignedCertificate

ÜBERSICHT
    Creates a new self-signed certificate for testing purposes.

SYNTAX
    New-SelfSignedCertificate [-CertStoreLocation <String>] [-CloneCert <Certificate>] [-DnsName <String>] [-Confirm]
    [-WhatIf] [<CommonParameters>]

BESCHREIBUNG
    The New-SelfSignedCertificate cmdlet creates a self-signed certificate for testing purposes. Using the CloneCert

Mmmhh, das war irgendwie nicht das was ich erwartet hatte. OK, vielleicht hilft ein Update der Hilfe, also Update-Help durchgeführt. Leider war das Ergebnis unverändert. Nun noch der Versucht online etwas mehr Infos zu bekommen, mittels

Get-Help New-SelfSignedCertificate –Online

Aber wieder nix. Ganz im Gegenteil, man landet momentan noch auf der Hilfeseite von Windows Server 2012 R2 und Windows 8.1 Hilfe. Mal wieder ein ganz mieses Qualitätsmanagement von Microsoft. Auf der anderen Seite kann man sagen, das ist so gewollt, weil vielleicht doch noch Beta.

Da Powershell wegen seiner flexiblen Innereien so genial ist, gibt es vielleicht noch eine andere Möglichkeit herauszufinden, was Sache ist. Wenn schon Get-Help die falsche Syntax hat, aber die TAB-Vervollständigung die ganzen Parameter kennt, dann kann man diese Parameter sicher auch abfragen. Dem ist tatsächlich so:

PS > $P= get-command New-SelfSignedCertificate
PS > $p.Parameters

Key                         Value
—                         —–
SecurityDescriptor          System.Management.Automation.ParameterMetadata
TextExtension               System.Management.Automation.ParameterMetadata
Extension                   System.Management.Automation.ParameterMetadata
HardwareKeyUsage            System.Management.Automation.ParameterMetadata
KeyUsageProperty            System.Management.Automation.ParameterMetadata
KeyUsage                    System.Management.Automation.ParameterMetadata
KeyProtection               System.Management.Automation.ParameterMetadata
KeyExportPolicy             System.Management.Automation.ParameterMetadata
KeyLength                   System.Management.Automation.ParameterMetadata

Um die Sache etwas übersichtlicher zu machen, verwendet man besser:

PS > $p.Parameters.keys | sort
AlternateSignatureAlgorithm
CertStoreLocation
CloneCert
Confirm
Container
CurveExport
Debug
DnsName
ErrorAction
ErrorVariable
ExistingKey
Extension
FriendlyName
HardwareKeyUsage
HashAlgorithm
InformationAction
InformationVariable
KeyAlgorithm
KeyDescription
KeyExportPolicy
KeyFriendlyName
KeyLength
KeyLocation
KeyProtection
KeySpec
KeyUsage
KeyUsageProperty
NotAfter
NotBefore
OutBuffer
OutVariable
Pin
PipelineVariable
Provider
Reader
SecurityDescriptor
SerialNumber
Signer
SignerPin
SignerReader
SmimeCapabilities
Subject
SuppressOid
TestRoot
TextExtension
Type
Verbose
WarningAction
WarningVariable
WhatIf

Alle fett dargestellten Parameter sind neu hinzugekommene. Wie man sieht, eine ganze Menge. Nun weiß man was es gibt aber welche Parameter kann man konkret füttern? Man kann hergehen und alles ausprobieren. Denn es gibt aktuell keinen einzigen Google Suchtreffer mit z. B. New-SelfsignedCertificate mit KeyUsage: https://www.google.com/search?q=new-selfsigncertificate+keyusage&oq=new-selfsigncertificate+keyusage&aqs=chrome..69i57.7167j0j7&sourceid=chrome&es_sm=93&ie=UTF-8#q=%22new-selfsigncertificate%22+%22keyusage%22
Man kann aber auch nachdenken und entdeckt:

Es kam diese Woche die Server 2016 Technical Preview 3 heraus. Was liegt also näher dort mal die Lage zu checken. Gesagt, getan. Tatsächlich sind hier bei Aufruf von Get-Help die Parameter alle verfügbar:

SYNTAX
New-SelfSignedCertificate [-SecurityDescriptor <FileSecurity>]
[-TextExtension <string[]>] [-Extension <X509Extension[]>] [-HardwareKeyUsage <HardwareKeyUsage[]> {None | SignatureKey | EncryptionKey | GenericKey | StorageKey | IdentityKey}] [-KeyUsageProperty <KeyUsageProperty[]> {None | Decrypt | Sign | KeyAgreement | All}] [-KeyUsage <KeyUsage[]> {None | EncipherOnly | CRLSign | CertSign | KeyAgreement | DataEncipherment | KeyEncipherment | NonRepudiation | DigitalSignature | DecipherOnly}] [-KeyProtection <KeyProtection[]> {None | Protect | ProtectHigh | ProtectFingerPrint}] [-KeyExportPolicy <KeyExportPolicy[]> {NonExportable | ExportableEncrypted | Exportable}] [-KeyLength <int>] [-KeyAlgorithm <string>] [-SmimeCapabilities] [-ExistingKey] [-KeyLocation <string>] [-SignerReader <string>) [-Reader <string>] [-Si gnerPin <securestring>] [-Pin <securestring>] [-KeyDescription <string>] [-KeyFriendlyName <string>] [-Container <string>] [-Provider <string>] [-CurveExport <CurveParametersExportType> {None | CurveParameters | CurveName}] [-KeySpec <KeySpec> {None | KeyExchange | Signature}] [-Type <CertificateType> {Custom | CodeSigningCert | DocumentEncryptionCert | SSLServerAuthentication | DocumentEncryptionCertLegacyCsp}] [-FriendlyName <string>] [-NotAfter <datetime>] [-NotBefore <datetime>] [-SerialNumber <string>] [-Subject <string>] [-DnsName <string[]>] [-Suppressoid <string[]> [-HashAlgorithm <string>] [-AlternateSignatureAlgorithm] [-TestRoot] [-Signer <Certificate>] [-CloneCert <Certificate>] [-CertStoreLocation <string>] [-whatlf] [-Confirm] [<CommonParameters>]

Ja das ist doch mal was.

Es geht noch besser, alle Parameteroptionen die beim Server aufgeführt werden, sind auf Windows 10 auch verfügbar! Ja dann kann man ja was daraus machen.

Eine weitere Hilfe stellt die Implementierung von Vadim Podans dar, welcher bereits früher für eine umfassende PKI-Unterstützung in Powershell gesorgt hat. Er hat in der Powershell Script Gallery bereits ein New-SelfSignedCertificate Skript veröffentlicht: https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6.

So das war es zunächst, sinnvolle Anwendungen kommen bei Gelegenheit…

Probleme mit Aktualisierungen von Dateien auf Serverlaufwerk oder Cachingverhalten von Windowsverzeichnissen mit verschiedenen SMB-Versionen

10 August 2015

Die letzten Jahre hat sich im SMB-Protokoll einiges getan. Von ewig lang gar nichts, ging es mit jeder Windowsversion seit Windows Vista schnell voran. Blöd, wenn man eine Anwendung hat, die ein bestimmtes Verhalten von “früher” voraussetzt und in neuen Umgebungen plötzlich Schwierigkeiten macht. Konkret wurde ein Windows Server 2003 durch einen neuere Version ersetzt. Windows Server 2003 kennt nur SMB1. Durch die Umstellung auf den neuen Server wurde automatisch SMB2 aktiviert. Der Client war bereits Windows 7. Und da fingen dann die Probleme an. Im Prinzip kann es jeden treffen der von Server 2003 auf Server 2008 bis Server 2012 R2 umstellt.

So wurde zur Durchsatzoptimierung seit SMB2 ein gewissen Caching von Verzeichnissen eingeführt. Eine Anwendung war nun gewohnt in einem bestimmten Verzeichnis auf das Anlegen einer Antwortdatei zu warten. Dies war in der Regel nach 2-3 Sekunden der Fall. Nach der Umstellung des Server waren es aber regelmäßig mehr als 10 Sekunden. Obwohl mit dem neuen Server alles schneller gehen sollte, war alles langsamer!

Nach vielem hin- und her wurde klar, dass es mit dem veränderten verhalten des Serverlaufwerks auf dem neuen Server zu tun hat. Die Lösung brachte dann:

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
Lanmanworkstation\Parameters" /v DirectoryCacheLifetime /t REG_DWORD /d 3

Damit wurde das Problem behoben, denn der Timeout von vorher 10 Sekunden wurde auf 3 Sekunden verringert. Der Registryeintrag muss am Client geändert werden.

Witzig, ich hatte über den Eintrag schon mal in anderem Zusammenhang geschrieben: https://newyear2006.wordpress.com/2011/05/24/oplocks-oder-opportunistic-locking-lsst-einen-nicht-los-oder-wie-man-alte-16bit-clipper-programme-mit-server-2008-r2-fileshares-ans-laufen-bekommt/

Hier noch ein Artikel mit Übersicht in welcher Kombination welches SMB-Protokoll zum Einsatz kommt: http://blogs.technet.com/b/josebda/archive/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-you-are-using.aspx. Genial ist die Antwort im Kommentarbereich, wie man das SMB-Protokoll vor Windows 8 ermitteln kann: Man nehmen einen Netzwerkmonitor und schneide Pakete mit…

Hier noch die offizielle Erklärung des Registrykeys: https://technet.microsoft.com/en-us/library/ff686200%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396.

Bei diesem Forumseintrag geht es auch um das Thema: https://social.technet.microsoft.com/forums/windowsserver/en-US/67baa9fd-5eaf-438e-9cc4-dc1a531b9e19/disabling-oplocksmb2-vs-fileinfocachelifetime, als offizielle Vorgehensweise bei Problemen wird vorgeschlagen, folgende Reihenfolge einzuhalten:

Recommendations

If you suspect metadata caching in the redirector as cause for misbehaving applications, disable the caches in the following order to determine which of these caches is affecting the application. Disabling the File information cache can have significant effect on client performance and show an increase in the number of metadata requests that are sent to the server.

1. Directory cache, by setting DirectoryCacheLifetime to ZERO.
2. File Not Found cache, by setting FileNotFoundCacheLifetime to ZERO.
3. File information cache, by setting FileInfoCacheLifetime to ZERO.

Na denn…

WMI Provider auflisten

8 August 2015

Ich glaub das Thema WMI Windows Management Instrumentation, eigentlich uralt und gibt es seit Win9x, wird uns die nächsten Jahre noch ziemlich beschäftigen.

Um einen Überblick bei WMI zu bekommen, muss man zunächst die Namespaces und WMI-Provider kennen. Erst daraus kann man dann das große Bild zusammenbauen.

Hier ein einfaches GIST zum Ermitteln der Namespaces und Provider mittels Powershell von Matt Graeber:

https://gist.github.com/mattifestation/2727b6274e4024fd2481

Als Ergebnis bekommt man z. B. diese Auflistung:

Namespace    : ROOT\subscription
ProviderName : LogFileEventConsumer

Namespace    : ROOT\subscription
ProviderName : ActiveScriptEventConsumer

Namespace    : ROOT\subscription
ProviderName : NTEventLogEventConsumer

Namespace    : ROOT\subscription
ProviderName : SMTPEventConsumer

Namespace    : ROOT\subscription
ProviderName : CommandLineEventConsumer

Namespace    : ROOT\DEFAULT
ProviderName : RegPropProv

Namespace    : ROOT\DEFAULT
ProviderName : RegProv

Namespace    : ROOT\DEFAULT
ProviderName : LogFileEventConsumer

Namespace    : ROOT\DEFAULT
ProviderName : ActiveScriptEventConsumer

Namespace    : ROOT\DEFAULT
ProviderName : RegistryEventProvider

Namespace    : ROOT\DEFAULT
ProviderName : NTEventLogEventConsumer

Namespace    : ROOT\DEFAULT
ProviderName : SMTPEventConsumer

Namespace    : ROOT\DEFAULT
ProviderName : SystemRestoreProv

Namespace    : ROOT\DEFAULT
ProviderName : CommandLineEventConsumer

Namespace    : ROOT\DEFAULT
ProviderName : IntelWLANEventProvider

Namespace    : ROOT\CIMV2
ProviderName : ProviderSubSystem

Namespace    : ROOT\CIMV2
ProviderName : SppProvider

Namespace    : ROOT\CIMV2
ProviderName : Msft_ProviderSubSystem

Namespace    : ROOT\CIMV2
ProviderName : Win32_OfflineFilesConfigurationProvider

Namespace    : ROOT\CIMV2
ProviderName : MS_NT_EVENTLOG_EVENT_PROVIDER

Namespace    : ROOT\CIMV2
ProviderName : MS_Power_Management_Event_Provider

Namespace    : ROOT\CIMV2
ProviderName : RegPropProv

Namespace    : ROOT\CIMV2
ProviderName : Win32_WinSAT

Namespace    : ROOT\CIMV2
ProviderName : InvProv

Namespace    : ROOT\CIMV2
ProviderName : ReliabilityMetricsProvider

Namespace    : ROOT\CIMV2
ProviderName : WmiPerfInst

Namespace    : ROOT\CIMV2
ProviderName : RegProv

Namespace    : ROOT\CIMV2
ProviderName : UserProfileConfigurationProvider

Namespace    : ROOT\CIMV2
ProviderName : MS_NT_EVENTLOG_PROVIDER

Namespace    : ROOT\CIMV2
ProviderName : WmiPerfClass

Namespace    : ROOT\CIMV2
ProviderName : VolumeChangeEvents

Namespace    : ROOT\CIMV2
ProviderName : Standard Non-COM Event Provider

Namespace    : ROOT\CIMV2
ProviderName : MSVSS__PROVIDER

Namespace    : ROOT\CIMV2
ProviderName : Win32_OfflineFilesProvider

Namespace    : ROOT\CIMV2
ProviderName : WMIPingProvider

Namespace    : ROOT\CIMV2
ProviderName : WMI Self-Instrumentation Event Provider

Namespace    : ROOT\CIMV2
ProviderName : RegistryEventProvider

Namespace    : ROOT\CIMV2
ProviderName : Cimwin32A

Namespace    : ROOT\CIMV2
ProviderName : NamedJobObjectLimitSettingProv

Namespace    : ROOT\CIMV2
ProviderName : RouteProvider

Namespace    : ROOT\CIMV2
ProviderName : SCM Event Provider

Namespace    : ROOT\CIMV2
ProviderName : WhqlProvider

Namespace    : ROOT\CIMV2
ProviderName : DFSProvider

Namespace    : ROOT\CIMV2
ProviderName : MS_Shutdown_Event_Provider

Namespace    : ROOT\CIMV2
ProviderName : CIMWin32

Namespace    : ROOT\CIMV2
ProviderName : NamedJobObjectActgInfoProv

Namespace    : ROOT\CIMV2
ProviderName : WBEMCORE

Namespace    : ROOT\CIMV2
ProviderName : RouteEventProvider

Namespace    : ROOT\CIMV2
ProviderName : MSVDS__PROVIDER

Namespace    : ROOT\CIMV2
ProviderName : NamedJobObjectSecLimitSettingProv

Namespace    : ROOT\CIMV2
ProviderName : UserProfileProvider

Namespace    : ROOT\CIMV2
ProviderName : MSIProv

Namespace    : ROOT\CIMV2
ProviderName : Win32_WIN32_TERMINALSERVICE_Prov

Namespace    : ROOT\CIMV2
ProviderName : Win32_UserStateConfigurationProvider

Namespace    : ROOT\CIMV2
ProviderName : SessionProvider

Namespace    : ROOT\CIMV2
ProviderName : NamedJobObjectProv

Namespace    : ROOT\CIMV2
ProviderName : WMI Kernel Trace Event Provider

Namespace    : ROOT\CIMV2
ProviderName : SECRCW32

Namespace    : ROOT\CIMV2
ProviderName : SystemConfigurationChangeEvents

Namespace    : ROOT\CIMV2
ProviderName : Win32_FolderRedirectionConfiguration

Namespace    : ROOT\CIMV2
ProviderName : DskQuotaProvider

Namespace    : ROOT\CIMV2
ProviderName : Win32ClockProvider

Namespace    : ROOT\CIMV2\mdm
ProviderName : MDMAppProv

Namespace    : ROOT\CIMV2\mdm
ProviderName : MDMSettingsProv

Namespace    : ROOT\CIMV2\mdm\dmmap
ProviderName : DMWmiBridgeProv

Namespace    : ROOT\CIMV2\Security\MicrosoftTpm
ProviderName : Win32_TpmProvider

Namespace    : ROOT\CIMV2\Security\MicrosoftVolumeEncryption
ProviderName : Win32_EncryptableVolumeProvider

Namespace    : ROOT\CIMV2\power
ProviderName : PowerMeterProvider

Namespace    : ROOT\CIMV2\power
ProviderName : ProfileAssociationProviderCimV2

Namespace    : ROOT\CIMV2\power
ProviderName : PowerWmiProvider

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSLOGONSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSREMOTECONTROLSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TERMINAL_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSACCOUNT_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSSESSIONSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSNETWORKADAPTERLISTSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSGENERALSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSENVIRONMENTSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSVIRTUALIP_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TERMINALSERVICESETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TERMINALSERVICETOSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TERMINALTERMINALSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSPERMISSIONSSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSNETWORKADAPTERSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSVIRTUALIPSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSSESSIONDIRECTORY_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSCLIENTSETTING_Prov

Namespace    : ROOT\CIMV2\TerminalServices
ProviderName : Win32_WIN32_TSSESSIONDIRECTORYSETTING_Prov

Namespace    : ROOT\CIMV2\Applications\WindowsParentalControls
ProviderName : WpcClamperProv

Namespace    : ROOT\CIMV2\Applications\WindowsParentalControls
ProviderName : WpcWebSyncProv

Namespace    : ROOT\CIMV2\Applications\WindowsParentalControls
ProviderName : WpcSProv

Namespace    : ROOT\CIMV2\Applications\WindowsParentalControls\Secured
ProviderName : WpcWebSyncProvSecured

Namespace    : ROOT\CIMV2\Applications\Games
ProviderName : MS_InstalledGameProv

Namespace    : ROOT\msdtc
ProviderName : MsDtcWmi

Namespace    : ROOT\msdtc
ProviderName : MsDtcWmi_EventProvider

Namespace    : ROOT\Intel_ME
ProviderName : IntelMEProv

Namespace    : ROOT\HyperVCluster\v2
ProviderName : VmmsWmiEventProvider

Namespace    : ROOT\HyperVCluster\v2
ProviderName : VmmsWmiInstanceAndMethodProvider

Namespace    : ROOT\RSOP
ProviderName : Rsop Logging Mode Provider

Namespace    : ROOT\RSOP
ProviderName : Rsop Planning Mode Provider

Namespace    : ROOT\PEH
ProviderName : MINT

Namespace    : ROOT\StandardCimv2
ProviderName : NetEventPacketCapture

Namespace    : ROOT\StandardCimv2
ProviderName : MSFT_Printer

Namespace    : ROOT\StandardCimv2
ProviderName : NetTtCim

Namespace    : ROOT\StandardCimv2
ProviderName : MsNetImPlatform

Namespace    : ROOT\StandardCimv2
ProviderName : NetDaCim

Namespace    : ROOT\StandardCimv2
ProviderName : NlmCim

Namespace    : ROOT\StandardCimv2
ProviderName : netnat

Namespace    : ROOT\StandardCimv2
ProviderName : wfascim

Namespace    : ROOT\StandardCimv2
ProviderName : NetSwitchTeam

Namespace    : ROOT\StandardCimv2
ProviderName : NetWnv

Namespace    : ROOT\StandardCimv2
ProviderName : NetAdapterCim

Namespace    : ROOT\StandardCimv2
ProviderName : dnsclientcim

Namespace    : ROOT\StandardCimv2
ProviderName : NetQosCim

Namespace    : ROOT\StandardCimv2
ProviderName : nettcpip

Namespace    : ROOT\StandardCimv2
ProviderName : NetPeerDist

Namespace    : ROOT\StandardCimv2
ProviderName : NetNcCim

Namespace    : ROOT\StandardCimv2\embedded
ProviderName : AssignedAccess

Namespace    : ROOT\WMI
ProviderName : BcdProv

Namespace    : ROOT\WMI
ProviderName : WMIEventProv

Namespace    : ROOT\WMI
ProviderName : MSiSCSIInitiatorProvider

Namespace    : ROOT\WMI
ProviderName : HiPerfCooker_v1

Namespace    : ROOT\WMI
ProviderName : WMIProv

Namespace    : ROOT\directory\LDAP
ProviderName : Microsoft|DSLDAPClassAssociationsProvider|V1.0

Namespace    : ROOT\directory\LDAP
ProviderName : Microsoft|DSLDAPInstanceProvider|V1.0

Namespace    : ROOT\directory\LDAP
ProviderName : Microsoft|DSLDAPClassProvider|V1.0

Namespace    : ROOT\Policy
ProviderName : PolicSOM

Namespace    : ROOT\Policy
ProviderName : PolicStatus

Namespace    : ROOT\virtualization\v2
ProviderName : VmmsWmiEventProvider

Namespace    : ROOT\virtualization\v2
ProviderName : VmmsWmiInstanceAndMethodProvider

Namespace    : ROOT\Interop
ProviderName : ProfileAssociationProviderInterop

Namespace    : ROOT\Hardware
ProviderName : IPMIPrv

Namespace    : ROOT\ServiceModel
ProviderName : ServiceModel

Namespace    : ROOT\Microsoft\protectionManagement
ProviderName : ProtectionManagement

Namespace    : ROOT\Microsoft\Windows\RemoteAccess\Client
ProviderName : VpnClientPSProvider

Namespace    : ROOT\Microsoft\Windows\Dns
ProviderName : DnsClientPSProvider

Namespace    : ROOT\Microsoft\Windows\Powershellv3
ProviderName : DiscoveryProvider

Namespace    : ROOT\Microsoft\Windows\TaskScheduler
ProviderName : ScheduledTaskProv

Namespace    : ROOT\Microsoft\Windows\DesiredStateConfigurationProxy
ProviderName : dscproxy

Namespace    : ROOT\Microsoft\Windows\SmbWitness
ProviderName : SmbWitnessWmiv2provider

Namespace    : ROOT\Microsoft\Windows\Wdac
ProviderName : WdacWmiProv

Namespace    : ROOT\Microsoft\Windows\winrm
ProviderName : WsmAgent

Namespace    : ROOT\Microsoft\Windows\AppBackgroundTask
ProviderName : appbackgroundtask

Namespace    : ROOT\Microsoft\Windows\PS_MMAgent
ProviderName : PS_MMAgent

Namespace    : ROOT\Microsoft\Windows\Storage
ProviderName : iSCSIWMIv2

Namespace    : ROOT\Microsoft\Windows\Storage
ProviderName : StorageWMI

Namespace    : ROOT\Microsoft\Windows\Storage\PT
ProviderName : DelegatorProvider

Namespace    : ROOT\Microsoft\Windows\Storage\PT\Alt
ProviderName : DelegatorProvider

Namespace    : ROOT\Microsoft\Windows\Storage\providers_v2
ProviderName : wsp_sr

Namespace    : ROOT\Microsoft\Windows\Storage\providers_v2
ProviderName : mispace

Namespace    : ROOT\Microsoft\Windows\Storage\providers_v2
ProviderName : wsp_fs

Namespace    : ROOT\Microsoft\Windows\Storage\providers_v2
ProviderName : wsp_health

Namespace    : ROOT\Microsoft\Windows\HardwareManagement
ProviderName : MSFT_PCSVDevice

Namespace    : ROOT\Microsoft\Windows\SMB
ProviderName : smbwmiv2

Namespace    : ROOT\Microsoft\Windows\EventTracingManagement
ProviderName : EventTracingManagement

Namespace    : ROOT\Microsoft\Windows\DesiredStateConfiguration
ProviderName : dsccore

Namespace    : ROOT\Microsoft\Windows\DesiredStateConfiguration
ProviderName : dsctimer

Namespace    : ROOT\Microsoft\Windows\DesiredStateConfiguration
ProviderName : DSCCoreProviders

Namespace    : ROOT\Microsoft\Windows\Defender
ProviderName : ProtectionManagement

Namespace    : ROOT\Microsoft\SecurityClient
ProviderName : AntimalwareMonitoringProvider

Namespace    : ROOT\Microsoft\SecurityClient
ProviderName : AntimalwareHealthStatusProv

Namespace    : ROOT\Microsoft\SecurityClient
ProviderName : AntimalwareInfectionStatusProv

Namespace    : ROOT\aspnet
ProviderName : DecoupledEventProvider

Viele WMI-Provider kommen direkt von Microsoft aber es gibt auch viele Provider von anderen Softwareherstellern. Hier eine Auflistung mit Beschreibungen der microsofteigenen Provider:

https://msdn.microsoft.com/en-us/library/bg126473(v=vs.85).aspx

Dort findet man so illustre Provider wie “Application Inventory Classes” wo vom Windows 10 Vorbereitungsupdate verwendet wird, um einen Überblick über die installierte Software zu bekommen. https://msdn.microsoft.com/en-us/library/dn894019(v=vs.85).aspx

Oder ProtectionManagement welches vom Defender-Powershell-Modul verwendet wird, um die Kommunikation mit dem Windowsdefender zu ermöglichen.

Soft- und Hardware-Inventarisierung per Powershell leichtgemacht

5 August 2015

Von Zeit zu Zeit muss man wissen, was alles in einem System verbaut ist, welche Software installiert ist, welche Frameworks verfügbar sind, welche DLLs da sind, welche Fehler aufgetreten sind, wie viel Speicherplatz frei ist, wann die Oma Geburtstag hat usw. usf.

Nichts leichter als das, man halte Zettel und Bleistift bereit und gibt in einer Powershelleingabeaufforderung – am besten mit Adminrechten – folgendes ein:

Get-CimAssociatedInstance (Get-CimInstance CIM_ComputerSystem)

Nun nehme man Zettel und Bleistift zur Hand und schreibe mit.

Mittels Alias wird es noch etwas knackiger:

Get-CimAssociatedInstance (gcim CIM_ComputerSystem)

Damit es funktioniert braucht man nur Windows 8, Server 2012 oder höher. Um es auf Windows 7 oder Server 2008 R2 ausführen zu können, benötigt man das Microsoft Management Framework 3.0, welches Powershell 3.0 mitbringt und damit auch die CIM-Cmdlets.

So wer jetzt immer noch die Infos auf seinem Zettel mitschreibt, dem sei gesagt, das Ding läuft EWIG, auch auf guter und aktueller Hardware!

Netter Nebeneffekt: Da durch den Aufruf so ziemlich alles im System angelangt wird, was irgendwie installiert oder verbaut ist, eignet sich der Aufruf auch ideal um Rechner auf Zuverlässigkeit zu testen. Forensiker freuen sich über die Vielzahl von Informationen. Mal sehen, vielleicht taugt es sogar für DOS-Attacken…

Übrigens, wer die ganzen Infos noch langfristig speichern möchte, der fügt noch ein | Export-CliXml Inventar.xml hinzu, also so:

Get-CimAssociatedInstance (gcim CIM_ComputerSystem) | Export-CliXML $Env:USERPROFILE\Inventar.XML

Somit kann man die ganzen Infos später wieder mittels Import-CliXML einlesen und zum Vergleich heranziehen. Somit hat man eine Baseline mittels der Veränderungen immer nachvollzogen werden können.

Nutzt man Powershell 5.0 kann man die XML-Datei mittels Compress-Archive noch etwas kleiner bekommen. Leider hat MS an den Möglichkeiten bei Compress-Archive etwas gezaudert, so dass nicht ein Stream von Export-CliXML übernommen werden kann, sondern es muss die XML-Datei von der Platte gelesen und dann komprimiert werden:

Compress-Archive $Env:USERPROFILE\Inventar.XML $Env:USERPROFILE\Inventar.ZIP

Hier noch eine kleine Einführung in CIM: http://blogs.msdn.com/b/powershell/archive/2012/08/24/introduction-to-cim-cmdlets.aspx.

Komischer Eintrag im Taskmanager beim Autostartregister

1 August 2015

Der Taskmanager von Windows 8 und Windows 10 kann, wenn man die Detailanzeige aktiviert hat ein Register Autostart anzeigen. In diesem Fenster werden dann alle Programme aufgelistet, die beim Rechnerstart automatisch ausgeführt werden.

Mit der rechten Maustaste kann man zusätzliche Infos zu den Programmen erhalten, indem man die Punkte “Dateipfad öffnen” oder “Eigenschaften” anklickt. Wenn man allerdings einen Eintrag hat, der beide Punkte nicht zulässt, um was handelt es sich dann?

Mittels http://live.sysinternals.com/autoruns.exe kann man sich die Lage genauer anschauen. Dort wird man dann rausfinden, dass das entsprechende Programm einfach nicht mehr existiert, obwohl der automatische Starteintrag noch vorhanden ist. Dies führt dazu, dass die beiden genannten Menüpunkte nicht aufrufbar sind.

Man kann also den Eintrag in Autoruns löschen und wie von magischer Hand verschwindet postwendend auch der Eintrag im Tastmanager.

Man kann den Vorgang auch simulieren, indem man z. B. folgenden Eintrag per Powershell ausführt:

New-ItemProperty -Name Test -Value "C:\temp\test.exe" -Path "HK
CU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Schupps taucht ein Eintrag beim Autostartregister im Taskmanager auf.

So bekommt man ihn wieder weg:

Remove-ItemProperty -Name Test -Path "HKCU:\SOFTWARE\Microsoft\
Windows\CurrentVersion\Run"

Umgang mit verschiedenen Versionen von Powershellmodulen und Ermittlung von Unterschieden

30 Juli 2015

Microsoft hat mit Veröffentlichung von Windows 10 auch neue Cmdlets für Powershell eingeführt. Bei Windows 10 Pro und vergleichbaren Versionen, wo der Client Hyper-V enthalten ist, gibt es viele neue Cmdlets für die Verwaltung von virtuellen Maschinen. Interessant dabei ist, dass es eine neue Version des Hyper-V-Moduls gibt. Bis Windows 8.1 und Server 2012 R2 kam die Version 1.1 zum Einsatz und mit Windows 10 gibt es das Hyper-V-Modul in Version 2.0.0.0.

Aus Kompatibilitätsgründen macht es Sinn ein Modul mit einer spezifischen Version zu laden. Vor allem, wenn man z. B. vergleichen möchte, was sich in der neuen Version des Moduls verändert hat.

Welche Version aktuell geladen ist, bekommt man mit Get-Module heraus:

PS> get-module hyper-v

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     1.1        hyper-v                             {Add-VMDvdDrive,…

Mittels Remove-Module kann man das Modul entladen und mit Hilfe von Get-Module –Listavailable erhält man alle verfügbaren Versionen:

PS> Remove-Module hyper-v
PS> Get-Module -ListAvailable Hyper-V

    Verzeichnis: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     2.0.0.0    Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMGroupMember, Add-VMHardDiskDrive…}
Binary     1.1        Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMHardDiskDrive, Add-VMMigrationNetwork…}

Mittels Import-Module kann man nun ein Modul laden:

PS> Import-Module Hyper-V
PS> Get-Module Hyper-V

ModuleType Version    Name                                ExportedCommands
———- ——-    —-                                —————-
Binary     2.0.0.0    Hyper-V                             {Add-VMDvdDrive, Add-VMFibreChannelHba, Add-VMGroupMember, Add-VMHardDiskDrive…}

Man bekommt automatisch die neueste Version. Mit dem Parameter –RequiredVersion kann man nun eine spezifische Version laden:

Import-Module Hyper-V -RequiredVersion 1.1

Nun kann man mittels dieser Möglichkeit beide Versionen laden, die Cmdlets einer Variablen zuweisen und diese Vergleichen lassen:

PS> Import-Module Hyper-V -RequiredVersion 1.1
PS> $cV1 = Get-Command -Module Hyper-V
PS> Remove-Module Hyper-V
PS> Import-Module Hyper-V -RequiredVersion 2.0.0.0
PS> $cV2 = Get-Command -Module Hyper-V
PS> compare $cv1 $cv2

InputObject                              SideIndicator
———–                              ————-
Add-VMGroupMember                        =>
Add-VMNetworkAdapterRoutingDomainMapping =>
Add-VMSwitchTeamMember                   =>
Add-VMTPM                                =>
Disable-VMConsoleSupport                 =>
Enable-VMConsoleSupport                  =>
Get-VHDSet                               =>
Get-VHDSnapshot                          =>
Get-VMGroup                              =>
Get-VMHostCluster                        =>
Get-VMNetworkAdapterIsolation            =>
Get-VMSwitchTeam                         =>
Get-VMTPM                                =>
Get-VMVideo                              =>
New-VMGroup                              =>
Optimize-VHDSet                          =>
Remove-VHDSnapshot                       =>
Remove-VMGroup                           =>
Remove-VMGroupMember                     =>
Remove-VMSwitchTeamMember                =>
Rename-VMGroup                           =>
Set-VMHostCluster                        =>
Set-VMNetworkAdapterIsolation            =>
Set-VMNetworkAdapterRoutingDomainMapping =>
Set-VMSwitchTeam                         =>
Set-VMTPM                                =>
Set-VMVideo                              =>
Start-VMTrace                            =>
Stop-VMTrace                             =>
Update-VMVersion                         =>
Add-VmNetworkAdapterRoutingDomainMapping <=
Get-VmNetworkAdapterIsolation            <=
Set-VmNetworkAdapterIsolation            <=
Set-VmNetworkAdapterRoutingDomainMapping <=

Dabei fällt auf, dass keine Cmdlets entfernt wurden, auch wenn es auf den ersten Blick so aussieht. Es wurde lediglich die Schreibweise bei den letzten vier Cmdlets von …-Vm… in …-VM… geändert.

Halten wir also fest, dies sind die neuen Cmdlets in Hyper-V 2.0.0.0:

Add-VMGroupMember
Add-VMNetworkAdapterRoutingDomainMapping
Add-VMSwitchTeamMember
Add-VMTPM
Disable-VMConsoleSupport
Enable-VMConsoleSupport
Get-VHDSet
Get-VHDSnapshot
Get-VMGroup
Get-VMHostCluster
Get-VMNetworkAdapterIsolation
Get-VMSwitchTeam
Get-VMTPM
Get-VMVideo
New-VMGroup
Optimize-VHDSet
Remove-VHDSnapshot
Remove-VMGroup
Remove-VMGroupMember
Remove-VMSwitchTeamMember
Rename-VMGroup
Set-VMHostCluster
Set-VMNetworkAdapterIsolation
Set-VMNetworkAdapterRoutingDomainMapping
Set-VMSwitchTeam
Set-VMTPM
Set-VMVideo
Start-VMTrace
Stop-VMTrace
Update-VMVersion


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.