.NET 4 Framework Fehler beim Update (Code 800B010B)

0

Hintergrund

Ein bzw. mehrere Sicherheitsupdates vom .NET4 lassen sich nicht installieren und werden mit dem einem Fehler: Code 800B010B abgelehnt.

Screenshot des Fehlers Code 800B010B

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:

Download:

Reg-Key (ausführbar): .NET4 Update Error - Code 800B010B (22)

VMware: Hinweis zu Konfigurationsprobleme bei gestartetem SSH auf dem Host

0

Hintergrund

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.

Screenshot der Meldung

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?

0

Unter ä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

0

Hintergrund:

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)

0

Hintergrund

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.

HC-2012_0009

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.

  1. Windows Update Dienst entweder über die GUI oder in einer administrativen Konsole über
    net stop wuauserv” stoppen
  2. den Ordner “%windir%\SoftwareDistribution” löschen (ggf. umbenennen)
  3. Windows Update Dienst starten
    net start wuauserv
  4. Windows Update ausführen

Exploit: JS/Blacole.BW Meldung auf der google Website

0

Hintergrund

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.

MS_Forefront_Exploit_FalsePositiv

Weiterführende Links/Quellen:

 

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

0

Es 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
    HC-2012_0005
  • In dem folgenden Setupfenster Product-Key ändern auswählen
    HC-2012_0006

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:

Vorfälle unter FP2010 für Exchange Server freigeben

0

Hintergrund

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

  1. Erstellen Sie in Microsoft Outlook eine neue E-Mail-Nachricht.
  2. Geben Sie die entsprechende Adresse ein.
  3. 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

Screenshot FP2010 for Exhange - Antispam

Screenshot aus dem Forefront Protection 2010 for Exchange zur Inhaltsfilterung

 

!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.

WindowsUpdate_Error_800B010B

Hinweise:

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.

PUF_NETFramework_ClientProfile_repair

Leider funktionierte dieser kleine Workaround nicht und wurde mit einem “Allgemeiner Vertrauensfehler” abgewiesen.

PUF_NETFramework_ClientProfile_repair_Error

Ein Blick in die Protokolldatei ergab auch keine neuen aufschlussreichen Erkenntnisse, bis auf den bereits angezeigten “Allgemeinen Vertrauensfehler”.

PUF_NETFramework_ClientProfile_repair_Error_detail

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

Ergebnis: Problem nicht gelöst – Problem tritt weiterhin auf

Variante 3

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

Ergebnis: Läuft

 

Weiterführende Links/Quellen:

Aktualisierung von Gruppenrichtlinien

0

Sofern 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.

 

nach oben