Benutzer mit den meisten Antworten
Windows 10 1511 Clients fordern Upgrade auf 1607 von WSUS nicht an

Frage
-
Hallo zusammen,
heute früh kamen bei uns die 1607 Upgrades im WSUS rein. Nach kurzem Aussortieren der Versionen habe ich nun noch 6 Upgrades offen, wovon aber jeweils 3 gleich benannt sind:
Meine Frage:
Was ist hier der Unterschied und welches Upgrade ist für Windows 10 Pro 1511 in de-DE und en-US im Retailchannel zu wählen?
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil
- Bearbeitet SandroReiter Montag, 29. August 2016 06:13
Antworten
-
Kurzes Update von meiner Seite:
4 Clients fordern das Upgrade nun an.
Ich habe nun folgende Änderung an den Policies vorgenommen:
Der zugehörige Registry-Eintrag befindet sich hier:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore\DisableOSUpgrade
Und nach einem gpupdate und einem Neustart lädt mein Testclient das Update nun auch runter:
Ich werde das Verhalten nun nochmal an paar Clients nachstellen, aber ich hoffe hier endlich die Lösung gefunden zu haben.
Wenn das stimmt, kann man sich an 2 Stellen einen Knüppel zwischen die Beine hauen. Einmal indem man Upgrades per Windows Update Richtlinie zurückstellt und einmal die beschriebene Methode über den Store.
Edit 1: Die Liste der Clients die das Upgrade anfordern wächst aktuell stetig ;)
Edit 2: Ich sehe das Thema hier als erledigt an, die Clients fordern reihenweise das Upgrade an.
Nach dem Upgrade zeigen die Clients allerdings das beschriebene Verhalten #2 von Steve Henry [MSFT]:
2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates This is a bug in the Windows client that will be fixed in an upcoming cumulative update. In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it. The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you've waited several days and haven't seen any download success in that time.
Da das allerdings ein anderes Thema ist, was MSFT bereits auf dem Schirm hat. Ist das Problem hier gelöst.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil
- Bearbeitet SandroReiter Freitag, 2. September 2016 07:59
- Als Antwort markiert SandroReiter Freitag, 2. September 2016 07:59
Alle Antworten
-
Am 17.08.2016 schrieb DerNetteMann118:
welches Upgrade ist für Windows 10 Pro 1511 in de-DE und en-US im Retailchannel zu wählen?
Ist doch einfach. ;) Runterladen und mal schauen, was deine Clients anfordern. Sieht mir irgendwie aber auch wieder nach "komischer/fehlerhafter" Produktbeschreibung aus.
Bye
Norbert
Dilbert's words of wisdom #04:
There are very few personal problems that cannot be solved by a suitable application of high explosives.
nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/ -
Ist doch einfach. ;) Runterladen und mal schauen, was deine Clients anfordern. Sieht mir irgendwie aber auch wieder nach "komischer/fehlerhafter" Produktbeschreibung aus.
Wenn's einfach wäre, hätte ich nicht gefragt - vielleicht :P
Also bei den 6 gelisteten Updates steht bei Anzahl "Erforderlich" überall 0. Hm. Doof. Das Update ist noch nicht genehmigt. Wir haben aber mehrere Dutzend Windows 10 1511 Clients.
Und nun? :D
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
- Bearbeitet Norbert-Fehlauer Freitag, 19. August 2016 11:55
-
Dann machen deine Windowskisten was anders als meine. ;)
So nun denn, erleuchte mich und mein Wissen bitte ;)
Wir haben Windows 10 1511 Pro im Einsatz und ich meine das dies die korrekten Upgrades sind, dennoch habe ich bei 71% der Geräte "Nicht zutreffend" :/
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Am 22.08.2016 schrieb DerNetteMann118:
Dann machen deine Windowskisten was anders als meine. ;)
So nun denn, erleuchte mich und mein Wissen bitte ;)
Wir haben Windows 10 1511 Pro im Einsatz und ich meine das dies die korrekten Upgrades sind, dennoch habe ich bei 71% der Geräte "Nicht zutreffend" :/
Was soll ich dazu sagen? ;) Wir haben 1511 Enterprise im Einsatz und alle diese fordern das Update an, wenn ich es denn freigeben würde. Insofern kann es jetzt an den WSUS Regeln des jeweiligen UPgrades liegen. Die fehlerhafte Produktbeschreibung seitens MS macht es auch nicht gerade übersichtlicher. ;) Also keins deiner 6 Upgrades wird angefordert?
Bye
Norbert -
keins deiner 6 Upgrades wird angefordert?
Keins, nicht eines. Null :(
Ich habe jetzt, eventuell voreilig abgelehnte Upgrades nochmal auf "Nicht genehmigt" gesetzt, mal schauen ob die Clients sich nun für eine Version entscheiden.
Wenn jemand noch irgendwas auffällt was der Fehler sein könnte, immer her mit den Tipps :)
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Auch heute: Kein Client fordert die Upgrades an, auch nicht die, die ich extra nochmal auf "Nicht genehmigt" gesetzt habe.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
haben die Clients einen Statusbericht beim WSUS abgeliefert, seitdem im WSUS das Upgrade als verfügbar angezeigt wird?
Hallo willy,
ich habe jetzt mal exemplarisch meinen Client genommen (Windows 10 Pro 1511 auf Surface Pro 3):
Letzter Statusbericht ist vom 23.08.16 um 07:27 Uhr
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Da fällt mir dann auch nicht mehr viel ein. Zeit ist glaube ich auch genug vergangen, seitdem das Upgrade synchronisiert wurde, oder? Sieht so aus, als würdest du schon eine Woche lang warten!?
Eventuell könntest du probieren den Ordner "SoftwareDistribution" im Windows Verzeichnis bei einem Client mal komplett zu leeren und danach nochmal probieren Updates abzurufen. Hatte die Tage auch so einen komischen Effekt. Nach dem Löschen wurde ein freigegebenes Update, das als "nicht verfügbar" angezeigt wurde, plötzlich heruntergeladen. Das war allerdings ein mit dem WPP selbst erstelltes Update.
-
Eine Woche ist es noch nicht ganz, da ich ja erst gestern alle Upgrades wieder zurück auf "nicht genehmigt" gesetzt habe. Aber 68% der Client lehnen die Updates bereits ab.
Bei 44 Clients soll es am SoftwareDistribution Verzeichnis hängen? Nicht ausgeschlossen, aber das sehe ich als nahezu unmöglich an ;)
Hat denn jemand Windows 10 1511 Pro im Einsatz und der Client fordert die Upgrades am WSUS an?
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
...
Bei 44 Clients soll es am SoftwareDistribution Verzeichnis hängen? Nicht ausgeschlossen, aber das sehe ich als nahezu unmöglich an ;)
Hat denn jemand Windows 10 1511 Pro im Einsatz und der Client fordert die Upgrades am WSUS an?
Ich sag nicht, dass es daran liegen soll. Es war ein Vorschlag von mir, um den Fehler etwas einzugrenzen. Dass es nicht ganz praktikabel wäre, das bei allen Clients zu machen, darüber brauchen wir nicht zu diskutieren.
Ja, ich hab es im Einsatz. Bei mir wird es angefordert, aber nicht installiert. Ist ne andere Baustelle...
-
Es war ein Vorschlag von mir, um den Fehler etwas einzugrenzen.
Ja, ich hab es im Einsatz. Bei mir wird es angefordert, aber nicht installiert. Ist ne andere Baustelle...
Ob es installiert wird ist auch erstmal 2. bei uns :D
Zumal ich mit der Beschneidung der Gruppenrichtlinienübernahme mehr als unzufrieden bin, aber ich hätte dennoch gern die Option es auszurollen wenn ich mal 'nen guten Tag habe.
Ich kann mir auch nicht wirklich erklären woran es liegt, fehlt da eventuell noch irgendein abhängiges Update? Es sind eigentlich alle für Windows 10 erschienen Updates freigegeben und auch installiert.
Am Retail Channel wird es vermutlich auch nicht liegen?
Die Clients wurden direkt mit der Version 1511 installiert und nicht von 1507 auf 1511 geupgradet. Daran kann es aber wohl auch kaum liegen? :/
Ich werde mal einen Client vom WSUS trennen und schauen, welche Updates er sich so aus dem "Internet" zieht. Vielleicht finde ich ja dann den Fehler ...
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil- Bearbeitet SandroReiter Dienstag, 23. August 2016 11:01
-
Siehe da, ohne WSUS zieht sich der CLient das Funktionsupdate für 1607
Nur habe ich keine KB Nummer zu dem Update :(
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Siehe da, ohne WSUS zieht sich der CLient das Funktionsupdate für 1607
Nur habe ich keine KB Nummer zu dem Update :(
Falls es dir was hilft:
Mein WSUS sagt KB3012973: Funktinosupdate für Windows 10 Pro, Version 1607...
Ohne WSUS hätte ich das Upgrade auch schon längst auf meinem Testclient. ;)
- Bearbeitet willy-goergen Dienstag, 23. August 2016 11:40
-
Falls es dir was hilft:
Leider nein, die hat der WSUS hier ja auch im Angebot - nur wollen die Clients das irgendwie nicht. Anscheinend fehlt aber auch kein vorher veröffentlichtes Update, denn mein Client zieht sich ja ohne WSUS sofort ohne zu meckern das Upgrade auf 1607, das vom WSUS steht den Clients hier aber anscheinend nicht an.Mein WSUS sagt KB3012973
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Ich habe hier exakt das gleiche Problem.
Die Upgrades werden im WSUS nicht richtig angezeigt, Version [ Release] und Languagecode werden nicht korrekt ausgewiesen, nur bei den Einzelhandelslizenzen sieht es etwas besser aus.
Auf Grund der fehlerhaften Upgradedeklaration hält keine Client das Upgrade für erforderlich.
Ich hatte ein fehlerhaft ausgeführtes KB 3159706 in Verdacht , wegen der ganzene manuellen Schritte dort, und hab es nochmal durchexerziert. Hat nicht geholfen, oder ich hab es wieder falsch gemacht.
Der Zustand ist seit Freitag unverändert, egal was ich anstelle. habe auch schon die Upgrade Classification zurückgesetzt, die Upgrades am WSUS gelöscht und neu synchronisiert - nicht geholfen. Bin zumindest froh das es nicht nur mir so geht. -
Bin zumindest froh das es nicht nur mir so geht.
Na Gott sein Dank ;)
Das KB3159706 für die ESD Kompatibilität habe ich bereits im Mai installiert und die Upgrades im WSUS erst im Juli aktiviert - daran (an falscher Reihenfolge) kann es also nicht liegen.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Ja, die ESD Kompartibilität wurde so im März eingeführt, für Feature- und zukünftige Upgrades. Da hab ich es auch installiert. Das 1511 ist doch aber wesentlich älter und war doch schon vorher per WSUS verfügbar wenn ich nicht irre. Insofern muss es nicht wundern das die Schwierigkeiten erst jetzt mit den "neuen" Upgrades auftreten, hm ?
die drei "gleichen" Upgrades aus deinem Anfangsthread kannst du auseinanderklamüsern wenn du sie mal anklickst, in den Details steht doch dann die unterstützte Sprache drin.
Bringt aber natürlich nix wenn die Clients sie nicht haben wollen :-)
Ich kann sagen das ich Bilder aus amerikanischen WSUS gesehen habe da war alles korrekt mit Version und Sprachlokalisierung, und da klappte es auch mit den Clients.
- Bearbeitet Pö Dienstag, 23. August 2016 14:45
-
Am 23.08.2016 schrieb Pö:
Moins,Ja, die ESD Kompartibilität wurde so im März eingeführt, für Feature- und zukünftige Upgrades. Da hab ich es auch installiert. Das 1511 ist doch aber wesentlich älter und war doch schon vorher per WSUS verfügbar wenn ich nicht irre.
Du irrst. Solltest du im WSUS auch sehen, wann das im WSUS veröffentlicht wurde. Afair im März und nochmal als "Re-Release" im Mai.
Insofern muss es nicht wundern das die Schwierigkeiten erst jetzt mit den "neuen" Upgrades auftreten, hm ?
Kannst du den Gedankengang erklären? :)
Ich kann sagen das ich Bilder aus amerikanischen WSUS gesehen habe da war alles korrekt mit Version und Sprachlokalisierung, und da klappte es auch mit den Clients.
Wundert mich wiederum gar nicht, dass es in englischsprachigen Systemen paßt.
Bye
Norbert
Dilbert's words of wisdom #19:
Am I getting smart with you? How would you know?
nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/- Bearbeitet Norbert-Fehlauer Mittwoch, 24. August 2016 07:49
-
Kann es sein, dass auf den Clients Featureupdates zurückgestellt sind (eventuell per GPO) und deshalb nicht angefordert werden? Dies nur als Idee...
Die Idee ist verdammt gut. Wir haben global DisableOSUpgrade in der Registry verteilt - was eigentlich nur für die Win7 und 8.1 Clients greifen sollte (da hat wohl jemand den WMI Filter vergessen *unschuldigpfeif*).
Ich stelle das jetzt nach und melde mich mit den Ergebnissen!
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Ich stelle das jetzt nach und melde mich mit den Ergebnissen!
Leider weiterhin keine Besserung, ich habe einen komplett neuen Client genommen und auch dieser fordert keins der verfügbaren Upgrades an :(
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
@ Norbert:
schön wenn jemand sowas alles im Kopf hat, sorry, da lag ich wohl daneben.
Danke für die Meldung. Ich habs nichts diesbezügliches per Reg verteilt, den Hinweis auf das CB / CBB aber zum Anlass genommen die Richtline "Computerconfig /Richtlinien/Adm Vorlagen/Windows Komponenten/Windows Update / Windows Updates zurückstellen" zu überprüfen.
Habe ich aber bei Einführung damals nach reichlicher Überlegung gar nicht aktiviert, ergab für mich keinen Sinn in Verbindung mit WSUS.
Ich wäre mir auch gar nicht sicher ob das tatsächlich zu einer " nicht erforderlich " Meldung führt. Würde eher denken das es in dem Fall zwar auf erforderlich steht, aber halt erst mal nicht installiert wird. Wäre logischer, aber was heißt das schon....
Interessanterweise habe ich einen Fall wo ein noch verbliebener W7 Prof Client mit einer Volumenlizenz das neue " Upgrade von Windows 7 und 8.1 auf Windows 10 Pro, Version [Release], [Sprachencode]" als erforderlich einstuft und gerne Upgraden würde. Obwohl die Beschreibung auch diese Lokalisierungsfehler enthält. Die Details zum Upgrade sehen tadellos korrekt aus, und liefern einen interessanten Hinweis:
Bei "Updates, die durch dieses Update ersetzt werden" ist das Vorgängerupdate W7->W10 1511 gelistet. So sollte es vermutlich auch bei den Funktionsupdates auf 1607 aussehen. Tut es aber nicht, da steht "Keine". Und daran könnte es mit liegen. Ich hab die 1511 Upgrades schon rausgeschmissen, aber womöglich kann mal jemand nachsehen ob die auch anführen das sie das 1507 ersetzen.
- Bearbeitet Pö Mittwoch, 24. August 2016 12:19
-
-
Ich kann hier leider keine Links setzen.
Ich übernehme das mal für Dich ;)
Ich habe den ESD Eintrag gesetzt, ich kann auch noch auf den WSUS zugreifen nach einem Neustart.
Edit: Ich hab das sowohl gerade auf dem Master als auch den Downstream WSUS gemacht, ging bei beiden ohne Probleme.
Mein Testclient fordert das Upgrade aber dennoch nicht an.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil- Bearbeitet SandroReiter Donnerstag, 25. August 2016 10:58
-
Ich habe mir nochmal die manuellen Steps zu KB3159706 angesehen.
Es ist doch richtig das man in der Web.config dann 4 Einträge zum Thema endpoint adress stehen hat, 2x binding configuration = "SSL" und 2x für binding configuration="ClientwebServiceBinding"
Die SSL einträge sollen doch zusätzlich rein, oder sollen die die bisherigen ersetzen?
Und obendrüber in dem File steht: wenn http UND https configuriert sind soll man Pfadangaben setzen für endpoint adress="...."
Da steht bei mir aber nichts drin weil in der Anleitung von MS zum KB keine Rede davon war. Das scheint mir dann so nicht richtig.
Ich habe aber nicht so den 100%igen Plan bei solchen Geschichten, könnte mal jemand ein korrekt geupdatetes Web.Config vorzeigen um da Fehler auszuschließen.
-
könnte mal jemand ein korrekt geupdatetes Web.Config vorzeigen um da Fehler auszuschließen.
Abschnitt <services>
<services> <!-- NOTE: To configure for both http and https, use full paths for endpoint addresses: e.g. <endpoint address="https://localhost:8531/ClientWebService/Client.asmx" --> <service name="Microsoft.UpdateServices.Internal.Client" behaviorConfiguration="ClientWebServiceBehaviour"> <!-- If using SSL, change the bindingConfiguration to "SSL". Configuration is Defined below in <bindings>...</bindings> section --> <!-- These 4 endpoint bindings are required for supporting both http and https --> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="SSL" contract="Microsoft.UpdateServices.Internal.IClientWebService" /> <endpoint address="secured" binding="basicHttpBinding" bindingConfiguration="SSL" contract="Microsoft.UpdateServices.Internal.IClientWebService" /> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="ClientWebServiceBinding" contract="Microsoft.UpdateServices.Internal.IClientWebService" /> <endpoint address="secured" binding="basicHttpBinding" bindingConfiguration="ClientWebServiceBinding" contract="Microsoft.UpdateServices.Internal.IClientWebService" /> </service> </services>
Abschnitt <system.serviceModel> (am Ende des Config Files)
</bindings> <!-- Requires AspNetCompatibility mode --> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" /> </system.serviceModel>
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Habt ihr daran gedacht, diese Config wieder dem TrustedInstaller als Besitzer zu geben.
Ich für meinen Teil habe das nicht gemacht, da es im zugehörigen KB Artikel auch nicht gefordert ist (etwas nachdenken damals hätte da vermutlich auch zu geführt das wieder zurückzustellen).
Ich hab es nun auf TrustedInstaller zurückgesetzt. Ich hoffe ich muss nun aber nicht den ganzen hässlichen Weg gehen und Upgrades deaktivieren, das Update nochmal deinstallieren, Serverbereinigung laufen lassen und dann das ganze Spiel nochmal rückwärts? :/
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Ich hoffe ich muss nun aber nicht den ganzen hässlichen Weg gehen und Upgrades deaktivieren, das Update nochmal deinstallieren, Serverbereinigung laufen lassen und dann das ganze Spiel nochmal rückwärts? :/
So, das File gehört nun wieder dem TrustedInstaller und ich habe den langen Weg mit Upgrade deaktivieren, Update KB3159706 deinstallieren, alle heruntergeladenen Upgrades löschen und dann wieder Update installieren, Config-File und IIS anpassen und dann Upgrades aktivieren erledigt.
Das Upgrade ist auf eine Testgruppe genehmigt - Ergebnis: Unverändert, kein Client fordert oder wendet das Upgrade an.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil -
Danke das du dir die Arbeit gemacht hast am Montag Morgen!
Danke für die .config, meine sieht genauso aus, hab ichs also doch kapiert gehabt :-)
Was ist damit, das meinte ich:
NOTE: To configure for both http and https, use full paths for endpoint addresses: e.g. <endpoint address="https://localhost:8531/ClientWebService/Client.asmx"
<endpoint address=""
<endpoint address="secured"
Das sieht nicht nach Full Path aus, und es ist doch beides konfiguriert mit den 4 Einträgen, denke ich?
Wobei ich das sowieso nur pro forma drin hab, mein kleines Netzt hier läuft über 8530, will sagen ohne SSL Verschlüsselung zu den Clients steht das Problem erst mal genauso. Aber irgendwie logisch, erst bei Installfehler am Client wäre die Verschlüsselung wohl ein Problemkanditat.
Hm.
-
NOTE: To configure for both http and https, use full paths for endpoint addresses: e.g. <endpoint address="https://localhost:8531/ClientWebService/Client.asmx"
Würde ich so verstehen wie: Wenn Du beides nutzen willst, dann arbeite bitte mit der vollständigen Pfadangabe.
Da wir nur https verwenden und Du nur http, sollte das mMn keine Auswirkung haben.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil- Bearbeitet SandroReiter Montag, 29. August 2016 07:38
-
Gleiches Problem auch hier, derzeit ohne Lösung. Aber hier stimmt schon mal die Beschriftung der Updates.
https://community.spiceworks.com/topic/1776782-feature-update-to-1607-not-applicable
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil
- Bearbeitet SandroReiter Dienstag, 30. August 2016 11:28
-
Eventuell könntest du probieren den Ordner "SoftwareDistribution" im Windows Verzeichnis bei einem Client mal komplett zu leeren und danach nochmal probieren Updates abzurufen.
Ich hab das nun mal an einer handvoll Clients gemacht - leider auch keine Besserung.
Eventuell ist es vorerst besser auf einen Fix von MSFT innerhalb der nächsten Patchdays zu warten anstatt unnötig Zeit in etwas zu stecken, für was es derzeit anscheinend keine Lösung gibt. :(
Bis die Maintenance vom 1511er Windows 10 ausläuft sind ja noch paar Monate.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil- Bearbeitet SandroReiter Dienstag, 30. August 2016 13:45
-
...
Eventuell ist es vorerst besser auf einen Fix von MSFT innerhalb der nächsten Patchdays zu warten anstatt unnötig Zeit in etwas zu stecken, für was es derzeit anscheinend keine Lösung gibt. :(
Bis die Maintenance vom 1511er Windows 10 ausläuft sind ja noch paar Monate....
Da wurde glaub ich meine bescheidene Wenigkeit zitiert.
So würde ich das auch erst mal sehen. Einen Client - vielleicht den eigenen? - könnte man aber ja testweise mal mit den neuesten Versionen Windows hochziehen, gerade wenn man irgendwo als Admin unterwegs ist.
Windows 10, unter anderem in Verbindung mit einem WSUS, ist im Moment in Unternehmen glaube ich nicht ganz unproblematisch.
Um sowas auf die Allgemeinheit der User loslassen zu können, fehlt mir die Kontinuität der früheren Windows Versionen. Ich frage mich sowieso, warum manche Menschen den Drang verspüren, das alles mitmachen zu müssen. Bitte nicht persönlich nehmen und falsch verstehen: Aber hat das was mit anstehenden Zertifizierungen zu tun?
Meine evtl. etwas subjektive Meinung dazu: So lange bzgl. Windows 10 so chaotische Zustände herrschen, werde ich den Teufel tun, meine gut laufende Umgebung mit sowas kaputt zu machen.
Grüße
willy
- Bearbeitet willy-goergen Dienstag, 30. August 2016 16:16
-
Wir haben global DisableOSUpgrade in der Registry verteilt
Ich möchte mich nicht der Thematik anschließen, die Frage gilt eher für meine Probleme mit dem 1607-Upgrade via WSUS. Greift DisableOSUpgrade auch auf das Anniversary-Upgrade, wenn man nach dem Registry-Eintrag (noch Win7 installiert) auf Windows 10 geupdatet hat?
Grüße
-
Wir haben global DisableOSUpgrade in der Registry verteilt
Ich möchte mich nicht der Thematik anschließen, die Frage gilt eher für meine Probleme mit dem 1607-Upgrade via WSUS. Greift DisableOSUpgrade auch auf das Anniversary-Upgrade, wenn man nach dem Registry-Eintrag (noch Win7 installiert) auf Windows 10 geupdatet hat?
Grüße
Was hältst du davon, einfach mal zu lesen was dir da auf dem Bildschirm angezeigt wird?
Die Richtlinie gibt es schon lange. Dafür brauchst du nicht mal direkt einen Registry-Eintrag zu setzen.
https://windowsserveressentials.com/2015/06/11/turn-off-the-upgrade-to-the-latest-version-of-windows-gpo/
Das wird immer noch greifen, wieso auch nicht?
- Bearbeitet willy-goergen Dienstag, 30. August 2016 18:42
-
Da wurde glaub ich meine bescheidene Wenigkeit zitiert.
Ja, ich dachte nach all den Versuchen probiere ich mal Deinen Vorschlag aus um den auch ausschließen zu können ;)
So würde ich das auch erst mal sehen. Einen Client - vielleicht den eigenen? - könnte man aber ja testweise mal mit den neuesten Versionen Windows hochziehen, gerade wenn man irgendwo als Admin unterwegs ist.
Ist bereits geschehen, 2 frisch installierte 1607er Versionen von Windows 10 befinden sich bereits im Test auf Herz und Nieren - allerdings muss auch das Upgrade verteilen und einspielen getestet werden.
Windows 10, unter anderem in Verbindung mit einem WSUS, ist im Moment in Unternehmen glaube ich nicht ganz unproblematisch.
Um sowas auf die Allgemeinheit der User loslassen zu können, fehlt mir die Kontinuität der früheren Windows Versionen.
Kontinuität wirst Du ohne eine Longtime Support Version von Windows 10 nicht mehr kriegen :(
Ich frage mich sowieso, warum manche Menschen den Drang verspüren, das alles mitmachen zu müssen. Bitte nicht persönlich nehmen und falsch verstehen: Aber hat das was mit anstehenden Zertifizierungen zu tun?
Verstehe ich nicht falsch, hat nichts mit Zertifizierungen zu tun. Ich für meine Verhältnisse beschäftige mich nur sehr gern mit dem neusten heißesten Zeug was so auf den Markt kommt ;) Da ist es für mich selbstverständlich als einer der ersten auch die aktuelle Win10 Version einzusetzen - wenn es denn getestet und für tauglich eingestuft wurde ;)
Mein Glück (oder Pech) ist, das mein AG das genauso sieht, der Einsatz neuster und moderner Technologien ist gern gesehen.
Meine evtl. etwas subjektive Meinung dazu: So lange bzgl. Windows 10 so chaotische Zustände herrschen, werde ich den Teufel tun, meine gut laufende Umgebung mit sowas kaputt zu machen.
Das ist auch richtig, so gehe ich das Thema ja auch an. Windows 10 1511 läuft problemlos (mal von dem Upgradeproblem derzeit abgesehen). Man muss aber halt auch aufpassen (jetzt nicht falsch verstehen), das man kein alteingesessener Admin wird und nur auf bewährte Technologien schwört - der Blick über den Tellerrand und die Bereitschaft neues zu lernen/auszuprobieren ist enorm wichtig um nicht stehen zu bleiben. Ansonsten stellt man eines Tages kurz vor Support Ende des OS fest: "Oh, wir sollten mal upgraden, aber lasst uns erstmal 1 Million aus dem Fenster werfen um den Support zu verlängern."
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil- Bearbeitet SandroReiter Mittwoch, 31. August 2016 06:54
-
Ja, das bei spiceworks hatte ich auch schon gesehen, aber das ist ja auch kein deutsches System :-)
Ich stehe unglücklicherweise noch vor dem Problem das ich der Empfehlung: setze esd application/octet-stream nicht folgen kann, sobald ich im IIS den MIME Typ eintrage startet die WSUS Konsole mit Fehler und kann keine Verbindung herstellen. Zum verrückt werden.
Ich habe jetzt mal ein Upgrade über ISO gemacht, nur um zu sehen was danach so passiert.
Das 1607 zieht sich die ProgrammUpdates die ich über die Softwareverteilung/WSUS verteile, aber wenn es um Windows Updates geht meldet er 0x8024500c.
Gemessen daran das die Einführung von 1511 damals gar keine Probleme machte ist das hier die totale Katastrophe.
-
Es gibt mittlerweile eine Antwort von Steve Henry [MSFT]:
3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update This is a newly reported issue that we are currently investigating. Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS. We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can. We'll share further updates on the investigation as they become available.
Den kompletten Thread (englisch) gibt's hier:
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil- Bearbeitet SandroReiter Mittwoch, 31. August 2016 11:47
-
Ah. Doch schon nach 2 Wochen.....
Ich möchte an der Stelle auf noch ein weiteres Problem aufmerksam machen, weil viele auch sagen: Ich hab das 1607, aber er zieht keine Updates!, was ich auch erlebt habe. Das wurde noch mit Error 0x8024500c garniert.
Nach Upgrade auf 1611 war der Testclient nicht in der Lage seinen Updatestand mit WSUS abzugleichen bzw. Updates zu ziehen da er keine Verbindung hatte. Am WSUS vorbei liefen die Updates.
Dies tritt auf in Verbindung mit bereits aktualisierten Windows 10 1607.admx Templates. Grund ist das die Windows Update Richtline "Upgrades und Updates zurückstellen" ersetzt wurde durch mehrere andere Richtlinien.
Wurde diese verwendet und die diesbezüglichen neuen Richtlinen ebenfalls kommt es zu Konflikten beim WSUS Zugriff.Man kann das aber nicht mehr ändern, da die Policity nicht mehr exsistiert. Mann muss sie also wieder erzeugen / wiederherstellen.
Erkennbar wird das Problem wenn man Gruppenrichtlinenergebnisse für einen Client erzeugen lässt und unter Adm. Vorlagen den Eintrag: "Zusätzliche Reg. -einst." findet. Dort werden aktive Policities gelistet für die es keine Nutzeroberfläche mehr gibt.
Um das Problem zu beheben kann man entweder die WindowsUpdate.admx aus den 1607er Templates duch die ältere Version der 1511er Templates ersetzen, setzt die Windows Update Richtline "Upgrades und Updates zurückstellen" zunächst auf "Nicht konfiguriert". Ab da kommunizieren die 1607er Windows sofort korrekt mit dem WSUS . Wartet ein paar Tage bis sie auch wirklich alle Clients gezogen haben. Dann ersetzt man sie wieder gegen die neue Version und konfiguriert nach Gusto.
Die andere Möglichkeit ist, man öffnet die .admx und die .adml, kopiert die entsprechende Policity und den Languageabschnitt von der 1511 Version in die 1607er Version. Das wäre perfekt. Hat bei mir aber nicht geklappt. Hat aber nichts zu sagen, vom Coden verstehe ich nichts.
-
Kurzes Update von meiner Seite:
4 Clients fordern das Upgrade nun an.
Ich habe nun folgende Änderung an den Policies vorgenommen:
Der zugehörige Registry-Eintrag befindet sich hier:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore\DisableOSUpgrade
Und nach einem gpupdate und einem Neustart lädt mein Testclient das Update nun auch runter:
Ich werde das Verhalten nun nochmal an paar Clients nachstellen, aber ich hoffe hier endlich die Lösung gefunden zu haben.
Wenn das stimmt, kann man sich an 2 Stellen einen Knüppel zwischen die Beine hauen. Einmal indem man Upgrades per Windows Update Richtlinie zurückstellt und einmal die beschriebene Methode über den Store.
Edit 1: Die Liste der Clients die das Upgrade anfordern wächst aktuell stetig ;)
Edit 2: Ich sehe das Thema hier als erledigt an, die Clients fordern reihenweise das Upgrade an.
Nach dem Upgrade zeigen die Clients allerdings das beschriebene Verhalten #2 von Steve Henry [MSFT]:
2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates This is a bug in the Windows client that will be fixed in an upcoming cumulative update. In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it. The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you've waited several days and haven't seen any download success in that time.
Da das allerdings ein anderes Thema ist, was MSFT bereits auf dem Schirm hat. Ist das Problem hier gelöst.
Freundliche Grüße
SandroMCSA: Windows Server 2012 in spe ;)
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)XING: Zum Profil
LinkedIn: Zum Profil
Facebook: Zum Profil
- Bearbeitet SandroReiter Freitag, 2. September 2016 07:59
- Als Antwort markiert SandroReiter Freitag, 2. September 2016 07:59
-
Hallo Sandro,
auch bei uns war die von dir genannte Funktion für den Windows Store eingeschaltet. Nach dem Deaktivieren fordern nun auch unsere Windows 10 Clients das Update an.
Danke für den Hinweis!
Gruß
Marcel
- Bearbeitet Marcel_H Freitag, 2. September 2016 08:57
-
Am 07.10. hat MSFT neue Revisionen der Funktionsupdates veröffentlicht. Diesmal haut auch die Channel und Sprachbeschreibung im Updatetitel korrekt hin.
Achtung: Zumindest bei mir waren die vorhandenen Genehmigungen wieder entfernt und auf "nicht genehmigt" zurückgestellt. Das hat den Upgraderollout natürlich verzögert.
Ob der WSUS-Fix KB3189866 jetzt bereits enthalten ist, kann ich leider nicht sagen. Ich habs noch nicht weiter getestet.
Freundliche Grüße
Sandro
MCSA: Windows Server 2012
Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)
- Bearbeitet SandroReiter Montag, 10. Oktober 2016 13:42