SUS Server und Service Pack Deployment

 

 

a)   Installation und Konfiguration SUS Server für Patches und Hotfixes

b)  Wie kann ich in den SUS ein schon per Hand heruntergeladenes Service Pack integrieren?

c)  Wie kann ich einen SUS Server auf eine andere Hardware „umziehen“?

d)    SUS Server für nicht Domain Mitglieder

e)    Sofortige Aktualisierung, erzwingen des Updates vom SUS Server am Client

f)  Installation des SUS Servers auf einer Windows 2000/XP Professional Version

g)    Tools und Add-Ons für den SUS

 

 

Installation und Konfiguration SUS Server für Patches und Hotfixes

 

Voraussetzungen am Server, nicht Pflicht aber empfohlen:

·         PIII 700MHz, 512MB, 6GB freier Plattenplatz (lt. SUS_Deployguide_sp1.doc)

·         IIS sollte schon vorher installiert sein, damit sich der SUS direkt in die Management Konsole integriert.

·         IE5.5, besser IE6.0 sollte sowohl am Server, als auch auf den Clients installiert sein

·         Funktionierende DNS Konfiguration, Namensauflösung und Gruppenrichtlinien setze ich voraus

·         WINS ist nicht Pflicht, aber da der SUS über den NetBIOS Namen angesprochen wird (Best Praxis) ist dieser zur Unterstützung empfohlen, ansonsten setze ich eine funktionierende NetBIOS Namensauflösung voraus. Bitte beachtet, dass diese in segmentierten, physikalisch getrennten Netzwerken Probleme verursachen kann, da NetBIOS BroadCasts nicht geroutet werden

·         Der Dienst „Software Update Service Synchronisation Service“ muss auf Automatisch gestellt sein.

 

Voraussetzungen am Client, nicht Pflicht aber empfohlen:

·        Bei Windows 2000 sollte Service Pack 3 schon vorhanden sein, da dieses den SUS Client schon mitbringt und dieser somit nicht extra eingerichtet werden muss.

·        Bei Windows XP sollte das Service Pack 1 installiert sein

·        IE5.5, besser IE6.0 sollte installiert sein

·        Der Dienst „Automatische Updates“ MUSS gestartet sein und auf Startart „Automatisch“ stehen, da viele User (wenn sie die Rechte haben) diesen deaktivieren. Zum einen weil es in vielen tolle Zeitschriften empfohlen wurde, oder von so sinnlosen Tools wie XP Antispy so vorgegeben wird. Damit uns das nicht ärgert, kann dieser Dienst und seine Startart über die Gruppenrichtlinien -> Dienste wie von uns gewünscht erzwungen werden. (Siehe auch HowTo => Zentrale Vergabe lokaler Berechtigungen)

 

 

 

1.      Download und Installation des Software Update Services

” Software Update Services Deployment White Paper”
http://www.microsoft.com/windows2000/docs/SUS_Deployguide_sp1.doc

” Software Update Services Server 1.0 with Service Pack 1”
http://www.microsoft.com/downloads/details.aspx?FamilyID=a7aa96e4-6e41-4f54-972c-ae66a4e4bf6c&DisplayLang=en

Das Deployment White Paper sollte jeder einmal in aller Ruhe durchgelesen haben, da ich in dieser Anleitung nur eine Beispiel-Konfiguration biete, wie sie in den meisten Netzwerken wohl zu finden ist. Sprich: Es ist eine AD Domäne mit nur einem Standort, in diesem Standort befinden sich alle Clients, es gibt keine RAS-User, bzw. Remote-Zugriffe von Computern, die von der Verteilung wegen der großer Datenmenge ausgeschlossen werden sollten.

Das White Paper bietet Hilfe und Anleitung für Konfigurationen mit Firewalls, Proxy-Szenarien usw.

Die Installation werde ich hier nicht dokumentieren, da diese im Whitepaper zu finden ist und assistent-gesteuert abläuft. Diese ScreenShots spare ich mir. Ich werde hier nur eine Beispiel-Konfiguration hinterlegen mit Hinweisen auf gern gemachte Fehler und bekannte Stolperfallen.

Gleich die erste: Der SUS kann ca. seit dem 18.09.03 Service Packs verteilen. Allerdings nur Windows 2000 SP4, Windows XP SP1a und die Service Packs die noch für diese beiden Betriebsysteme und aktuell für den Windows Server 2003 kommen werden. Von den angebotenen Hotfixes,  Patches und Updates, die über http://v4.windowsupdate.microsoft.com/de/default.asp zu erreichen sind können aber weiterhin nur die „Wichtigen“ aber keine „Empfohlen“ und/oder “keine Treiberupdates“ mit dem SUS installiert werden. Das bleibt dann wohl für die V2.0 des SUS.

Hier der Auszug aus der SUS Homepage http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp
Software Update Services now provides Windows service packs (SPs), in addition to critical and security updates. SUS will deliver Windows XP SP1, Windows 2000 SP4, and all future service packs for Windows 2000, Windows XP, and the Windows Server™ 2003 family of products.

2.      Konfiguration des SUS Server

Nach erfolgreicher Installation kann der Server am Server selber über http://localhost/susadmin erreicht und verwaltet werden. Bei Fernwartung/~konfiguration ist localhost natürlich durch den Servernamen (NetBIOS!) zu ersetzen.

Als erstes sollten nun die Optionen ("Set Options") durchgeschaut werden und dann die Synchronisierung mit dem Windowsupdate-Server im Internet erfolgen und ein regelmäßiges Update eingerichtet werden.


Einstellung der Optionen

Die Einstellungen der Proxy-Konfiguration kann sich jeder aus dem White Paper entnehmen.

In der ersten Option finden wir den NetBIOS Namen des Servers wieder. Wenn später in der Konfiguration der Richtlinie (wuau.adm) anstelle des NetBIOS Namens der FQDN (Full Qualified Domain Name) oder die IP des SUS Servers vergeben werden soll, weil die NetBIOS Namensauflösung nicht über die vorhandenen Standorte konfiguriert ist, oder eine Firewall nur den FQDN, bzw. die IP durchlässt, dann MUSS an dieser Stelle der später in der Richtlinie verwendete Servernamen eingetragen werden!

=> Servername: Serverhostname.EureDomain.TLD, bzw.
=> Servername: xxx.yyy.zzz.xxx

Der Punkt ob alle heruntergeladenen aktualisierten Updates von ehemals schon als „approved“ (akzeptiert) gekennzeichneten Patches automatisiert werden sollte ist streitbar. Es betrifft zwar nur die aktualisierten Versionen der schon vom Admin akzeptierten Patches, aber man muss bedenken, dass in dem Moment diese automatisch ohne Test(!) an die Clients und Server verteilt werden. Letztlich sollten sie so wie die neuen Patche behandelt werden und erst nach erfolgreichem Test veröffentlicht werden.
Man kann jetzt blauäugig meinen, wenn’s ein offizieller Patch ist, dann sollte der auch funktionieren, aber leider hat die letzte Zeit gezeigt, dass MS bei einigen Patches schon Probleme eben durch die Patches verursacht hat. Man denke nur an Q329170 (langsame Abmeldung und defekte SB Profile) und war es Q813489? der den IE und den Explorer zur Schnecke degradierten?
Grundsätzlich rate ich dazu die Patches vor dem Deployment an alle Clients erst auf mehreren repräsentativen Workstations (die PC´s der Admin drängeln sich hier gerade zu auf … J ) zu testen und erst danach per „approve“ den Schalter umzulegen.

Tipp: Leider dauert der erste Download eine ganze Weile (ca. 159 Updates, ca. 300MB Stand 12.09.2003). Ärgerlicherweise fehlt die Schaltfläche „Alle auswählen“ auf der Seite "Approve Updates". Nun kann man in einer „TAB+Space Orgie“ alle Updates per Hand auswählen … was nicht so sehr Spaß bereitet. Hilfe zur Automatisierung dieses Problems gibt es bei den englischen Kollegen. Auf der Seite http://www.susserver.com von Scott Korman findet man im Bereich Tools ein VBScript, was dieses für uns erledigt. Download und Dokumentation hier: “Auto Approve New Updates on schedule for MS SUS Server“

 



Informationen und Probleme zu den aktuellen Patches lassen sich ebenfalls leicht über die Newsgroups sammeln, da dort die Anwender als erste ihre Fragen hineinposten.

Natürlich sollte man vor dem Apply auch die von Microsoft extra dafür veröffentlichten Security-Bulletins lesen und demnach handeln. Was aber nicht nur für den Fall des SUS gelten sollte. Eine gute Möglichkeit bietet hier der Newsletter von Microsoft, um über die aktuellen Risiken informiert zu werden.

Zur Anmeldung geht’s hier lang: 
“ Abonnieren des Microsoft Sicherheitsbenachrichtigungsdienstes (Microsoft Security Notification Service)“
http://www.microsoft.com/germany/ms/technetdatenbank/overview.asp?siteid=430926

zur Homepage hier:
“ Microsoft Security Bulletins - Aktuelle Sicherheitsbenachrichtigungen“
http://www.microsoft.com/germany/ms/technetservicedesk/bulletin/index.htm

Zusätzlich ist http://patch-info.de von Ottmar Freudenberger eine gute Anlaufstelle.



Nach der Synchronisation, dem Approve der Updates und der Einstellung der Optionen ist der SUS soweit eingerichtet, dass die zentrale automatische Verteilung an die Clients erfolgen kann. Dafür setzen wir die Gruppenrichtlinien und das Template wuau.adm ein.

Noch ein Tipp:

Wie kann ich in den SUS ein schon per Hand heruntergeladenes Service Pack integrieren?

 

Alle, die schon die beiden SP´s für Win2000 (SP4) und WinXP (SP1a, bzw. SP2) in der Network Installation Version heruntergeladen haben und deswegen ein wenig irritiert sind, dass schon wieder 260MB zusätzlich fällig sind, nur weil der SUS auf einmal auch ServicePacks verteilen kann, denjenigen kann geholfen werden und der doppelte Download der beiden Dateien kann erspart bleiben. So, wie folgt beschrieben hat es bei mir funktioniert. Die Dateinamen sind auch für eure Installationen gültig, da sie vom UpdateCatalog vorgegeben werden.

 

Der Weg:

·         Manueller Start der Synchronisierung, und damit Start des Downloads von Win2000 SP4.

·         Schaut in den Ordner \SUS\Content\cabs\  (der Speicherort der Patches und Fixes) dort wird jetzt eine Temporäre Datei angelegt. Name: w2ksp4_de_00d4912b4703c77c46cf53a8a8f2027.tmp

·         Abbruch der Synchronisation und manuelle Kopie des vorhandenen SP´s in dieses Verzeichnis.

·         Umbenennen der W2KSP4_DE.exe in w2ksp4_de_00d4912b4703c77c46cf53a8a8f2027.exe

·         Wieder Start der Synchronisierung und damit Start des Downloads von WinXP SP1

·         Schaut wieder in den Ordner \SUS\Content\cabs\ dort wird jetzt erneut eine Temporäre Datei angelegt. Name bei mir: XPSP1A_CB7D182645EA1019741D9D94732C29251294ACDC.tmp

·         Wieder Abbruch der Sync. und manuelle Kopie des vorhandenen SP´s in dieses Verzeichnis.

·         Umbenennen der xpsp1_de_x86.exe in XPSP1A_CB7D182645EA1019741D9D94732C29251294ACDC.exe

·         Gleiches Spiel für XPSP2: Umbenennen der Datei in xpSP2_12801880cf15f82af95f22fab02533f.exe

·         Wenn jetzt eine Synchronisation gestartet wird, sollten diese beiden Service Packs nicht mehr auf der „ToDo-Liste“ stehen, sondern nur noch auf die noch fehlenden, was bei der Erst-Synchronisation aber immer noch 300MB ausmacht.

·         Im Approve Ordner liegen jetzt die beiden ServicePacks und warten darauf ihren "Haken" zu bekommen.

·         Bei mir habe ich übrigens anstelle des W-XP-SP1a, das "alte" SP1 reinkopiert, das noch die Java-VM enthält und siehe da, es wird akzeptiert. Scheinbar werden die Signaturen der Dateien doch nicht kontrolliert und überprüft.

·         Ein weiterer Test ergabt, das es reicht eine leere Textdatei mit den beiden oben genannten Namen zu hinterlegen. Was darauf schließen lässt, dass weder die Größe, noch die Signaturen kontrolliert werden, sondern allein der Name der Datei überprüft wird.

·        Hier liegt aktuell für das XP-SP1 eine 0KB Große Textdatei herum mit dem Namen XPSP1A_CB7D182645EA1019741D9D94732C29251294ACDC.exe und der SUS meldet sie im Approve Dialog als:

·        

Trotzdem würde ich nicht mit einer leeren Textdatei dort arbeiten, sondern mit dem manuell heruntergeladenen Network Installation Service Packs, da diese dann an neu installierte Clients verteilt werden können.

Der oben beschriebene Weg funktioniert sowohl für die ServicePacks, wie auch für alle anderen Fixes und Patches.



Wie kann ich einen SUS Server auf eine andere Hardware „umziehen“?


Wenn man einen vorhandenen Server auf einen neue Plattform bringen möchte, oder schon mal alles für einen Kunden vorbereiten möchte, so ist es etwas einfacher als beim Service Pack, da die nötigen Dateien schon alle bereitliegen mit dem jeweils richtigen Namen. Die Umbenennung wie beim händischen „reinflicken“ des SP´s entfällt somit.

 

·         SUS auf dem neuen Server installieren

·         Synchronisation einmalig anstoßen und bei Beginn des ersten Downloads (nach dem Windows Catalog) den Vorgang abbrechen

·         Dann den kompletten \Content\Cabs Ordner des laufenden SUS rüberkopieren

·         Die Synchronisation erneut anstoßen.

·         „Approve“ der Updates am Einfachsten mit dem schon oben genannten Script
“Auto Approve New Updates on schedule for MS SUS Server“


Wesentlich einfacher wäre es natürlich den eigenen vorhandenen SUS in den SET OPTIONS einzutragen und eine Synchronisation im LAN, was auch in größeren Netzwerk-Umgebungen der normale Weg wäre. Ein SUS Server gleicht sich mit dem Windows-Update Server über das Internet ab, alle anderen synchronisieren sich dann mit diesem und der Vorteil ist, daß der Approved Status mit übernommen wird.

Gleichzeitig mit der Bastelanleitung für den "Umzug" hat man auch damit eine Form gefunden, ein funktionielles Backup des SUS Servers zu erstellen. Wobei es kein "Desaster Recovery" ist, aber zumindest spart es den erneuten Download aller Patche und ServicePacks. Denn der SUS ist schnell neuinstalliert und der Conten\cabs Ordner kann von einer DVD wieder eingelesen werden. Oder von mittlerweile mindestens 2 CDs ;-)



3.      Konfiguration der Clients über Gruppenrichtlinien und dem WUAU.ADM Template

Zusätzliche Voraussetzungen, bzw. Best Praxis und einige Erklärungen für die Clients:
Alle Client Computer werden in einer eigenen OU verwaltet für die der SUS Server eingerichtet wird, damit wieder eine klare Trennung von DefDomPol und Computer-Richtlinie erfolgen kann.

Die wuau.adm aus %systemroot%\inf wird nach Installation des neusten Service Packs am Server erneut in die Administrativen Vorlagen importiert, damit gewährleistet ist, dass die aktuellste Version zum Einsatz kommt (aktuell 26.03.2003, bzw. 19.06.2003).

Bei den Benutzern gehe ich in diesem Beispiel davon aus, dass keine Lokalen Administratoren zum Einsatz kommen und somit die Updates ohne Benutzereingriff erfolgen, bzw. direkt ohne Nachfrage auf den Client per „Push-Installation“ zugewiesen werden müssen.



Erst nach dem die wuau.adm importiert ist erhält man unter:
Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten den Ordner \Windows Update und darin die zu konfigurierenden Richtlinien




“Automatische Updates konfigurieren“
Die hier gewählte Einstellung dient der grundsätzlichen Aktivierung der SUS Client Funktion und die Updates sind so konfiguriert, dass sie täglich um 8:00 Automatisch heruntergeladen werden und eben laut diesem Zeitplan installiert werden.
Wenn die Updates automatisch per Scheduler zugewiesen werden sollen, ist die Option „4“ die einzig zulässige Auswahl.

Es stehen noch zur Verfügung:
"2 - Vor Download und Installation benachrichtigen"

"3 - Autom. Downloaden, aber vor Installation benachrichtigen"

"4 - Autom. Downloaden und laut Zeitplan installieren"

Die Optionen 2 und 3 funktionieren nur zuverlässig, wenn die Benutzer über lokale Administratoren Rechte verfügt, da er nur benachrichtigt wird, dass Updates vorliegen, er sie aber in seinem Benutzerkontext bestätigen und installieren muss, ansonsten würde nur das WindowsUpdate Zeichen im Systray erscheinen, aber die Installation würde an den fehlenden Berechtigungen eines Benutzers scheitern.

Hinweis:
Selbst mit konfigurierter Option "4" erhält ein Benutzer mit lokalen Administratoren Berechtigung den Hinweis, daß Updates zur Verfügung stehen (Hinweis, WindowsUpdate Logo im Systray) er hat aber nur die Möglichkeit, die Installation direkt zu starten oder auf später zu verschieben.
Wenn man möchte, daß die Updates auch bei lokalen Administratoren ohne Nachfrage installiert werden, da man die User nur aus Kompatibilitätsgründen zu solchen gemacht hat, aber nicht, weil sie wirklich wissen was sie zu tun haben, der hat die Chance, den Hinweis im Systray per Richtlinie zu unterdrücken:

Benutzerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Windows Update
"Zugriff auf alle Windows Update-Funktionen entfernen"





“Interner Pfad für den Microsoft Updatedienste angeben“
Der hier verwendete Name MUSS dem Servernamen aus den „Set Options“ der SUS Server Konfiguration entsprechen.

“Geplante Installationen automatischer Updates erneut planen“
Wird diese Richtlinie aktiviert, so wird eine Installation, die zuvor nicht stattgefunden hat, nach der Anzahl der angegebenen Minuten nach dem nächsten Neustart des Computers ausgeführt.



“Kein automatischer Neustart für geplante Installationen automatischer Updates“
Die „Wunschrichtlinie“ aller Administratoren, die den SUS in seiner ersten Version getestet haben.
Das Problem ist, dass einige Updates einen Neustart des Systems erfordern. Wenn jetzt ein Benutzer während seiner normalen Arbeit in Word, Excel oder einer Faktura das Update zugewiesen bekommt, dann wird das System, ohne Aktivierung dieser Richtlinie, rücksichtslos den Computer neu starten, ohne dem Benutzer die Chance zu lassen, den Shutdown zu unterbrechen, um die Daten zu speichern. Ihm wird einfach der Boden unter den Füssen weggezogen. Was in bestimmten Situationen überhaupt nicht lustig ist und zu teuren Datenverlust führen kann, wenn die Arbeit eines ganzen Vormittages einer Person (man denke mal an Technische Zeichnungen, Konstruktionen usw.) so über den Jordan geht.


“Computerkonfiguration\Windows-Einstellungen\Systemdienste“
hier sollte jetzt als letztes noch dafür gesorgt werden, dass der Dienst „Automatische Updates“ auch wirklich an jedem Client auf „Automatisch“ steht und somit die Richtlinie über zu Anwendung kommen kann, denn ansonsten würde der Client zwar die nötigen Registry Einträge der Richtlinie erhalten, aber sie wären im total egal, da der Dienst, der sie überhaupt erst ausliest und anwendet nicht vorhanden ist.



!!! ACHTUNG !!!

Wer die Berechtigungen am Dienst Automatische Updates konfiguriert hat, der kann ein Problem mit Windows XP SP2 bekommen.

Bis zum SP2 werden die Berechtigungen per Default auf „Adminstratoren – Voll“ und „System – Vollzugriff“ eingestellt. (Wenn man diese aktiviert) Ab SP2 ist es aber nicht mehr der „SYSTEM-Account“ unter dem der Dienst gestartet wird, sondern das Konto „DIENST“. Also bitte darauf achten diesen Account in den Berechtigungen einzutragen.

 

So, ab jetzt, nach Konfiguration der Richtlinie und der Konfiguration des SUS Server können wir uns entspannt zurücklehnen und den morgigen Tag abwarten. Leider gibt es keine Möglichkeit den SUS-Client zum Download der vorhandenen Updates per Knopfdruck zu zwingen. Wir müssen also den Scheduler Plan abwarten und dann schauen, was passiert oder müssen einen etwas größeren Umweg gehen, wie ich auch weiter unten beschrieben habe.




Wie kriege ich Rechner die nicht zur Domäne gehören, aber physikalischen Kontakt zum internen SUS Server haben dazu sich die Updates von diesem herunterzuladen?

 

Folgende Problematik:

Clients die der Domäne nicht angehören sind natürlich auch nicht von der Richtlinie betroffen und laden aus diesem Grund per Default Konfiguration die Updates erst mal aus dem Internet herunter, was für unnötigen zusätzlichen Traffic sorgt.

 

2 Lösungsansätze:

·         Man stellt die nötigen Registry-Einträge per Hand, Pfade und Valuenames sind leicht aus der wuau.adm zu entnehmen und wie diese zu lesen ist, solltet ihr euch hier schon längst angeschaut haben … J .. oder verwendet lokal am Rechner gpedit.msc um die SUSClient Einstellungen über die GUI zu konfigurieren. Der Trick der jetzt noch benötigt wird damit es auch klappt ist, dass der SUS Server noch in die %systemroot%\system32\drivers\etc\LMHOSTS eingetragen werden muss, damit der Server identifiziert werden kann.

·         Die 2te Alternative führt über die Commandline und einen 3rd Party Produkt, dem „SUS Utility“ von Nextwish, leider zur Zeit nicht erreichbar, deswegen hier abgelegt http://www.gruppenrichtlinien.de/Tools/nwsusutil.zip

 

 

 

Sofortige Aktualisierung, Erzwingen des Updates vom SUS Server am Client
Quelle (leicht umformuliert): Andreas Steffens, http://groups.google.com/groups?selm=055201c37b56$c321c500$a301280a@phx.gbl

 

·         Über die Gruppenrichtlinien oder die oder lokale Sicherheitsrichtlinie per gpedit.msc die wuau.adm hinzufügen und wie oben beschrieben konfigurieren. Bei der Konfiguration über gpedit.msc an einer Standalone Maschine werden die Registry Einträge sofort übernommen. Bei einem Domänen-Mitglied muss der Rechner neugestartet werden oder die Computerrichtlinie per secedit (W2K) oder gpupdate (XP) aktualisiert werden.

·         Nach Anwendung/Übernahme der Richtlinie am Client den ersten Punkt der Policies „Automatische Updates konfigurieren“ wieder auf „Nicht konfiguriert“ setzen und diese Einstellung wie oben beschrieben erneut übergeben. Dadurch wird der Automatische Update Client deaktiviert, aber die Einträge zur Verwendung des SUS-Servers bleiben erhalten. Nun sollte auch das lokale Updatetool in der Systemsteuerung „Automatische Updates“ verfügbar sein (ist vorher durch die Konfiguration der Richtlinie ausgegraut gewesen).

·         Um eine sofortige Aktualisierungsanfrage zu starten muss folgender Key gelöscht werden:

HKEY_LOKAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\WINDOWSUPDATE\AUTO UPDATE\
“LastWaitTimeout“.

·         Das lokale Updatetool mit der Option 2 einstellen und übernehmen.

·         Den Dienst „Automatische Updates“ beenden und starten. Nun wird innerhalb von zwei Minuten eine Updateanfrage erfolgen. … wenn alles Andere stimmt J

·         Diese stark nach Umweg riechende Anleitung ist unbedingt nötig, da  das lokale Update-Tool ansonsten den Internetpfad zum Windows-Update nutzt und nicht den von uns gewünschten hausinternen SUS Server, denn durch unsere Manipulation bleibt dieser für den Client eingetragen.

 

Wenn man mehrere Dinge testen möchte, sollte man nach der Anzeige von verfügbaren Updates dass lokale Tool wieder deaktivieren und den Windowsupdate-Ordner-Inhalt löschen. Zu weiteren Tests brauch nur das lokale Tool wieder aktiviert werden. Ein Neustart des Dienstes ist nicht erforderlich. Diese Prozedur eignet sich besonders für die Fehlersuche, wenn Jemand zwar die Anzeige für vorhandene Updates bekommt, aber anschließend nach der Downloadwahl niemals eine Installation erfolgt oder angeboten wird.

 

 

 

Installation des SUS Servers auf einer Windows 2000/XP Professional Version

Anlehnnung an den c´t Artikel aus 21/2003, Seite 118 ff

 

wenn man das SUSSetup.msi auf einer Workstation aufruft, wird die Installation mit einer Fehlermeldung abbrechen: "You must be running Windows Server 2003 or 2000 ..."

Microsoft hat das MSI Paket so geschnürt, daß es bei der Installation zum einen die vorhandene Internet Explorer Version überprüft, ein vorhandener Internet Dienst gesucht wird und es wird eben auch das aktuelle Betriebsystem ausgewertet. Da es aus MS Sicht kaum einen Sinn macht einen SUS Server ohne "Server" zu verwenden ist diese Sperre wohl eingebaut.


Aber, es gibt doch noch einige kleine Peer-To-Peer Netzwerke die mit einer Professional Version als "Server" aufgebaut sind.

Mein Hauptargument für einen SUS Server auf einer Workstation ist aber ein anderer: Wer wie ich mit einem Notebook ausgestattet ist und viel bei Kunden unterwegs ist, der hätte schon des Öfteren gerne seinen SUS Server dabei, um die Clients zu aktualisieren oder einen neuinstallierten SUS Server mit den \content\cab Dateien zu versorgen. Einen Weg habe ich ja oben beschrieben, aber nicht jeder hat die Möglichkeit einen Server auf dem Notebook zu installieren und arbeitet deswegen mit einer Professional Version.


Die Frage nach der Legalität möchte ich hier nicht weiter erörtern, aber ich weise extra darauf hin, daß jeder selber wissen muss, was er tut.

 

 

 

Tools und Add-Ons für den SUS 

 

·         Sofortige Aktualisierung des SUS erzwingen => Nextwish, leider zur Zeit nicht erreichbar, deswegen hier abgelegt http://www.gruppenrichtlinien.de/Tools/nwsusutil.zip
Das habe ich im oberen Teil ja schon vorgestellt.

·    Da die Seite von Midthought nicht immer erreichbar ist und man für die eigene Umgebung noch ein paar kleine Änderungen vornehmen muss habe ich mal eine angepasste Variante für den IIS6 (Server 2003) hinterlegt. Die Datei könnt ihr direkt im \inetpub\wwwroot\ entpacken. Es wird ein Ordner \Images erstellt in dem die 4 GIF Dateien (dir_misc.gif, minus_icon.gif, plus_icon.gif, rightgrey.gif) hinterlegt werden. Die vorhandene toc.inc unter \Inetpub\wwwroot\autoupdate\administration\shared\inc wird ersetzt. Die beiden ASP Seiten (kaos_date.asp, SUSLogViewer.asp) landen im \wwwroot.
Der Pfad zu den IIS Log Dateien verweist auf "C:\WINDOWS\system32\LogFiles\W3SVC1\"

Download Link für Windows 2003, %systemroot% = c:\windows
http://www.gruppenrichtlinien.de/tools/suslogviewer_iis6.zip 

Download Link für Windows 2000, %systemroot% = c:\winnt
http://www.gruppenrichtlinien.de/tools/suslogviewer_iis5.zip 


Noch ein Tip an dieser Stelle: Der Unterschied in den beiden Zip Dateien ist nur die Anpassung der suslogviewer.asp in Zeile 71.

----- cut: suslogviewer.asp -----

'***********************************************
'************* Path to Log file ****************
'***** Change to your path on the server *******
'***********************************************
strPath = "C:\WINDOWS\system32\LogFiles\W3SVC1\"

----- cut: suslogviewer.asp -----
 

·    Im "Client Status Monitor" finden sich die Rechner, die den SUS kontaktiert haben mit ihrer IP  wieder. Der SUSLogViewer wertet nur die Protokolldateien vom IIS in einer optisch ansprechenden Form aus. Wenn man anstelle der IPs, die Rechnernamen in den Protokollen eingetragen haben möchte, dann muss der DNS Lookup am IIS konfiguriert werden. "HOW TO: Enable Reverse DNS Lookup for IIS"

Die Konfiguration erfolgt über die Kommandozeile, Aufruf der adsutil.vbs im AdminScripts-Ordner
[Pfad]\Inetpub\Adminscripts\adsutil set w3svc/EnableReverseDNS TRUE

 

 

(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright