{"id":759,"date":"2015-07-30T15:47:11","date_gmt":"2015-07-30T13:47:11","guid":{"rendered":"https:\/\/www.krombusch.de\/?p=759"},"modified":"2021-11-01T12:36:39","modified_gmt":"2021-11-01T11:36:39","slug":"wsus-beware-of-share","status":"publish","type":"post","link":"https:\/\/www.krombusch.de\/?p=759","title":{"rendered":"WSUS: Beware of share!"},"content":{"rendered":"

Mit den Jahren waren die f\u00fcrs Intranet zwischengespeicherten Updates auf knapp 200 GB\u00a0 angewachsen. Der WSUS-Bereinigungsassistent kam l\u00e4ngst nicht mehr durch das Chaos und brach mit Timeout ab. WSUS neu installieren und alles nochmal von windowsupdate.com runterladen? Ist f\u00fcr M\u00e4dchen. Von Hand mit For-Each-Powershell? Muss auch nicht. Warum also nicht einfach ein 200GB-Tapetenwechsel mit \u201ewsusutil.exe movecontent \\\\netz\\lauf\\werk\u201c?<\/p>\n

wsusutil kopierte brav den Content-Ordner und setzte danach den physikalischen Pfad zum virtuellen Verzeichnis im IIS neu. F\u00fcr unsere Clients sollte die Aktion transparent sein: Sie melden sich per Gruppenrichtlinie regelm\u00e4\u00dfig beim WSUS und installieren zu festen Zeiten, was wir ihnen dort anbieten. Taten sie danach aber nicht mehr.<\/p>\n

Die Fehlermeldungen im Client (%windir%\\windowsupdate.log) sind zwar gut zu googlen, aber letztlich Folgefehler. Sowas wie \u201eDownload call completed, hr = 0x80244017\u201c sagt somit eher, dass schon an h\u00f6herer Stelle etwas nicht funktioniert hat. Ein auf dem WSUS-Server laufender Procmon zeigte das Problem:<\/p>\n

\"wsus-share01\"<\/a><\/p>\n

Es ist also dem (anonymen) Internetkonto, \u00fcber das der WSUS seine Gesch\u00e4fte abwickelt, erst einmal nicht gar nicht erlaubt, auf ein Share zuzugreifen. Das hat seinen Sinn, wie (der gesunde Menschenverstand? Sch\u00e4m!) und Microsoft<\/a> schon sehr fr\u00fch betonten. Wohl deshalb bestraft Windows Zuwiderhandlungen mit unlogischem Verhalten. Denn sowohl das Setzen von Share- und NTFS-Berechtigungen auf den neuen Ordner als auch eine Identit\u00e4ts\u00e4nderung (Impersonation) im AppPool liefen f\u00fchrten weiterhin zum \u201eAccess Denied\u201c heraus, wenn der Client mit dem Download der Updates beginnen wollte.<\/p>\n

\"wsus-share02\"<\/a><\/p>\n

\"wsus-share03\"<\/a><\/p>\n

Die n\u00e4chste Stufe w\u00e4re folglich das Einsetzen eines \u201enormalen\u201c Dom\u00e4nen-Dummykontos f\u00fcr die Wsus-Asp-Anwendung, aber irgendwann wird die Fehlerkette einfach zu lang. (Account woanders deaktiviert, Lizenzen usw.). Und irgendwann gibt man auf und geht den Weg, der auch schon im Setup des WSUS vorgezeichnet ist: Bitte lokales Laufwerk f\u00fcr den Content ausw\u00e4hlen! M\u00e4dchen w\u00e4ren sofort schlauer gewesen.<\/p>\n

IIS7 and UNC-based virtual directories.<\/a><\/p><\/blockquote>\n