Archive for the ‘WMI’ Category

Speicherinfos mittels Powershell unter Windows ermitteln

31 Juli 2019

Um schnell einen Überblick über die Arbeitsspeichersituation eines Rechners zu bekommen helfen diese WMI-Informationen:

$Slots=Get-CimInstance -ClassName Win32_PhysicalMemoryArray
$RAM=Get-CimInstance -ClassName Win32_PhysicalMemory
$slots | % {"DIMM Slots: $($_.MemoryDevices)"}
$ram | % {"Memory installed: $($_.DeviceLocator)"; "Memory Size $($_.Capacity/1GB)"}

und gibt dann

DIMM Slots: 2
Memory installed: ChannelA-DIMM0
Memory Size 16
Memory installed: ChannelB-DIMM0
Memory Size 16

aus.

Wenn man erfahren möchte, wie viel Speicher davon benutzt wird, kann man diese Zeilen verwenden:

Get-CimInstance win32_operatingsystem | select @{N="Frei GB";E={$_.FreePhysicalMemory/1MB}}, @{N="Gesamt GB";E={$_.TotalVisibleMemorySize/1MB }}, @{N="Anteil frei in Prozent";E={$_.FreePhysicalMemory*100 / $_.TotalVisibleMemorySize}}

ergibt z. B.:

Frei GB                : 16,7665214538574
Gesamt GB              : 31,8850631713867
Anteil frei in Prozent : 52,5842503862545

Werbeanzeigen

Trusted Platform Module (TPM) unter Windows und SpecVersion ermitteln

13 Februar 2018

Um Passwörter und Geheimnisse abzusichern werden immer mehr Hardwaremodule eingesetzt. Eines dieser Module ist z. B. TPM. Die Aufgabe eines Trusted Platform Module ist es bestimmte Schlüssel und Geheimnisse abzuspeichern. Es ist zwar meist ein Hardwaremodul aber es kann im Innern doch auch wieder per Software updatebar sein. Ich hatte bereits vor Jahren versucht TPM unter Hyper-V mit ans laufen zu bekommen https://newyear2006.wordpress.com/2014/05/15/hyper-v-vms-trusted-platform-module-und-das-problem-mit-den-virtual-smart-cards/.  Damals gab es aber noch keine Unterstützung im Hyper-V. Dies sieht heute anders aus. Dadurch kann man sich nun mit TPM beschäftigen, ohne sich viel Gedanken machen zu müssen. Wo TPM bei Windows 10 zum Einsatz kommt, kann man hier nachlesen: https://docs.microsoft.com/en-us/windows/security/hardware-protection/tpm/how-windows-uses-the-tpm.

Eine Frage die sich schnell ergibt, wenn man sich damit beschäftigt, ist, welche Version hat man eigentlich? Gängig sind Version 1.2 oder 2.0. Ruft man mittels TPM.MSC also die “Trusted Platform Module”-Management (TPM)-Konsole auf, dann kann man dort unter TPM-Herstellerinformationen die Spezifikationsversion einsehen. Schön, aber wie geht das auch per Commandline? Da gibt es eigentlich das Cmdlet Get-Tpm:

PS > Get-Tpm

TpmPresent                : True
TpmReady                  : True
ManufacturerId            : 1297303124
ManufacturerIdTxt         : MSFT
ManufacturerVersion       : 8213.275
ManufacturerVersionFull20 : 8213.275.21.18466

ManagedAuthLevel          : Full
OwnerAuth                 : R8yRy4e6DfK2hDS/EbQxdhA=
OwnerClearDisabled        : False
AutoProvisioning          : Enabled
LockedOut                 : True
LockoutHealTime           : 10 minutes
LockoutCount              : 0
LockoutMax                : 31
SelfTest                  : {}

Hier hätte ich erwartet, dass SpecVersion auftaucht, doch leider tut sie es nicht. Ok wir haben ja Powershell, vielleicht versteckt sich die Info woanders:

Get-Command -Module TrustedPlatformModule -ParameterName *spec*

Aber da kommt leider auch nix raus. Zumindest in der Version 2.0 der Cmdlets aus dem TrustedPlatformModule-Modul.

Also was tun? Wie immer liegt die Lösung im WMI, denn dort kann man die Klasse Win32_Tpm finden, zunächst brauchen wir aber eine einfache Möglichkeit um alle Namespaces zu durchlaufen:

Function Get-NamespaceRecursive ($namespace) {
$nss=Get-CimInstance -Namespace $namespace -ClassName __NAMESPACE
$nss | % {"$namespace/$($_.Name)"; Get-NamespaceRecursive "$namespace/$($_.Name)" }
}

Mit dieser können wir mittels diesem Aufruf alle verfügbaren Namespaces ermitteln und dort nach TPM Ausschau halten:

$ns=Get-NamespaceRecursive "root"
$tpm=$ns| % {Get-CimClass -Namespace $_ -ClassName *} | where CimClassName -match tpm

   NameSpace: ROOT/CIMV2/Security/MicrosoftTpm

CimClassName                        CimClassMethods      CimClassProperties
————                        —————      ——————
Win32_Tpm                           {IsEnabled, IsOwn… {IsActivated_Initial…

Damit erhalten wir zwei Treffer, einer davon Win32_TPM. Diesen schauen wir uns genauer an:

(Get-CimClass -Namespace ROOT/CIMV2/Security/MicrosoftTpm -ClassName Win32_Tpm).CimClassProperties | where name -match specversion

Name               : SpecVersion
Value              :
CimType            : String
Flags              : Property, NullValue
Qualifiers         : {Description, Implemented}
ReferenceClassName :

Also Volltreffer. Es gibt sie also, die gesuchte Information.

Um in Zukunft die SpecVersion des TPM zu ermitteln verwendet man diesen einfachen Aufruf:

wmic /namespace:\\root\CIMV2\Security\MicrosoftTpm path Win32_Tpm get /value

IsActivated_InitialValue=TRUE
IsEnabled_InitialValue=TRUE
IsOwned_InitialValue=TRUE
ManufacturerId=1297303124
ManufacturerIdTxt=MSFT
ManufacturerVersion=8213.275
ManufacturerVersionFull20=8213.275.21.18466
ManufacturerVersionInfo=496f5420536f6674776172652054504d00
PhysicalPresenceVersionInfo=1.3
SpecVersion=2.0, 0, 1.15

Ups, das war der falsche Befehl 🙂 Bin da etwas in alte Zeiten ohne Powershell abgerutscht… Trotz allem könnte obiger Befehl in Situationen wichtig sein, wenn man mittels WinPE oder WinRE unterwegs ist und kein Powershell an Bord hat. In diesem Fall sollte man aber noch drvload x:\windows\inf\tpm.inf im Hinterkopf behalten, denn ohne Treiber geht evtl. nix. Zurück aber zum Thema.

Gemeint war dieser:

(Get-CimInstance -Namespace ROOT/CIMV2/Security/MicrosoftTpm -ClassName Win32_Tpm).SpecVersion
2.0, 0, 1.15

Schön nun haben wir Version 2.0, 0, 1.15 und das bedeutet nun? Ist es 2.0 oder eine verkappte 1.2 Version? Tja, Aufklärung gibt es auf der Microsoft Seite zur Win32_Tpm-Klasse https://msdn.microsoft.com/en-us/library/windows/desktop/aa376484, dort steht:

The version of the Trusted Computing Group (TCG) specification that the TPM supports. This value includes the major and minor TCG specification version, the specification revision level, and the errata revision level. All values are in hexadecimal. For example, a version information of "1.2, 2, 0" indicates that the device was implemented to TCG specification version 1.2, revision level 2, and with no errata.

When the data is unavailable, "Not Supported" is returned.

Aha, wir bekommen also ziemlich viel geboten. Nur stellt sich die Frage, was für Erratas und Revisionen gibt es? Nun, wenn man beim Informationsimperium anfragt, dann bekommt man diese Seite geliefert: https://trustedcomputinggroup.org/tpm-library-specification/. Übrigens hatte ich die Trusted Computing Group schon mal mit SED im Programm: https://newyear2006.wordpress.com/2016/10/01/self-encrypting-drives-sed-und-probleme-mit-gelschten-bitlocker-partitionen/.

Obige SpecVersion mit 2.0, 0, 1.15 sagt also aus, dass wir es mit der 2.0er-Familie, dem Level 0 und der Revision 01.16 vom Oktober 2014 zu tun haben. Wobei die Angaben sich mit der Beschreibung von Microsoft oben nicht decken.

Hier die aktuell bekannten Versionen:

Familie/Version Level Revision vom
2.0 0 01.38 September 2016
2.0 0 01.16 Oktober 2014
2.0 0 00.99 Oktober 2013
2.0 0 00.96 März 2013
1.2 2 116  
1.2 2 103  
1.2   94  
1.2   85  
1.2   62  
1.1b      

Die Werte für 1.2 sind von hier: https://trustedcomputinggroup.org/tpm-main-specification/.

Wer sich tiefergehend mit TPM 2.0 beschäftigen möchte, der sollte sich unbedingt die Architekturbeschreibung und die Einrichtungsrichtlinien anschauen, https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf und https://trustedcomputinggroup.org/wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf.

TPM 2.0 und Linux sind dann nochmal ein Thema für sich: https://blog.hansenpartnership.com/tpm2-and-linux/.

Nicht zu vergessen sind auch die CVEs mit TPMs, welche es zu beachten gibt: https://www.google.de/search?q=cve+tpm.

Windows 10 Device Guard

2 Oktober 2016

Ein sinnvolles Feature um einen Windows Rechner sicherer zu machen aber leider nur bei Enterprise Versionen verfügbar. Damit kann man mittels Credential Guard seine Passwörter und Tickets absichern.

Aber da ich davon ausgehe, dass in künftigen Versionen noch mehr Features von Device Guard in alle Windowsversionen Einzug halten, hier ein paar Dinge, die wichtig sind.

Wie immer hier die Einleitung zum Thema: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard.

Wie kann man per Powershell feststellen, ob Device Guard verfügbar ist bzw. Credential Guard läuft? Am einfachsten mittels WMI:

PS> Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard

AvailableSecurityProperties                  : {0}
CodeIntegrityPolicyEnforcementStatus         : 0
InstanceIdentifier                           : 4ff40742-2649-41b8-bdd1-e80fad1cce80
RequiredSecurityProperties                   : {0}
SecurityServicesConfigured                   : {0}
SecurityServicesRunning                      : {0}
UsermodeCodeIntegrityPolicyEnforcementStatus : 0
Version                                      : 1.0
VirtualizationBasedSecurityStatus            : 0
PSComputerName                               :

Obiges Beispiel ist von einem älteren Rechner (BIOS), welcher Windows 10 Pro v1607 (32-Bit) installiert hat und keine Virtualisierungsfeatures aktiviert hat.

Hier ein etwas neuerer Rechner (UEFI) ebenfalls v1607 Pro (64-Bit) aber mit lokalem aktiviertem Hypervisor:

PS> get-ciminstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard

AvailableSecurityProperties                  : {1, 3}
CodeIntegrityPolicyEnforcementStatus         : 0
InstanceIdentifier                           : 4ff40742-2649-41b8-bdd1-e80fad1cce80
RequiredSecurityProperties                   : {0}
SecurityServicesConfigured                   : {0}
SecurityServicesRunning                      : {0}
UsermodeCodeIntegrityPolicyEnforcementStatus : 0
Version                                      : 1.0
VirtualizationBasedSecurityStatus            : 2
PSComputerName                               :

Für die Ausgangsfrage ist, wie weiß man, dass Device Guard mit Credential Guard eingerichtet ist? Dazu fragt man SecurityServicesConfigured ab, wenn dieser Wert 1 oder höher enthält, dann ist er aktiv. Eine Beschreibung zu SecurityServicesConfigured gibt es unter https://technet.microsoft.com/de-de/itpro/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.

Wenn man wissen möchte, ob der Dienst auch läuft schaut man bei SecurityServicesRunning nach:

$DevGuard = Get-CimInstance –ClassName Win32_DeviceGuard 
–Namespace root\Microsoft\Windows\DeviceGuard;

If ($DevGuard.SecurityServicesConfigured -contains 1)
{"Credential Guard configured"};
If ($DevGuard.SecurityServicesRunning -contains 1)
{"Credential Guard running"}
https://blogs.technet.microsoft.com/poshchap/2016/09/23/
security-focus-check-credential-guard-status-with-powershell/
Übrigens auf einem Windows 10 Pro v1511 gibt es den Namespace root/
Microsoft/Windows/DeviceGuard gar nicht erst:

PS> Get-CimClass -Namespace root/Microsoft/Windows/DeviceGuard

Get-CimClass : Ungültiger Namespace

In Zeile:1 Zeichen:1

+ Get-CimClass -Namespace root/Microsoft/Windows/DeviceGuard

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

    + CategoryInfo          : MetadataError: (:) [Get-CimClass], CimException

    + FullyQualifiedErrorId : HRESULT 0x8004100e,Microsoft.Management.Infrastructure.CimCmdlets.GetCimClassCommand

Vorsicht mit Get-NetFirewallRule bzw. WMI MSFT_NetFirewallRule-Klasse bei Abfrage der Enabled-Eigenschaft – gilt allgemein bei $True und $False in Powershell

10 Juli 2016

Ein Script welches Windows Firewall Regel-Eigenschaften abfragte funktionierte nicht wie erwartet. Es wurde immer die Enabled Eigenschaft abgefragt aber es kam nicht das erwartete Ergebnis, wurde die Abfrage aber negiert, kam das erwartete Ergebnis heraus! Am Ende stellte es sich heraus, dass die Enabled-Eigenschaften kein klassisches Bool sondern einen String zurückgibt, hier die Story:

Fragen wir zunächst die aktuelle Anzahl von Regeln ab, hier bei einem aktuellen Windows 10:

$r=Get-NetFirewallRule
$r.length
413

Es gibt also 413 Regeln. Nun sollen alle Regeln ermitteln werden, die aktiviert sind:

($r | where enabled -eq $true).length
184

Jetzt sollen alle Regeln ermittelt werden, die nicht aktiviert sind:

($r | where enabled -eq $false).length
0

Die 0 ist jetzt nicht das erwartete Ergebnis, wenn man davon ausgeht, dass es 413 Regeln gibt, davon sind 184 aktiv, dann sollten mehr als 0 inaktiv sein.

Wo liegt das Problem? Das Problem ist, dass bei $True oder $False in Powershell immer True oder False am Bildschirm ausgegeben wird. Man interpretiert einen solchen Wert schnell als Boolean. Aber in diesem Fall hat man es nicht mit einem Boolean zu tun:

$r[0].enabled.pstypenames
Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled
System.Enum
System.ValueType
System.Object

Es ist also ein Aufzählungstyp!

($r | where enabled -eq "True").length
184
($r | where enabled -eq "False").length
229

So macht die Sache mehr Sinn!

Oder man macht die Abfrage über den passenden Typ:

($r| where enabled -eq ([Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled]:
:True)).length
184
($r| where enabled -eq ([Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.Enabled]:
:False)).length
229

Übrigens: $true –eq "True" ergibt immer True, auch wenn man $true –eq "irgendwas" setzt! Und $False –eq "False" ergibt immer False, egal mit was verglichen wird, außer $false!

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.

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.

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/

Powershell 9 Arten ein externes Programm zu starten, mir sind aber 11 bekannt oder noch mehr?

7 Januar 2013

Dieser Artikel http://www.admin-source.de/BlogDeu/433/powershell-9-arten-ein-externes-programm-executable-zu-starten, dessen Grundlage, dieser Technet-Wiki-Eintrag ist http://social.technet.microsoft.com/wiki/contents/articles/7703.powershell-running-executables.aspx, spricht von 9 Arten externe Programme unter Powershell starten zu können.

Allerdings muss man bei Version 2 von Powershell sagen, es gibt eigentlich 10 Arten, denn es gibt das tolle Kommando Invoke-WSManAction http://technet.microsoft.com/en-us/library/hh849865.aspx. Mit den richtigen Parametern gefüttert:

Invoke-WSManAction -Action create -ResourceURI wmicimv2/win32_process -ValueSet @{commandline="notepad.exe";currentdirectory="C:\"}

führt dies auch zum Start von Notepad.exe!

Jetzt mag der eine oder andere einwenden, dass ja nur Win32_Process aufgerufen wird aber wird nicht auch bei den anderen Möglichkeiten im Hintergrund immer nur CreateProcess() aufgerufen?

Ach übrigens mit Powershell 3 gibt es noch eine weitere Variante! Die da wäre Invoke-CIMAction http://technet.microsoft.com/en-us/library/jj590759.aspx. Dies sind dann so aus:

$cim=Invoke-CimMethod -ClassName Win32_process -MethodName "Create" -Arguments @{ Commandline="notepad.exe";CurrentDirectory="C:\" }

Wenn ich allerdings jetzt nochmal genau darüber nachdenke, dann fallen mir noch weitere Möglichkeiten ein, wie z. B. ScheduledJobs, BackgroundJobs also Jobs allgemein, mittels Win32_ScheduleJob oder indem man einen Druckertreiber mit entsprechendem Monitorprogramm installiert und dann was ausdruckt. Dann wäre da noch die Möglichkeit über Win32_Service. Und es gibt noch soviel mehr, wenn man seine Kreativität walten lässt.

Man könnte ja auch Powershell benutzen, um mehr zu erfahren

gwmi -List | where if ($_.methods -ne $null) {($_.methods).name -contains "Create"}

listet unter anderem

Win32_Process
Win32_BaseService
Win32_Service
Win32_TerminalService
Win32_SystemDriver
Win32_ScheduledJob

Bei CIM wären die Invoke-Aktionen aber CIM ist noch so undurchschaubar. Gute, wenn auch alte Infos über CIM gibt es hier: http://klaus.jaehne.de/papers/cim/node6.html.

Ich glaub jetzt bin ich irgendwie übers Ziel rausgeschossen. Halten wir also fest: Es gibt mehr Methoden, als wir zu wissen glauben.

WinPE mit Powershell das ultimative Gespann

13 März 2012

Mit Windows 8 kommt der Knaller für WinPE und Powershell. Seither war die Kombination WinPE (Windows Preinstallation Environment) mit Powershell nur über spezielle Modifikationen möglich, wie z. B. hier beschrieben: http://chentiangemalc.wordpress.com/2011/01/24/how-to-net-powershell-in-windows-pe-2/.

Aber Microsoft hatte ein Einsehen mit den geplagten Admins und Powerusern dieser Welt und machte eine offizielle Unterstützung von Powershell auf WinPE möglich. Aber nicht irgendein Powershell, nein gleich Powershell 3.0 mit Net-Framework 4 und den nötigen Storage Cmdlets!! Perfekt, davon hat man jahrelang geträumt.

Wie wird’s gemacht? Man benötigt das “Windows Assessment and Deployment Kit (ADK)” für Windows 8. Darin enthalten sind die nötigen Komponenten.
Download: http://www.microsoft.com/download/en/details.aspx?id=28997
Installationsbeschreibung: http://msdn.microsoft.com/en-us/library/windows/desktop/hh825494.aspx#InstallingNonNetworked

Eine Dokumentation, wie man dann vorgeht steht hier: http://technet.microsoft.com/en-us/library/hh825110.aspx

Dabei braucht man folgende optionalen Komponenten:

WinPE-WMI
WinPE-NetFX4
WinPE-Scripting
WinPE-PowerShell3
WinPE-DismCmdlets
WinPE-StorageWMI

Eine Beschreibung der Komponenten gibt es hier: http://technet.microsoft.com/en-us/library/hh824926.aspx#bkmk_3

In genau dieser Reihenfolge sollten diese an DISM.EXE beim Parameter /add-package angeliefert werden. Unverständlich ist nur, dass bei den ganzen Dokus noch alles mit DISM.EXE angegeben ist, wo es doch Powershell 3.0 mit DISM-Cmdlets gibt?!? Smiley

Wurde alles sauber gemacht erhält man ein Windows PE 4.0 mit .Net Framework 4.0 und Powershell 3.0 mit WMI Unterstützung!

Achso, hab ich schon betont wie genial ich das finde? Ok, ich wiederhole mich aber ich bin halt begeistert.

Nur ein paar Vorteile:

  • Es löst DISKPART.EXE ab, welches häufiger in diesem Blog zu finden ist, vor allem lassen sich nun Plattenputz- oder Einrichtaktionen schön scripten.
  • Es erlaubt Offline-Registry Zugriffe um zum Beispiel bei P2V bestimmte Treiber ausfindig zu machen und umzubeamen.
  • Man bekommt Zugriff auf VHD- und ISO-Dateien bzw. deren Inhalt und kann so leichter auf nötige Treiber oder Installationsdateien zurückgreifen.
  • Bei erkannter Netzwerkkarte bekommt man mittels Invoke-RestMethod Zugriff auf RSS-Feeds.
  • Im Grunde sind die Möglichkeiten nun unbegrenzt.

USV eines Hyper-V mit WMI-Events überwachen

17 Mai 2011

Es bringen zwar nicht alle USVs eine Unterstützung für WMI mit, aber die USVs von APC tun dies zum Glück. Somit ist es möglich, auch unter einem Microsoft Hyper-V Server den Status der USV abzufragen, ohne die herstellerspezifische Software zu installieren.

In einem früheren Artikel wurde schon mal auf die Möglichkeiten hingewiesen, wie eine Abfrage in Powershell aussehen könnte: https://newyear2006.wordpress.com/2010/01/16/hyper-v-r2-server-mit-usv-absichern-per-vbscript-oder-powershell/

Aber es gibt immer eine noch elegantere Möglichkeit. Der im Artikel verlinkte Foreneintrag, pollt die ganze Zeit den Status der Batterie. Sobald eine Änderung erkannt wird, wird darauf reagiert. Eine schönere Variante ist die Verwendung von WQL der WMI Query Language und Anwendung von Intrinsic Events.

Eine kompakte aber gute Einführung in WQL gibts hier:
1. WMI query language – An introduction 
2. WMI query language – Keywords and Operators
3. WMI query language – Data Queries: SELECT, FROM, and WHERE
4. WMI query language – Data Queries: Associators Of
5. WMI query language – Data Queries: References Of
6. WMI query language – Event Queries: Introduction
7. WMI query language – Event Queries: Syntax
8. WMI query language – Event Queries: Intrinsic Events
9. WMI query language – Event Queries: Extrinsic Events
10. WMI query language – Schema queries

Mittels dieser Intrinsic Events kann man folgendes Konstrukt schreiben:

$query = "select * from __instanceModificationEvent within 60 where targetinstance ISA ‚Win32_Battery‘ AND targetinstance.BatteryStatus = 1"
Register-WmiEvent –Query $query –Action {Write-Host "Battery Alarm"}

Dabei wird alle 60 Sekunden der Batteriestatus der Klasse Win32_Battery abgefragt. Sollte dieser auf den Wert 1 geändert sein, wird mit der Ausgabe von “Battery Alarm” reagiert. Natürlich könnte hier dann alles mögliche passieren.

Aber Achtung WMI-Events laufen nur solange die Powershell Konsole läuft. Ein verlassen der Konsole oder gar ein Reboot überlebt der Event nicht. Aber dafür kann man PowerEvents verwenden: http://powerevents.codeplex.com/