Archive for the ‘Windows 10’ Category

Übermittlungsoptimierung Neuigkeiten in Windows 10 v1703

5 April 2017

Ich hatte mich hier schon mal mit der Übermittlungsoptimierung auseinandergesetzt, als ein WLAN verstopft wurde. https://newyear2006.wordpress.com/2016/05/28/bermittlungsoptimierung-frisst-die-gesamte-bandbreite/. Microsoft hat mit Windows 10 angefangen Updates nicht mehr per BITS auszuliefern sondern eben über die Übermittlungsoptimierung. Nur waren seither die Möglichkeiten darüber Informationen zu erhalten sehr begrenzt.

Mit dem Creators Update allerdings, hat ein neues Modul mit Namen DeliveryOptimization Einzug gehalten.

PS > get-command -Module DeliveryOptimization

CommandType     Name                                               Version    Source
———–     —-                                               ——-    ——
Cmdlet          Get-DeliveryOptimizationPerfSnap                   1.0.0.0    DeliveryOptimization
Cmdlet          Get-DeliveryOptimizationStatus                     1.0.0.0    DeliveryOptimization

Man kann zwar keine Einstellungen ändern, allerdings bekommt man nun endlich einige Infos zu dem was im Hintergrund stattfindet.

PS > Get-DeliveryOptimizationStatus
No active Delivery Optimization download or upload jobs
PS > Get-DeliveryOptimizationPerfSnap
There are no Delivery Optimization downloads to show PerfSnap data

Nachdem man bei den Updateeinstellungen dann die Verbreitung über das LAN oder übers Internet aktiviert hat, bekommt man entsprechende Daten, hier zu den einzelnen Dateien:

PS > Get-DeliveryOptimizationStatus

FileId                  : a4d873c066a67a58ce46f0bb69bc6e6d2eaddda8
FileSize                : 182553
TotalBytesDownloaded    : 182553
PercentPeerCaching      : 0
BytesFromPeers          : 0
BytesFromHttp           : 182553
Status                  : Caching
Priority                : Foreground
BytesFromLanPeers       : 0
BytesFromGroupPeers     : 0
BytesFromInternetPeers  : 0
BytesToLanPeers         : 0
BytesToGroupPeers       : 0
BytesToInternetPeers    : 0
HttpConnectionCount     : 4
LanConnectionCount      : 0
GroupConnectionCount    : 0
InternetConnectionCount : 0
DownloadMode            : 99
SourceURL               : http://download.windowsupdate.com/c/msdownload/update/software
/crup/2017/04/windows10.0-kb
6251-x64-express_a4d873c066a67a58ce46f0bb69bc6e6d2eaddda8.cab

Dabei sind vor allem die gesammelten Performance Daten interessant:

PS > Get-DeliveryOptimizationPerfSnap
FilesDownloaded                 : 5
FilesUploaded                   : 0
TotalBytesDownloaded            : 565.427
TotalBytesUploaded              : 0
AverageDownloadSize             : 113.085
AverageUploadSize               : 0

Diese gibt es auch in erweiterter Fassung bei Verwendung von –Verbose:

PS > Get-DeliveryOptimizationPerfSnap -Verbose
FilesDownloaded                 : 4
FilesUploaded                   : 0
TotalBytesDownloaded            : 398.452
TotalBytesUploaded              : 0
AverageDownloadSize             : 99.613
AverageUploadSize               : 0
DownloadMode                    : 3
Files                           : 7
CacheSizeBytes                  : 0
TotalDiskBytes                  : 135.770.664.960
AvailableDiskBytes              : 120.237.105.152
NumberOfPeers                   : 0
CdnConnections                  : 10
LanConnections                  : 0
GroupConnections                : 0
InternetConnections             : 0
DownlinkBps                     : 2.339.984
UplinkBps                       : 127.664
ForegroundDownloadRatePct       : 90
BackgroundDownloadRatePct       : 45
UploadRatePct                   : 100
UploadCount                     : 0

Hier wurde das Modul das erste Mal erwähnt: https://2pintsoftware.com/delivery-optimization-powershell-cmdlets/. Hier findet man auch weitere wissenswerte Infos zur Übermittlungsoptimierung. Der Downloadmode wird hier beschrieben: https://2pintsoftware.com/delivery-optimization-dl-mode/.

Advertisements

Neue Provisioning Cmdlets in Windows 10 v1703 Creators Update

4 April 2017

Beim durchschauen der neuen Windows 10 Version bin ich auf ein neues Powershell Modul gestoßen. Es nennt sich schlicht und ergreifend Provisioning ist aber bereits in Version 3 verfügbar.

Cool ein neues Modul und dann gleich Version 3! Bei der Recherche mittels Google war nichts in der Richtung zu finden, auch die Hilfe des Moduls zeigte nur ins Nirvana. Also eine echte Neuentdeckung Smiley.

So schaut man sich die Modul Infos an:

PS C:\WINDOWS\system32> get-module provisioning|fl *

LogPipelineExecutionDetails : False
Name                        : Provisioning
Path                        : C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Provisioning\provisioning.psm1
ImplementingAssembly        :
Definition                  : #
                              # Script Module file for provcmdlets module.
                              #
                              # Copyright (c) Microsoft Corporation
                              #
                              #
                              # Cmdlet aliases
                              #
                              Set-Alias Add-ProvisioningPackage Install-ProvisioningPackage
                              Set-Alias Remove-ProvisioningPackage Uninstall-ProvisioningPackage
                              Set-Alias Add-TrustedProvisioningCertificate Install-TrustedProvisioningCertificate
                              Set-Alias Remove-TrustedProvisioningCertificate Uninstall-TrustedProvisioningCertifi
                              Export-ModuleMember -Alias * -Function * -Cmdlet *
Description                 :
Guid                        : 1323f046-a4bd-47df-a8bc-8253eabc49b2
HelpInfoUri                 : http://go.microsoft.com/fwlink/?LinkId=525624
ModuleBase                  : C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Provisioning
PrivateData                 :
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    :
Version                     : 3.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0
CompanyName                 : Microsoft Corporation
Copyright                   : © Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      :
ExportedFunctions           : {}
Prefix                      :
ExportedCmdlets             : {[Export-ProvisioningPackage, Export-ProvisioningPackage], [Export-Trace, Export-Tra
                              [Get-ProvisioningPackage, Get-ProvisioningPackage], [Get-TrustedProvisioningCertific
                              Get-TrustedProvisioningCertificate]…}
ExportedCommands            : {[Export-ProvisioningPackage, Export-ProvisioningPackage], [Export-Trace, Export-Tra
                              [Get-ProvisioningPackage, Get-ProvisioningPackage], [Get-TrustedProvisioningCertific
                              Get-TrustedProvisioningCertificate]…}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {provcmdlets}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 4.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : provisioning.psm1
ExportedVariables           : {}
ExportedAliases             : {[Add-ProvisioningPackage, Add-ProvisioningPackage],
                              [Add-TrustedProvisioningCertificate, Add-TrustedProvisioningCertificate],
                              [Remove-ProvisioningPackage, Remove-ProvisioningPackage],
                              [Remove-TrustedProvisioningCertificate, Remove-TrustedProvisioningCertificate]}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {}
ExportedTypeFiles           : {}

Bei den NestedModules fällt provcmdlets auf. Sucht man damit in Google findet man gerade mal 10 Einträge und alles erst seit Ende 2016. Also alles noch ganz heiß!

provcmdlets findet man im Verzeichnis C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Provisioning:

PS C:\WINDOWS\system32> dir C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Provisioning

    Verzeichnis: C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Provisioning

Mode                LastWriteTime         Length Name
—-                ————-         —— —-
-a—-       18.03.2017     21:57           6570 provautologger_add.reg
-a—-       18.03.2017     21:57            152 provautologger_del.reg
-a—-       18.03.2017     21:57          20992 provcmdlets.dll
-a—-       18.03.2017     21:57          90112 provcommon.dll
-a—-       18.03.2017     21:57           2238 provisioning.psd1
-a—-       18.03.2017     21:57            482 provisioning.psm1
-a—-       18.03.2017     21:57         745984 provpackageapi.dll
-a—-       18.03.2017     21:57           8378 provtrace.wprp
-a—-       18.03.2017     21:57          13312 wiminterop.dll

D. h. es gibt verschiedene DLL-Dateien und sogar Registry-Dateien die involviert sind. Bekommt man irgendwelche Infos von den DLL-Dateien?

PS C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Provisioning> (dir).versioninfo| select comments, filedescription

Comments FileDescription
——– —————

 

 

         "ProvPackageAPI.DYNLINK"

Gähnende Leere. Schade.

Was ist nun an Cmdlets enthalten?

PS C:\WINDOWS\system32> get-command -Module
Provisioning

CommandType     Name                                               Version    Source
———–     —-                                               ——-    ——
Alias           Add-ProvisioningPackage                            3.0        Provisioning
Alias           Add-TrustedProvisioningCertificate                 3.0        Provisioning
Alias           Remove-ProvisioningPackage                         3.0        Provisioning
Alias           Remove-TrustedProvisioningCertificate              3.0        Provisioning
Cmdlet          Export-ProvisioningPackage                         3.0        Provisioning
Cmdlet          Export-Trace                                       3.0        Provisioning
Cmdlet          Get-ProvisioningPackage                            3.0        Provisioning
Cmdlet          Get-TrustedProvisioningCertificate                 3.0        Provisioning
Cmdlet          Install-ProvisioningPackage                        3.0        Provisioning
Cmdlet          Install-TrustedProvisioningCertificate             3.0        Provisioning
Cmdlet          Uninstall-ProvisioningPackage                      3.0        Provisioning
Cmdlet          Uninstall-TrustedProvisioningCertificate           3.0        Provisioning

Dabei verweisen die Add-Aliase auf die Install-Cmdlets und die Remove-Aliase auf die UnInstall-Cmdlets. Netto bleiben also folgende Cmdlets übrig:

Export-ProvisioningPackage
Export-Trace
Get-ProvisioningPackage
Get-TrustedProvisioningCertificate
Install-ProvisioningPackage
Install-TrustedProvisioningCertificate
Uninstall-ProvisioningPackage
Uninstall-TrustedProvisioningCertificate

Wenn man sich die Auflistung so anschaut, dann würde man meinen mit Get-ProvisioningPackage könnte man etwas anfangen. Dem ist leider nicht so. Auch Get-ProvisioningPackage –AllInstalledPackages brachte nichts zurück.

Also mal die Parameter so anschauen:

PS C:\> (get-command Get-ProvisioningPackage).Definition

Get-ProvisioningPackage [-PackageId] <string> [-LogsDirectoryPath <string>] [-WprpFile <string>]
[-ConnectedDevice] [<CommonParameters>]

Get-ProvisioningPackage [-PackagePath] <string> [-LogsDirectoryPath <string>] [-WprpFile
<string>] [-ConnectedDevice] [<CommonParameters>]

Get-ProvisioningPackage [-AllInstalledPackages] [-LogsDirectoryPath <string>] [-WprpFile
<string>] [-ConnectedDevice] [<CommonParameters>]

Jetzt hatte ich da so eine Idee, welche auch Version 3 erklärt. Denn es gibt in DISM sogenannte Provisioning Package Command Line Optionen https://msdn.microsoft.com/de-de/windows/hardware/commercialize/manufacture/desktop/dism-provisioning-package-command-line-options, welche seither noch keine Powershell Entsprechung gefunden haben. Wahrscheinlich sind die Provisioning Cmdlets darauf abgestellt?

Also die These mal schnell überprüft. Provisioning Packages haben ihre eigenen Dateiendungen nämlich .ppkg. Es finden sich auf Windows 10 Systemen im Verzeichnis C:\windows\Provisioning\Packages entsprechende Dateien:

PS C:\windows\Provisioning\Packages> dir

    Verzeichnis: C:\windows\Provisioning\Packages

Mode                LastWriteTime         Length Name
—-                ————-         —— —-
-a—-       18.03.2017     21:57           6139 Power.EnergyEstimationEngine.Control.ppkg
-a—-       18.03.2017     21:57           5654 Power.EnergyEstimationEngine.CPU.ppkg
-a—-       18.03.2017     21:57           5701 Power.EnergyEstimationEngine.Display.ppkg
-a—-       18.03.2017     21:57           5677 Power.EnergyEstimationEngine.MBB.ppkg
-a—-       18.03.2017     21:57           5622 Power.EnergyEstimationEngine.StandbyActivation.ppkg
-a—-       18.03.2017     21:57           6498 Power.EnergyEstimationEngine.Storage.ppkg
-a—-       18.03.2017     21:57           5637 Power.EnergyEstimationEngine.Telemetry.ppkg
-a—-       18.03.2017     21:57           5644 Power.EnergyEstimationEngine.Wifi.ppkg
-a—-       18.03.2017     21:57           6512 Power.Settings.Battery.ppkg
-a—-       18.03.2017     21:57           5718 Power.Settings.Button.ppkg
-a—-       18.03.2017     21:57           5612 Power.Settings.Disk.ppkg
-a—-       18.03.2017     21:57           5598 Power.Settings.Display.ppkg
-a—-       18.03.2017     21:57           5411 Power.Settings.EnergySaver.ppkg
-a—-       18.03.2017     21:57           5551 Power.Settings.IdleResiliency.ppkg
-a—-       18.03.2017     21:57           5631 Power.Settings.PCIExpress.ppkg
-a—-       18.03.2017     21:57          11478 Power.Settings.Processor.ppkg
-a—-       18.03.2017     21:57           6623 Power.Settings.Sleep.ppkg

Was passiert nun wenn man Get-ProvisioningPackage mit so einer Datei aufruft?

PS C:\windows\Provisioning\Packages> Get-ProvisioningPackage -PackagePath .\Power.Settings.Processor.ppkg

IsInstalled     : False
PackageID       : fc01e91f-914c-45af-9d7c-0b2e5fbedf62
PackageName     : Power.Settings.Processor
PackagePath     : C:\windows\Provisioning\Packages\Power.Settings.Processor.ppkg
Description     :
Rank            : 0
Altitude        : 0
Version         : 7.0
OwnerType       : Microsoft
Notes           :
LastInstallTime :
Result          :

Ja das sieht ja nun schon wesentlich besser aus. Also handelt es sich tatsächlich um Cmdlets um ppkg-Dateien verwalten zu können. These also bestätigt.

Und wo braucht man nun ppkg-Dateien konkret? Zur Einrichtung von Rechnern oder Handies, dazu musste man seither bei den Einstellungen auf Konten, dort auf Arbeits- und Schulkonto gehen und da dann auf Bereitstellungspaket hinzufügen oder entfernen. Dies geht nun wesentlich einfacher!

Hier eine Beschreibung zum Thema: https://technet.microsoft.com/en-us/itpro/windows/deploy/provisioning-how-it-works.

Man könnte nun noch viel mehr probieren aber die Richtung ist schon mal klar.

Einfacher SNMP Walker in Powershell

15 März 2017

Ein Uraltprotokoll das Simple Network Management Protokoll kurz SNMP gibt es heute immer noch. Teilweise hilft es sogar ganz schnell Informationen zu erhalten, die sonst nur mühsam aus anderen Geräten, z. B. Druckern zu erhalten sind.

Auch im Server 2016 und Windows 10 gibt es standardmäßig eine COM-Bibliothek welche die Kommunikation mit SNMP-Geräten ermöglicht. Die Bibliothek bringt eine Funktion mit Namen GetTree mit. Mittels dieser Funktion kann man auf einen Schlag alle relevanten Informationen erhalten. Dies hilft oft schon einen ersten Eindruck von einem Gerät zu erhalten, man muss lediglich die IP-Adresse kennen. Wichtig zu wissen, die OIDs müssen mit einem führenden Punkt angegeben werden:

$IP = "192.168.1.87"
$SNMP = New-Object -ComObject olePrn.OleSNMP
$SNMP.Open($IP, "public")
$SNMP.GetTree(".1.3.6.1")
$SNMP.Close()

Die Zahl 1.3.6.1 ist quasi eine Art Adresse. Bei einem aktuellen HP-Drucker funktioniert diese 1.3.6.1 die Adresse 1.3.6 allerdings nicht. Interessiert man sich speziell für Managementdaten dann wird man unter 1.3.6.1.2 fündig. Hier eine schöne Auflistung mit RFC-Verweisen, was wo gefunden werden kann: http://www.multinet.de/fileadmin/mib2/. Drucker werden speziell über die OID 1.3.6.1.2.1.43 abgefragt. Auf der Internetseite http://www.alvestrand.no/objectid/ ist die Hierarchie schön erklärt. Darüber kann man dann den Sinn der Zahlen verstehen.

Was kann man mit diesen OIDs und SNMP anstellen? Z. B. kann man einen Reboot eines Druckers im Netz auslösen: https://newyear2006.wordpress.com/2016/07/10/hp-netzwerkdrucker-per-remote-und-reboot-txt-neu-starten-nix-klappt-aber-snmp-bringt-die-lsung/. Man findet z. B. für die OID 1.3.6.1.2.1.43.5.1.1.3 folgenden Eintrag:

{iso(1) identified-organization(3) dod(6) internet(1) mgmt(2) mib-2(1) printmib(43) prtGeneral(5) prtGeneralTable(1) prtGeneralEntry(1) prtGeneralReset(3)}

prtGeneralReset OBJECT-TYPE
-- This value is a type 3 enumeration
SYNTAX INTEGER {
notResetting(3),
powerCycleReset(4), -- Cold Start
resetToNVRAM(5), -- Warm Start
resetToFactoryDefaults(6) -- Reset contents of
-- NVRAM to factory defaults
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this value to `powerCycleReset, `resetToNVRAM, or `resetToFactoryDefaults will result in the resetting of the printer. When read, this object will always have the value `notResetting(3), and a SET of the value `notResetting shall have no effect on the printer. Some of the defined values are optional. However, every implementation must support at least the values `notResetting and resetToNVRAM."

Quelle: http://oid-info.com/get/1.3.6.1.2.1.43.5.1.1.3

Die tatsächliche Quelle in diesem Fall ist aber eine RFC, die RFC 1759, https://tools.ietf.org/html/rfc1759.html. Dadurch, dass es eine RFC ist, wird es natürlich klar, dass es bei dem Script für den Druckreboot nicht um eine HP spezifische OID handelt sondern um eine allgemein gültige OID, welche auch von anderen Druckerherstellern verwendet werden kann. Damit funktioniert der Neustart auch bei anderen Netzwerkdruckern.

Noch ein Hinweise zum Artikel mit dem Druckerreset. Die Angabe des Parameters 4 ist nun auch klar, denn die steht für powerCycleReset, siehe oben die Parameter.

Um einfache Infos zu einem Gerät zu erhalten fragt mein einfach den sysDescr ab. Der sysDescr stellt eine Gerätebeschreibung dar. http://www.alvestrand.no/objectid/1.3.6.1.2.1.1.1.html. Der Aufruf sieht dann so aus:

$snmp.get(".1.3.6.1.2.1.1.1.0")
HP ETHERNET MULTI-ENVIRONMENT

oder noch besser, man fragt mittels Tree nach:

$snmp.GetTree(".1.3.6.1.2.1.1.1")
system.sysDescr.0
HP ETHERNET MULTI-ENVIRONMENT

Dabei ist offensichtlich, dass sich HP nicht an die Vorgabe hält und Versionsinformationen unterdrückt. Das Beispiel zeigt aber auch, dass man einen einzelnen Wert mittels Get() und .0 erhalten kann und bei GetTree() automatisch alles dazugehörige erhält, sogar den Typ.

Mit dieser Information können wir nun auch folgendes schreiben:

$snmp.get("system.sysDescr.0")
HP ETHERNET MULTI-ENVIRONMENT

D. h. man kann nun sprechendere Namen verwenden. Für unser Druckerreset wäre dies:

$snmp.gettree(".1.3.6.1.2.1.43.5.1.1.3")
printmib.prtGeneral.prtGeneralTable.prtGeneralEntry.prtGeneralReset.1
3
$snmp.get("printmib.prtGeneral.prtGeneralTable.prtGeneralEntry.prtGeneralReset.1")
3

Beides mal wird die 3 für notResetting geliefert.

Noch ein Punkt der wichtig ist, um die Rückgaben von GetTree() besser zu verstehen. Es werden immer zwei Arrays zurückgegeben, d. h. zuerst ein Array mit den Namen der OIDs und danach ein Array mit den eigentlichen Werten zu den OIDs. Dies wird deutlich wenn man die verfügbaren Sprachen des Druckers abfragt:

$snmp.gettree("printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage")
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.1
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.2
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.3
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.4
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.5
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.6
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.7
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.8
en
es
de
fr
ar
it
pt
nl

In Wahrheit ist es jedoch ein verschachteltes bzw. zweidimensionales Array:

($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[0]
Der Index [0] ist für einen Zugriff auf ein 2-dimensionales Array unzulässig.
In Zeile:1 Zeichen:1
+ ($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[0]
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NeedMultidimensionalIndex

($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[0,0]
printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage.1.1
($snmp.gettree(".1.3.6.1.2.1.43.7.1.1.2"))[1,0]
en

Man erhält zuerst die Namen und in der zweiten Dimension die Werte. Also [0,*] enthält alle Namen und [1,*] enthält alle Werte.

Achso, wie bin ich jetzt von “printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage” auf 1.3.6.1.2.1.43.7.1.1.2 gekommen? Auch dazu gibt es eine Funktion:

$snmp.OIDFromString("printmib.prtLocalization.prtLocalizationTable.prtLocalizationEntry.
prtLocalizationLanguage") -join "."
1.3.6.1.2.1.43.7.1.1.2

Jetzt hab ich soviel von den ganzen Zusammenhängen geschwafelt, warum nun nicht am Schluss noch etwas sinnvolles zusammenbauen, z. B. eine Tabelle mit allen sinnvollen Werten?

$e=$SNMP.GetTree(".1.3.6.1")
$d=@()
# umsortieren der Arraystruktur
for($i=0;$i-lt $e.length/2;$i++){$d+=@($e[0,$i], $e[1,$i]) }
$d | out-gridView

Oder noch besser alles mehr powershelllike mit Objekten:

$e=$SNMP.GetTree(".1.3.6.1")
$d=@()
# umsortieren der Arraystruktur
for($i=0;$i-lt $e.length/2;$i++){$d+=[pscustomobject]@{ID=$e[0,$i];Value=$e[1,$i];OID=($snmp.OIDFromString(($e[0,$i])) -join ".")} }
$d | out-gridView

Damit steht dem Erkunden der SNMP-Welt nichts mehr im Wege!

“Wie soll diese Website geöffnet werden?”-Dialog wegbekommen

10 März 2017

In bestimmten Situationen, vor allem nach einer Installation oder Deinstallation eines Programms, kann es bei einem neu eingerichteten Windows 10 dazu kommen, dass ein Dialog geöffnet wird mit dem Text:

Wie soll diese Website geöffnet werden?

App verwenden
—–
Standardbrowser verwenden

[  ]  Immer diese App zum Öffnen von <Website> verwenden

OK

Da die Installationen oder Deinstallationen meistens mit Adminrechten durchgeführt werden, kann es zu einer Situation kommen, wenn man die Meldung nicht beachtet und der eigentliche administrative Vorgang bereits abgeschlossen ist, dass die Meldung weiterhin am Bildschirm stehen bleibt und nicht mehr wegzubekommen ist. Das hat mit den fehlenden Rechten des Standardbenutzers nach der Installation zu tun.

Was also tun?

Entweder Rechnerneustart oder im Taskmanager die Datei OpenWith.EXE beenden.

Treiber von Windows 10 im Windows Server 2016 installieren wenn es keine offiziellen Treiber gibt, am Beispiel einer Intel-Netzwerkkarte

7 März 2017

Eigentlich sind sich Windows 10 und Windows Server 2016 recht nahe, je nach Versionsstand von Windows 10. Dennoch gibt es manchmal bei der verwendeten Hardware Einschränkungen in Bezug auf Treiber. In einem aktuellen Fall war in einem Rechner eine Intel I219-V Netzwerkkarte verbaut. Dieser Karte genügt natürlich heutigen Managementansprüchen in Servern nicht unbedingt und deshalb wurde in Server 2016 die Treiberunterstützung für diese Karte unterlassen. Was an dieser Karte aber komisch ist, ist dass es eine Zertifizierung im Windows Server Katalog dafür gibt: https://www.windowsservercatalog.com/item.aspx?idItem=985d89e0-d6d1-b9e0-654c-0209df71a8c7&bCatID=1468.

Was kann man machen um die Karte trotzdem nutzen zu können? Früher ging man her und änderte die zugehörige Treiber-INF-Datei und aktivierte die Windows 10 Treiber für Server 2016. Diese Methode wurde seit Windows Vista Zeiten immer schwieriger. Man benötigt nun passende Zertifikate, damit Änderungen an INF-Dateien autorisiert sind. Man kann aber in Server 2016 noch die bewährte Methode gehen, die Überprüfung der Treibersignatur auszuschalten, dann installiert man einmal die Treiber, ladet und segnet sie ab. Danach aktiviert man wieder die Prüfung der Treibersignaturen. Nun kann man die Geräte mit Windows 10 Treibern unter Windows Server 2016 nutzen.

Für obiges Beispiel beschreibt dieser Blogartikel den Vorgang sehr schön: http://blog.citrix24.com/install-windows-server-2016-core-intel-nuc/.

Hier mache ich aber eine komplette Beschreibung wegen ein paar Besonderheiten und weil oft Blogs im Internet auch verschwinden.

Ermittlung der HardwareID
Fangen wir an die betreffenden Geräte ausfindig zu machen. Normalerweise würden erkannte Netzwerkadapter mittels Get-NetAdapter auftauchen. Aber die Intel I219-V ist nicht dabei. Nun kann man wie im Blogartikel beschrieben mittels

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Ethernet"}

die HardwareID ermitteln, welche

name     : Intel(R) Ethernet Connection I219-V
deviceid : PCI\VEN_8086&DEV_1570&SUBSYS_20638086&REV_21\3&11583659&0&FE

ergibt. Von dieser Info ist die VEN_8086&DEV_1570 von Bedeutung. Im Blogartikel wird noch eine zweite Variante genannt, die bezieht sich auf die WLAN-Karte, welche nicht unter Ethernet zu finden ist, sondern unter Network. Wenn man allerdings unter einem deutschsprachigen Windows diesen Befehl ausführt

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Network"}

dann erscheint nicht die gesuchte Info, sondern

name                                   deviceid
—-                                   ——–
Microsoft Kernel Debug Network Adapter ROOT\KDNIC\0000

weil es Network nicht gibt. Man muss statt dessen nach

GetWMIObject win32_PNPEntity |select name,deviceid |where {$_.Name match "Netzwerkcontroller"}

suchen, um z. B. dieses Ergebnis zu bekommen:

name     : Netzwerkcontroller
deviceid : PCI\VEN_8086&DEV_24F3&SUBSYS_90108086&REV_3A
\4&A711841&0&00E0

Blöd und umständlich so was. Aber wir sind ja auf Server 2016, da gibt es neuere Möglichkeiten Hardwaredinge abzufragen:

Get-PnpDevice -Class Net| select status, friendlyname, instanceid|fl *

status       : OK
FriendlyName : Intel(R) Ethernet Connection I219-V
InstanceId   : PCI\VEN_8086&DEV_1570&SUBSYS_20638086&REV_21\3&11583659&0&FE

status       : Error
FriendlyName : Netzwerkcontroller
InstanceId   : PCI\VEN_8086&DEV_24F3&SUBSYS_90108086&REV_3A
\4&A711841&0&00E0

Prima. Hier sehen wir auch gleich, dass es beim Wirelesscontroller ebenso Probleme gibt, weil dort der Status Error steht. Dies war beim I219-V am Anfang natürlich auch, allerdings sind hier im Beispiel bereits die LAN-Treiber geladen.

Wir müssen uns also nur merken, dass wir anstatt der WMI-Abfrage von Win32_PNPEntity auch direkt Get-PnPDevice –Class Net verwenden können.

Treiber herunterladen und entpacken
Neben der HardwareID benötigen wir auch die passenden Treiber von Windows 10. In diesem Fall waren diese unter https://downloadcenter.intel.com/de/download/ unter dem Stichwort ProWin und ProsetWireless zu finden. Damit man aber mit den Dateien etwas anfangen kann, müssen diese aber entpackt werden. Leider wird es immer mehr zur Unsitte nicht mehr hinzuzuschreiben, wie man Treiber nur entpacken aber nicht installieren kann. Im Zweifel verwendet man 7zip um die Treiber aus den .EXE-Dateien zu extrahieren.

INF-Datei modifizieren
So nun muss man zu den IDs den passenden Treiber finden. Dazu ruft man

Get-ChildItem –Recurse | Select-String –Pattern "VEN_8086&DEV_1570" | group Path | select name

Name
—-
D:\IntelTreiber\PRO1000\Winx64\NDIS62\e1d62x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS63\e1d63x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS64\e1d64x64.inf
D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

auf. Dabei sollte man bereits im Pfad stehen, wo man die Treiber entpackt liegen hat.

Eine Frage ergibt sich, welche Datei man nun bearbeitet? Im konkreten Fall die e1d65x64.inf. Mit den kryptischen Versionen 62, 63, 64 und 65 ist die NDIS-Version gemeint. Windows Server 2016 beherrscht zwar bereits NDIS 6.60 aber ist abwärtskompatibel, deshalb die 65 für Version 6.50. Hier findet man ein paar Infos zu den verschiedenen NDIS-Versionen bei Windowsversionen: https://en.wikipedia.org/wiki/Network_Driver_Interface_Specification.

Man ladet nun die INF-Datei einfach in Notepad, im obigen Beispiel so:

Notepad D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

Nun müssen wir uns die Sektionen [Intel.NTamd64.10.0.1] und [Intel.NTamd64.10.0] genauer ansehen. Kurz die 10.0.1 steht für Windows Clientversionen, und 10.0 für Server.

Die Sektionen haben bei INF-Dateien eine besondere Bedeutung. Das lustige ist, dass in der betreffenden INF-Datei nicht nur Windows 10 sondern auch Server 2016 Informationen stehen, ja sogar explizit für die I219-V Netzwerkkarte. Allerdings wurde im für Server entscheidenden Abschnitt die I219-V ausgelassen!

Mehr Infos zu den Herstellerangaben bei INF-Dateien findet man hier, da wird auch der genaue Aufbau der Sektionsnamen beschrieben: https://msdn.microsoft.com/de-de/windows/hardware/drivers/install/inf-manufacturer-section.

Man fügt also unter [Intel.NTamd64.10.0] diesen Eintrag hinzu

%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570.10.0.1,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179

dabei müsste auch

%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570
%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570&SUBSYS_00008086
%E1570NC.DeviceDesc%            = E1570,       PCI\VEN_8086&DEV_1570&SUBSYS_00011179

funktionieren und stellt sogar die sicherere Variante dar.

Treibersignaturprüfung ausschalten
Jetzt kommt der eigentlich wichtigste Punkt. Ohne diesen bekommt man die Sache nicht zum Laufen.

bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING ON
bcdedit /set NOINTEGRITYCHECKS ON

Für diese Änderung muss allerdings der Rechner neu gestartet werden, also

Restart-Computer

Treiber installieren
Nun kommt der spannende Moment, wenn man die Treiber lädt, ob es klappt.

pnputil.exe -i -a D:\IntelTreiber\PRO1000\Winx64\NDIS65\e1d65x64.inf

Wenn dann so was ausgegeben wird, hat alles geklappt:

Microsoft-PnP-Hilfsprogramm

Verarbeitungsinf.:            e1d65x64.inf
Der Treiber konnte auf einem Gerät dieses Systems installiert werden.
Das Treiberpaket wurde erfolgreich hinzugefügt.
Veröffentlichter Name:            oem2.inf

Versuche gesamt:              1
Anzahl erfolgreicher Importe: 1

Abschlussarbeit
Natürlich muss man nun die Treibersignaturprüfung wieder aktivieren.

bcdedit /set LOADOPTIONS ENABLE_INTEGRITY_CHECKS
bcdedit /set TESTSIGNING OFF
bcdedit /set NOINTEGRITYCHECKS OFF

 

UEFI Boot und Probleme ins BIOS/UEFI zu kommen

3 Dezember 2016

Bei aktuellen Rechnern mit ihren superschnellen Bootvorgängen kann es schon schwierig werden ins BIOS bzw. UEFI zu kommen. Man hämmert wie blöde auf irgendwelche F-Tasten, die man manchmal schon gar nicht mehr auf der Tastatur hat, um dann später festzustellen, es war die falsche oder man war mal wieder zu langsam. Hier eine Aufstellung von möglichen Tasten: http://www.isunshare.com/windows-password/how-to-set-your-computer-to-boot-from-usb-drive.html#opt4.

Windows
Für obiges Problem gibt es seit Windows 8 Abhilfe. Man konnte seither unter den PC-Einstellungen->Update und Sicherheit->Wiederherstellung den Erweiterten Start aufrufen. Da konnte man dann meist den Eintrag UEFI-Firmware Einstellungen unter Problembehandlung->Erweiterte Optionen aufrufen oder die Starteinstellungen ändern. Diese Möglichkeit ist gut aber als bekennender Commandliner nicht sehr befriedigend.

Nun hat Microsoft bereits bei Windows 8 beim Shutdownbefehl den Parameter /o eingeführt. Dieser kürzt die Sache deutlich ab und man gelangt direkt in den Bildschirm mit den Erweiterten Startmöglichkeiten. So gehts:

shutdown /r /o

Wer sich nun unter Windows 10 v1607 die Parameter des Shutdown-Befehls anschaut, der stellt fest, es gibt nun auch einen Parameter /fw, welcher für Firmware steht und Firmware steht wiederum für die ganze UEFI-Geschichte. Man kann also mittels

shutdown /r /fw

direkt in die UEFI-Einstellungen booten! Endlich ein sauber gesteuerter Zugriff ohne zig unnötige Menüs zwischendrin!

Übrigens noch ein Tipp: Es gibt Situationen, da hat man SetHC.EXE oder UTILMAN.EXE umgebogen. Hier ein Beispiel dafür: https://newyear2006.wordpress.com/2015/08/30/abgelaufene-aktivierungen-erschweren-einem-das-leben-unter-windows/. In diesem Fall funktioniert shutdown /r /o z. B. nicht. Man kann sich jedoch behelfen, wenn man statt shutdown /o einfach

reagentc.exe /boottore

verwendet. Hat den gleichen Effekt, funktioniert aber bisher in allen Situationen! Einzige Voraussetzung dafür ist ein korrekt eingerichtetes RecoveryEnvironment. Infos dazu erhält man über reagentc /info.

Linux
Wer nun mit Linux unterwegs ist welches bereits SystemD nutzt, der kommt mit diesem Befehl in die UEFI-Einstellungen:

systemctl reboot --firmware-setup

Hier noch ein paar erhellende Infos zu UEFI unter Linux, vor allem, wie man Firmwarevariablen erzeugen kann und wie man darauf zugreift: https://firmware.intel.com/blog/accessing-uefi-variables-linux.

Ein weiterer interessanter Link für Linux und UEFI: http://superuser.com/questions/519718/linux-on-uefi-how-to-reboot-to-the-uefi-setup-screen-like-windows-8-can.

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

Tschüss Teamviewer– Alternative – Willkommen Remotehilfe

4 August 2016

Teamviewer war mal eine echte Hilfe aber wie bei allem wird es irgendwann zur Plage. Hier hab ich mich schon mal über den Teamviewer ausgelassen: https://newyear2006.wordpress.com/2014/07/05/teamviewer-hat-seinen-zenit-berschritten/. Er hat seine Vorteile aber wenn es darum geht jemand unbedarftem schnell zu helfen, dann stößt man immer öfter an seine Grenzen.

Microsoft hatte schon bei Windows XP mit der Remoteunterstützung versucht das Leben der Supporter einfacher zu machen. Bei Windows 7 mit Einführung von Easy Connect war das Prinzip gut aber Microsoft war damals noch nicht in der Cloud angekommen. Deshalb gab es zu viele Situationen wo die Remoteunterstützung einfach nicht brauchbar war. Mit dem Windows 10 Anniversary Update, also Version v1607 hat Microsoft nun einen neuen Versuch gestartet die Sache anzugehen.

Und oh Wunder, es scheint richtig gut geworden zu sein! Muss auch mal MS loben, sonst wird ja nur über sie hergezogen Smiley.

Wer Cortana um Remotehilfe befragt dem zeigt sich die Remotehilfe App auch Quick Assist genannt. Dabei zeigt sich ein einfaches Fenster, wo man Jemand Hilfe anbieten oder Hilfe in Anspruch nehmen kann. Voll simpel.

Der Hilfesuchende klickt einfach auf “Unterstützung anfordern” und wird dann aufgefordert einen sechstelligen Code einzugeben. Dieser Code wird vom Gegenüber demjenigen der die Hilfe anbietet erzeugt und angezeigt. Dieser ruft auch Remotehilfe auf und wählt dann “Unterstützung gewähren” aus. Danach öffnet sich ein Fenster, wo man sich mit seinem Microsoft Konto anmelden muss, dies erscheint nicht, wenn man sein lokales Konto mit dem Microsoft Konto verbunden hat. Danach wird der sechstellige Sicherheitscode erzeugt und angezeigt. Diesen teilt man nun dem Hilfesuchenden mit und schon kann es losgehen.

Bei der Vorgehensweise zeigt sich eine Umkehrung des Teamviewerverbindungsaufbauprinzips. Nicht der Hilfesuchende hat die ID und das Kennwort sondern der Gewährende. Durch die Azurecloud und modernste ICE-Techniken um NATs zu durchbohren, klappt dann die Verbindung ohne Probleme.

Eine prima Alternative also zum Teamviewer! Aber es geht noch besser.

Ruft man die Internetseite https://remoteassistance.support.services.microsoft.com auf, dann bekommt man auch hier die Auswahl Hilfe anzufordern oder zu gewähren. Wie bei der Desktop-App kann eine Sitzung aufgebaut werden. Leider bricht die Verbindung zum jetzigen Zeitpunkt immer ab, wenn es darum geht den Bildschirm zu übertragen. Schade, schade, das wäre eine echtes Highlight gewesen, wenn dies auch noch funktioniert hätte. Aber warten wir mal ab…

Was ist neu bei Windows 10 v1607?

3 August 2016

Das Anniversary Update von Windows 10 ist nun offiziell verfügbar, stellt sich wie immer die Frage, was hat sich geändert?

Hier der Link zu Technet: https://technet.microsoft.com/en-us/itpro/windows/whats-new/whats-new-windows-10-version-1607

und MSDN: https://msdn.microsoft.com/en-us/windows/uwp/whats-new/windows-10-version-1607

Weitere Infos kann man hier finden: https://newyear2006.wordpress.com/2016/01/28/neueste-beschreibungen-fr-windows-10-bzw-windows-10-mobile/. Dabei auch die Kommentare beachten.

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!