Vista Business an Server 2008 DC

[reinerk 10]

Guten Abend Gemeinde,

habe mir eine (kleine) Testumgebung aufgebaut :

Vista Business + Server 2008 Standard ( beide 64 Bit )

Nachdem beide Systeme wirklich top "laufen" habe ich den Vista Client an der Domäne angemeldet...bis dahin alles in Ordnung.

Ab der 2. Anmeldung des Clients ging's dann los : fast 10 min. Wartezeit bis ich angemeldet war, danach nur schleppende Reaktionen am Client.

Folgendes ist mir aufgefallen :

 

Auf dem Server 2008 ist der WSUS installiert.

Bei dessen Erstsynchronisation ging's schon mit den ersten Fehlern los, dass "einige Updates nicht heruntergeladen werden können". Das Problem ist bekannt und sollte auch schnell behoben sein...dachte ich.

Bin dann darauf gestossen, dass in der Registry folgender Schlüssel angelegt wird :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\Safer mit dem Wert 1

Setzt man diesen Wert auf 0 und wiederholt den nicht durchgeführten Download in der WSUS Konsole, dann klappt das.

( Löschen des kompletten Unteschlüssels ..."Safer" bringt den gleichen Erfolg)

Nun werden bei der Erstsynchronisation ja einige Mengen an Updates runtergeladen, so dass sich dieses Spiel auch wiederholt.

 

Warum ich das hier erwähne ? Ganz einfach:

 

Nach der Erstanmeldung des Vista-Clients am 2008 DC ist alles noch normal.

Nun hat er aber die WSUS-GPO übernommen und bei der 2. Anmeldung kommt der von mir beschriebene Fehler zu Stande....fast 10 min. warten etc.

 

In der Registry des Clients steht der gleiche Schlüssel :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\Safer mit dem Wert 257.

Unterschlüssel löschen, oder Wert auf 0 setzen und das Problem ist weg, der Client ist superfix an der Domäne angemeldet.

 

Ich gehe also davon aus, dass es am WSUS liegen muss, der diesen Reg-Eintrag immer wieder neu erstellt ( mit den Standardwerten ).

 

Kennt Ihr diesen Fehler oder hat jemand das gleiche Problem ?

 

Sorry, bevor ich's vergesse :

In beiden Systemlogs, sowohl Server, als auch Client tauchen keinerlei

Fehlerereignisse auf.

[Sunny61 773]

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\Safer

 

Nein, der WSUS macht nichts an der Stelle. Auch die WSUS-GPO schreibt nicht an der Stelle in der Registry. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Update > und darunter sind die Einträge von der WSUS-GPO zu finden.

[olc 18]

Hi,

 

Nein, der WSUS macht nichts an der Stelle. Auch die WSUS-GPO schreibt nicht an der Stelle in der Registry. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Update > und darunter sind die Einträge von der WSUS-GPO zu finden.

 

Doch, indirekt ist der Schlüssel wichtig für den WSUS, nur fehlt unterhalb des "Safer" in der Auflistung oben wahrscheinlich der eigentliche Schlüssel, nämlich "AuthenticodeFlags". Neben anderen Diensten nutzt der WSUS Dienst diesen Key soweit ich weiß, um die Code Signaturen der Pakete gegenzuprüfen. Ist hier ein falscher Wert gesetzt, kann es vielleicht zu den Problemen kommen.

 

Ich würde einmal mittels RSOP prüfen, ob unter Umständen der Wert über eine Gruppenrichtlinie oder ein Logonscript geändert wird - das würde erklären, warum der Fehler erst nach dem 2. Anmelden auftritt.

 

Certificate Revocation and Status Checking

 

Viele Grüße

olc

[reinerk 10]

Ja Danke für's schnelle Antworten.

Habe folgendes ausprobiert :

1. Sämtliche GPO's deaktiviert

- Kein Wert gesetzt und alle Unterschlüssel bis auf "Safer" waren weg

2. WSUS GPO aktiviert

- Alle Unterschlüssel wieder vorhanden aber alle "ohne Wert"

( also wie bei einer jungfräulichen Default Domain Policy, bis auf die WSUS

Einstellungen )

3. Default Domain Policy aktiviert

- Unterschlüssel "Safer" wieder mit Wert "1"

 

Das ganze hängt damit zusammen, dass ich in der GPO in den

"Richtlinien für öffentliche Schlüssel" und den

"Einstellungen für die Überprüfung des Zertifikatpfades"

Optionen aktiviert hatte.

Da dieser Reg-Schlüssel jetzt "ohne Wert" ist, werde ich das Ganze mal 2 Tage beobachten und mich dann noch mal fix melden, ob sich was getan hat.

[reinerk 10]

...Doch, indirekt ist der Schlüssel wichtig für den WSUS

 

Da gebe ich Dir Recht,

als der Vista Client noch Solo war und nicht in der Domäne,

schlugen auf Grund dieser von mir getätigten Einträge in der lokalen Gruppenrichtlinie bezüglich der Zertifikate, die Automatischen Updates

auch über "Microsoft Update" fehl

[Sunny61 773]

2. WSUS GPO aktiviert

- Alle Unterschlüssel wieder vorhanden aber alle "ohne Wert"

( also wie bei einer jungfräulichen Default Domain Policy, bis auf die WSUS

Einstellungen )

3. Default Domain Policy aktiviert

- Unterschlüssel "Safer" wieder mit Wert "1"

 

Mich interessiert es einfach. Zeig mir doch mal die WSUS-GPO, in der ist das doch bestimmt nicht drin. Wenn nein, von welcher Einstellung kommt das dann?

[reinerk 10]

Mich interessiert es einfach. Zeig mir doch mal die WSUS-GPO, in der ist das doch bestimmt nicht drin. Wenn nein, von welcher Einstellung kommt das dann?

 

also die WSUS GPO ist neu erstellt aus der Default Domain Policy

( Du weisst wie das geht )

und nur in der Computerrichtlinie : "Administrative Vorlagen-Windows Komponenten-

WindowsUpdate"

entsprechende Einstellungen angepasst...der WSUS läuft ja auch fehlerfrei.

Ich hatte in der Richtlinie : "Computer-Sicherheitseinstellungen-

Richtlinien für Öffentliche Schlüssel-Einstellungen

für die Überprüfung des Zertifikatpfades"

 

die entsprechenden Standardeinstellungen aktiviert, und der von mir oben beschriebene Registryschlüssel bekam einen Wert zugewiesen, der sowohl

die Updates über den WSUS als auch die direkten Online Microsoft Updates

verhinderte und dann auch dafür sorgte, dass bei der 2. Anmeldung des Vista

Clients, das Login unerträglich lange dauerte.

Da dieser Unterschlüssel in der Registry zu den Trusted Publishers gehört, wundert es mich schon, dass kein Zugriff auf die Updateseite von MS möglich ist.