20
WSUS 3.0 auf einen neuen Server übertragen - anschließend SyncProbleme!
Hallo Admins,
der Server, auf dem unser WSUS vorher lief, ist leider veraltet und leistet nicht mehr genug Performance.
Nun habe ich einen neuen Server mit ausreichend Ressourcen und habe hier die IIS und WSUS Rolle hinzugefügt.
Den neuen Server habe ich als Replikat des alten Servers erstellt, also als Downstreamserver.
Nach dem Konfigurieren und einem erfolgreichem Verbindungstest will sich der neue WSUS natürlich mit dem alten Synchronisieren um die alten Daten/Regeln/Pakete usw. zu erhalten.
Dieser Prozess geht auch immer bis 99% gut, dann hängt er sich leider auf und ich muss den Serverknoten zurücksetzen.
Fehlermeldung ist folgende:
Auch nachdem die Dienste neu gestartet sind, tritt der Fehler immer wieder auf.
Aktuelle Serverversion ist die 3.2.7600.256, ist zwar nicht die neuste, aber laut diversen Foren muss die Version des alten WSUS mit dem neuen zur Synchronisierung übereinstimmen.
Kann mir jemand bei dem Problem helfen?
Kann der Fehler von der mangelhaften Performance des Upstreamservers produziert werden?
Welche Auswirkungen hätte es wenn ich den neuen nicht als Replikat konfiguriere sondern die Updates direkt von Microsoft beziehe?
Natürlich müsste ich die Regeln ja manuell neu erstellen, aber werden dann genauso alle wartenden Updates geladen wir vorher auf dem alten Server?
Danke!
der Server, auf dem unser WSUS vorher lief, ist leider veraltet und leistet nicht mehr genug Performance.
Nun habe ich einen neuen Server mit ausreichend Ressourcen und habe hier die IIS und WSUS Rolle hinzugefügt.
Den neuen Server habe ich als Replikat des alten Servers erstellt, also als Downstreamserver.
Nach dem Konfigurieren und einem erfolgreichem Verbindungstest will sich der neue WSUS natürlich mit dem alten Synchronisieren um die alten Daten/Regeln/Pakete usw. zu erhalten.
Dieser Prozess geht auch immer bis 99% gut, dann hängt er sich leider auf und ich muss den Serverknoten zurücksetzen.
Fehlermeldung ist folgende:
Die WSUS-Verwaltungskonsole konnte über die Remote-API keine Verbindung mit dem WSUS-Server herstellen.
Stellen Sie sicher, dass der Update Services-Dienst, IIS und SQL auf dem Server ausgeführt werden. Starten Sie IIS, SQL und den Update Services-Dienst erneut, wenn das Problem weiterhin besteht.
System.Net.WebException -- Timeout für Vorgang überschritten
Source
System.Web.Services
Stack Trace:
bei System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
bei System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
bei Microsoft.UpdateServices.Internal.DatabaseAccess.ApiRemotingCompressionProxy.GetWebResponse(WebRequest webRequest)
bei System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object parameters)
bei Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPSearchUpdates(String updateScopeXml, String preferredCulture, Int32 publicationState)
bei Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPSearchUpdates(String updateScopeXml, String preferredCulture, ExtendedPublicationState publicationState)
bei Microsoft.UpdateServices.Internal.BaseApi.Update.SearchUpdates(UpdateScope searchScope, ExtendedPublicationState publicationState, UpdateServer updateServer)
bei Microsoft.UpdateServices.UI.AdminApiAccess.UpdateManager.GetUpdates(ExtendedUpdateScope filter)
bei Microsoft.UpdateServices.UI.AdminApiAccess.WsusSynchronizationInfo.InitializeDerivedProperties()
bei Microsoft.UpdateServices.UI.AdminApiAccess.WsusSynchronizationInfo.get_NewUpdatesCount()
bei Microsoft.UpdateServices.UI.SnapIn.Pages.SyncResultsListPage.GetSyncInfoRow(WsusSynchronizationInfo syncInfo)
bei Microsoft.UpdateServices.UI.SnapIn.Pages.SyncResultsListPage.GetListRows()Auch nachdem die Dienste neu gestartet sind, tritt der Fehler immer wieder auf.
Aktuelle Serverversion ist die 3.2.7600.256, ist zwar nicht die neuste, aber laut diversen Foren muss die Version des alten WSUS mit dem neuen zur Synchronisierung übereinstimmen.
Kann mir jemand bei dem Problem helfen?
Kann der Fehler von der mangelhaften Performance des Upstreamservers produziert werden?
Welche Auswirkungen hätte es wenn ich den neuen nicht als Replikat konfiguriere sondern die Updates direkt von Microsoft beziehe?
Natürlich müsste ich die Regeln ja manuell neu erstellen, aber werden dann genauso alle wartenden Updates geladen wir vorher auf dem alten Server?
Danke!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 261248
Url: https://administrator.de/forum/wsus-3-0-auf-einen-neuen-server-uebertragen-anschliessend-syncprobleme-261248.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
20 Kommentare
Neuester Kommentar
Hallo.
Auch nachdem die Dienste neu gestartet sind, tritt der Fehler immer wieder auf.
Aktuelle Serverversion ist die 3.2.7600.256, ist zwar nicht die neuste, aber laut diversen Foren muss die Version des alten
WSUS mit dem neuen zur Synchronisierung übereinstimmen.
Ich würde beide beteiligten Server nach diesem Schema trotzdem erstmal auf den gleichen Versionsstand bringen, denn mit der Version 256 hängst Du gleich um 2 Versionen hinterher:
WSUS 3.0 (SP2): Build 3.2.7600.226
WSUS 3.0 (SP2) + KB2720211: Build 3.2.7600.251
WSUS 3.0 (SP2) + KB2734608: Build 3.2.7600.256
WSUS 3.0 (SP2) + KB2828185: Build 3.2.7600.262
WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274
Kann mir jemand bei dem Problem helfen?
Kann der Fehler von der mangelhaften Performance des Upstreamservers produziert werden?
Eventuell mangelnde Performance würde doch hier durch den Faktor Zeit ausgeglichen, wenn Du vergleichsweise alles bei Microsoft ziehst, dauert das je nach Internetgeschwindigkeit doch auch lange. Wenn der Upstreamserver die Updates bislang erfolgreich an Clients und Server herausgegeben hat, warum soll von ihm aus nicht auch ein neuer WSUS betankt werden können?
Welche Auswirkungen hätte es wenn ich den neuen nicht als Replikat konfiguriere sondern die Updates direkt von Microsoft
beziehe?
Mir ist nicht ganz klar, was Du mit "Replikat" meinst. Meint das nur, daß Du als Downloadquelle nicht Microsoft, sondern eben den alten WSUS angegeben hast?
Natürlich müsste ich die Regeln ja manuell neu erstellen, aber werden dann genauso alle wartenden Updates geladen wir
vorher auf dem alten Server?
vorher auf dem alten Server?
Du mußt nichts neu erstellen, das Regelwerk ist in der SUS-DB des alten Servers enthalten, und auch diese kann man umziehen. Sieh' Dir mal diesen Thread an:
WSUS Migration von Windows Server 2003 auf Windows Server 2008 R2
Daraus geht auch hervor, daß Du den ganzen WSUS_Content ganz simpel per Explorer über Netzwerk vom alten auf den neuen Server kopieren kannst, ohne vorerst ein Replikat des alten (Downloadquelle) Servers erstellen zu müssen, dann bist Du Dein Abbruchproblem bei 99% auch los.
Danke!
Grüße
von
departure69
1
Ich würde beide beteiligten Server nach diesem Schema trotzdem erstmal auf den gleichen Versionsstand bringen, denn mit der
Version 256 hängst Du gleich um 2 Versionen hinterher:
WSUS 3.0 (SP2): Build 3.2.7600.226
WSUS 3.0 (SP2) + KB2720211: Build 3.2.7600.251
WSUS 3.0 (SP2) + KB2734608: Build 3.2.7600.256
WSUS 3.0 (SP2) + KB2828185: Build 3.2.7600.262
WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274
Version 256 hängst Du gleich um 2 Versionen hinterher:
WSUS 3.0 (SP2): Build 3.2.7600.226
WSUS 3.0 (SP2) + KB2720211: Build 3.2.7600.251
WSUS 3.0 (SP2) + KB2734608: Build 3.2.7600.256
WSUS 3.0 (SP2) + KB2828185: Build 3.2.7600.262
WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274
Ok werde ich mal probieren. Der alte WSUS läuft so schlecht, zu verlieren habe ich nichts.
Eventuell mangelnde Performance würde doch hier durch den Faktor Zeit ausgeglichen, wenn Du vergleichsweise alles bei
Microsoft ziehst, dauert das je nach Internetgeschwindigkeit doch auch lange. Wenn der Upstreamserver die Updates bislang
erfolgreich an Clients und Server herausgegeben hat, warum soll von ihm aus nicht auch ein neuer WSUS betankt werden können?
Microsoft ziehst, dauert das je nach Internetgeschwindigkeit doch auch lange. Wenn der Upstreamserver die Updates bislang
erfolgreich an Clients und Server herausgegeben hat, warum soll von ihm aus nicht auch ein neuer WSUS betankt werden können?
Noch ein Problem... das Verteilen läuft dermaßen schleppend auf dem alten WSUS. Der alte WSUS hat ca. 5000 Updates welche noch genehmigt werden müssen.
Aber die Updates kann ich nicht genehmigen, da der Serverknoten beim Anzeigen der Updates abstürzt :D
Mir ist nicht ganz klar, was Du mit "Replikat" meinst. Meint das nur, daß Du als Downloadquelle nicht Microsoft,
sondern eben den alten WSUS angegeben hast?
sondern eben den alten WSUS angegeben hast?
http://www.prontosystems.org/_media/win/wsus_03.png?cache=
Du mußt nichts neu erstellen, das Regelwerk ist in der SUS-DB des alten Servers enthalten, und auch diese kann man umziehen.
Sieh' Dir mal diesen Thread an:
WSUS Migration von Windows Server 2003 auf Windows Server 2008 R2
Sieh' Dir mal diesen Thread an:
WSUS Migration von Windows Server 2003 auf Windows Server 2008 R2
Danke!
Gruß zurück
Hi,
wir haben das pragmatischer gelöst.
Da ja alle PCs schon aktuell sind, einfach den WSUS komplett neu hochgezogen, dann im AD den WSUS-Servername geändert und fertig.
Den alten einfach abschalten.
Der neue WSUS findet die Clients, oder besser sie ihn, synchronisieren und fertig.
Dann irgendwann einen neuen Client dranhängen, gucken was der an Updates braucht, diese freigeben, fertig.
Hat bisher so schon 2mal geklappt, da wurde nie was verschoben.
VG,
Deepsys
wir haben das pragmatischer gelöst.
Da ja alle PCs schon aktuell sind, einfach den WSUS komplett neu hochgezogen, dann im AD den WSUS-Servername geändert und fertig.
Den alten einfach abschalten.
Der neue WSUS findet die Clients, oder besser sie ihn, synchronisieren und fertig.
Dann irgendwann einen neuen Client dranhängen, gucken was der an Updates braucht, diese freigeben, fertig.
Hat bisher so schon 2mal geklappt, da wurde nie was verschoben.
VG,
Deepsys
Zitat von @CortaX:
> Eventuell mangelnde Performance würde doch hier durch den Faktor Zeit ausgeglichen, wenn Du vergleichsweise alles bei
> Microsoft ziehst, dauert das je nach Internetgeschwindigkeit doch auch lange. Wenn der Upstreamserver die Updates bislang
> erfolgreich an Clients und Server herausgegeben hat, warum soll von ihm aus nicht auch ein neuer WSUS betankt werden
können?
Noch ein Problem... das Verteilen läuft dermaßen schleppend auf dem alten WSUS. Der alte WSUS hat ca. 5000 Updates
welche noch genehmigt werden müssen.
Aber die Updates kann ich nicht genehmigen, da der Serverknoten beim Anzeigen der Updates abstürzt :D
> Eventuell mangelnde Performance würde doch hier durch den Faktor Zeit ausgeglichen, wenn Du vergleichsweise alles bei
> Microsoft ziehst, dauert das je nach Internetgeschwindigkeit doch auch lange. Wenn der Upstreamserver die Updates bislang
> erfolgreich an Clients und Server herausgegeben hat, warum soll von ihm aus nicht auch ein neuer WSUS betankt werden
können?
Noch ein Problem... das Verteilen läuft dermaßen schleppend auf dem alten WSUS. Der alte WSUS hat ca. 5000 Updates
welche noch genehmigt werden müssen.
Aber die Updates kann ich nicht genehmigen, da der Serverknoten beim Anzeigen der Updates abstürzt :D
Genehmige weniger, in kleineren Schritten (ist halt etwas mehr Aufwand, dauert etwas länger). Oder stürzt der Serverknoten auch schon ab, wenn Du z. B. nur mal 10 Updates genehmigst?
> Mir ist nicht ganz klar, was Du mit "Replikat" meinst. Meint das nur, daß Du als Downloadquelle nicht
Microsoft,
> sondern eben den alten WSUS angegeben hast?
http://www.prontosystems.org/_media/win/wsus_03.png?cache=
Alles klar, also so, wie ich es verstanden hab'.
> Du mußt nichts neu erstellen, das Regelwerk ist in der SUS-DB des alten Servers enthalten, und auch diese kann man
umziehen.
> Sieh' Dir mal diesen Thread an:
>
>
WSUS Migration von Windows Server 2003 auf Windows Server 2008 R2
Danke!
Gerne.
Gruß zurück
Grüße
von
departure69
wir haben das pragmatischer gelöst.
Da ja alle PCs schon aktuell sind, einfach den WSUS komplett neu hochgezogen, dann im AD den WSUS-Servername geändert und
fertig.
Den alten einfach abschalten.
Da ja alle PCs schon aktuell sind, einfach den WSUS komplett neu hochgezogen, dann im AD den WSUS-Servername geändert und
fertig.
Den alten einfach abschalten.
nur das unsere PCs nur mit den Updates aktuell sind, welche automatisch genehmigt werden.
Andere, sicherheitsrelevante und hochpriorisierte Updates, welche nicht automatisch genehmigt werden stehen noch aus und das sind ca. 5000.
Wenn ich den neuen einfach hochziehe und den alten abschalte, synchronisiert sich der WSUS dann bei Microsoft auf den selben Stand zurück den ich jetzt hier habe?
Genehmige weniger, in kleineren Schritten (ist halt etwas mehr Aufwand, dauert etwas länger). Oder stürzt der
Serverknoten auch schon ab, wenn Du z. B. nur mal 10 Updates genehmigst?
Serverknoten auch schon ab, wenn Du z. B. nur mal 10 Updates genehmigst?
er stürzt schon ab, bevor er mir überhaupt welche anzeigt. Ich wäre ja froh drum dir Auflistung einmal zu sehen um anzufangen die Updates in kleinen Schritten zu genehmigen. Aber er schafft es nichtmal die darzustellen
Nur zur Situation:
Der WSUS läuft aktuell auf einem SmallBusiness Server 2k11 (zusammen mit Exchange, welcher bekanntlich extrem Arbeitsspeicher frisst) und soll auf einen Windows Server 2008 R2
Hallo.
wir haben das pragmatischer gelöst.
Klingt nach einem sauberen Neuanfang, ja.
ABER:
Da ja alle PCs schon aktuell sind,
Das würde ich angesichts 5000 nicht genehmigter Updates vorerst mal bezweifeln.
einfach den WSUS komplett neu hochgezogen,
Hat er ja schon gemacht.
dann im AD den WSUS-Servername geändert und
fertig.
fertig.
Muß er dann ohnehin, keine Frage.
Den alten einfach abschalten.
Würde ich vorerst nicht tun. Wir wissen nicht, ob der TO in seiner WSUS-Struktur unterhalb von "Computer" nicht deutlich mehr und tiefer für seine Rechner strukturiert hat als nur den Standard, der nur aus "Alle Computer" und "Nicht zugewiesene Computer" besteht. Falls er mehr gemacht hat, dann hängen da auch noch Regeln dran, Gruppenmitgliedschaften, GPO-Berechtigungen undsoweiter. Falls ja, und er das nicht alles mühselig wieder einrichten will, sollte er seine SUS_DB auf jeden Fall mitumziehen. Und wenn er das macht, dann kann er auch den ganzen, auf dem alten WSUS bereits existierenden Content gleich mitnehmen, ohne bei Microsoft alles neu herunterladen zu müssen, das können schließlich viele Gigabite sein, und der Sync mit Microsoft ist bekanntermaßen, auch bei schneller Internetverbindung, nicht der allerschnellste.
Der neue WSUS findet die Clients, oder besser sie ihn, synchronisieren und fertig.
Dann irgendwann einen neuen Client dranhängen, gucken was der an Updates braucht, diese freigeben, fertig.
Wie gesagt, dann müßte der neue aber jeglichen Content bei Microsoft erstmal wieder herunterladen. warum nicht den alten Content gleich mitnehmen (simple Kopie oder Verschieben per Explorer über's Netzwerk).
Hat bisher so schon 2mal geklappt, da wurde nie was verschoben.
Geht, wie gesagt, nur dann schmerzfrei, wenn keine angepasste Struktur aus der SUS_DB mitgenommen werden muß, und der riesige Neu-Download bei Microsoft nicht gescheut wird.
Ansonsten kann man das aber tatsächlich so machen, wie Du es beschreibst.
VG,
Deepsys
Viele Grüße
von
departure69
Zitat von @CortaX:
> Genehmige weniger, in kleineren Schritten (ist halt etwas mehr Aufwand, dauert etwas länger). Oder stürzt der
> Serverknoten auch schon ab, wenn Du z. B. nur mal 10 Updates genehmigst?
er stürzt schon ab, bevor er mir überhaupt welche anzeigt. Ich wäre ja froh drum dir Auflistung einmal zu sehen um
anzufangen die Updates in kleinen Schritten zu genehmigen. Aber er schafft es nichtmal die darzustellen
> Genehmige weniger, in kleineren Schritten (ist halt etwas mehr Aufwand, dauert etwas länger). Oder stürzt der
> Serverknoten auch schon ab, wenn Du z. B. nur mal 10 Updates genehmigst?
er stürzt schon ab, bevor er mir überhaupt welche anzeigt. Ich wäre ja froh drum dir Auflistung einmal zu sehen um
anzufangen die Updates in kleinen Schritten zu genehmigen. Aber er schafft es nichtmal die darzustellen
Oweh, obwohl Microsoft das so vorsieht (WSUS auf SBS), würde ich schleunigst davon weg, ein dedizierter WSUS hat Vorteile. Der SBS ist elementar für Dein Netz und Deine Domäne. Wenn nun der WSUS auf dem SBS so dermaßen spinnt, würde ich den auch sobald als möglich herunternehmen. Und genau das willst Du ja auch.
Nur ein paar Zwischenfragen, kein direkter Zusammenhang mit WSUS::
Hast Du dem SBS 2011 genügend RAM gegeben (32 GB kann er maximal, und die würde ich ihm auch geben), schnelle und genügend große Platten sowie CPUs mit genügend Dampf? Deine Beschreibung klingt nämlich´so, als habe der SBS allgemein ein bißchen zu schwache Hardwareressourcen, was sich jetzt vorerst beim WUS gezeigt hat. Spätestens, wenn irgendwann auch Exchange mal rummuckt, würde ich mal in mehr oder bessere Hardware investieren.
Nur zur Situation:
Der WSUS läuft aktuell auf einem SmallBusiness Server 2k11 (zusammen mit Exchange, welcher bekanntlich extrem Arbeitsspeicher
frisst) und soll auf einen Windows Server 2008 R2
Sinnvoll. Habe ich auch so gemacht (WSUS von einem SBS 2008 runter und auf einen virt. W2K8R2 drauf). Ich hatte aber das Glück, daß ich ohne Fehlermeldung oder Absturz den alten als Quellserver verwenden konnte.
Falls Du keine Besonderheiten im WSUS strukturiert/konfiguriert hast (also die alte SUS_DB nicht brauchst), und Dir der neue Download von sämtlichem Content bei Microsoft nicht zu groß ist, nimm die Lösung von @Deepsys. Das einzige, was Du wieder einstellen mußt, sind dann noch die Produkte und Klassifizierungen.
Grüße
von
departure69
Zitat von @departure69:
Würde ich vorerst nicht tun. Wir wissen nicht, ob der TO in seiner WSUS-Struktur unterhalb von "Computer" nicht
deutlich mehr und tiefer für seine Rechner strukturiert hat als nur den Standard, der nur aus "Alle Computer" und
"Nicht zugewiesene Computer" besteht. Falls er mehr gemacht hat, dann hängen da auch noch Regeln dran,
Gruppenmitgliedschaften, GPO-Berechtigungen undsoweiter. Falls ja, und er das nicht alles mühselig wieder einrichten will,
sollte er seine SUS_DB auf jeden Fall mitumziehen. Und wenn er das macht, dann kann er auch den ganzen, auf dem alten WSUS bereits
existierenden Content gleich mitnehmen, ohne bei Microsoft alles neu herunterladen zu müssen, das können
schließlich viele Gigabite sein, und der Sync mit Microsoft ist bekanntermaßen, auch bei schneller Internetverbindung,
nicht der allerschnellste.
Würde ich vorerst nicht tun. Wir wissen nicht, ob der TO in seiner WSUS-Struktur unterhalb von "Computer" nicht
deutlich mehr und tiefer für seine Rechner strukturiert hat als nur den Standard, der nur aus "Alle Computer" und
"Nicht zugewiesene Computer" besteht. Falls er mehr gemacht hat, dann hängen da auch noch Regeln dran,
Gruppenmitgliedschaften, GPO-Berechtigungen undsoweiter. Falls ja, und er das nicht alles mühselig wieder einrichten will,
sollte er seine SUS_DB auf jeden Fall mitumziehen. Und wenn er das macht, dann kann er auch den ganzen, auf dem alten WSUS bereits
existierenden Content gleich mitnehmen, ohne bei Microsoft alles neu herunterladen zu müssen, das können
schließlich viele Gigabite sein, und der Sync mit Microsoft ist bekanntermaßen, auch bei schneller Internetverbindung,
nicht der allerschnellste.
Hast du da nicht was vertauscht?
In den GPOs stehen die Regeln zur WSUS-Mitgliedschaft, nicht auf dem WSUS.
Und ja, wir haben auch mehrere Gruppen, aber wie gesagt, steht in der GPO.
Und da sein WSUS wohl eh hinüber ist, und er wohl seit Monaten/Jahren nichts mehr aktualisiert hat, würde ich bei 0 anfangen.
Den neuen mit Microsoft synchronisieren und alle Updates freigeben.
Edit: .... alle Updates die deine System benötigen freigeben.
Oweh, obwohl Microsoft das so vorsieht (WSUS auf SBS), würde ich schleunigst davon weg, ein dedizierter WSUS hat Vorteile.
Der SBS ist elementar für Dein Netz und Deine Domäne. Wenn nun der WSUS auf dem SBS so dermaßen spinnt, würde
ich den auch sobald als möglich herunternehmen. Und genau das willst Du ja auch.
Der SBS ist elementar für Dein Netz und Deine Domäne. Wenn nun der WSUS auf dem SBS so dermaßen spinnt, würde
ich den auch sobald als möglich herunternehmen. Und genau das willst Du ja auch.
richtig ;)
Nur ein paar Zwischenfragen, kein direkter Zusammenhang mit WSUS::
Hast Du dem SBS 2011 genügend RAM gegeben (32 GB kann er maximal, und die würde ich ihm auch geben), schnelle und
genügend große Platten sowie CPUs mit genügend Dampf? Deine Beschreibung klingt nämlich´so, als habe
der SBS allgemein ein bißchen zu schwache Hardwareressourcen, was sich jetzt vorerst beim WUS gezeigt hat. Spätestens,
wenn irgendwann auch Exchange mal rummuckt, würde ich mal in mehr oder bessere Hardware investieren.
Hast Du dem SBS 2011 genügend RAM gegeben (32 GB kann er maximal, und die würde ich ihm auch geben), schnelle und
genügend große Platten sowie CPUs mit genügend Dampf? Deine Beschreibung klingt nämlich´so, als habe
der SBS allgemein ein bißchen zu schwache Hardwareressourcen, was sich jetzt vorerst beim WUS gezeigt hat. Spätestens,
wenn irgendwann auch Exchange mal rummuckt, würde ich mal in mehr oder bessere Hardware investieren.
Intel(R) Xeon(R) CPU E5620 @ 2,40 GHz (2 Prozessoren) und 24 GB RAM
Festplattenplatz ist groß genug.
Leider nicht die optimale Performance (CPU-mäßig) aber das sind halt die Ressourcen die ich hier vorgefunden habe (bin noch relativ neu in der Firma)
Aber egal wie viel RAM man einem Exchange gibt, der schnappt es sich eh weg *gg*
Deshalb muss ich den WSUS ja auch so schnell wie möglich da weg bekommen
Falls Du keine Besonderheiten im WSUS strukturiert/konfiguriert hast (also die alte SUS_DB nicht brauchst), und Dir der neue
Download von sämtlichem Content bei Microsoft nicht zu groß ist, nimm die Lösung von @Deepsys. Das einzige, was Du
wieder einstellen mußt, sind dann noch die Produkte und Klassifizierungen.
Download von sämtlichem Content bei Microsoft nicht zu groß ist, nimm die Lösung von @Deepsys. Das einzige, was Du
wieder einstellen mußt, sind dann noch die Produkte und Klassifizierungen.
Der WSUS ist lediglich in 5 Untergruppen geordnet was die verwalteten PCs angeht. Deshalb wäre der Aufwand zwar nicht der allergrößte aber natürlich schöner wenn ich es mit der SUS_DB gleich mitnehme.
Ich denke ich werde den WSUS erneut hochziehen (habe in der Verzweiflung die Rollen mal entfernt um sie erneut zu konfigurieren) und dann den Content und die DB-File rüberziehen.
Soll ich denn, wenn ich so vorgehe, den neuen WSUS von Microsoft holen lassen oder ihn noch als Downstreamserver laufen lassen? ... Denke doch mal, dass ich den WSUS dann von Microsoft die Updates holen lasse oder nicht?
Danke erstmal für eure Hilfe
Gruß
Moin,
LG, Thomas
p.s.: hast Du mal geschaut, was an dem Teil krumm ist? Mal den WSUS versucht, zu reparieren? Wenn Du dem SBS den WSUS wegnimmst, fängt dann an das Monitoring zu spinnen, die SBS-Konsole wird nicht mehr richtig funktionieren, dann biegt man wieder mit der Hand den Krümmungsradius nach ... and so on ...and so on ...
Der WSUS läuft aktuell auf einem SmallBusiness Server 2k11 (zusammen mit Exchange, welcher bekanntlich extrem Arbeitsspeicher frisst) und soll auf einen Windows Server 2008 R2
warum? Der SBS ist ein SBS ist ein SBS ... läuft bei mir ohne Murren und ohne Probleme mit 32GB. Da scheint eher jemand den SBS vermurkst zu haben ...LG, Thomas
p.s.: hast Du mal geschaut, was an dem Teil krumm ist? Mal den WSUS versucht, zu reparieren? Wenn Du dem SBS den WSUS wegnimmst, fängt dann an das Monitoring zu spinnen, die SBS-Konsole wird nicht mehr richtig funktionieren, dann biegt man wieder mit der Hand den Krümmungsradius nach ... and so on ...and so on ...
p.s.: hast Du mal geschaut, was an dem Teil krumm ist? Mal den WSUS versucht, zu reparieren? Wenn Du dem SBS den WSUS wegnimmst,
fängt dann an das Monitoring zu spinnen, die SBS-Konsole wird nicht mehr richtig funktionieren, dann biegt man wieder mit der
Hand den Krümmungsradius nach ... and so on ...and so on ...
fängt dann an das Monitoring zu spinnen, die SBS-Konsole wird nicht mehr richtig funktionieren, dann biegt man wieder mit der
Hand den Krümmungsradius nach ... and so on ...and so on ...
Da ist nicht viel krumm. Exchange läuft super, als DC mit AD usw. macht er sich auch gut und der WSUS genehmigt auch fleißig.
Allerdings seeeehr langsam. RAM-Auslastung fast immer bei 95%+, den buffert sich ja der Exchange weg.
WSUS nun, wie schon mehrfach gesagt, so langsam, dass er nicht mal mehr die Updates anzeigt weil sich vorher der Serverknoten abschießt.
Dazu gesagt, mein Vorgänger hat den WSUS nur ursprünglich einmal konfiguriert und dann nie wieder was daran gemacht oder gar Updates genehmigt.
Und ich versuche da jetzt irgendwie einen grünen Strich drunter zu bekommen, damit alles wieder gut funktioniert.
Ich denke ich werde den WSUS erneut hochziehen (habe in der Verzweiflung die Rollen mal entfernt um sie erneut zu konfigurieren)
und dann den Content und die DB-File rüberziehen.
und dann den Content und die DB-File rüberziehen.
Ganz so superleicht ist das nicht rübergezogen. Nimm diese Kurzanleitung, damit sollte es gehen:
WSUS Migration von Windows Server 2003 auf Windows Server 2008 R2
Soll ich denn, wenn ich so vorgehe, den neuen WSUS von Microsoft holen lassen oder ihn noch als Downstreamserver laufen lassen?
... Denke doch mal, dass ich den WSUS dann von Microsoft die Updates holen lasse oder nicht?
... Denke doch mal, dass ich den WSUS dann von Microsoft die Updates holen lasse oder nicht?
Wenn Du den gesamten Content vom alten Server auf den neuen rüberkopiert hast, bringt das Replizieren mit dem alten ja nichts mehr, ist ja schon alles "drüben", was soll danach vom alten noch kommen --> Microsoft als Downloadquelle eintragen.
Danke erstmal für eure Hilfe
Gruß
Viele Grüße
von
departure69
Mahlzeit.
Wenn Du dem SBS den WSUS wegnimmst,
fängt dann an das Monitoring zu spinnen, die SBS-Konsole wird nicht mehr richtig funktionieren, dann biegt man wieder mit der
Hand den Krümmungsradius nach ... and so on ...and so on ...
fängt dann an das Monitoring zu spinnen, die SBS-Konsole wird nicht mehr richtig funktionieren, dann biegt man wieder mit der
Hand den Krümmungsradius nach ... and so on ...and so on ...
Das der SBS erwartet, auch einen WSUS an Bord zu haben, ist ja bekannt. Nimmt man ihm den WSUS weg, schaut's im Eventlog tatsächlich so richtig schön bunt aus
.Ich hab' das an unserem SBS 2008 aber in Kauf genommen, alle weiteren Dienste wie AD, DNS, DHCP, WINS und Exchange sind danach aber richtig gut weitergelaufen, und durch den dedizierten WSUS auf einem virt. W2K8R2 gab's dann auch keine WSUS-Probleme mehr. Die vielen Fehlereinträge im Eventlog im SBS, den fehlenden WSUS betreffend, muß man dann halt ignorieren. Wenn man weiß, wovon die herrühren, sollte das doch kein Problem sein.
Viele Grüße
von
departure69
Prinzipiell kann man alles kaputt machen ... reparieren ist dann zumeist schwieriger . Die Frage ist doch, warum kauft man sich einen SBS, wenn man ihn nicht nutzt? Zumal hier auch einige Unkenntnis mit reinspielt, wen stört es eigentlich, wenn sich der MX RAM reserviert? Mich nicht ... und über 28GB habe ich den SBS2011 auch mit viel "Mühe" treiben können. Aber sei es drum, wenn ein Prozess RAM braucht, bekommt er ihn auch. Und wenn mich das optisch stört, dann rüste ich die Büchse halt auf - Luft nach oben ist ja noch.
LG, Thomas
. Die Frage ist doch, warum kauft man sich einen SBS, wenn man ihn nicht nutzt? Zumal hier auch einige Unkenntnis mit reinspielt, wen stört es eigentlich, wenn sich der MX RAM reserviert? Mich nicht ... und über 28GB habe ich den SBS2011 auch mit viel "Mühe" treiben können. Aber sei es drum, wenn ein Prozess RAM braucht, bekommt er ihn auch. Und wenn mich das optisch stört, dann rüste ich die Büchse halt auf - Luft nach oben ist ja noch.Leider nicht die optimale Performance (CPU-mäßig)
Der E5620 ist ein halbwegs schneller Quadcore mit Hyperthreading, was bitte läuft da alles auf der Büchse, wenn nicht mal die CPU (oder sind es gar zwei davon??) (2 Prozessoren)
ausreicht??LG, Thomas
So jetzt wird es interessant.
Neue Anweisung vom Chef: Alten WSUS ignorieren, neuen aufsetzen und in Kauf nehmen, das der Server den ganzen Content neu runterlädt.
Die paar Gruppen die dort konfiguriert waren müssten sowieso überarbeitet werden und sind somit auch irrelevant.
Das bedeutet für mich doch jetzt einfach die IIS und die WSUS Rolle hinzufügen und Standardmäßig konfigurieren oder?
Und wie bekomme ich dann die Clients da rein? Habe das noch nie gemacht und habe was davon gelesen das die Clients per GPO sich beim WSUS melden.
ist das soweit richtig?
Neue Anweisung vom Chef: Alten WSUS ignorieren, neuen aufsetzen und in Kauf nehmen, das der Server den ganzen Content neu runterlädt.
Die paar Gruppen die dort konfiguriert waren müssten sowieso überarbeitet werden und sind somit auch irrelevant.
Das bedeutet für mich doch jetzt einfach die IIS und die WSUS Rolle hinzufügen und Standardmäßig konfigurieren oder?
Und wie bekomme ich dann die Clients da rein? Habe das noch nie gemacht und habe was davon gelesen das die Clients per GPO sich beim WSUS melden.
ist das soweit richtig?
Zitat von @CortaX:
So jetzt wird es interessant.
Neue Anweisung vom Chef: Alten WSUS ignorieren, neuen aufsetzen und in Kauf nehmen, das der Server den ganzen Content neu
runterlädt.
So jetzt wird es interessant.
Neue Anweisung vom Chef: Alten WSUS ignorieren, neuen aufsetzen und in Kauf nehmen, das der Server den ganzen Content neu
runterlädt.
O.K.
Die paar Gruppen die dort konfiguriert waren müssten sowieso überarbeitet werden und sind somit auch irrelevant.
Auch O.K.
Das bedeutet für mich doch jetzt einfach die IIS und die WSUS Rolle hinzufügen und Standardmäßig
konfigurieren oder?
Beim Hinzufügen der WSUS-Rolle kriegst Du sowieso angezeigt, was Du dafür sonst nach alles an Rollen und Features brauchst, kannst vorerst nix falsch machen.
Nach dem Serverneustart solltest Du allerdings noch ein paar Dinge tun:
- Microsoft Report Viewer in der Version 9.0.21022.143 installieren
- den WSUS auf die aktuelle Version bringen (z. Zt. WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274)
- Produkte und Klassifizierungen konfigurieren
- Microsoft als Downloadquelle angeben
- automatische Genehmigungsregel konfigurieren (oder jeden Monat zu jedem Patchday alles einzeln genehmigen, manche wollen halt vorher testen)
- GPO auf neuen Server ändern
Und wie bekomme ich dann die Clients da rein? Habe das noch nie gemacht und habe was davon gelesen das die Clients per GPO sich
beim WSUS melden.
ist das soweit richtig?
beim WSUS melden.
ist das soweit richtig?
Yep, wenn die GPO richtig konfiguriert ist und bei den Clients wirkt, saugen die sich die Updates von allein. Irgendwann (kann etwas dauern) siehst Du die Clients dann auch alle wieder in der Liste unter "Computer".
Grüße
von
departure69
- Produkte und Klassifizierungen konfigurieren
da stehen jetzt nur knapp 10 Punkte, bei unserem alten WSUS stehen dort gefühlte 150 Stück.
Wie bekomme ich die Produkte da wieder rein?
hat sich erledigt. nach erfolgreiche Sync mit Microsoft kam alles dazu. melde mich später ob alles so geklappt hat wie ich hoffe
Während des Sync kannst Du an den Konfigurationen im WSUS nichts ändern, erst, wenn der Sync beendet ist, kannst Du wieder Änderungen vornehmen, z. B. weitere Produkte und Klassifizierungen auswählen.
