kosta88

Moin, vielleicht kennt da was wer, aber meine Win10 Clients im HyperV auf Server 2016 stürzen auf Low Memory immer wieder ab. Ich habe zwei und beide machen es. Sind aber sauber installiert, und auf einer läuft praktisch nichts... Ereignisanzeige zeigt ja massive Einträge, und die Apps die den Speicher füllen sind unterschiedlich, meistens ja irgendwelche Windows Programme. IE ist auch nicht offen. Die Maschinen haben jeweils 4GB RAM, aber das spielt keine Rolle, bei 8GB dauert es nur länger... Da es auf zwei VMs passiert, ist da was bekannt? Danke

Die Genehmigungen sollten auf dem Upstream Server gemacht werden, der zweite übernimmt, jedoch die Clients die auf dem Downstream Server eingetragen sind sollen die Updates direkt von MS ziehen. Oben scheinbar verschrieben. Sorry.

Ob gleich oder nicht, weiß nicht ob egal. Offensichtlich habe ich was wichtiges nicht erwähnt: Bei meinem Replica-WSUS handelt sich um den Server der die Updates aus dem Netz zieht - die zugewiesenen Clients sollen nichts aus dem Content Ordner ziehen. Daher hat sich eigentlich die Frage erübrigt, wenn ich es richtig verstehe - Haken weg.

Und kann das das gleiche wie der Upstream WSUS? Also der gleiche Pfad für beide?

Wenn man im Server-Manager WSUS installiert, man wählt die Rolle aus, und dann kommt Eintrag für den Content Ordner ("Content Location Selection"). Kommt natürlich nicht, wenn ich mit Powershell installiere, somit hinterfrage ich ob das das gleiche ist, was beim ersten Aufruf vom WSUS aufpoppt, vonwegen Content (die normale Ersteinrichtung).

Eine Frage dazu, wenn schon zum Thema Pfad: Bei einem Replica-WSUS, werde ich nach dem selben Eintrag bei der Installation und bei der Einrichtung gefragt. Bei der Einrichtung weiß ich dass ich den Häckchen entfernen muss, jedoch bei der Installation, was gebe ich dort ein? Danke

Das Problem ist gelöst - lag offensichtlich an dem UNC Pfad. Auf Spiceworks habe ich die Antwort bekommen dass es manche mit dem FQDN gelöst haben. Ich hatte nicht gewusst dass UNC Pfade nicht supportet sind - vielen vielen Dank, das hat einige Nerven gekostet...

Danke. Werde ich ändern (wieder via iSCSI) und wieder reporten.

Dort gibt es einige Einträge. Als Beispiel Silverlight Update: Viele txt-Datei Referenzen und dann zwei mal Silverlight.exe und einmal Siliverlight_x64.exe. Die .exe Dateien sind im File-System vorhanden. Ich sehe allerdings WSUS zeigt mir den HTTP Link. Damit fange ich irgendwie nichts an... jedoch schaue ich auf meiner Freigabe auf dem anderen Server (WSUS-Content Ordner), dann finde ich diese Dateien dort. Wenn ich mal überlege, früher habe ich die Konfiguration immer mit iSCSI Laufwerken auf der NAS gemacht. Ist ja doch gar nicht verkehrt den WSUS-Contant auf einem Share (UNC-Pfad) zu hinterlegen?

Ja, das meine ich ja! Die Spalte habe ich eingeblendet und wenn man darüber schwebt, steht ja zuerst dass heruntergeladen wird, mein Netzwerk ruddert mit ein paar MBit, und nach paar Minuten ist Ruhe, und dann ist das Symbol anders und wenn man darüber schwebt steht "Ready for installation". Ich hoffe ich habe es nicht zum 2. Mal missverstanden...

Das Update, wie auch jeder andere der hängt, sind alle im WSUS zu finden, und sind bereits heruntergeladen ("Ready for Installation" Status). Weitere Updates die hängen sind Silverlight KB4023307 und 2018-01 Win10 Update KB4074608. Es ist aber egal welcher Rechner, alle die irgendein Update ziehen wollen, hängen bei Downloading 0%. Ich poste nicht den ganzen Log, das ist wohl klar, aber eine Zeile fällt mir auf: Dynamic download data fetcher for ServiceId 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 does not exist.

WSUS Build: 10.0.14393.1914 Update Status: "Ready for installation" Es handelt sich hier spezifisch um MS SQL Server 2014 SP2 CU KB3178925. Aber es hängt auch zB. Silverlight, dort wo kein SQL vorhanden ist. Derzeit sind nur 4 Updates in WSUS, ist ja ganz frisch sozusagen...

Hallo, die Updates auf den Win10 Rechnern bleiben bei 0% download hängen. Nach einiger Recherche, sehe ich dass das mit 2016 und 10 bekannt sein soll, und einiges empfohlen wird, aber bei mir wirkt ja gar nichts. 1) es ist kein Proxy in Verwendung 2) die kumulativen Updates sind drauf: 2018-01, sowohl Server wie auch Client (damit auch soll das Problem mit Windows Update Agent erledigt sein) 3) Windows Firewall Domain/Private ist aus, Public ist an, Dienst ist gestartet 4) Die Methode net stop/start wuauserv/bits, und SoftwareDistribution zu löschen, habe ich gemacht Wie soll mein weiteres Troubleshooting fortlaufen? Danke

Nein - es gibt keinen direkten Grund den ich nennen kann. Deswegen fragte ich ja - siehe zweite Zeile des Eröffnungsposts.

Weil das derzeit Best Practice ist, meistens werden Zertifikate und Exchange als Gründe erwähnt. Etwas was derzeit nicht verwendet wird, aber wird später. Will ich nicht. Ich will sie, wenn schon, dann neu aufziehen.

Norbert, da Frage war wohl rhetorisch, das war ja für mich irgendwie klar. Natürlich kann mir niemand was garantieren. Die Firma die uns extern supportet, habe ich ja nachgefragt, meinte ich könnte das ja machen, da die Umstände aufgrund der jetzigen Größe nicht allzu groß sind. Aber auch wie hier gesagt, nicht zwingend notwendig. Aber wenn schon, würde ich das Umbennenen nicht wirklich bevorzugen. Es gefällt mir wesentlich besser, das Thema von Grund auf neu zu machen, sofern ich die großen Brocken aus der alten Domain mitnehmen kann... die GPOs, DHCP Reservierungen usw.

Hallo ihr beiden, besten Dank für die Antworten. Es ist derzeit in meinem AD kein Exchange im Betrieb. Auch was SQL betrifft, kann ich die DB exportieren und in den anderen SQL importieren. Unsere Produktiv-Umgebung ist ja im Rechenzentrum via Citrix. Dort haben wir auch Exchange, und die company.at Domain (Email-Adressen). Ob dort company.local die ADDS Domain ist, oder nicht, weiß ich nicht. Auf die Administration der Systeme habe ich keinen Zugriff. Unsere company.at Domain wird auch von diesem Rechenzentrum gehostet. Und zusätzlich haben wir dort eine Subdomain, office.company.at, diese wird für Office 365 Adressen verwendet. Und wie schon erwähnt, es soll später lokal bei uns Exchange kommen, dieser wird also nicht die @company.at Adressen tragen, die haben wir ja schon im Rechenzentrum. Aber vermutlich dann was anderes, @wien.company.at o.ä. Das Domainhosting bleibt ja weiterhin im Rechenzentrum. Nun, je länger ich das System betreue, desto größer wird es, und wenn was geändert wird, wäre JETZT der richtige Zeitpunkt, und nicht später. Kann mir jemand garantieren dass die .local nicht "auslaufen" wird, und irgendwann in 2-3 Jahren es dazu kommt, dass eine .at Domäne sinnvoller wäre? Wenn man schon kurz das Thema Gruppennamen angesprochen hat: Diese Gruppen lassen sich nicht umbennenen, auch wenn ich das aus kosmetischen Gründen wollen würde.

Hallo, vor vielen Jahren wurde unsere Domäne company.local genannt. Nach einigen googeln finde ich jedoch keine trifftigen Gründe um von .local auf .at zu wechseln - gibt es da welche? Unter anderem werden wir auch Exchange 2016 einsetzen, aber nicht im firmenweiten Produktivbetrieb. Auch will ich unsere Domain in das Englische System ziehen, und dazu auch komplett - auch die Gruppennamen bspw. Daher wären so, in Zuge unseres IT-Umbaus möglich, zwei Sachen zu richten - falls wirklich sinnvoll. Wie ich mir das vorgestellt habe: Derzeit habe ich 2 Server mit je einem DC. Dazu würde ich zwei zusätzliche DCs aufziehen, die die andere Domain tragen, die komplett wie die alten DCs konfigurieren, und die Clients dann am Ende Stück nach Stück in die neue Domain setzen. Wichtig dabei zu erwähnen, was bei uns in Verbindung mit der Domain verwendet wird: Außer User/Gruppen/GPO nicht viel mehr. Wir haben dzt. kein Exchnage. Damit werden die Sachen wie Software-Verteilung, Windows-Einstellungen u.ä. gemacht (Senkung des allgemeinen Administrationaufwandes). Unsere eigene Software, die lässt sich aber relativ leicht umstellen. Ich will hier wissen ob es sinnvoll ist eine Änderung von .local auf.at (also unsere echte Domain) anzustreben und ob der obige Weg der sinnvoll Weg ist. Danke

Hallo, ich bin etwa irritiert: Ich habe im WSUS die Sprachpaket-Gruppe ausgewählt und gesynct. Soweit so gut. Die einzigen zwei Sprachpakete die mich interessieren sind Englisch und Deutsch. Diese wurden auch freigegeben. Habe auf meinem Client getestet und das Englische Sprachpaket installiert, wurde ja vom WSUS bezogen. Jedoch sind es noch einige andere Rechner im WSUS und diese haben die zwei Sprachpakete als "needed". Jedoch installiert nichts - was auch klar ist - die Clients haben die Sprache nicht hinzugefügt. Ich würde gerne meinen WSUS schon sauber haben. Woran liegt es denn, Idee? Danke

Macht Sinn, danke.

Hallo, spricht was dagegen die Servers (2016) auf Englisch zu installieren und die Clients auf Deutsch? Danke

Kann ich dann gerne berichten. Wird ja ein wenig dauern, da jetzt nur die HW angeschafft wird, und ich jetzt die Hochsaison mit den Installationen habe, aber die Umsetzung ist für das erste Quartal 2018 geplant.

Proposed as answer by BriReyEDU Thursday, November 30, 2017 9:12 PM

Hier das Posting vom Technet Forum: https://social.technet.microsoft.com/Forums/ie/en-US/1158d776-1dea-4078-aa4e-1f56b703ac62/kb4043961-wsus-not-installing?forum=winserverwsus Betrifft bei mir KB4049855, wurde von Clients nicht gezogen, obwohl im WSUS die meisten Clients als "Needed" erschienen. Das nächste kumulative Update KB4051963 wurde dann normal gezogen und installiert.

Danke für die Tipps. Leider lag es nicht daran. Ich hätte nicht gedacht dass es an einem Update liegen kann - ich hatte ein Thread gefunden, wo mehrere Berichte diesbezüglich waren, genau mit dem Update auch, mit dem darauffolgenden kumulativen Update (die KB-Nummer habe ich jetzt nicht bei der Hand) hat es dann funktioniert.