Normales Thema Selbstupdate funktioniert nicht. - 13042 auf ganz Hartnäckig (Gelesen: 2290 mal)
Murdock
WSUS Neuling
Offline


I Love WSUS!

Beiträge: 3
Mitglied seit: 20.01.12
Selbstupdate funktioniert nicht. - 13042 auf ganz Hartnäckig
20.01.12 um 20:09:13
Beitrag drucken  
Hallo zusammen,

mein (WSUS-)Server leidet momentan unter dem o.g. Problem: In der Ereignisanzeige habe ich den Fehler 13042 mit der Beschreibung "Selbstupdate funktioniert nicht" stehen und bekomme ihn auch nach stundenlanger Internet-Recherche und verschiedenen Ansätzen zur Problemlösung nicht weg.

Grundlegendes zum System:
- Windows Server 2008 Enterprise Edition (32-Bit)
- AD-Mitglied
- WSUS 3.0 SP2
- 2 Netzwerkschnittstellen: 192.168.1.2 im DNS mit dem Servernamen ("Server", FQDN="server.lan.local") registriert, 192.168.1.3 registriert sich im DNS explizit nicht (=Absicht!) und wird vom internen DNS mit meiner DynDNS Domain (random.homelinux.net) aufgelöst.
- 3 IIS Sites: "intern" auf 192.168.1.2:80 sowie 127.0.0.1:80, "extern" auf 192.168.1.3:80, "WSUS-Verwaltung" auf "*:8530" bzw auf "*:8531" mit SSL.

Das Konstrukt mit dem DynDNS Namen auf der externen Site auf der internen IP hat den Sinn dass ich die Seiten die dort laufen vom LAN aus exakt genauso erreiche wie vom Internet aus.

Interessanterweise funktioniert der Zugriff mittels Browser auf die Dateien im Verzeichnis "selfupdate" von dena nderen Clients aus 1A.

Was nicht richtig funktioniert ist der Zugriff vom Server selbst aus, und zwar weder über "server" noch über "server.lan.local" und auch nicht über "localhost" sondern jediglich über die IP-Adressen (192.168.1.2 sowie 127.0.0.1) klappt der Zugriff vom Server selbst aus.

Was ich schon an Lösungsansätzen durch hab:
- Rechte auf das Verzeichnis C:\Program Files\Update Services\Selfupdate geprüft
- "SSL erforderlich" ist sowohl auf der Site "intern" als auch im virtuellen Verzeichnis "Selfupdate" deaktiviert
- der Registrykey "UsingSSL" steht auf "0"
- der Registrykey "PortNumber" steht auf "8530"
- in der Bindung der IIS-Site "intern" steht kein Hostname drin und "Selfupdate" ist über den Port 80 erreichbar

Meine Clients kriegen auch alle ihre Updates und der Server selbst auch.

Mir ist aber aufgefallen dass mein Server sich über nslookup zwar selbst richtig auflöst, wenn er sich selbst pingt aber die IPV6 Loopback Adresse verwendet.

Vielleicht hat ja von euch jemand einen heißen Tip für mich wie ich dieses Problem aus der Welt schaffen kann, auch wenn sich's augenscheinlich im großen und ganzen auf die Meldung in der Eventlog beschränkt.
  
Zum Seitenanfang
 
Sunny
Microsoft MVP
*****
Offline



Beiträge: 15134
Mitglied seit: 11.02.07
Geschlecht: männlich
Re: Selbstupdate funktioniert nicht. - 13042 auf ganz Hartnäckig
Antwort #1 - 20.01.12 um 23:21:26
Beitrag drucken  
Existiert auf Port 80, auf der Default Website die Site Selfupdate? (Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).
  
Zum Seitenanfang
 
Murdock
WSUS Neuling
Offline


I Love WSUS!

Beiträge: 3
Mitglied seit: 20.01.12
Re: Selbstupdate funktioniert nicht. - 13042 auf ganz Hartnäckig
Antwort #2 - 21.01.12 um 02:17:35
Beitrag drucken  
Ja das virtuelle Verzeichnis "selfupdate" existiert auf Port 80 auf der primären IP (192.168.1.2=server.lan.local sowie 127.0.0.1).
Ist auch von nem Client aus per Browser zugänglich und ich kann das was drin ist auch herunterladen.

Es liegt also auch kein Berechtigungsproblem vor, das habe ich schon mehrfach überprüft.

EDIT:
Und SSL ist auch aus, sowohl auf der Site selber als auch im virtuellen Directory "selfupdate".
  
Zum Seitenanfang
 
Sunny
Microsoft MVP
*****
Offline



Beiträge: 15134
Mitglied seit: 11.02.07
Geschlecht: männlich
Re: Selbstupdate funktioniert nicht. - 13042 auf ganz Hartnäckig
Antwort #3 - 21.01.12 um 09:32:22
Beitrag drucken  
Hast Du denn im lokalen DNS auch in der Reverse Lookup Zone alles korrekt eingetragen?
  
Zum Seitenanfang
 
Murdock
WSUS Neuling
Offline


I Love WSUS!

Beiträge: 3
Mitglied seit: 20.01.12
Problem gelöst!
Antwort #4 - 21.01.12 um 10:19:51
Beitrag drucken  
Ich hab das Problem inzwischen lösen können, s.u.!

Der Server steht in der Reverse-Lookupzone richtig drin.
Wird mir per nslookup auch direkt vom Server aus richtig aufgelöst.

Was er mir nicht auflöst ist "localhost", wenn ich localhost pinge macht er das zwar verwendet aber die ipv6 Adresse.
Ist das Absicht?

EDIT:
Eins ist mir grad nochmal aufgefallen, hatte ich im Startpost zwar nochmal geschrieben aber ich ab den Eindruck dass da der Hase im Pfeffer begraben liegt:

Wenn ich direkt auf dem Server den Hostnamen per nslookup auflösen lasse klappt das 1A.

Pinge ich den Server von sich selbst aus über "server" pingt er die ipv6 Adresse.

Rufe ich vom Server aus "http://server" auf (irgendeine Seite die drunter liegt und tatsächlich vorhanden ist und auch von den Clients aus 1A geht) bekomme ich einen 404.

Lösung:
Ich hatte ja festgestellt dass ich vom Server selbst aus nicht über den Hostnamen auf den IIS kam. Das betraf sowohl "localhost" als auch "server" bzw. "server.lan.local".

Per nslookup wurde zwar alles korrekt aufgelöst, ich hab allerdings festgestellt dass beim Ping an einen der Hostnamen immer die IPV6 Adresse verwendet wurde.

Probehalber mal den externen IIS auf der 192.168.1.3 gestoppt (zur Erinnerung: Die Standardwebseite verwendet 192.168.1.2 und nur diese IP wird mit "server" aufgelöst) und der internen IIS Site eine Bindung auf * verpasst, schon ging's.

Anschließend hab ich die Bindung meiner internen IIS Site mal zusätzlich zu 192.168.1.2 auf die IPv6 Adresse meines Servers gelegt und schon klappts auch im Browser und der Fehler mit dem "Selbstupdate" in der Eventlog ist auch weg.

Jetzt stellt sich mir eine Frage:
die IPv6 Adresse ist ja dynamisch zugewiesen und kann sich irgendwann mal ändern, dann stimmt die Bindung nicht mehr.
Weise ich sie fix zu? klemm ich IPv6 ganz ab (wovon ja eigentlich abgeraten wird)?

Im LAN verwende ich ja (noch) kein IPv6, aber irgendwann werde ich mich ohnehin damit auseinandersetzen müssen.

Alternative Lösung:
Eine Alternative kann wie ich oben bereits angesprochen hatte prinzipiell sein IPv6 zu deaktivieren.

Wenn man sich ein wenig umhört (z.B. (Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).) wird teilweise aber durchaus davon abgeraten.

Ich hab jetzt eine Art Mittelweg gewählt, nämlich IPv4 gegenüber IPv6 bevorzugt zu verwenden (die Standardeinstellung ist genau andersherum).
IPv6 funktioniert dann nach wie vor, bevorzugt wird jedoch eben IPv4 verwendet wenn nicht explizit IPv6 verlangt bzw. eine IPv6 Adresse verwendet wird.

Wenn ich jetzt auf meinem Server einen Ping auf "localhost" oder "Server" absetze wird die IPv4 Adresse verwendet und ich kann das Thema IPv6 erstmal wieder aufschieben.
  
Zum Seitenanfang
 
Bookmarks: Facebook Google Google+ Linked in Twitter Yahoo
 



Nutzungsbedingungen | Datenschutz
Kontakt | RSS | Feedback | Impressum
Facebook | News einsenden