.NET 4 Framework Fehler beim Update (Code 800B010B)
0Hintergrund
Ein bzw. mehrere Sicherheitsupdates vom .NET4 lassen sich nicht installieren und werden mit dem einem Fehler: Code 800B010B abgelehnt.
Nachdem dieses Problem bereits vor einigen Wochen schonmal aufgetreten ist (hier der entsprechende Blogeintrag), habe ich mich nochmal auf die Suche begeben um eine lauffähige Lösung zu erhalten, da die Variante 6 auf meinem Blogeintrag auch nicht mehr funktionierte und ich eine komplette Deinstallation von .NET 4 mit dem Cleanuptool vermeiden möchte (Variante 5 – übrigends diese funktioniert immer noch).
Nach einer kurzen Suche bin ich über folgenden Threat im Technet gestoßen, der das gleiche Problem aufgreift.
Lösung
Die Lösung selbst steht in dem verlinkten Artikel im Technet. Letztendlich hilft hier einen Registrierungsschlüssel zu verändern. Dies erklärt auch letztendlich warum die Variante 6 in meinem alten Blogeintrag nicht mehr funktioniert.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing] “State”=dword:00022849
Letztendlich lässt sich darüber Diskutieren, ob das nun ein Workaroung oder die Lösung ist. Fakt ist, dass das Hautpproblem die Signierung der Pakete ist und die Sperrliste nicht überprüft werden kann, obwohl diese online erreichbar sind/waren. Wenn die Überprüfung fehl schlägt wird die Signierung als ungültig erklärt.
Die Entwickler der Updates haben die Möglichkeit die Online-Verifizierung Ihrer Pakete auszuschalten. Dies kann auch manuell über das “signtool verify /pa” geschehen. Aber ich persönlich habe keine Lust dies bei jedem .NET4 Framework Paket das nicht funktioniert zu tun und erst recht nicht auch unzähligen Maschinen. Zwischenzeitlich verteile ich den Registrierungsschlüssel per Gruppenrichtlinie auch wenn dies ein erhöhtes Sicherheitsrisiko darstellt.
Weiterführende Links/Quellen:
- Threat im Technet zu diesem Thema
http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/e29bab28-4b44-48eb-b56c-23a025499ec1 - Der Blogeintrag zum gleichen Thema
http://blog.alekel.de/?p=573
Download:
Reg-Key (ausführbar): .NET4 Update Error - Code 800B010B (22)
VMware: Hinweis zu Konfigurationsprobleme bei gestartetem SSH auf dem Host
0Hintergrund
Sobald man unter vSpehre 4.1 oder 5.+ auf dem Host den SSH Service startet erhält man im vSphere Client einen Hinweis, dass der SSH für den Host aktiviert wurde.
Grundsätzlich ist diese Meldung sinnvoll, sofern man die Sicherheit betrachtet. Einen offenen SSH Dienst auf einem Server stellt ein Risiko dar.
Fehlermeldung
Die Fehlermeldung lautet wie folgt
deutsch:
Konfigurationsprobleme
SSH für den Host wurde aktiviert
englisch:
Configuration Issues
SSH for the host has been enabled
Lösung
Es gibt mehrere Lösungen, je nachdem was man tatsächlich erreichen möchten.
SSH Dienst auf dem Host deaktivieren
Wenn man den SSH Dienst nicht benötigt, sollte man diesen wieder auf dem Host deaktivieren.
Anzeige der Meldung ausschalten
Wenn man über den SSH Dienst auf dem Server arbeiten möchte, besteht auch die Möglichkeit die Anzeige der Meldung auszuschalten. Hierfür kann man über die Konfiguration > Software > Erweiterte Einstellung > UserVars > UserVars.SuppressShellWarning > 1 die Meldung ausschalten.
VMware: RDM oder VMFS?
0Unter älteren VMware Versionen wurde aus Performancegründen für Server mit hoher I/O-Last immer empfohlen mit dem Raw Device Mapping (RDM) zu arbeiten. Dies hat sich zwischenzeitlich relativiert. Hierüber habe ich einige Seiten im Internet gefunden, die sich mit dieser Problematik auseinander setzen
Fehler: SQL-Netzwerkschnittstelle, error: 26
0Hintergrund:
In letzter Zeit begegnen mir immer häufiger eine Fehlermeldung, die im Zusammenhang mit der Anmeldung an einer MS-SQL Datenbankinstanz durch eine Applikation auftritt. Die Applikation lief bis dahin ordnungsgemäß. Es wurden keine Änderungen an der Instanz bzw. Kennwort vorgenommen. Die Verbindung mit dem Managementstudio läuft auch ohne Probleme.
Fehlermeldung:
deutsch:
SQL-Netzwerkschnittstelle, error: 26 – Fehler beim Bestimmen des
angegebenen Servers\oder angegebener Instanz
englisch:
SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified
Lösung:
Den Grund habe ich leider noch nicht ermitteln können. Durch Neustart des Dienstes “SQL Server Browser” auf dem Server, auf dem die Instanz liegt, löst das Problem.
Client erhält keine Windows Updates (Ereignis-ID: 454)
0Hintergrund
Ein Client erhält keine Windows Updates mehr. Das Ereignisprotokoll enthält diesbezüglich Fehler
Fehlermeldung:
wuaueng.dll (1016) SUS20ClientDataStore: Bei Datenbankwiederherstellung trat ein unerwarteter Fehler -1011 auf.
Lösung
Der Fehler deutet darauf hin, dass die Datenbank korrupt ist. auf www.eventid.net bin ich auf einen Hinweis gestoßen, der letztendlich das Problem löst.
- Windows Update Dienst entweder über die GUI oder in einer administrativen Konsole über
“net stop wuauserv” stoppen - den Ordner “%windir%\SoftwareDistribution” löschen (ggf. umbenennen)
- Windows Update Dienst starten
”net start wuauserv” - Windows Update ausführen
Exploit: JS/Blacole.BW Meldung auf der google Website
0Hintergrund
Seit dem gestrigen Update, oder vielleicht auch das Update der google Website erscheint eine Meldung am TMG, Microsoft Forefront Endpoint Protection sowie MS Security Essentials. Die unterschiedlichen Foren sind zwischenzeitlich voll mit dieser Meldung. So wie es aussieht ist es eine False Positive Meldung, was bedeutet, dass es eine Falschmeldung darstellt. Seitens der Scanner wird ein Skript, welches auf der google Website gestartet wird, als diesen Exploit erkannt.
Weiterführende Links/Quellen:
- Nachfolgender Threat aus dem offiziellen MS Forum:
http://social.technet.microsoft.com/Forums/en-US/Forefrontedgegeneral/thread/e8eb8300-ecdd-4b23-b6df-f6ac0a67a226
Ich werde die einzelnen Lösungswege später nachreichen.
[Update, 18:38]
Zwischenzeitlich existiert das Problem nicht mehr und werde mich auch nicht mehr damit auseinander setzen. Da ich bisher kein neues Definitionsupdate erhalten habe, glaube ich dass google das Script, welches für den Valentinstag gedacht war, wieder entfernt hat.
Office 2010 Product Key ändern
0Es kommt hin und wieder vor, dass der Produkt Schlüssel einer Office Installation geändert werden soll. Sofern man dies nicht ohnehin nicht mit dem Key Management Service bewerkstelligt, kann man dies wie nachfolgend erläutert umsetzen.
- öffnen der Programme und Funktionen in der Systemsteuerung
- Anwahl des Office-Produktes und mit Ändern das Setup aufrufen

- In dem folgenden Setupfenster Product-Key ändern auswählen

In größeren Firmen empfehle ich den Einsatz eines Key Management Service (KMS), der zwischenzeitlich auch die Office Aktivierung vornehmen kann.
Weiterführende Links/Quellen:
- How-To: Key Management Service mit Windows Server 2008 R2 auf Server Talk
http://www.server-talk.eu/2010/03/17/how-to-key-management-service-kms-mit-windows-server-2008-r2-reloaded/
Vorfälle unter FP2010 für Exchange Server freigeben
0Hintergrund
Forefront Protection 2010 für Exchange Server protokolliert einen Vorfall. Dieser wurde aber falsch erkannt und soll zugestellt werden.
Lösung
Eine Lösung gibt es leider nicht – zumindest habe ich diese nicht gefunden. Man kann die protokollierten Vorälle auflisten und auch ggf. löschen. In der Liste selbst werden nur rudimentäre Informationen (Zeit, Grund, Absender, Empfänger, usw) dargestellt, nicht aber der Inhalt. Ich interpretiere dies so, dass die Mails selbst gelöscht werden und diese garnicht mehr zur Verfügung stehen. Als Lösung selbst muss also der Absender der Mail nochmals gebeten werden, seine Mail zuzustellen. Vorab muss zumindes eine der Varianten des nachfolgenden Workarounds umgesetzt werden.
Zusätzlich zum Workaround kann auch der Hersteller des Antispammoduls informiert werden. An dieser stelle darf ich die Windows Hilfe zu Forefront Protection zitieren:
… [Entnommen aus Konfiguration von Inhaltsfilterung]
Berichten von falsch positiven Werten und entgangenem Spam
Informationen zu falsch negativen und positiven Werten dienen dem Hersteller des Antispammoduls zur Verbesserung der Modulleistung.
Senden Sie die E-Mail als RFC 2822-Anlage, um falsch positive oder falsch negative Spam-E-Mails zu übermitteln. Senden Sie keine falsch klassifizierten Nachrichten mithilfe des Befehls Weiterleiten, da dadurch wichtige Headerinformationen verloren gehen und keine gültige Übermittlung stattfindet.
Senden Sie die ursprüngliche E-Mail zu Analysezwecken an folgende Adressen:
- Für falsch negative Werte: Forefront-spam@submit.cloudmark.com
- Für falsch positive Werte: Forefront-legit@submit.cloudmark.com
So fügen Sie eine E-Mail-Nachricht als RFC 2822-Anlage an
- Erstellen Sie in Microsoft Outlook eine neue E-Mail-Nachricht.
- Geben Sie die entsprechende Adresse ein.
- Klicken Sie auf die Schaltfläche Element anfügen, wählen Sie die falsch klassifizierten E-Mails aus, und klicken Sie dann auf OK.
Workaround
Anknüpfend an die Logik der Lösung, muss erreicht werden, dass der Absender nicht als “Vorfall” klassifiziert wird. Dies kann auf mehrere Arten realisieren oder beide Varianten kombinieren.
Variante 1
Der Absender bzw. die Domäne wird auf die sog. Whitelist gesetzt.
-> Richtlinienverwaltung -> Antispam -> Inhaltsfilter, “Listen mit zulässigem Inhalt konfigurieren…”
Variante 2
Alle als SPAM deklarierte Nachrichten werden nicht als Vorfall gewertet, sondern werden in die Quarantäne gestellt. Hierfür muss der SCL Wert auf “SCL 5 bis 9″ gesetzt werden.
-> Richtlinienverwaltung -> Antispam -> Inhaltsfilter -> SCL-Schwellenwerte und -Aktionen
!Vorsicht bei Variante 2, da vermutlich auch mehr Speicherplatz verbraucht wird. Ich empfehle entsprechen die Quarantäneoption für das automatische löschen zu konfigurieren (Überwachung -> Konfiguration -> Quarantäneopntion, “Elemente unter Quarantäne automatisch löschen” + Tageswert)
[update 17.05.2012] .NET 4 Framework Fehler beim Update (KB2656351)
2[17.05.2012]
Das Problem ist gelöst – siehe Blogeintrag (http://blog.alekel.de/?p=640)
[24.02.2012]
Das Problem ist immer noch nicht zufriedenstellend gelöst. Derzeit elegantester Weg ist die Variante 6.
Hintergrund
Das Sicherheitsupdate für Microsoft .NET Framework 4 für x64-basierte Systeme (KB2656351) kann nicht über das Windows Update durchgeführt werden. Als Fehlermeldung wird der Code 800B010B angezeigt, der als Unbekannter Fehler bei Windows Update ausgegeben wird.
Hinweise:
- Microsoft Security Bulletin zu diesem Update:
http://technet.microsoft.com/de-de/security/bulletin/ms11-100 - deutsche Kurzversion zum Update
http://support.microsoft.com/kb/2638420
Analyse
Dieser Fehler ist im Zusammenhang mit .NET Updates nicht neu und ist mir ab und an begegnet. Durch eine Reparatur der Installation konnte dieser Fehler wieder behoben werden. Hierfür muss man über “Programme und Funktionen” (Start > Systemsteuerung > Programme und Funktionen”) das Paket “Microsoft .NET Framework 4 Client Profil” auswählen und über die Auswahl “Deinstallieren/ändern” die Reparatur anstoßen.
Leider funktionierte dieser kleine Workaround nicht und wurde mit einem “Allgemeiner Vertrauensfehler” abgewiesen.
Ein Blick in die Protokolldatei ergab auch keine neuen aufschlussreichen Erkenntnisse, bis auf den bereits angezeigten “Allgemeinen Vertrauensfehler”.
Dem Hinweis das entsprechende MSU Paket zu löschen, bin ich nicht nachgekommen.
Lösungsansätze
Viele Artikel beschreiben einen Mögliche Lösung. Die in diesem Update – zumindest bei mir – nicht geholfen hat.
Variante 1
- Über Programme und Funktionen eine Reparatur anstoßen (siehe Analyse)
Ergebnis: Problem nicht gelöst – Problem tritt weiterhin auf
Variante 2
- Download des eigenständigen Installers
http://www.microsoft.com/downloads/de-de/details.aspx?displaylang=de&FamilyID=e5ad0459-cbcc-4b4f-97b6-fb17111cf544 - Starten des Pakets
- Reparieren der Installation auswählen

- Neustart des Computers
- Windows Updates Prüfen
Ergebnis: Problem nicht gelöst – Problem tritt weiterhin auf
Variante 3
- Securitypatch heruntergeladen und manuell installiert
http://www.microsoft.com/downloads/de-de/details.aspx?familyid=37a8fb34-e3ad-4605-980b-28361889ce72&displaylang=de
Ergebnis: Problem nicht gelöst – Problem tritt weiterhin auf
Variante 4
- die MSU Datei (Windows6.1-KB958488-v6001-x64.msu) wie im Logfile angegeben gelöscht
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\ - Neuinstallation über den eigenständigen Installer
- Neustart
Ergebnis: Problem nicht gelöst – Problem tritt weiterhin auf
Variante 5
- Deinstallation aller .NET4 Framework Komponenten – am Besten mit dem .NET Framework Cleanup Tool.
(Beim Cleanup Tool nur .NET 4 deinstallieren) - Neuinstallation – am Besten über Windows Update
Ergebnis: Läuft – auch wenn die Lösung unschön ist
Variante 6
danke für den Hinweis Jona
- Anmelden unter einem anderen Benutzer
- Windows Update starten
Ergebnis: Läuft nur bedingt (siehe Blogeintrag http://blog.alekel.de/?p=640)
Variante 7 (Update 17.05.2012)
siehe Blogeintrag http://blog.alekel.de/?p=640
- Registrierungsschlüssek ändern
verarbeitbare Datei unter: .NET4 Update Error - Code 800B010B (22)
Ergebnis: Läuft
Weiterführende Links/Quellen:
- Microsoft .NET Framework 4 Client Profile (eigenständiger Installer)
http://www.microsoft.com/downloads/de-de/details.aspx?displaylang=de&FamilyID=e5ad0459-cbcc-4b4f-97b6-fb17111cf544 - .NET Framework Cleanup Tool auf Aaron Stebners Weblog
http://blogs.msdn.com/b/astebner/archive/2008/08/28/8904493.aspx
Aktualisierung von Gruppenrichtlinien
0Sofern man die Aktualisierung der Gruppenrichtlinie nicht manuell (“gpupdate”) anstößt, wird diese regelmäßig bei Mitgliedern der Domäne aktualisiert.
Maximal alle 120 Minuten wird die Gruppenrichtlinie von den Mitgliedern verarbeitet (90 Minuten +/- 30 Minuten zufällige Verzögerung). Die Domänencontroller verarbeiten diese alle 5 Minuten.
Nachzulesen ist dies im englischen TechNet Magazine Tip.



