Archive for the ‘Updates’ Category

Server bootet nicht nach Installation einer Intel I350-T2V2 Netzwerkkarte

30 April 2018

Bei einer Aufrüstung eines Hyper-V Servers mit einer “Intel Ethernet Server Adapter I350-T2V2”-Karte bootete der Rechner nach dem Einstecken der Netzwerkkarte nicht mehr. Nicht einmal das BIOS des Rechners war erreichbar. Statt dessen erschien nur oben links ein blinkender Cursor auf schwarzem Hintergrund.

Der Server selber war schon etwas älter deshalb gab es keine BIOS-Updates. Was also tun? Die Beschreibung auf dieser Seite brachte die Lösung: https://communities.intel.com/thread/56362.

Im Prinzip war das Flashen der Firmware der Netzwerkkarte notwendig. Das passende Utility war dieses hier: https://downloadcenter.intel.com/download/19186, das sogenannte “Intel® Ethernet Connections Boot Utility, Preboot Images, and EFI Drivers”.

Jetzt wurde nur noch ein Rechner benötigt, der mit der Karte bootete, tatsächlich konnte ein anderer, älterer Windows-Rechner mit eingesteckter Karte problemlos booten. Damit konnte dann mittels (es war ein 32-Bit Windows, bei 64-Bit ist der Aufruf leicht anders)

BOOTUTILW32.EXE

die Netzwerkkarte ermittelt werden und mittels

BOOTUTILW32.EXE –up PXE –nic 1

aktualisiert werden. Zuvor musste aber noch die Datei BootIMG.FLB aus dem übergeordneten Verzeichnis in das Verzeichnis der BOOTUTILW32.EXE kopiert werden.

Mit dem Boot Utility wurde die Firmware der Netzwerkkarte von der Version 1.3.98 auf die Version 1.5.85 aktualisiert. Danach konnte der ursprüngliche Rechner mit der Netzwerkkarte problemlos gebootet und eingerichtet werden.

Advertisements

Probleme mit Windows 10 Feature Update weil ein alter Treiber das Update auf 1709 zunichte machte

16 März 2018

Bei einem Windows 10 Rechner mit v1703 sollte auf auf das Fall Creator Update v1709 aktualisiert werden. Doch dies war nicht möglich. Egal welche Variante probiert wurde, es klappte einfach nicht. Installiert war die 32-Bit-Variante, ob dies mit dem Problem zu tun hat, konnte nicht ermittelt werden. Was aber im weiteren Verlauf noch von Bedeutung sein wird, ist, dass es sich um einen Rechner handelt der bereits Windows Vista und Windows 7 davor gesehen hat und über Jahre hinweg immer mittels Windows-Updates aktualisiert wurde.

Der eigentliche v1709-Updatevorgang lief sogar zu fast 100% durch. Doch am Anfang wurde nach einem Neustart das Update immer rückgängig gemacht. Übliche Troubleshootversuche wie https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolve-windows-10-upgrade-errors brachte leider nichts.

Es wurde dann auch die setupact.log-Datei analysiert, welche im Verzeichnis "C:\$WINDOWS.~BT\Sources\Panther" zu finden ist. Dort war lediglich diese Fehlerinformation zu finden:

Error                 SYSPRP ActionPlatform::DeleteValue: Error from RegOpenKeyExW on key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Sysprep\OfflineState; dwRet = 0x13

Aber es gibt scheinbar keine Informationen darüber. Lediglich ein MSDN-Foreneintrag https://social.msdn.microsoft.com/Forums/de-DE/ee8c7041-930c-4a2e-9720-e6b49a05c67f/windows-10-fcu-update-fails-with-registry-key-delete-of-sysprep-offlinestate?forum=win10itprosetup mit ähnlicher Konstellation deutete etwas an, dass es an einem Treiber liegen müsse.

Nachdem einige Versuche fehlgeschlagen sind, wurde die Sache erst nach weiteren zwei Monaten in Angriff genommen. Nach normalen Windows Updates tauchte beim erneuten Versuch das Featureupdate zu installieren auf einmal diese Meldung auf:

"Windows could not configure one or more system components"

Aufgrund der Meldung und dieses Artikels https://social.technet.microsoft.com/Forums/en-US/1b5b24b7-a0f0-4955-9f44-32a977643aef/windows-10-fall-creator-upgrade-1709-stops-at-45-with-windows-could-not-configure-one-or-more?forum=win10itprosetup wurde weiter gesucht. Ein Eintrag sagt, man solle sich die Datei $Windows.~bt\Sources\Rollback\setupapi\setupapi.dev.log genauer anschauen. Tatsächlich waren darin Fehler vermerkt.

Eigentlich sollte Windows 10 vor einem Update prüfen, ob die Treiber alle verfügbar sind und entsprechend ein Update von vornherein ablehnen, wenn etwas nicht passt. Aber vielleicht ist der Computer mal wieder nicht schlau genug seine Probleme selber zu lösen.

Tatsächlich  brachte die Suche nach unnötigen Treibern die Lösung. So wurde mittels pnputil.exe zunächst die vorhandenen Treiberdateien aufgelistet.

pnp-util /enum-drivers

Dabei tauchten einige alte NDIS-Treiber, also Netzwerkkartentreiber auf. Im obigen Forums-Artikel gibt es viele, die auf einmal nach abstöpseln von WLAN-Adaptern erfolgreich das Update einspielen konnten. Also die alten NDIS und andere unsinnige alte Treiber mittels

pnputil /delete-driver oemx.inf /force 

gelöscht, wobei x bei oemx.inf immer eine Zahl die bei enum-drivers ermittelt wurde, darstellt.

Am Ende hat doch tatsächlich die Installation geklappt!

Automatische Windows-Updates bei Windows 10 (v1709) unterdrücken

8 Januar 2018

Bei Windows 10 mit der Version v1709 ist es nicht mehr so einfach möglich Automatische Windows-Updates zu verschieben, zu verzögern oder gar komplett zu unterbinden. Ok man könnte dem Rechner den Internetzugang unterbinden aber macht das Sinn? Leider herrscht hier absolutes Chaos und es ist nicht leicht sinnvolle Informationen dazu zu erhalten. Vor allem, da bei jedem Halbjahresupdate Änderungen am Updatemechanismus stattfinden. OK in der Knowledge Base ist eine Methode beschrieben, Problembehaftete Updates loszuwerden: https://support.microsoft.com/en-us/help/3183922/how-to-temporarily-prevent-a-windows-update-from-reinstalling-in-windo das gleiche für Treiber: https://support.microsoft.com/en-us/help/3073930/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-window.

Es gibt jedoch momentan jedoch noch eine einfachere Möglichkeit Automatische Updates zu unterbinden, man muss nur den Zugriff auf den Update-Session-Orchestrator Client (USOClient.EXE) unterbinden.

Öffnet man als Administrator eine Powershell-Eingabeaufforderung, so führt man einfach folgende Befehle aus:

cd "$($Env:windir)\System32"
.\takeown.exe /f .\UsoClient.exe /a
.\icacls.exe "$($Env:windir)\System32\UsoClient.exe" /inheritance:r /remove "Administratoren" "
Authentifizierte Benutzer" "Benutzer" "System"

Wichtig! Obige Befehle funktionieren nur auf einer deutschen Windowsversion! Nach dem Aufruf kann UsoClient.exe nicht mehr aufgerufen werden und es erscheint eine Fehlermeldung:

PS C:\Windows\System32> .\UsoClient.exe
Fehler beim Ausführen des Programms "UsoClient.exe": Zugriff verweigertIn Zeile:1 Zeichen:1
+ .\UsoClient.exe
+ ~~~~~~~~~~~~~~~.
In Zeile:1 Zeichen:1
+ .\UsoClient.exe
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

Möchte man die Automatischen Updates wieder zulassen, so kann man UsoClient.exe wieder die Standardrechte zukommen lassen, indem man diesen Aufruf startet:

.\icacls.exe "$($Env:windir)\System32\UsoClient.exe" /reset

Wie funktioniert die Sache? Im Grunde entscheidend ist der Entzug der Ausführungsrechte des Benutzers bei UsoClient.EXE, d. h. es wird effektiv VORDEFINIERT\Benutzer:(RX) von UsoClient.EXE entzogen. Die aktuellen Einstellungen kann man so einsehen:

.\icacls.exe "$($Env:windir)\System32\UsoClient.exe"

Grundlage für diese Vorgehensweise war hier beschrieben: https://www.tenforums.com/tutorials/8013-enable-disable-windows-update-automatic-updates-windows-10-a-post1224927.html#post1224927. Es gibt auch noch eine Hammermethode generell Updates loszuwerden, diese ist hier beschrieben: https://www.tenforums.com/tutorials/8013-enable-disable-windows-update-automatic-updates-windows-10-a-50.html#post1236513. D. h. solange man bei oben beschriebener Methode bleibt und auf die Hammermethode verzichtet, kann man manuelle Updates über Einstellungen->Updates noch anstoßen, auch die Defenderupdates klappen problemlos.

In der Aufgabenplanung sind unter Microsoft\Windows\UpdateOrchestrator verschiedene Aufgaben welche mindestens einmal am Tag ausgeführt werden, welche nach Updates Ausschau halten. Dabei wird UsoClient.EXE aufgerufen. Wenn die Rechte entzogen sind, kann der Aufruf nicht erfolgen und die Aufgabenplanung meldet den Fehler “Zugriff verweigert (0x80070005)”, prüfbar mit diesem Befehl:

"0x{0:x}" -f (Get-ScheduledTask -TaskName "Schedule Scan"|Get-ScheduledTaskInfo).lasttaskresult

Der Beweis, dass dem tatsächlich so ist, kann hiermit erbracht werden:

Get-ScheduledTask -TaskName "Schedule Scan"| select taskname -ExpandProperty actions

taskname         : Schedule Scan
Id               :
Arguments        : StartScan
Execute          : %systemroot%\system32\usoclient.exe
WorkingDirectory :
PSComputerName   :

UsoClient.EXE kennt folgende Parameter:

StartScan
StartDownload
StartInstall
ScanInstallWait
RefreshSettings
ResumeUpdate

Zum Thema gäbe es noch mehr zu schreiben, weil einige zusätzliche Aufgaben je nach Status des Vorgangs erzeugt, bzw. geändert werden, deshalb hier ein paar Aufgabennamen, welche hier teilweise auftauchen können:

Reboot
Schedule Scan
USO_Broker_Display
AC Power Download
AC Power Install
Maintenance Install
MusUx_LogonUpdateResults

Neben obigen Aufgaben kann man davon ausgehen, wenn es AC Power gibt, dass es bei Notebooks evtl. auch DC Power Aufgaben, also

DC Power Download
DC Power Install

geben könnte. Daneben gab es beim Testen auch noch einmal

Schedule Scan Retry

als keine Netzwerkverbindung zur Verfügung stand.

Obige Ausführungen zu den Aufgabennamen beziehen sich auf eine Testmaschine. Auf einem Rechner welcher in einer Domäne war, welcher bereits auch Windows 7 und mehrere Windows 10 Updates gesehen hatte, hatte folgende Aufgaben zu bieten:

Combined Scan Download Install
Maintenance Install
MusUx_UpdateInterval
Policy Install
Reboot
Refresh Settings
Resume On Boot
Schedule Scan
USO_UxBroker_Display
USO_UxBroker_ReadyToReboot

Man kann davon ausgehen, dass z. B. Policy Install und Refresh Settings mit Gruppenrichtlinien etwas zu tun haben.

Die Aufgabennamen kann man mittels

Get-ScheduledTask | where taskpath -match UpdateOrchestrator
# oder
Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\"

ermitteln. Weitere Powershell-Aufrufe in diesem Zusammenhang seien hier noch kurz genannt:

# Dienststatus:
Get-Service UsoSvc,wuauserv
# Ermitteln von LastRuntime, LastTaskResult und NextRuntime:
Get-ScheduledTask | where taskpath -match UpdateOrchestrator|Get-ScheduledTaskInfo
# Status der Aufgaben:
Get-ScheduledTask | where taskpath -match UpdateOrchestrator|fl *
# Aktionen der einzelnen Aufgaben:
Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\"| select taskname -ExpandProperty actions

Windows hat mittlerweile auch Powershell-Cmdlets zum Updates aufrufen, diese sollen noch kurz genannt werden:

Get-WUIsPendingReboot
Get-WULastInstallationDate
Get-WULastScanSuccessDate
Start-WUScan
Install-WUUpdates
# schon länger verfügbar
Get-Hotfix

Um alles abzurunden wären jetzt noch Windows Ereigniseinträge vom UpdateOrchestrator eine schöne Sache, doch leider gibt es dazu noch keinen Provider. Komisch oder ich bin blind…

Nein, da war noch was. Unter C:\ProgramData\UsoShared\Logs finden sich .ETL-Dateien. D. h. da gibt es was! Dann sei noch schnell C:\ProgramData\USOPrivate\UpdateStore genannt. Aber dazu vielleicht irgendwann mehr.

Logging Komponenten bei Windows 10 Updates und Installationen

27 November 2017

Bei Windows gibt es mehrere setupact.log-Dateien. In diesen wird der komplette Update- bzw. Installationsprozess dokumentiert. Bei den Logeinträgen gibt es die sogenannten Logging-Komponenten. Eine Beschreibung von Microsoft https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolve-windows-10-upgrade-errors#log-entry-structure nennt dabei diese Komponenten:

Kürzel Beschreibung
CONX compatibility information
MOUPG main upgrade component?
PANTHR ?
SP setup platform
IBSLIB Image-based Setup (Lib?)
MIG migration engine
DISM Deployment Image Servicing and Management
CSI Component Servicing Infrastructure
CBS Component-Based Servicing

Wie das immer so ist mit den Beschreibungen, enthält die Realität mehr Überraschungen parat. Wenn man ein aktuelles Windows 10 v1709 mittels dieses Scripts

Get-Content .\setupact.log | % {If ($_) { If ($_.Substring(0, 1)) {  If ($_.length -gt 48) { If ($_.SubString(19, 1) -eq ",") { $_.Substring(43, 6)}}}} }| sort -Unique | ? {$_.trim() -gt 0} | % {$_.trim()}

untersucht, dann kommen weitere Logging-Komponenten zum Vorschein:

Kürzel Beschreibung
DIAG diagnose?
DU Driver/device updates
IBS Image-based Setup
SYSPRP System Preparation

Lässt man obiges Script auf eine erfolgreiche Windows 10 Update-Installation los, wo sich die SetupAct.log in C:\Windows\Panther befindet, dann tauchen noch ein paar Komponenten mehr auf:

Kürzel Beschreibung
CMI  
DIAGER diagnose error?
SXS side by side?
TOOL  
UI user interface?

Hier nochmal alle bisher gefundenen Komponenten in einer Tabelle:

Kürzel Beschreibung
CONX compatibility information
MOUPG main upgrade component?
PANTHR ?
SP setup platform
IBSLIB Image-based Setup (Lib?)
MIG migration engine
DISM Deployment Image Servicing and Management
CSI Component Servicing Infrastructure
CBS Component-Based Servicing
DIAG diagnose?
DU Driver/device updates
IBS Image-based Setup
SYSPRP System Preparation
CMI  
DIAGER diagnose error?
SXS side by side?
TOOL  
UI user interface?

Die SetupAct.log kann man an verschiedenen Stellen finden, je nach Phase des Updatevorgangs. Hier die möglichen Verzeichnisse:

Phase Pfad
Down-Level $Windows.~BT\Sources\Panther
OOBE $Windows.~BT\Sources\Panther\UnattendGC
Rollback $Windows.~BT\Sources\Rollback
Pre-initialization (prior to downlevel) Windows
Post-upgrade (after OOBE) Windows\Panther

Für weitere Unternehmungen in Powershell hier die bekannten Komponenten:

$klc="CONX", "MOUPG", "PANTHR", "SP", "IBSLIB", "MIG", "DISM", "CSI", "CBS", "DIAG", "DU", "IBS", "SYSPRP", "CMI",
"DIAGER", "SXS", "TOOL", "UI"

und so kann man feststellen, ob man es mit neuen Komponenten zu tun hat:

Get-Content .\setupact.log | % {If ($_) { If ($_.Substring(0, 1)) {  If ($_.length -gt 48) { If ($_.SubString(19, 1) -eq ",") { $_.Substring(43, 6)}}}} }| sort -Unique | ? {$_.trim() -gt 0} | % {$_.trim()}| % {If (-not ($_ -in $klc)) {$_}}

Nicht schön aber selten ;–)

Ü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/.

Übermittlungsoptimierung frisst die gesamte Bandbreite

28 Mai 2016

Eigentlich ist die Idee von Peer2Peer Protokollen reizvoll. So ermöglicht Windows 10 z. B. Updates über Peer2Peer von anderen Rechnern im Internet anstatt von Microsoft direkt zu laden. Leider hapert es an der Umsetzung.

Das Problem trat massiv bei einer aktuellen Windows 10 Preview mit Build 14295 auf. Als gerade eine neuere Buildversion verfügbar wurde, konnte man mit anderen Rechnern im selben Netzwerk nicht mehr vernünftig ins Internet. Die massiven Downloads, mehrere Verbindungen vom selben Rechner des neuen Builds, sorgten auf den anderen Rechnern für Stillstand.

Am Anfang war dies gar nicht klar, denn Windows Updates hatten früher noch nie Probleme gemacht. Diese laufen normalerweise über den Intelligenten Hintergrundübertragungsdienst (BITS). Erst Windows 10 führte die Möglichkeit der Peer2Peer Updates ein. Als das Problem dem Windowsrechner zugeordnet war, ging es an die Ursachenforschung.

Ein Get-Bitstransfer –AllUsers brachte gähnende Leere. Also war der BITS nicht Schuld, aber was war es dann, wo die Bandbreite fraß? Also den Windows Ressourcenmonitor angeworfen und beim Netzwerkverkehr nach den Downloads geschaut. Tatsächlich war hier der SVCHOST.EXE netsvcs mit einem fetten Download beteiligt. Nachdem zuerst der BITS-Dienst ausgeschaltet wurde, vielleicht hat er ja eine geheime Übertragung am Laufen, gab es immer noch keine Besserung.

Dann mal geschaut, was alles hinter netsvcs steckt:

$netsvcs= (Get-ItemProperty ‚registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost\‘ -Name netsvcs).netsvcs

$netsvcs
CertPropSvc
SCPolicySvc
lanmanserver
gpsvc
IKEEXT
iphlpsvc
seclogon
AppInfo
msiscsi
EapHost
schedule
winmgmt
browser
ProfSvc
SessionEnv
wercplsupport
dosvc
DcpSvc
wlidsvc
NcaSvc
NetSetupSvc
Themes
RetailDemo
lfsvc
FastUserSwitchingCompatibility
Ias
Irmon
Nla
Ntmssvc
NWCWorkstation
Nwsapagent
Rasauto
Rasman
Remoteaccess
SENS
Sharedaccess
SRService
Tapisrv
Wmi
WmdmPmSp
wuauserv
BITS
ShellHWDetection
LogonHours
PCAudit
helpsvc
uploadmgr
dmwappushservice
BDESVC
XboxNetApiSvc
UsoSvc
XblGameSave
DmEnrollmentSvc
DsmSvc
UserManager
XblAuthManager
AppMgmt

Na super da kommt richtig Freude auf. Um mehr Infos zu bekommen, könnte man nun

$netsvcs | Get-Service

aufrufen, da aber sicher nicht alle Dienste laufen, macht es mehr Sinn gleich mal die nicht vorhandenen und nicht laufenden auszunehmen:

($sr=$netsvcs | Get-Service | where status -eq running) 2> $null

Status   Name               DisplayName
——   —-               ———–
Running  CertPropSvc        Zertifikatverteilung
Running  lanmanserver       Server
Running  iphlpsvc           IP-Hilfsdienst
Running  AppInfo            Anwendungsinformationen
Running  schedule           Aufgabenplanung
Running  winmgmt            Windows-Verwaltungsinstrumentation
Running  browser            Computerbrowser
Running  ProfSvc            Benutzerprofildienst
Running  SessionEnv         Konfiguration für Remotedesktops
Running  dosvc              Übermittlungsoptimierung
Running  Themes             Designs
Running  lfsvc              Geolocation-Dienst
Running  SENS               Benachrichtigungsdienst für Systeme…
Running  ShellHWDetection   Shellhardwareerkennung
Running  UserManager        Benutzer-Manager
Running  AppMgmt            Anwendungsverwaltung

Damit wird die Sache schon übersichtlicher und man hat nähere Infos zum Geschehen.

Und so kann man sich dann die Frage stellen, was ist ein Übermittlungsoptimierungs-Dienst dosvc? Genauer gesagt handelt es sich dabei um die Windows Update Übermittlungsoptimierung. Also offizielle Infos dazu: http://windows.microsoft.com/de-de/windows-10/windows-update-delivery-optimization-faq.

Dann werden auch schnell die Probleme offensichtlich: https://social.technet.microsoft.com/Forums/en-US/b94d8e74-58de-451a-b137-7ec2028adc27/delivery-optimization-service-downloading-something-and-using-all-my-bandwidth?forum=win10itprogeneral

Get-ItemProperty registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dosvc -Name ServiceDLL| select servicedll

ServiceDll
———-
C:\WINDOWS\system32\dosvc.dll

Also ist die dosvc.dll die DLL, die es zu beachten gibt.

Nachdem das nun geklärt ist, so dann sollten wir mal wieder mit Mythen aufräumen, die sich leider immer wieder ergeben und ohne jeden Beweis behauptet werden.

Hier https://social.technet.microsoft.com/Forums/forefront/en-US/074181bc-1e1f-4b06-b816-6d9e1dac3da4/wudo-clarification-can-it-tunnel-out-through-the-fireall-protecting-my-network?forum=win10itprosecurity und hier http://www.wintotal.de/windows-10-p2p-update-verteilung-deaktivieren/ behauptet jemand, das für TCP und UDP vom Übertragungsoptimierungs-Dienst zwei unterschiedliche Ports benutzt werden. Einmal 7680 bei TCP und 3544 UDP. Dem ist aber nicht so.

Schauen wir uns zunächst die Regel in der Firewall an, ob es da was passendes gibt:

Get-NetFirewallServiceFilter -Service dosvc|Get-NetFirewallRule

Name                  : DeliveryOptimization-TCP-In
DisplayName           : Übermittlungsoptimierung (TCP eingehend)
Description           : Eingehende Regel, die der Übermittlungsoptimierung die Verbindung mit Remoteendpunkten erlaubt.
DisplayGroup          : Übermittlungsoptimierung
Group                 : @%systemroot%\system32\dosvc.dll,-100
Enabled               : True
Profile               : Any
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Allow
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 :
PrimaryStatus         : OK
Status                : Die Regel wurde erfolgreich vom Speicher aus analysiert. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

Name                  : DeliveryOptimization-UDP-In
DisplayName           : Übermittlungsoptimierung (UDP eingehend)
Description           : Eingehende Regel, die der Übermittlungsoptimierung die Verbindung mit Remoteendpunkten erlaubt.
DisplayGroup          : Übermittlungsoptimierung
Group                 : @%systemroot%\system32\dosvc.dll,-100
Enabled               : True
Profile               : Any
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Allow
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 :
PrimaryStatus         : OK
Status                : Die Regel wurde erfolgreich vom Speicher aus analysiert. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

Also es gibt eine Regel für TCP und UDP und welche Ports werden nun benutzt?

Get-NetFirewallServiceFilter -Service dosvc|Get-NetFirewallRule|Get-NetFirewallPortFilter

Protocol      : TCP
LocalPort     : 7680
RemotePort    : Any
IcmpType      : Any
DynamicTarget : Any

Protocol      : UDP
LocalPort     : 7680
RemotePort    : Any
IcmpType      : Any
DynamicTarget : Any

Ergo, nix UDP auf 3544. Übrigens Port 3544 wäre Teredo, wahrscheinlich hat da jemand nicht genau genug geschaut und die Leute übernehmen immer alles ohne es zu prüfen. http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3544