8
Wsus Server will nicht
Hallo zusammen,
langsam fang ich an zu verzweifeln an diesem WSUS
Folgendes ist passiert:
Auf einem SBS 2008 (virtualisiert unter Hyper V) wurde der WSUS Server deintallaliert, aber im Servermanager ist immer noch die Rolle WSUS Server zu sehen, die aber nix mehr macht, weil kein Client ein Update bekommt. Auch ein manuelles Suchen nach Updates führt sofort zu einer Fehlermeldung, Fehlercode: 8024401F Das passiert auf den Clients wie auf dem Server
Greift man über den Servermanager auf die Rolle WSUS zu, erhält man folgenden Fehler:
Ausnahmefehler im Snap-In des verwalteten Codes:
FX:{8b6499ed-0241-e032-6508-da4b1c879d7f}
Die Datei oder Assembly "Microsoft.UpdateServices.UI.SnapIn, Version=3.1.6001.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Stapelüberwachung: System.IO.FileNotFoundException
Ausnahmestapelüberwachung:
bei System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
bei System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
bei System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
bei System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
bei System.Activator.CreateInstance(String assemblyName, String typeName)
bei System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
bei Microsoft.ManagementConsole.Internal.SnapInClient.CreateSnapIn(String assemblyName, String typeName)
bei Microsoft.ManagementConsole.Internal.ClassLibraryServices.Microsoft.ManagementConsole.Internal.IClassLibraryServices.CreateSnapIn(String assemblyName, String typeName)
bei Microsoft.ManagementConsole.Executive.SnapInInitializationOperation.OnStart()
bei Microsoft.ManagementConsole.Executive.RunningOperationsTable.EnqueueOperation(Operation operation)
bei Microsoft.ManagementConsole.Executive.NamespaceExtensionComponentData.GetScopeNodeForExpand(IDataObject dataObject, IntPtr hScopeItem)
bei Microsoft.ManagementConsole.Executive.ComponentData.OnExpandSync(IDataObject dataObject, IntPtr hScopeItem)
bei Microsoft.ManagementConsole.Executive.ExpandSyncMmcNotification.OnNotify(IntPtr dataObject, IntPtr arg, IntPtr param)
bei Microsoft.ManagementConsole.Executive.MmcNotifyTarget.Notify(IntPtr dataObject, NotificationType eventType, IntPtr arg, IntPtr param)
und das kann man nur mit OK bestätigen.
Das Einzige was geht, ist, dass Online nach Updates gesucht wird, dann werden auch Updates angezeigt, die installiert werden können.
Wenn man dann nach Updates sucht, dann bekommt man regelmäßig den WSUS 3 als Update zur Installation angeboten, das schlägt aber irgendwann fehl.
Also habe ich mir gedacht, dass ich einfach einen weiteren Server aufsetze, der das mit dem WSUS übernimmt. Der Sevrver, der neu hinzugekommen ist, ist ein einfacher Member Server 2012 Standard, der virtualisiert im Netzwerk läuft und eine spezielle Software zur Verfügung stellt.
Die Rolle lässt sich auch installieren und fortan zieht der neue WSUS Server die Updates von Microsoft runter und stellt diese im Netzwerk zur Verfügung.
Damit die Clients auch was davon haben, wurde in der Registry des Clients der Server unter :
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://<Neuer Server>:8530"
"WUStatusServer"="http://<Neuer Server>:8530"
Eingetragen.
Gleichzeitig wurde die Gruppenrichtlinie aktiviert:
Automatische Updates wurden konfiguriert => aktviert
Internen Pfad für den MS Updatedienst angeben => aktiv und mit den Werten für den neuen Server bestückt.
Dann funktonierte das Updates auch wieder, allerdings mit dem Fehler, dass nicht einstellbar gewesen ist, dass beim Herunterfahren die Option: Updates installieren und herunterfahren angezeigt wurde.
Im WSUS Manager des neuen Server wurden auch drei Testmaschinen angezeigt, die mit dem von Hand angelegten Registry Key versorgt wurden.
Zunächst dachte ich ja, dass es eventuell an der GPO liegen könnte, die nicht übernommen wurde. gpupdate /force hat aber nix gebracht.
Als ich heute wieder an das Problem gegangen bin, konnte ich feststellen, dass bein den Clients wieder der alte Server als Pfad drin stand und deswegen weder Updates installiert werden können noch sonst irgendwas passiert, weil die Clients ja auf den falschen Server schauen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://<ALTER Server>:8530"
"WUStatusServer"="http://<ALTER Server>:8530"
Wenn ich diesen Eintrag aber ändere, wird mit Aufruf von gpupdate /force sofort wieder der <ALTE Server> in die Registry eingetragen, OBWOHL in der Richtlinie der <NEUE Server> drinn steht.
Wie kann das gehen? Wozu habe ich denn eine Richtlinie, wenn die nicht angewendet wird und woher kommt der Wert des alten Servers?
Offensichtlich hängt das mit der defekten WSUS Rolle zusammen. Gibt es denn keine Möglichkeit, diesen WSUS aus der Registry von Hand raus zu kratzen, deinstallieren lässt sich dieser WSUS ja nicht mehr.
Das schönste ist jetz, dass ich nicht einmal mehr auf dem SBS nach Updates suchen kann, denn seit ich mit dieser GPO Einstellung angefangen hat, sagt mir dort die Windos Update info, dass alles vom Admin verwaltet wird und es gibt keine Möglichkeit mehr, irgendwas zu ändern. Es werden auch keine Links mehr zum Online Installieren angezeigt oder was anderes. Ich kann also auf der Update Einstellung rein gar nichts mehr machen.
Bitte gebt mir mal einen Tip, ich dreh bald mit diesem Geraffel durch
Gruß Kellogs
langsam fang ich an zu verzweifeln an diesem WSUS
Folgendes ist passiert:
Auf einem SBS 2008 (virtualisiert unter Hyper V) wurde der WSUS Server deintallaliert, aber im Servermanager ist immer noch die Rolle WSUS Server zu sehen, die aber nix mehr macht, weil kein Client ein Update bekommt. Auch ein manuelles Suchen nach Updates führt sofort zu einer Fehlermeldung, Fehlercode: 8024401F Das passiert auf den Clients wie auf dem Server
Greift man über den Servermanager auf die Rolle WSUS zu, erhält man folgenden Fehler:
Ausnahmefehler im Snap-In des verwalteten Codes:
FX:{8b6499ed-0241-e032-6508-da4b1c879d7f}
Die Datei oder Assembly "Microsoft.UpdateServices.UI.SnapIn, Version=3.1.6001.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Stapelüberwachung: System.IO.FileNotFoundException
Ausnahmestapelüberwachung:
bei System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
bei System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
bei System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
bei System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
bei System.Activator.CreateInstance(String assemblyName, String typeName)
bei System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
bei Microsoft.ManagementConsole.Internal.SnapInClient.CreateSnapIn(String assemblyName, String typeName)
bei Microsoft.ManagementConsole.Internal.ClassLibraryServices.Microsoft.ManagementConsole.Internal.IClassLibraryServices.CreateSnapIn(String assemblyName, String typeName)
bei Microsoft.ManagementConsole.Executive.SnapInInitializationOperation.OnStart()
bei Microsoft.ManagementConsole.Executive.RunningOperationsTable.EnqueueOperation(Operation operation)
bei Microsoft.ManagementConsole.Executive.NamespaceExtensionComponentData.GetScopeNodeForExpand(IDataObject dataObject, IntPtr hScopeItem)
bei Microsoft.ManagementConsole.Executive.ComponentData.OnExpandSync(IDataObject dataObject, IntPtr hScopeItem)
bei Microsoft.ManagementConsole.Executive.ExpandSyncMmcNotification.OnNotify(IntPtr dataObject, IntPtr arg, IntPtr param)
bei Microsoft.ManagementConsole.Executive.MmcNotifyTarget.Notify(IntPtr dataObject, NotificationType eventType, IntPtr arg, IntPtr param)
und das kann man nur mit OK bestätigen.
Das Einzige was geht, ist, dass Online nach Updates gesucht wird, dann werden auch Updates angezeigt, die installiert werden können.
Wenn man dann nach Updates sucht, dann bekommt man regelmäßig den WSUS 3 als Update zur Installation angeboten, das schlägt aber irgendwann fehl.
Also habe ich mir gedacht, dass ich einfach einen weiteren Server aufsetze, der das mit dem WSUS übernimmt. Der Sevrver, der neu hinzugekommen ist, ist ein einfacher Member Server 2012 Standard, der virtualisiert im Netzwerk läuft und eine spezielle Software zur Verfügung stellt.
Die Rolle lässt sich auch installieren und fortan zieht der neue WSUS Server die Updates von Microsoft runter und stellt diese im Netzwerk zur Verfügung.
Damit die Clients auch was davon haben, wurde in der Registry des Clients der Server unter :
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://<Neuer Server>:8530"
"WUStatusServer"="http://<Neuer Server>:8530"
Eingetragen.
Gleichzeitig wurde die Gruppenrichtlinie aktiviert:
Automatische Updates wurden konfiguriert => aktviert
Internen Pfad für den MS Updatedienst angeben => aktiv und mit den Werten für den neuen Server bestückt.
Dann funktonierte das Updates auch wieder, allerdings mit dem Fehler, dass nicht einstellbar gewesen ist, dass beim Herunterfahren die Option: Updates installieren und herunterfahren angezeigt wurde.
Im WSUS Manager des neuen Server wurden auch drei Testmaschinen angezeigt, die mit dem von Hand angelegten Registry Key versorgt wurden.
Zunächst dachte ich ja, dass es eventuell an der GPO liegen könnte, die nicht übernommen wurde. gpupdate /force hat aber nix gebracht.
Als ich heute wieder an das Problem gegangen bin, konnte ich feststellen, dass bein den Clients wieder der alte Server als Pfad drin stand und deswegen weder Updates installiert werden können noch sonst irgendwas passiert, weil die Clients ja auf den falschen Server schauen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://<ALTER Server>:8530"
"WUStatusServer"="http://<ALTER Server>:8530"
Wenn ich diesen Eintrag aber ändere, wird mit Aufruf von gpupdate /force sofort wieder der <ALTE Server> in die Registry eingetragen, OBWOHL in der Richtlinie der <NEUE Server> drinn steht.
Wie kann das gehen? Wozu habe ich denn eine Richtlinie, wenn die nicht angewendet wird und woher kommt der Wert des alten Servers?
Offensichtlich hängt das mit der defekten WSUS Rolle zusammen. Gibt es denn keine Möglichkeit, diesen WSUS aus der Registry von Hand raus zu kratzen, deinstallieren lässt sich dieser WSUS ja nicht mehr.
Das schönste ist jetz, dass ich nicht einmal mehr auf dem SBS nach Updates suchen kann, denn seit ich mit dieser GPO Einstellung angefangen hat, sagt mir dort die Windos Update info, dass alles vom Admin verwaltet wird und es gibt keine Möglichkeit mehr, irgendwas zu ändern. Es werden auch keine Links mehr zum Online Installieren angezeigt oder was anderes. Ich kann also auf der Update Einstellung rein gar nichts mehr machen.
Bitte gebt mir mal einen Tip, ich dreh bald mit diesem Geraffel durch
Gruß Kellogs
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 237523
Url: https://administrator.de/contentid/237523
Printed on: April 19, 2024 at 23:04 o'clock
8 Comments
Latest comment
Hallo Kellogs,
als erstes würde ich auf dem alten Server "force remove wsus" durchführen, wie u.a. hier beschrieben:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/8bee5c27 ...
oder auch hier: http://windowshell.wordpress.com/2011/08/26/force-uninstall-of-windows- ...
Danach eine Reparaturinstallation des neuen WSUS Server und Bereitstellung per GPO, wobei wohl ein durchforsten der GPO nicht wegfällt um die alten Einträge zu finden (Default Domain Policy usw.)
als erstes würde ich auf dem alten Server "force remove wsus" durchführen, wie u.a. hier beschrieben:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/8bee5c27 ...
oder auch hier: http://windowshell.wordpress.com/2011/08/26/force-uninstall-of-windows- ...
Danach eine Reparaturinstallation des neuen WSUS Server und Bereitstellung per GPO, wobei wohl ein durchforsten der GPO nicht wegfällt um die alten Einträge zu finden (Default Domain Policy usw.)
1
OK, ich werde das mal versuchen. Hatte mir schon fast gedacht, das sich die GPO durchsuchen muss, wollte das aber nicht wahr haben 
Ich gebe Besched, wenn ich was herausgefunden habe.
Ich gebe Besched, wenn ich was herausgefunden habe.
Aufgrund dessen, dass ich mich gerade selber damit beschäftigt habe:
Grundsätzlich solltest Du davon absehen, irgendwelche Einstellungen auf einen SBS händisch zu ändern. Sinnvoll und praktikabel bei einen Windows Server, jedoch bei einen SBS zerschiesst du dort meistens die integierten Consolen, da diese die Daten mit Ihren eigenen Daten noch einmal gegen checken und bei einen Konflikt die Console aussteigt.
Ich habe gestern ebenfalls den WSUS auf einen SBS neu installieren müssen. Folgende Anleitung war hierfür äußert hilfreich:
http://technet.microsoft.com/en-us/library/gg680316.aspx (für SBS 2008 ebenfalls im Netz, jedoch identisch)
Sollten weitere Probleme auftreten, nach der beherzigung von ollioe und meinem Post, dann einfach noch einmal melden.
Grundsätzlich solltest Du davon absehen, irgendwelche Einstellungen auf einen SBS händisch zu ändern. Sinnvoll und praktikabel bei einen Windows Server, jedoch bei einen SBS zerschiesst du dort meistens die integierten Consolen, da diese die Daten mit Ihren eigenen Daten noch einmal gegen checken und bei einen Konflikt die Console aussteigt.
Ich habe gestern ebenfalls den WSUS auf einen SBS neu installieren müssen. Folgende Anleitung war hierfür äußert hilfreich:
http://technet.microsoft.com/en-us/library/gg680316.aspx (für SBS 2008 ebenfalls im Netz, jedoch identisch)
Sollten weitere Probleme auftreten, nach der beherzigung von ollioe und meinem Post, dann einfach noch einmal melden.
Zitat von @KellogsFR:
Als ich heute wieder an das Problem gegangen bin, konnte ich feststellen, dass bein den Clients wieder der alte Server als Pfad
drin stand und deswegen weder Updates installiert werden können noch sonst irgendwas passiert, weil die Clients ja auf den
falschen Server schauen:
Als ich heute wieder an das Problem gegangen bin, konnte ich feststellen, dass bein den Clients wieder der alte Server als Pfad
drin stand und deswegen weder Updates installiert werden können noch sonst irgendwas passiert, weil die Clients ja auf den
falschen Server schauen:
Was bei den Clients Wunder hilft, ist insofern mit deiner Struktur machbar, das raus schmeißen der Clients aus der Domäne und ein erneutes rein heben, mittels des Assistenten unter http://connect
Hi Deltablue,
danke für den Tip, ich habe bereits versucht, den SBS mit einer etwas älteren Version dieser Beschreibung neu zu installieren, hat aber auch nicht geklppt.
http://technet.microsoft.com/en-us/library/dd443475%28v=ws.10%29.aspx
Ich habe soeben auch versucht, dass ich die SBS Console starte, das funktioniert aber nur im erweiteren Modus. die normal Konsole startet gar nicht mehr. Es scheint also so zu sein, als ob der WSUS noch irgendwo im System ist, sich aber nicht mehr ansprechen lässt.
In der erweiterten Konsole, auf dem Reiter Updatges kann ich keine Einstellungen vornehmen, alles schlägt fehl.
Du hast wahrscheinlich recht, dass die internen Consolen hinüber sind. Ich werde jetzt nochmyl versuchen, dass ich das mit den Anweisungen von ollioe versuche und melde mich dann wieder.
Bis später
danke für den Tip, ich habe bereits versucht, den SBS mit einer etwas älteren Version dieser Beschreibung neu zu installieren, hat aber auch nicht geklppt.
http://technet.microsoft.com/en-us/library/dd443475%28v=ws.10%29.aspx
Ich habe soeben auch versucht, dass ich die SBS Console starte, das funktioniert aber nur im erweiteren Modus. die normal Konsole startet gar nicht mehr. Es scheint also so zu sein, als ob der WSUS noch irgendwo im System ist, sich aber nicht mehr ansprechen lässt.
In der erweiterten Konsole, auf dem Reiter Updatges kann ich keine Einstellungen vornehmen, alles schlägt fehl.
Du hast wahrscheinlich recht, dass die internen Consolen hinüber sind. Ich werde jetzt nochmyl versuchen, dass ich das mit den Anweisungen von ollioe versuche und melde mich dann wieder.
Bis später
Teilerfolg:
Wie oben beschrieben konnte ich ja in der Systemsteuerung bei Windows Update keine Einstellungen mehr vornehmen, weil die Anzeige mitteilte, dass alles vom Admin verwaltet wird.
Das lag daran, dass ich die Richtlinie Zugriff auf alle Windows Update Funktionen entfernen in Benutzerkonfi - ADM Vorlagen - Win Kompnenten - Win Update aktiveirt habe.
Nachdem ich die wieder deaktiverit hatte, wurden mir in der Konsole wieder die Updates angeboten, ich kann jetzt auch wieder danach suchen lassen, bekomme aber den Fehler: 80071EFD
Immerhin, ein neuer Fehler
Wie oben beschrieben konnte ich ja in der Systemsteuerung bei Windows Update keine Einstellungen mehr vornehmen, weil die Anzeige mitteilte, dass alles vom Admin verwaltet wird.
Das lag daran, dass ich die Richtlinie Zugriff auf alle Windows Update Funktionen entfernen in Benutzerkonfi - ADM Vorlagen - Win Kompnenten - Win Update aktiveirt habe.
Nachdem ich die wieder deaktiverit hatte, wurden mir in der Konsole wieder die Updates angeboten, ich kann jetzt auch wieder danach suchen lassen, bekomme aber den Fehler: 80071EFD
Immerhin, ein neuer Fehler
OK, der Fehler verschwindet, wenn ich den richtigen Server in die Registry eintrage.
Ein GPupdate trägt aber sofort wieder den flaschne Server ein und schon gehts schief.
Was mich wundert ist, dass ich einen Neustart machen kann, ohne dass der falsche (der alte) Server in die Registry eingetragen wird. Eigentlich sollte doch die Gruppenrichtlinie beim Neustart / Anmeldung übernommen werden.
Ein GPupdate trägt aber sofort wieder den flaschne Server ein und schon gehts schief.
Was mich wundert ist, dass ich einen Neustart machen kann, ohne dass der falsche (der alte) Server in die Registry eingetragen wird. Eigentlich sollte doch die Gruppenrichtlinie beim Neustart / Anmeldung übernommen werden.
Hallo zusammen,
also, ich hab noch so einiges probiert und kann folgendes sagen:
Es funktioniert jetzt. Mein Fehler war wohl, dass ich die Gruppenrichtlinien geändert habe, nachdem ich diese wieder zurückgestellt hatte, war alles in Ordnung. Da jetzt ein neuer WSUS Server im Netzwerk verfügbar ist, wurden in die Registry folgende Werte eingetragen:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://<WSUSSERVER>:8530"
"WUStatusServer"="http://<WSUSSERVER>:8530"
"ElevateNonAdmins"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduleWaitTime"=dword:00000001
"RebootWarningTimeoutEnabled"=dword:00000001
"RebootWarningTimeout"=dword:00000005
"RebootRelaunchTimeoutEnabled"=dword:00000001
"RebootRelaunchTimeout"=dword:0000000a
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000001
"AutoInstallMinorUpdates"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000000
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000d
Nachdem ich das gemacht hatte, werden auch die Updates wieder sauber verteilt und alles funktioniert reibungslos.
Zu den Werten der Registry ist noch zu sagen, dass man sich diese googeln kann und eine ganze Menge dort einstellen kann, was die Verteilung betrifft. Es gibt noch eine Menge mehr Werte, hier lohnt eine kurze Suche, für mich waren diese Werte ausreichend. In jedem Falles gegenchecken, nicht einfach übernehmen.
Fazit ist, dass ich im Grunde relativ einfach einen WSUS Server hätte ersetzten können, wenn ich gleich von Anfang an die Werte in die Registry eingetrgen hätte. Allerdings muss man den ursrpünglichen WSUS Server halt auch deinstallieren, um ihn zu ersetzten. Ich glaube, dass es beim SBS da einige Probleme geben kann, weil ja einiges per Script eingestllt wird, was bei einem normalen Server einfacher zu sein scheint.
Hoffe, das hilft irgendwann einmal jemandem weiter.
also, ich hab noch so einiges probiert und kann folgendes sagen:
Es funktioniert jetzt. Mein Fehler war wohl, dass ich die Gruppenrichtlinien geändert habe, nachdem ich diese wieder zurückgestellt hatte, war alles in Ordnung. Da jetzt ein neuer WSUS Server im Netzwerk verfügbar ist, wurden in die Registry folgende Werte eingetragen:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://<WSUSSERVER>:8530"
"WUStatusServer"="http://<WSUSSERVER>:8530"
"ElevateNonAdmins"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduleWaitTime"=dword:00000001
"RebootWarningTimeoutEnabled"=dword:00000001
"RebootWarningTimeout"=dword:00000005
"RebootRelaunchTimeoutEnabled"=dword:00000001
"RebootRelaunchTimeout"=dword:0000000a
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000001
"AutoInstallMinorUpdates"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000000
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000d
Nachdem ich das gemacht hatte, werden auch die Updates wieder sauber verteilt und alles funktioniert reibungslos.
Zu den Werten der Registry ist noch zu sagen, dass man sich diese googeln kann und eine ganze Menge dort einstellen kann, was die Verteilung betrifft. Es gibt noch eine Menge mehr Werte, hier lohnt eine kurze Suche, für mich waren diese Werte ausreichend. In jedem Falles gegenchecken, nicht einfach übernehmen.
Fazit ist, dass ich im Grunde relativ einfach einen WSUS Server hätte ersetzten können, wenn ich gleich von Anfang an die Werte in die Registry eingetrgen hätte. Allerdings muss man den ursrpünglichen WSUS Server halt auch deinstallieren, um ihn zu ersetzten. Ich glaube, dass es beim SBS da einige Probleme geben kann, weil ja einiges per Script eingestllt wird, was bei einem normalen Server einfacher zu sein scheint.
Hoffe, das hilft irgendwann einmal jemandem weiter.
