Tales from the Script
November 2004
Alle auf Deutsch verfügbaren "Tales from the Script"-Kolumnen finden Sie hier.
Das Windows XP Service Pack 2 hat meine Computer verschwinden lassen
Menschen sind von Dingen, die verschwinden, fasziniert. Wer von uns ist beispielsweise nicht begeistert, wenn ein Zauberer auf der Bühne einen Freiwilligen aus dem Publikum verschwinden lässt? Amelia Earhart war zum Beispiel die erste Frau, die den Atlantik überflogen hat. Ist sie aber damit berühmt geworden? Natürlich nicht - sie wurde erst berühmt, als Sie spurlos verschwand. Egal ob es sich um das Bermuda-Dreieck oder den Hamster, den Sie als Kind hatten, handelt (den Hamster, über den Ihre Mutter gesagt hat, er wäre irgendwie aus seinem verschlossenen Käfig ausgebrochen) - Menschen sind weit mehr an Dingen interessiert, die nicht da sind als an vorhandenen Dingen.
Anmerkung: Wissen Sie, je länger wir darüber nachdenken, desto mehr sind wir davon überzeugt, dass sich der Hamster nicht aus seinem Käfig herausgewunden hat. Vielleicht sollten Sie einmal Ihre Mutter anrufen… |
Natürlich ist es nicht immer so nett, wenn Dinge verschwinden (bei unserem Bankkonto wären wir zum Beispiel nicht so begeistert). Wenn Sie beispielsweise Windows XP Service Pack 2 (SP2) auf Ihren Computern installiert haben, erhielten Sie beim ersten Versuch, einen dieser Computer remote zu verwalten, nur diese Fehlermeldung:
Um Himmels Willen! Hat Windows XP SP2 Ihre Computer verschwinden lassen? Hat Windows XP Ihre gesamte IT-Infrastruktur in Luft aufgelöst? Ist es ein Zufall, dass Amelia Earhart seit der Veröffentlichung des SP2 nicht mehr gesehen wurde?!?
Entspannen Sie sich - alles ist in Ordnung und Ihre Computer sind noch immer da (wenn Sie uns nicht glauben, machen Sie doch einen Gang durch die Firma und schauen nach). SP2 hat Ihre Computer nicht in Luft aufgelöst. (Velleicht wäre es ganz praktisch, wenn das mit einigen Ihrer Benutzer möglich wäre? Leider kann SP2 das aber auch nicht.)
In Wahrheit hat SP2 überhaupt nichts mit Ihren Computern angestellt. Tatsächlich soll es Ihre Computer sogar schützen. Die Windows Firewall verhindert jedoch, dass Sie irgendetwas anderes als Gruppenrichtlinien zur Administration Ihrer Computer nutzen. Sie ist unter SP2 nicht nur standardmäßig aktiviert, sondern außerdem auch mit den denkbar sichersten Einstellungen konfiguriert. Darum können Sie Ihre Computer nicht mehr remote verwalten. Die Computer sind zwar noch da, aber die Windows Firewall lässt nichts mehr an sie ran - inklusive Scripte, Kommandozeilentools und andere Verwaltungsanwendungen, die Sie möglicherweise verwenden.
Diesen Monat geben wir Ihnen ein paar Tipps zu unterschiedlichen Wegen, die Firewall-Einstellung von SP2 vor dessen Installation festzulegen - auf diese Art bleiben Ihre Computer auch nach der Installation noch verwaltbar. Wenn Sie SP2 bereits installiert haben, können Sie trotzdem ganz locker bleiben; wir zeigen Ihnen, welche Änderungen Sie vornehmen müssen.
Was genau ist die Windows Firewall?
Die Windows Firewall ist ein neues Feature für Windows XP (sie ist nicht das gleiche wie die Internetverbindungsfirewall, die ursprünglich mit Windows XP zur Verfügung gestellt wurde). Die Windows Firewall soll Ihren Computer vor allen Arten von Angriffen schützen. Dies erreicht sie auf recht einfache Weise: Sie verwirft automatisch den gesamten unverlangt eingehenden Netzwerkverkehr. Das ist der Grund dafür, dass Ihre Scripte nicht mehr funktionieren - der Remotecomputer hat die Scripte ja nicht angefordert. Daher wird der entsprechende Netzwerkverkehr einfach verworfen. Ja, wir wissen, dass Sie lokaler Administrator auf dem Remoterechner sind. Das spielt keine Rolle. Die Firewall prüft nicht, wer den Netzwerkverkehr sendet - sie verwirft ihn einfach. Punkt.
Standardmäßig gibt es keine Ausnahmen von dieser Regel. Ihre Scripte kommen ebenso wenig "durch" wie Kommandozeilentools, MMC-Snap-Ins oder irgendetwas anderes. Das einzige, was Sie standardmäßig zur Verwaltung von Remotecomputern nutzten können, ist eine Gruppenrichtlinie. Das liegt daran, dass Gruppenrichtlinien nicht als unverlangt eingehender Netzwerkverkehr behandelt werden - sie werden beim Start des Computers oder beim Anmelden des Benutzers über Active Directory abgerufen. Somit sind sie angeforderter Netzwerkverkehr und werden von der Firewall durchgelassen.
Anmerkung: Das gleiche gilt für An- und Abmeldescripte bzw. für Scripte für den Start und das Herunterfahren des Computers. Da diese Scripte über Gruppenrichtlinien zugewiesen und in deren Kontext ausgeführt werden, werden sie von der Firewall nicht verworfen. Anders sieht es bei Scripten aus, die Sie von Ihrer eigenen Arbeitsstation starten - diese Scripte werden zurückgewiesen. Der umgekehrte Weg ist allerdings jederzeit möglich. Sagen wir, Sie haben SP2 auf einem Computer installiert und möchten auf diesem Computer nun ein Script starten, das sich mit einem Remotecomputer verbindet (einem Remotecomputer, auf dem kein SP2 ausgeführt wird). Dieser Vorgang sollte kein Problem sein (bis auf ein paar Ausnahmen) - die Firewall schränkt den ausgehenden Netzwerkverkehr nicht ein. |
Jetzt denken Sie vielleicht "Ok, das mag die Standardeinstellung sein - aber ich kann ohnehin keine Standardeinstellungen leiden". Na gut, dann lassen Sie uns darüber reden, wie Sie diese Standardeinstellungen ändern können.
Wie bekommen Sie ihre Computer zurück?
Da dies eine Scripting-Kolumne ist (ja, wir wissen, dass das manchmal schwer zu glauben ist), kümmern wir uns hauptsächlich darum, unsere Computer unter SP2 wieder remote über Scripte verwalten zu können. Wenn man bedenkt, wie effektiv die Firewall den eingehenden Netzwerkverkehr abfertigt, dann klingt das erstmal nach einer Menge Arbeit.
Aber - glauben Sie es oder nicht - die Kontrolle über die Computer zurück zu erlangen (oder zumindest sie wieder verwaltbar zu machen), ist überraschend einfach. Alles, was Sie tun müssen, ist die Einstellung Remoteadministration der Firewall zu aktivieren. Damit sind Ihre Scripte, Kommandozeilentools, MMC-Snap-Ins usw. wieder im Spiel. Statt die Einstellung direkt zu ändern, haben Sie allerdings noch eine Menge anderer Möglichkeiten: Sie können eine Gruppenrichtlinie, die Registrierung, Netsh.exe oder ein Script dazu verwenden. Um genau zu sein, ist das Problem nicht so sehr die Art wie Sie die Remoteadministration aktivieren, sondern dass Sie sie aktivieren - und zwar aus zwei Gründen:
| • | Wenn Sie SP2 installieren und sich dann dazu entscheiden, die Remoteadministration zu aktivieren, dann können Sie dies nicht über ein Script oder über ein Kommandozeilentool durchführen. Stattdessen müssen Sie eine Gruppenrichtlinie verwenden (oder Sie gehen zu jedem Computer und aktivieren die Remoteadministration per Hand). |
| • | Wenn Sie sich dazu entscheiden die Einstellung auf jedem Computer einzeln zu aktivieren, dann sollten Sie nicht auf die Hilfe Ihrer Benutzer hoffen. Um die Firewall-Einstellungen zu ändern, müssen Sie lokale Administratorrechte besitzen (Firewall-Einstellungen gelten für den gesamten Computer. Sie können keine Einstellungen vornehmen, die für Benutzer A gelten, aber für Benutzer B nicht). Wenn Ihre Benutzer also keine lokalen Administratoren sind, sind Ihre Möglichkeiten gerade deutlich weniger geworden. Sie können zum Beispiel nicht einfach ein entsprechendes Script schreiben und dieses an die Benutzer schicken. Wenn die Benutzer keine Administratoren sind, schlägt das Script fehl. |
Wir sehen uns die verbleibenden Möglichkeiten gleich näher an. Da es sich hier aber ja um eine Scripting-Kolumne handelt, lassen Sie uns einen kleinen Umweg nehmen. Sprechen wir darüber, wie Sie die Windows Firewall über Scripte bearbeiten können.
Die Windows Firewall und Scripting
Die Windows Firewall hat ein ziemlich gutes Scripting-Modell. Dieses Modell hat jedoch einen entscheidenden Nachteil: Das Firewall-Objekt (HNetCfg.FwMgr) kann nicht remote erstellt werden. Mit anderen Worten: Nehmen wir an, Sie sitzen vor Computer A und möchten auf Remotecomputer B eine Instanz des Firewall-Objekts erstellen. Wahrscheinlich würden Sie eine Scriptzeile wie die folgende verwenden:
Set objFirewall = CreateObject("HNetCfg.FwMgr", "Computer-B")
Rein technisch ist das genau der richtige Weg, um ein Objekt auf einem Remotecomputer zu erstellen. Leider erhalten Sie bei diesem Script die folgende Fehlermeldung:
Warum? Ganz einfach: Sie können auf einem Remotecomputer keine Instanz des Firewall-Objekts erstellen. Punkt.
Laut dem für die Firewall verantwortlichen Produktteam wurde dies so festgelegt, um die Sicherheit zu verbessern. Per Definition ist alles, was remote erstellt werden kann, nicht so sicher wie etwas, das nur lokal ausgeführt werden kann. Und da die Firewall entwickelt wurde, um Ihren Computer sicherer zu machen, schließt dies die Remote-Erstellung von Firewall-Objekten nun mal aus.
Ist das ein Problem? Um ehrlich zu sein - ja. Schließlich sind Sie es gewohnt, an Ihrer Administrator-Arbeitsstation zu sitzen und WMI-Scripte auszuführen, die eine Verbindung mit einem Remotecomputer aufbauen und die gewünschten Informationen zurückgeben. Mit der Firewall funktioniert das nicht. Firewall-Scripte müssen lokal ausgeführt werden. Also: Ja, es ist es Problem. Glücklicherweise gibt es ein paar Wege, um das Problem zu umgehen (auch wenn einer von ihnen - die Verwendung der WMI-Klasse Win32_Process - nur nach Aktivierung der Remoteadministration funktioniert).
Ein Weg, das Problem zu umgehen, ist die Verwendung von Start- oder Herunterfahren-Scripten für den Computer (wir hatten es erwähnt: Gruppenrichtlinien werden von der Firewall nicht verworfen).
"Warum keine Anmelde- bzw. Abmelde-Scripte verwenden?", fragen Sie? Erinnern Sie sich: Sie müssen zur Konfiguration der Firewall über lokale Administratorrechte verfügen. Wenn Ihre Benutzer keine lokalen Administratoren sind, funktioniert dieser Weg also nicht - die Scripte werden nämlich im Sicherheitskontext des Benutzers ausgeführt, der sich an- oder abmeldet. Start- und Herunterfahren-Scripte werden im Gegensatz dazu unter dem Sicherheitskontext des Systemkontos ausgeführt. Dieses Konto verfügt natürlich über das Recht, die Firewall zu konfigurieren.
Wenn Sie Start- und Herunterfahren-Scripte nutzen, sollten Sie bedenken, dass diese Scripte lokal auf dem jeweiligen Computer ausgeführt werden. Das ist zum Beispiel dann wichtig, wenn Sie Wscript.Echo für Ausgaben nutzen. Unten sehen Sie beispielsweise ein Script, das anzeigt, ob die Windows Firewall aktiviert oder deaktiviert ist. Es erstellt ein Firewall-Objekt und gibt über die Firewallrichtlinie den Wert der Eigenschaft FirewallEnabled aus:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Wscript.Echo "Firewall aktiviert: " & objPolicy.FirewallEnabled
Wenn Sie das Script auf Ihrem Computer ausführen, ist das auch kein Problem. Wenn Sie das Script als Starten- oder Herunterfahren-Script einsetzen, wird es aber auf dem entsprechenden Computer ausgeführt. Somit werden in diesem Fall auch alle Ausgaben auf diesem Computer angezeigt - Sie werden die Ausgaben also niemals zu Gesicht bekommen.
Wie können wir dieses Problem umgehen? Kein Thema - das ist einfach. Statt Wscript.Echo zur Ausgabe von Informationen zu verwenden, nutzen Sie das FileSystemObject und schreiben die Daten in eine Textdatei. Das folgende Script macht genau das - es sammelt Informationen zur grundlegenden Firewall-Konfiguration und schreibt diese in eine Textdatei, die in einer Freigabe auf Server atl-fs-01 liegt:
Set objNetwork = CreateObject("Wscript.Network")
strComputer = objNetwork.ComputerName
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.CreateTextFile("\\atl-fs-01\firewall\" _
& strComputer & ".log")
objTextFile.WriteLine("Firewall aktiviert: " & objPolicy.FirewallEnabled)
objTextFile.WriteLine("Keine Ausnahmen zugelassen: " & objPolicy.ExceptionsNotAllowed)
objTextFile.WriteLine("Benachrichtigungen deaktiviert: " & objPolicy.NotificationsDisabled)
objTextFile.WriteLine("Unicast-Antworten auf Multicasts/Broadcasts deaktiviert: " & _
objPolicy.UnicastResponsestoMulticastBroadcastDisabled)
objTextFile.Close
Wenn Sie sich mit dem FileSystemObject auskennen, ist das Script ziemlich einfach zu lesen (wenn Sie sich mit dem Objekt nicht auskennen, lesen Sie diesen Abschnitt im Microsoft Windows 2000 Scripting Guide ). Es gibt nur eine etwas ungewöhnlichere Sache in diesem Script. In den ersten zwei Zeilen verwenden wir das Wscript.Network, um den Namen des Computers abzufragen, auf dem das Script ausgeführt wird. Diesen Namen weisen wir dann der Variable strComputer zu.
Warum? Schön, dass Sie gefragt haben. Wir hätten natürlich einen Dateinamen fest in das Script eintragen (hardcodieren) können - sagen wir zum Beispiel \\atl-fs-01\firewall\firewall_settings.log. Das würde auch prima funktionieren… solange wir nur einen Computer abfragen. Stellen Sie sich aber vor, wir hätten zwei Computer. Der erste Computer startet und speichert seine Konfigurationsinformationen in der Datei Firewall_settings.log. Dann startet der zweite Computer und speichert seine Konfigurationsinformationen auch in Firewall_settings.log - er überschreibt also die Informationen von Computer 1. Dieses Problem umgehen wir, wenn wir einen eindeutigen Dateinamen für jeden Computer erzeugen.
Anmerkung: Hätten wir nicht auch die Konfigurationsinformationen jeweils an die Datei anhängen können? Klar, hätten wir - Sie sollten in diesem Fall nur daran denken, zusätzlich zu den Daten der Firewall auch den jeweiligen Computernamen in die Datei zu schreiben. Sie hätten die Daten auch in eine gemeinsame Excel-Tabelle schreiben können. Wir wollen hier nicht besprechen, wie Sie mit den Daten umgehen - es ging nur darum zu zeigen, wie Sie an die Daten der Firewall herankommen. Unser Beispiel zeigt den einfachsten Weg (das muss nicht zwingend auch der beste Weg sein). |
In vielen Organisationen ist es allerdings so, dass die Benutzer ihre Computer niemals herunterfahren. Stattdessen melden sie sich einfach ab und gehen. Damit haben wir ein neues Problem: Wenn die Benutzer ihre Computer nicht herunterfahren, werden natürlich auch keine entsprechenden Scripte ausgeführt.
Natürlich gibt es auch hier eine Möglichkeit. Beim folgenden Ansatz ist es jedoch erforderlich, dass die Remoteadministration auf den Computern mit SP2 bereits aktiviert wurde. Wenn Sie das Firewall-Script auf die jeweiligen Remotemaschine kopieren, können Sie die WMI-Klasse Win32_Process und deren Methode Create verwenden, um das Script zu starten. Sie könnten zum Beispiel auf allen Computern einen Ordner mit dem Namen C:\Scripts erstellen und Ihr Firewall-Script auf jedem Computer in diesen Ordner kopieren (und natürlich können Sie diesen Prozess ziemlich einfach über ein weiteres Script automatisieren).
Nehmen wir nun einmal an, es wäre drei Uhr am Nachmittag. Sie sitzen an Ihrem Schreibtisch und denken: "Hmmm, ich frage mich, wie wohl die Firewall auf Computer atl-ws-01 konfiguriert ist”. Eine Gruppenrichtlinie würde Ihnen hier nicht weiterhelfen. Gruppenrichtlinien wurden zur Konfiguration von Computern entworfen - nicht zur Abfrage von Konfigurationen. Sie können natürlich den Benutzer des Computers anrufen und ihn bitten, Ihnen die Firewall-Einstellungen mitzuteilen. Um ehrlich zu sein, klingt das jedoch nicht gerade nach einer echten Alternative. Was Sie brauchen, ist ein Script, das eine Verbindung mit dem Remotecomputer aufnimmt und Ihnen die Firewall-Einstellungen zurückgibt. Aber haben wir nicht gerade erklärt, dass Sie ein Firewall-Objekt nicht remote erstellen können?
Ja, haben wir. Stimmt auch: Sie können remote kein solches Objekt erstellen. Allerdings haben wir ja gerade alle unsere Scripte im Bezug auf die Firewall auf alle Remotecomputer kopiert. Und da das Script, das Sie ausführen wollen (Basic_properties.vbs) ja nun im lokalen Ordner C:\Scripts auf atl-ws-01 liegt, können Sie dieses Script verwenden, um Basic_properties.vbs auf dem Remotecomputer auszuführen:
strComputer = "atl-ws-01"
Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")
Error = objWMIService.Create _
("c:\scripts\basic_properties.vbs", null, null, intProcessID)
In diesem Script erstellen wir eine Bindung an die Klasse Win32_Process auf dem Remotecomputer atl-ws-01. Dann verwenden wir die Methode Create, um das Script C:\Scripts\Basic_properties.vbs auszuführen. Das Coole an der Sache ist, dass C:\Scripts\Basic_properties.vbs ja ein Pfad auf der Remotemaschine ist. Wir erstellen keine Referenz auf C:\Scripts\Basic_properties.vbs auf unserer Administrator-Arbeitsstation - wir erstellen eine Referenz auf C:\Scripts\Basic_properties.vbs auf dem Remotecomputer atl-ws-01.
Bedenken Sie aber, dass für Basic_properties.vbs das gleiche gilt wie für das Script von vorhin. Es kann keine Ausgaben über Echo durchführen - Sie würden diese Ausgaben ja niemals zu Gesicht bekommen. Stattdessen müssen Sie eine Textdatei, eine Datenbank oder Ähnliches verwenden. Der gerade gezeigte Ansatz sollte im Allgemeinen funktionieren - und er ist nicht wirklich mühsam.
Moment mal …
Ok … der Ansatz ist etwas mühsam. Wenn Sie mehrere Hundert Computer abfragen müssen, müssen Sie Ihre Firewall-Scripte schließlich auf all diese Computer kopieren. Und außerdem müssen Sie sich darum kümmern, dass diese Scripte dann auch bei jeder Änderung an den Originalscripten aktuell bleiben. Keine Panik! Wir haben da einen kleinen Workaround für Sie. Das haben Sie sich schon gedacht? Ist nicht wahr!
Wie auch immer - hier ist der Workaround. Dieses Script verwendet das FileSystemObject, um ein Firewall-Script (Basic_properties.vbs) in den Ordner C:\Scripts auf Computer atl-ws-01 zu kopieren. Dann nutzt das Script die Klasse Win32_Process, um Basic_properties.vbs zu starten und das Script dann sofort wieder von atl-ws-01 zu löschen. Ergebnis: Das Script wird auf der Remotemaschine ausgeführt, aber Sie müssen sich nicht darum kümmern, dass das Script auf der Remotemaschine immer aktuell bleibt. Und als kleiner Bonus bleiben auf atl-ws-01 keine Spuren von Basic_properties.vbs zurück (damit sinkt auch die Wahrscheinlichkeit, dass ein Benutzer - versehentlich oder mit Absicht - das Script löscht, ändert oder irgendetwas anderes damit anstellt).
Const OverwriteExisting = TRUE
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.CopyFile "C:\Firewall\basic_properties.vbs", _
"\\atl-ws-01\C$\Scripts\", OverWriteExisting
strComputer = "atl-ws-01"Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")
Error = objWMIService.Create _
("cscript c:\scripts\basic_properties.vbs", null, null, _
intProcessID)
objFSO.DeleteFile("\\atl-ws-01\C$\Scripts\basic_properties.vbs")
Anmerkung: Damit das Script funktioniert, müssen die administrativen Freigaben (C$ usw.) vorhanden sein. Wenn Sie keine administrativen Freigaben verwenden, müssen Sie die Datei in einen anderen freigegebenen Ordner der Arbeitsstation kopieren. |
Ähm - meine Computer habe ich noch immer nicht wieder …
Oh, stimmt - jetzt wo Sie es sagen …. in dieser Kolumne ging es ja darum die Remoteadministration von Computern mit SP2 zu ermöglichen. Sieht fast so aus, als wäre die gesamte Kolumne, die wir schreiben wollen, einfach verschwunden! Unheimlich…
Also bitte: Der offizielle, empfohlene Weg zur Aktivierung der Remoteadministration ist die Verwendung einer Gruppenrichtlinie. Und zweifellos ist eine Gruppenrichtlinie - unter den richtigen Umständen - der schnellste und einfachste Weg, um die Einstellung zu aktivieren. Es gibt jedoch einen Haken an der Sache (es gibt immer einen Haken): Um die neuen Firewall-Einstellungen in der Gruppenrichtlinie nutzen zu können, müssen Sie erst SP2 auf dem Computer installieren, den Computer neu starten, sich als Domänenadministrator anmelden und dann über den SP2-Computer die Einstellungen im entsprechenden GPO ändern - und zwar weil Sie die Gruppenrichtlinienvorlage System.adm auf dem Server mit der Gruppenrichtlinienvorlage System.adm aus SP2 ersetzen müssen.
Wenn Sie das so machen, können Sie ab da - und wir zitieren hier aus der offiziellen Dokumentation - die Gruppenrichtlinie nur noch über einen Computer unter Windows XP SP2 ändern. Wenn Sie SP2 auf Ihrer Administrator-Arbeitsstation nicht installiert haben, können Sie die GPOs über die Arbeitsstation nicht mehr bearbeiten. Wenn die anderen Administratoren SP2 nicht installiert haben, können sie die GPOs ebenfalls nicht mehr bearbeiten. Das liegt daran, dass die Vorlage System.adm auf Ihrem System veraltet ist. Es wird zwar an Updates gearbeitet, um dieses Problem zu beheben, aber Sie sollen diesen Punkt auf jeden Fall berücksichtigen.
Sie sollten also darüber nachdenken, stattdessen ein Start-Script zu verwenden. Start-Scripte werden zwar über GPOs konfiguriert, aber hierzu sind keine ADM-Vorlagen notwendig. Konsequenterweise können Sie Start-Scripte somit über jede Arbeitsstation konfigurieren.
Ein Start-Script zur Aktivierung der Remoteadministration sieht zum Beispiel so aus:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Set objAdminSettings = objPolicy.RemoteAdminSettings
objAdminSettings.Enabled = TRUE
Alles, was wir in diesem Script machen, ist ein Firewall-Objekt zu erstellen, es an das aktuelle Profil zu binden, eine Bindung an das RemoteAdminSettings-Objekt zu erstellen und die Eigenschaft Enabled auf TRUE zu setzen. Das ist alles - mehr brauchen Sie nicht zu tun. Wenn Sie sich später dazu entscheiden, die Remoteadministration zu deaktivieren, setzen Sie die Eigenschaft einfach auf FALSE:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Set objAdminSettings = objPolicy.RemoteAdminSettings
objAdminSettings.Enabled = FALSE
Wenn Sie noch nicht alle Computer auf SP2 aktualisiert haben, sollten Sie außerdem etwas Code einbinden, um zu überprüfen, ob SP2 auf der entsprechenden Maschine installiert ist. Andernfalls bekommen Sie Probleme, wenn das Script auf einem Computer ohne SP2 versucht, das HNetCfg.FWMgr-Objekt zu erstellen. Glücklicherweise haben wir etwas Beispielcode parat, mit dem Sie feststellen können, ob SP2 installiert ist:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & _
"\root\cimv2")
Set colOS = objWMIService.ExecQuery _
("Select * from Win32_OperatingSystem WHERE ")
"Caption = 'Microsoft Windows XP Professional' AND " & _
ServicePackMajorVersion = 2")
If colOS.Count <> 0 Then
Wscript.Echo " Windows XP Service Pack 2 ist installiert."
Else
Wscript.Echo "This computer is not running Windows XP Service Pack 2."
End If
Auch dieses Script ist ziemlich simpel. Wir fragen alle Instanzen der Klasse Win32_OperatingSystemClass ab, bei denen Caption den Wert Microsoft Windows XP Professional und ServicePackMajorVersion den Wert 2 hat. Wenn Count den Wert 0 hat, dann bedeutet das, dass es sich entweder nicht um Windows XP Professional handelt und/oder das SP2 nicht installiert ist. Wenn Count den Wert 1 hat, ist SP2 installiert.
Weitere Informationen zur Konfiguration und Zuweisung von Start- und Herunterfahren-Scripten für Computer finden Sie im Whitepaper Enterprise Logon Scripts.
Ist die Gruppenrichtlinie meine einzige Möglichkeit?
Uns ist klar, dass einige von Ihnen Gruppenrichtlinien nicht mögen oder dass einige von Ihnen Gruppenrichtlinien nicht einsetzen können (z. B. weil es sich um ein kleines Unternehmen mit einer Arbeitsgruppe statt mit einem Verzeichnisdienst handelt). Wenn das der Fall ist, ist es die beste Variante, die Remoteadministration vor der Installation von SP2 zu konfigurieren. Dies können Sie über eine .INF-Datei oder über eine Antwortdatei für eine unbeaufsichtigte Installation erledigen. Weitere Informationen hierzu finden Sie im Handbuch zum Installieren und Bereitstellen von Microsoft Windows XP SP2. Vielleicht möchten Sie sich auch ein paar Minuten Zeit nehmen und den Webcast der Scripting Guys ansehen: Scripting with Microsoft Windows XP SP2: SOS! (englischsprachig).
Und was, wenn Sie SP2 bereits installiert haben? Tja, dass ist ein kleines Problem. Wenn Sie keine Gruppenrichtlinie verwenden können, müssen Sie einzeln zu jedem Computer gehen und ein Script starten, dass die Remoteadministration aktiviert. Wenn Ihre Benutzer allerdings lokale Administratoren sind, können Sie diesen das Script per Mail schicken und es ausführen lassen. Andernfalls sind Sie beim guten alten Turnschuh-Netz angelangt.
Ja, wir wissen es: Das ist nicht exakt das, was Sie hören wollen. Da die Remoteadministration aber deaktiviert ist, können Sie die Änderung nicht über das Netzwerk durchführen. Jemand muss alle Computer physikalisch aufsuchen und die Einstellung direkt vornehmen. Oder (unauffälliger Hinweis) Sie verwenden endlich die Gruppenrichtlinien. Glauben Sie uns: Die Arbeit mit Gruppenrichtlinien ist wirklich nicht sehr kompliziert - und es gibt ein Whitepaper, das die Verwaltung der Firewall über Gruppenrichtlinien Schritt für Schritt beschreibt.
Was ist aber, wenn ich die Windows Firewall nicht haben will?
Grundsätzlich können wir eine Deaktivierung der Windows Firewall nicht empfehlen - warum sollten Sie sich selbst einem solchen Risiko aussetzen? Natürlich mag es sein, dass Sie bereits eine Firewall eines Drittanbieters einsetzen. In diesem Fall macht es möglicherweise durchaus Sinn, eine von beiden zu deaktivieren (man kann wohl mit ruhigem Gewissen behaupten, dass zwei Firewalls nicht sicherer sind als eine). Mit diesem kleinen Script können Sie die Windows Firewall deaktivieren:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
objPolicy.FirewallEnabled = FALSE
Was aber, wenn Sie sich später anders entscheiden? Kein Problem:
Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
objPolicy.FirewallEnabled = TRUE
Natürlich können Sie auch wieder eine Gruppenrichtlinie verwenden. Außerdem können Sie eine .INF-Datei oder eine Antwortdatei verwenden, um die Firewall bereits bei der Installation von SP2 zu deaktivieren. Wiederum gibt es mehrere Varianten - besonders dann, wenn Sie SP2 noch nicht installiert haben.
Es ist nicht so schlimm, wie es aussieht
Die gute Seite ist (und es gibt tatsächlich eine gute Seite), dass Sie nach der Aktivierung der Remoteadministration alle Verwaltungsmöglichkeiten wiederhaben, die Ihnen auch vor der Installation von SP2 zur Verfügung standen. Außerdem steht Ihnen mit SP2 eine Fülle von neuen Möglichkeiten zur Verfügung. Wenn Sie Beispiele zu den neuen Möglichkeiten benötigen, dann sehen sie sich die Windows XP Service Pack 2 Application Compatibility Scripts aus dem Script Center an (englischsprachig).
Haben Sie Fragen oder Vorschläge zu dieser Kolumne? Wissen Sie, wo Amelia Earhart tatsächlich geblieben ist? Schreiben Sie uns unter scripter@microsoft.com (bitte nur in englischer Sprache). Und vergessen Sie nicht Ihre Mutter nach dem Hamster zu fragen.
Zusätzliche Informationen
| • |