Hi,
ich habe nun zum ersten mal einen Win Updateserver aufgesetzt. Er dient dazu Systeme bevor sie zum Kunden gehen Einmahlig mit Updates zu versorgen. Um dies zu ereichen nutze ich das Tool nwsusutil2 mit diesem Parameter servername:80. Die erste Rutsche Updates bekommt der Client auch ohne Probleme. Wenn ich das Tool jetzt nach einem Neustart nochmals mit identischen Parametern aufrufe, findet der Client keine Updates mehr. Ich meine er Sucht sogar noch nicht einmal danach, weil weder Netzwerk- bzw. Festplatten aktivitaet da ist.
Ich habe dann auch noch mal das Tool Connect2WSUSSE in der INI-File Variante getestet. Eingestellt habe ich das ganze so:
WSUS: http://servername:80
WSUSReport : http://servername:80
Gruppe: XYZ

Die Gruppe XYZ habe ich auf dem Updateserver in der WSUS Verwaltungsoberflaeche erstellt und alle Updates fuer diese Gruppe frei gegeben. Klicke ich jetzt auf Start kommt diese Fehlermeldung:

Fehler 70 - SourcefrmMain.cmdStart_Click(); WSUS Permission denied

Also dieses Sourcefrm... ist denke ich mal einfach die Funktion des Programms die aufgerufen wird, um das Update anzustossen. Und dann halt dass er keine Zugriffsrechte hat. Aber was muss ich Einstellen damit er Rechte erhaelt?
Zur Info: Der Updateserver haengt am Firmen Netz. In diesem existiert auch eine Domain. Aber UpdateServer so wie Clients sind nicht in diese Eingebunden. Client wie auch Updateserver erhalten ihre IP dynamisch.

Vielen Dank und Gruss
Nico

nico schrieb am 05.12.07 um 09:03:34:

Parameter servername:80.

Wenn Du den Standardport 80 verwendest, brauchst Du ihn nicht mehr anzugeben. Das Protokoll HTTP läuft auf Port 80. Wir der WSUS auf Port 8530 installiert, dann mußt Du das angeben: http://meinwsus:8530



nico schrieb am 05.12.07 um 09:03:34:

Die erste Rutsche Updates bekommt der Client auch ohne Probleme. Wenn ich das Tool jetzt nach einem Neustart nochmals mit identischen Parametern aufrufe, findet der Client keine Updates mehr. Ich meine er Sucht sogar noch nicht einmal danach, weil weder Netzwerk- bzw. Festplatten aktivitaet da ist.

Führe auf dem Client ein wuauclt /resetauthorization /detectnow und anschließend ein paar mal ein wuauclt /detectnow aus. Kontrolliere jetzt mit NETSTAT ob eine HTTP Verbindung zum WSUS besteht. Wenn nicht, poste den relevanten Teil aus der WindowsUpdate.log.


nico schrieb am 05.12.07 um 09:03:34:

Ich habe dann auch noch mal das Tool Connect2WSUSSE in der INI-File Variante getestet. Eingestellt habe ich das ganze so: WSUS: http://servername:80 WSUSReport : http://servername:80 Gruppe: XYZ

Laß das :80 weg, völlig überflüssig.



nico schrieb am 05.12.07 um 09:03:34:

Die Gruppe XYZ habe ich auf dem Updateserver in der WSUS Verwaltungsoberflaeche erstellt und alle Updates fuer diese Gruppe frei gegeben. Klicke ich jetzt auf Start kommt diese Fehlermeldung: Fehler 70 - SourcefrmMain.cmdStart_Click(); WSUS Permission denied

Du hast das Tool gleich nach dem anmelden gestartet, richtig? Warte mal ein oder zwei Minuten, probiers dann nochmal. Jetzt muß es gehen.

Ist das ein VISTA Client? Wenn ja, dann mußt Du Connect2WSUS mit Rechtsklick > Ausführen als starten.



nico schrieb am 05.12.07 um 09:03:34:

Also dieses Sourcefrm...

Sollte eigentlich Source frmMain.cmdStart heißen. Mit Leerzeichen zwischen Source + frmMain.


nico schrieb am 05.12.07 um 09:03:34:

ist denke ich mal einfach die Funktion des Programms die aufgerufen wird, um das Update anzustossen. Und dann halt dass er keine Zugriffsrechte hat. Aber was muss ich Einstellen damit er Rechte erhaelt?

Du bist als Admin auf dem Client angemeldet?


nico schrieb am 05.12.07 um 09:03:34:

Zur Info: Der Updateserver haengt am Firmen Netz. In diesem existiert auch eine Domain. Aber UpdateServer so wie Clients sind nicht in diese Eingebunden. Client wie auch Updateserver erhalten ihre IP dynamisch.

Schlecht ist, das der WSUS eine dynamische IP bekommt, vergib ihm eine feste IP, alles andere ist Mift.

Hi,
vielen Dank. Ich denke mal das wuauclt /resetauthorization /detectnow war es was geholfen hat. Sicher kann ich dass erst sagen wenn ich ein paar Tests mit unterschiedlichen Clients gemacht habe.

Gruss
Nico

OK, Hauptsache es läuft jetzt. ;)

Die anderen/restlichen Fragen magst/kannst Du nicht beantworten?

So,
sorrt fuer meine spaete antwort. war im urlaub :-)
also die fehlenden antworten:

Zitat:

Du hast das Tool gleich nach dem anmelden gestartet, richtig? Warte mal ein oder zwei Minuten, probiers dann nochmal. Jetzt muß es gehen. Ist das ein VISTA Client? Wenn ja, dann mußt Du Connect2WSUS mit Rechtsklick > Ausführen als starten.

Habe kurz nach dem anmelden gestartet. geht wenn ich laenger warte besser. ist aber kein vista client.


Zitat:

Du bist als Admin auf dem Client angemeldet?

Jop :-)


Zitat:

Schlecht ist, das der WSUS eine dynamische IP bekommt, vergib ihm eine feste IP, alles andere ist Mift.

Er bekommt bald eine. aber erstmal muss es ohne gehen.

So, nun ja das Problem hatte sich, so dachte ich jedenfalls, erledigt. jetzt habe ich hier aber wieder einen winXP64 Client der keine Updates bekommt. der client meldet sich aber auf dem updateserver an, der sagt halt nur das der client noch keinen status reported hat.
ich habe mir inzwischen ein batchfile gebastelt:

Code (]
@echo off
cls
ECHO Stoppe Automatic Update Service
Net Stop wuauserv
ECHO OK
ECHO Setze Registry Werte
addWSUS.REG
ECHO OK
ECHO Starte Automatic Update Service
ECHO OK
Net Start wuauserv
ECHO Erzwinge Updatesuche
wuauclt /resetauthorization /detectnow
wuauclt /detectnow
wuauclt /detectnow
wuauclt /detectnow
pause
[/code):

in der addWSUS.reg steht folgendes: [code] Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "WUServer"="http://orca" "WUStatusServer"="http://orca" "TargetGroupEnabled"=dword:00000001 "TargetGroup"="TEST" "ElevateNonAdmins"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:0000000a "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "AutoInstallMinorUpdates"=dword:00000001 "RebootRelaunchTimeoutEnabled"=dword:00000001 "RebootRelaunchTimeout"=dword:0000003c "RescheduleWaitTimeEnabled"=dword:00000001 "RescheduleWaitTime"=dword:0000000f "DetectionFrequencyEnabled"=dword:00000001 "RebootWarningTimeoutEnabled"=dword:00000001 "RebootWarningTimeout"=dword:0000001e "UseWUServer"=dword:00000001 "NoAUShutdownOption"=dword:00000000 "NoAUAsDefaultShutdownOption"=dword:00000000

Gruss und vielen Dank
Nico

nico schrieb am 14.12.07 um 11:10:28:

Habe kurz nach dem anmelden gestartet. geht wenn ich laenger warte besser. ist aber kein vista client.

OK. Zum Zeitpunkt der Anmeldung sind bei XP viele Dienste noch nicht gestartet, bzw. werden grade gestartet. Es wird einfach nur möglichst schnell der Desktop angezeigt.


nico schrieb am 14.12.07 um 11:10:28:

Er bekommt bald eine. aber erstmal muss es ohne gehen.

Dann mach wenigstens eine DHCP-Reservierung. Und kontrolliere im DNS, ob auch alles korrekt eingetragen ist. Reverse Lookup Zone nicht vergessen.



nico schrieb am 14.12.07 um 11:10:28:

So, nun ja das Problem hatte sich, so dachte ich jedenfalls, erledigt. jetzt habe ich hier aber wieder einen winXP64 Client der keine Updates bekommt. der client meldet sich aber auf dem updateserver an, der sagt halt nur das der client noch keinen status reported hat.

Was sagt die WindowsUpdate.log auf dem Client?


nico schrieb am 14.12.07 um 11:10:28:

ich habe mir inzwischen ein batchfile gebastelt: [code] @echo off cls ECHO Stoppe Automatic Update Service Net Stop wuauserv ECHO OK ECHO Setze Registry Werte addWSUS.REG

Wird die REG-Datei überhaupt importiert?


nico schrieb am 14.12.07 um 11:10:28:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "WUServer"="http://orca" "WUStatusServer"="http://orca" "TargetGroupEnabled"=dword:00000001 "TargetGroup"="TEST" "ElevateNonAdmins"=dword:00000000

Steht auch anschließend so in der Registry drin? Löst der Client den Namen vom WSUS korrekt auf?