Konzept für die Windows Freigabe

bereits vor einiger Zeit, habe ich einen Artikel zu Freigabe- und NTFS-Berechtigung unter Windows veröffentlicht. Mit diesem Artikel möchte ich ein Konzept vorstellen, dass ich gerne nutze um komplexe Aufgaben in den Windows Freigaben abzubilden. Es ist wahrscheinlich nicht für alle leichte Kost und erfordert ein wenig Konzentration und die Bereitschaft es umsetzten zu wollen. Die Arbeit steckt hier im Detail und in der Vorbereitung.

Weiterlesen …

Freigabe- und NTFS-Berechtigungen unter Windows

040413_1253_Freigabeund3.png

Das Verwalten von Benutzerrechten und Freigaben von Verzeichnissen und Dateien, gehört für einen Administrator zur täglichen Arbeit. Leider stolpert man allzu oft über Windows Freigaben, die unterschiedlichen Gruppen Vollzugriff gewährt. Dies stellt grundsätzlich kein Problem dar und wenn man damit richtig umgeht, ist ein sicheres Arbeiten möglich. Die richtige Kombination mit Freigaben und NTFS-Rechten ist hier der Schlüssel zum Erfolg. Leider schleichen sich genau in dieser Kombination sehr oft Fehler ein. Zum Schutz aller Administratoren muss ich hier erwähnen, dass dies meisten unbewusst und aus historischen Gründen geschieht.

Meine Grundregeln lauten:

  • Vollzugriff auf NTFS-Ebene bekommen nur die, die Wissen was sie tun (oder die es wissen sollten) – also nur die Administratoren
  • Rechte nur auf Gruppen nie Einzelpersonen
  • Nur Rechte gewähren die notwendig sind
  • Kein „Verweigern“

Weiterlesen …

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

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 nochmals auf die Suche begeben, um eine lauffähige Lösung zu finden, da die Variante 6 von meinem Blogeintrag auch nicht mehr funktionierte. Die einzige Variante war es bisher die Deinstallation von .NET 4 mit dem Cleanuptool was ich aber vermeiden wollte.

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 warum die Variante 6 in meinem alten Blogeintrag nicht mehr funktioniert.

Es lässt sich darüber Diskutieren, ob das nun ein Workaround 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 auf 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): dotNet4_Update-Error_800B010B.zip (423 Downloads)

[update 17.05.2012] .NET 4 Framework Fehler beim Update (KB2656351)

[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:

Offline Dateien verschieben

Mit der Funktion “Immer offline verfügbar” auf Datei- oder Ordnerebene besteht die Möglichkeit, dass mobile Nutzer die Daten mit Ihrem Gerät synchronisieren können. Zu diesem Zwecke werden die als offline Markierten Dateien oder Ordner auf den lokalen Speicher des Gerätes kopiert. Als Standardpfad wird hierfür der Ordner %windir%\CSC festgelegt. Wenn die zu synchronisierenden Daten immer größer werden schwindet nun aber auch die Systemfestplatte. Um dies zu verhindern, besteht die Möglichkeit den Offline Dateien einen anderen Speicherplatz zuzuweisen.

Bitte nachfolgende Schritte nur durchführen, wenn die letzte Synchronisierung bereits durchgelaufen ist, da bereits gespeicherte Daten gelöscht werden.

  1. Anlegen eines Ordners, auf dem die Offline Dateien gespeichert werden sollen z.B.
    D:\Offline_Speicher
  2. Übernahme des Besitzes des Standardpfads.
    Hierfür auf einer administrativen Konsole eingeben:
    takeown /r /f %windir%\CSC
    Die folgenden Meldungen mit “J” für Ja bestätigen
  3. Sofern bereits Dateien bzw. Ordner synchronisiert werden in das Synchronisierungscenter wechseln  und den Menüpunkt “Offline Dateien” –> “Offline Dateien deaktivieren” anwählen und das Gerät neu starten.
  4. Auf einer administrativen Konsole das alte Verzeichnis löschen und mit dem neuen Speicherort verlinken:
    rd /s %windir%\CSC
    mklink /j %windir%\CSC “D:\Offline_Speicher”
  5. Das Synchronisationscenter öffnen und die Offline-Synchronisation wieder aktivieren “Oflline Dateien” –> “Offline Dateien aktivieren”.
  6. Mit dem nächsten Neustart, werden die Dateien mit dem neuen Speicherort synchronisiert.