Hey, Scripting Guy!Desktopverwaltung aus dem Jenseits

Die Scripting Guys von Microsoft

Laden Sie den Code für diesen Artikel herunter: HeyScriptingGuy2007_11.exe (151KB)

Angesichts der überwältigenden Nachfrage haben wir uns für diesen Monat etwas Anderes überlegt: Statt gleich mit der Skriptprogrammierung für die Systemadministration anzufangen, werden wir mit einer Gespenstergeschichte beginnen!

Hinweis: Wenn wir, prinzipiell betrachtet, diesen Monat wirklich auf eine kleine Änderung aus wären, würden wir damit anfangen, zur Abwechslung einmal tatsächlich die Skriptprogrammierung für die Systemadministration zu behandeln. Spielen Sie einfach mit. Danke!

Vor vielen Jahren ist die Ur-Ur-Urgroßmutter eines der Scripting Guys gestorben. Kurz nachdem die Großmutter in ihrem einfachen Holzsarg zur letzten Ruhe gebettet wurde, stellten sich beim Großvater schreckliche Albträume ein, in denen seine geliebte Ehefrau verzweifelt versuchte, sich aus dem Grab befreien. Nach wiederkehrenden Angstträumen und nach wiederholten dringenden Bitten konnte der Großvater schließlich die lokalen Zuständigen davon überzeugen, ihren Körper auszugraben. Als der Sarg geöffnet wurde, sah jeder entsetzt, dass die Nägel der Großmutter völlig verbogen und die Innenseiten des Sargs mit Kratzern überdeckt waren!

Diese Geschichte ist wahrscheinlich nicht ganz wahrheitsgetreu. Je länger wir darüber nachdenken, umso mehr sehen wir ein, dass sie keinen Fünkchen Wahrheit enthält. Trotzdem lässt sich aus dieser Geschichte eine wichtige Lehre ziehen. Wir haben zwar keine Ahnung, was das sein könnte, aber sie ist irgendwo hier begraben.

Halt, jetzt erinnern wir uns wieder! Särge wurden ursprünglich entworfen, um Verstorbene vor den Naturelementen zu schützen und um zu verhindern, dass der Körper verwest. Leider hatten Särge auch eine unbeabsichtigte Folge: Sie ließen theoretisch zu, dass eine Person lebendig begraben werden konnte und nicht mehr aus dem Grab herauskam. Wie die Geschichte der Ur-Ur-Urgroßmutter eines der Scripting Guys verdeutlicht, können sogar die besten Pläne katastrophal enden – und damit, dass Personen lebendig begraben werden! (Cue the ominous music one more time.)

Hinweis: Es sei denn, Sie entscheiden sich für das optimierte Sargmodell, das von Franz Vester in den 1860er Jahren erfunden wurde. Dieser Sarg enthielt einen Strick, der mit einer Klingel über der Erde verbunden war. Im Fall einer voreiligen Beerdigung konnte der oder die „Verstorbene“ einfach klingeln und um Hilfe rufen. Der verbesserte Sarg enthielt zudem eine Faltleiter, auch wenn uns nicht ganz klar ist, wie sie einem helfen soll, sich aus einem Sarg zu befreien, der fast zwei Meter tief in der Erde begraben ist. Wenn jemand auf dem Dach einer Garage begraben wird, sicher, dann wäre eine Faltleiter wohl nützlich. Otherwise ....

Dasselbe (nämlich dass die besten Pläne katastrophal enden) gilt auch in gewisser Weise für Internetfirewalls. (Well, sort of.) Firewalls wurden ursprünglich entworfen, um die Bösewichte nicht hereinzulassen: Sie blockieren eingehenden Netzwerkverkehr. Das hilft, um die Hacker und Angreifer von Ihren Computern fern zu halten. Das ist zwar großartig, kann jedoch – wie beim Risiko mit dem Lebendigbegrabenwerden – auch eine unbeabsichtigte Folge haben: Firewalls können auch den Guten den Zugang versperren. Dies ist besonders bei der Windows®-Verwaltungsinstrumentation (Windows® Management Instrumentation, WMI) der Fall, die sich auf DCOM verlässt, um administrative Aufgaben auf Remotecomputern durchzuführen. Firewalls neigen dazu, jeglichen eingehenden DCOM-Datenverkehr zu blockieren, was die programmgesteuerte Verwaltung von Computern über das Internet sehr erschwert (wenn nicht gar völlig unmöglich macht). Genau genommen ist dies ohne die Öffnung zusätzlicher Ports auf der Firewall und der damit einhergehenden Anfälligkeit gegen Hacker völlig unmöglich. Es sei denn natürlich, Sie entscheiden sich für WinRM: Windows Remote Management.

Was ist die Windows Remote Management?

Laut dem WinRM SDK (msdn2.microsoft.com/aa384426) ist Windows Remote Management „die Microsoft-Implementierung von WS-Management Protocol, dem SOAP-basierten, firewallfreundlichen Standardprotokoll, das die Zusammenarbeit von Hardware und Betriebssystemen verschiedener Hersteller ermöglicht“. Beeindruckend, nicht wahr? Die Einzelheiten des WS-Management Protocol werden im Artikel für diesen Monat nicht behandelt. Deshalb empfehlen wir, diese im WinRM SDK nachzulesen. Vorläufig ist es wichtig festzuhalten, dass WinRM unter Windows Server® 2003 R2, Windows Vista® und Windows Server 2008 verfügbar ist und Ihnen das Verwalten von Computern über das Internet ermöglicht. WinRM erzielt dies mithilfe von Port 80, einem Standardinternetdienstport, den die meisten Firewalls geöffnet lassen. (Der von WinRM und der Standardtransportmethode, HTTP, verwendete Port kann jedoch nach Bedarf geändert werden.)

Im vorliegenden Artikel wird des Weiteren nicht besprochen, wie WinRM installiert und konfiguriert wird. Zu diesem Thema sind bereits zahlreiche Informationen verfügbar (msdn2.microsoft.com/aa384372). Ein Punkt soll hier jedoch hervorgehoben werden: Wenn Sie mithilfe von WinRM Informationen von einem Remotecomputer abrufen möchten (was natürlich der Hauptgrund für die Verwendung von WinRM ist), dann müssen Sie sowohl auf Ihrem lokalen Computer als auch auf dem Remotecomputer WinRM ausführen.

Was bedeutet das? Es bedeutet Folgendes: Falls Sie Ihre Clientcomputer nicht auf Windows Vista oder Ihre Server nicht auf Windows Server 2003 R2 oder Windows Server 2008 aktualisiert haben, werden Sie zumindest vorläufig nicht viel Nutzen aus WinRM ziehen können. Das kann sich aber morgen schon ändern. (Falls Ihre Firewall es ermöglicht, können Sie zur Verwaltung von Remotecomputern natürlich immer WMI und DCOM verwenden.)

Zurückgeben aller Eigenschaften und Instanzen einer Klasse

Doch wer achtet schon auf Vorsichtsmaßnahmen und Haftungsausschlüsse? Im Folgenden soll statt dieses unverständlichen Kauderwelschs untersucht werden, ob ein Skript erstellt werden kann, das sich WinRM zunutze macht. Zufällig lag uns ein einfaches kleines Skript vor, das mithilfe des HTTP-Protokolls und des Ports 80 eine Verbindung zu einem Computer namens „atl-fs-01.fabrikam.com“ herstellt und dann die Informationen über die auf diesem Computer installierten Dienste zurückgibt. Das Skript ist in Abbildung 1 dargestellt.

Figure 1 Silverlight-Projektkomponenten

Datei	Beschreibung
CreateSilverlight.js	Ein JScript-Skript (in der ersten Version unterstützt Silverlight nur JScript-Skripting), mit dem die ursprünglichen Silverlight-Starteinstellungen einschließlich der zum Konfigurieren der Benutzeroberfläche und von Grafikobjekten verwendeten XAML-Datei angegeben werden.
SampleProject.js	Eine leere Datei, in die JScript-Funktionen eingefügt werden können.
Silverlight.js	Diese Datei dient zum Initialisieren des Silverlight-Steuerelements.
SampleProject.html	Hier geht es richtig los. SampleProject.html ist einfach eine HTML-Datei, die Code zum Einlesen der drei .js-Dateien umfasst. Sie enthält darüber hinaus Code zum Instanziieren des Silverlight-Steuerelements.
SampleProject.xaml	Wozu dient diese Datei? Um das herauszufinden, müssen Sie zum Haupttext dieses Artikels zurückkehren.

Figure 1 Auflisten von Diensten auf einem Remotecomputer

strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")    
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub

Wie Sie sehen können, wird zuerst der DNS-Name des Computers (atl-fs-01.fabrikam.com) einer Variablen namens „strComputer“ zugewiesen. Alternativ dazu könnte die Verbindung mit der IP-Adresse des Computers (oder sogar seiner IPv6-Adresse) hergestellt werden. Beispiel:

strComputer = "192.168.1.1"

Nachdem strComputer ein Wert zugewiesen wurde, wird eine Instanz des WSMan.Automation-Objekts erstellt. Anschließend wird die CreateSession-Methode aufgerufen, um eine Verbindung zum Remotecomputer herzustellen, in diesem Fall mit dem HTTP (wie bereits angekündigt):

Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)

Wie schon angemerkt, wollen wir Informationen über die Dienste zurückgeben, die auf dem Remotecomputer installiert sind. Außerdem und zumindest für dieses erste Beispiel möchten wir Informationen über alle Eigenschaften aller Dienste erhalten. Was bedeutet das alles? Es bedeutet, dass wir eine URI-Ressource angeben müssen, die uns an die Win32_Service-Klasse auf dem Remotecomputer bindet:

strResource = _
  "https://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"

Zugegebenermaßen ist dies nicht der ansehnlichste URI. (Wo wir schon bei diesem Thema sind: Wir können uns nicht erinnern, jemals einen ansehnlichen URI gesehen zu haben.) Erfreulicherweise handelt es sich beim Großteil des URIs um Textbausteine. Aufmerksamkeit erfordert nur der WMI-Pfad am Ende:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service

Das sollte ziemlich einfach sein. Was ist, wenn Sie eine Verbindung zur Klasse „root/cimv2/Win32_Process“ herstellen möchten? Dann muss nur der URI-Pfad entsprechend geändert werden:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process

Sie sind an der Klasse „root/default/SystemRestore“ interessiert? Auch hier gilt: Ändern Sie einfach nur die URI-Klasse, und denken Sie daran, den Standardnamespace (statt des cimv2-Namespace) anzugeben:

https://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore

Und so weiter ... Es ist zwar schade, dass der Teil „https://schemas.microsoft.com/wbem/wsman/1/wmi“ des URI ebenfalls enthalten sein muss, aber ...

Jetzt können einige Daten abgerufen werden. Dazu wird einfach die Enumerate-Methode aufgerufen, wobei die Variable „strResource“ als einziger Methodenparameter übergeben wird:

Set objResponse = _
  objSession.Enumerate(strResource)

Wird diese Codezeile tatsächlich „objResponse“ mit Informationen über die Dienste, die auf dem Computer „atl-fs-01“ installiert werden, auffüllen? Gewiss. Im Unterschied zu WMI-Standardskripts wird jedoch keine Reihe von Objekten, jedes mit seinen eigenen Eigenschaften und Eigenschaftsmethoden, zurückgegeben. Stattdessen wird ein großes, althergebrachtes XML-Blob zurückgegeben, das ungefähr so aussieht wie in Abbildung 2.

Figure 2 Hübsche Farben

<Canvas
 xmlns="https://schemas.microsoft.com/client/2007"
 xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">
 
 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>

Figure 2 Großes, althergebrachtes XML-Blob

<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center

Wenn Sie ein XML-Genie sind, ist das kein große Sache. Jeder, der mit XML vertraut ist, sollte diese Informationen analysieren und ohne große Schwierigkeiten ausgeben können (auch wenn sich diese Informationen laut dem WinRM SDK nicht in einem „von Menschen lesbaren Format“ befinden). Aber was ist, wenn Sie kein XML-Genie sind? Im diesem Fall haben Sie zwei Möglichkeiten. Erstens können Sie bis zum nächsten Monat warten, wo wir ein paar Tricks für die Arbeit mit dem XML von WinRM vorstellen. Zweitens können Sie so vorgehen wie wir in unserem Beispielskript: Setzen Sie „XSL transform“ ein, das zusammen mit WinRM installiert wird.

Was ist das?

Ein „XSL transform“ ist nichts anderes als eine Vorlage, die beschreibt, wie eine XML-Datei angezeigt werden soll. Eine vollständige und sogar eine oberflächliche Erörterung von XSL-Dateien geht über den Rahmen dessen hinaus, was wir im Artikel für diesen Monat anbieten können. Deshalb werden wir nicht versuchen, die Funktionsweise von WsmTxt.xsl (der Name des integrierten „transform“) zu erklären. Stattdessen zeigen wir einfach, wie Sie „transform“ in Ihrem Skript verwenden.

Wenn Sie die Enumerate-Methode aufrufen, sendet WinRM XML-Daten zurück. Am leichtesten lässt sich mit diesen Daten arbeiten, indem eine Do Until-Schleife eingerichtet wird, die so lange fortgesetzt wird, bis Sie das Ende des Datenstroms erreichen. Das ist, was wir hier machen:

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Wie Sie sehen können, rufen wir innerhalb unserer Schleife eine Unterroutine namens „DisplayOutput“ auf. Wenn wir diese Unterroutine aufrufen, übergeben wir den Wert der ReadItem-Methode des Datenstroms als Unterroutinenparameter. (Wie diese ganze Vorgehensweise impliziert, wird der XML-Datenstrom in separaten Stücken statt eines großen Datenpakets zurückgeschickt. Unser Skript wiederum liest die XML-Daten immer nur Stück für Stück bzw. Element für Element.)

Mittlerweile sieht die DisplayOutput-Unterroutine folgendermaßen aus:

Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")    
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub

Kurz gesagt, werden als Erstes zwei Instanzen des MSXml2.DOMDocument.3.0-Objekts erstellt. Der XML-Datenstrom (strWinRMXML) wird in ein Objekt geladen. Dann wird die XSL-Datei (WsmTxt.xsl) in ein anderes Objekt geladen. An diesem Punkt wird die TransformNode-Methode aufgerufen, um die Informationen in der XSL-Datei zu verwenden, um die vom XML-Datenstrom erfassten Daten zu formatieren und anzuzeigen.

Stimmt, das ist etwas verwirrend. Zumindest ist die Ausgabe, wenn auch nicht perfekt, so doch ein bisschen leichter zu lesen (siehe Abbildung 3).

Figure 3 Text malen

<TextBlock 
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20" 
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>

Figure 3 Eine ordentlichere Version des XML

Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.

Wie schon erwähnt, ist dies zwar gut, doch es ist nicht unbedingt hervorragend. Ein Grund mehr, den Artikel des nächsten Monats zu lesen, wo wir Ihnen ein paar Möglichkeiten zeigen werden, die XML-Ausgabe selbst zu bearbeiten.

Zurückgeben ausgewählter Instanzen und Eigenschaften einer Klasse

Natürlich ist das alles wunderbar, bis auf eine Ausnahme: Es repräsentiert möglicherweise nicht vollständig die Art und Weise, wie Sie in der Regel arbeiten. Mitunter wird es vorkommen, dass Sie alle Eigenschaften aller Instanzen einer Klasse zurückgeben möchten. Doch es wird auch Zeiten geben (und vielleicht gar nicht so selten), in denen Sie nur ausgewählte Eigenschaften oder Instanzen einer Klasse zurückgeben möchten. Sie möchten zum Beispiel nur Informationen über Dienste zurückgeben, die gerade ausgeführt werden – etwas, was Sie in einem regelmäßigen WMI-Skript mithilfe eines Codes wie dem folgenden durchführen:

Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")

That's nice. Doch wie ändern Sie die Ressourcenzeichenfolge, um sie entsprechend anzupassen?

Um ganz ehrlich zu sein, werden Sie Ihre Ressourcenzeichenfolge nicht so ändern, dass sie ein Äquivalent zur ExecQuery-Anweisung darstellt. Sie müssen die Ressourcenzeichenfolge mit Sicherheit ändern, doch Sie müssen andere Dinge ebenfalls ändern.

Betrachten Sie dazu die Abbildung 4. Es ist ein WinRM-Skript, das Informationen über die Dienste zurückgibt, die auf einem Computer ausgeführt werden (im Gegensatz Diensten, die auf dem Computer installiert sind).

Figure 4 TextBlock-Tricks

<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0" 
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>

Figure 4 Suchen ausgeführter Dienste

strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "https://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "https://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")    
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub

Auf den ersten Blick mag alles mit dem ersten WinRM-Skript, das oben angeführt wurde, fast identisch erscheinen, doch es gibt einige sehr wichtige Unterschiede. Betrachten Sie zum einen den der Ressourcenzeichenfolge zugewiesenen Wert:

strResource = _
  "https://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"

Beachten Sie, dass beim Erstellen einer gefilterten Abfrage der eigentliche Name der zu verwendenden Klasse (Win32_Service) nicht angegeben wird. Stattdessen wird einfach eine Verbindung zum Namespace (root/cimv2), in dem sich diese Klasse befindet, hergestellt. Vergessen Sie dabei das Sternchen (*) am Ende nicht. Wenn Sie es nicht verwenden, gibt Ihnen das Skript die Meldung „... the class name must be '*' (star)“ zurück. Das heißt, dass Sie den Klassennamen als „*“ angeben müssen.

Außerdem müssen ein Filter und ein Dialekt definieren werden:

strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "https://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"

Der Filter dürfte kein Problem darstellen. Dort wird die WQL-Abfrage gestellt (Windows Management Instrumentation Query Language, WMI-Abfragesprache): "Select * From Win32_Service Where State = 'Running'". Der Dialekt ist die Abfragesprache, die beim Erstellen des Filters verwendet wird. Im Augenblick ist nur eine Abfragesprache zulässig: WQL. Dennoch muss der Dialekt angegeben werden, sonst schlägt das Skript fehl und gibt an, dass der Filterdialekt nicht unterstützt ist.

Hinweis: Interessanterweise legt die Fehlermeldung nahe, den Dialekt zu entfernen, wenn Sie die Enumerate-Methode aufrufen. Das ist eine Empfehlung, der Sie nicht folgen sollten. Bei einer gefilterten Abfrage muss der Dialekt unbedingt angegeben werden, und zwar als WQL. Period.

Die einzige andere Änderung, die vorgenommen werden muss, fällt beim Aufrufen der Enumerate-Methode an. An diesem Punkt müssen die Variablen übergeben werden, die den Filter (strFilter) und den Dialekt (strDialect) darstellen, sowie die Variable, die die Ressource (strResource) darstellt:

Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)

Probieren Sie es aus.

Können denn nur ausgewählte Eigenschaften einer Klasse zurückgegeben werden? Angenommen, Sie möchten nur Name und DisplayName für alle Dienste zurückgeben, die auf einem Computer ausgeführt werden. Was dann?

In solch einem Fall können Sie versuchen, das XML zu manipulieren, sodass nur Name und DisplayName angezeigt werden. Das ist möglich, aber auch etwas knifflig. Eine leichtere Möglichkeit wäre, beim Zuweisen des Filters nur diese Eigenschaften anzugeben:

strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"

Dann werden nur Name und DisplayName der jeweiligen Dienste angegeben, etwa so:

XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem

Zugegeben, die Formatierung ist etwas seltsam. (Was soll der ganze XmlFragment-Kram?) Ein weiterer Grund, nächsten Monat hier wieder vorbeizuschauen.

Geduld

Mit etwas Glück müsste dies jetzt für die ersten Schritte in der wilden und wunderbaren WinRM-Welt ausreichen. Selbstverständlich können wir keinen Artikel zu WinRM abschließen, ohne die früher so genannten Leichenhäuser zu erwähnen, die einst weit verbreitet waren in Deutschland. In Städten mit Leichenhäusern wurden die Leichen nicht sofort begraben. Stattdessen wurden sie in warmen Zimmern aufbewahrt und mit einer Reihe von Stricken und Drähten an ihren Fingern und Zehen versehen. Dahinter stand natürlich der Gedanke, dass die geringste Bewegung einen Alarm auslösen und Hilfe herbeirufen würde, da damals die Furcht, lebendig begraben zu werden, ziemlich weit verbreitet war. Die Körper blieben so lange in diesen provisorischen Leichenhallen, bis kein Zweifel mehr daran bestand, dass es für diese Menschen tatsächlich keine Hoffnung mehr gab.

Das hört sich ganz so wie im Scripting Guys-Team an. In jenen Leichenhäusern ist gewiss niemand jemals wieder zum Leben erwacht – die dem Scripting Guys-Team zugeteilten Menschen hingegen ...

Der Scripting Perplexer von Dr. Scripto

Im Juni 2007 haben die Scripting Guys die Tech•Ed-Konferenz in Orlando, Florida, besucht. Einfach nur an der Konferenz teilzunehmen, reichte uns nicht, also beschlossen wir, etwas Spaß zu haben. Nicht nur das, wir dachten uns, dass alle anderen auch etwas Spaß vertragen könnten. Also haben wir uns das Fun Book von Dr. Scripto einfallen lassen, ein Heft voller Rätsel zur Skripterstellung und mit diversen anderen Informationen. Wir taten uns mit dem TechNet Magazin zusammen – das heißt, wir überredeten sie, uns eine winzige Ecke ihres Stands in der Ausstellungshalle zu überlassen – und verteilten die Spaßbücher an alle, die vorbeiliefen.

Wie sich herausstellte, kam unser Fun Book gut an. Die Leute vom TechNet Magazin, nett und opportunistisch wie sie sind, sahen, wie sie sich erneut den Erfolg der Scripting Guys zunutze machen konnten (die Scripting Guys können anscheinend nie von ihrem eigenen Erfolg profitieren), und baten uns, einige Rätsel für sie zu entwerfen. Als Jean Ross, eine der Scripting Guys, sich für einen kleinen Moment abwendete, sagte Scripting Guy Greg Stemp: „Klar, machen wir!“ Hier ist das Ergebnis: Der Scripting Perplexer von Dr. Scripto. Viel Spaß.

Drop-In Scripting

In diesem Rätsel ergeben alle Buchstaben im oberen Teil bei ihrer Entwirrung ein Skript (in VBScript). Keine Sorge, Sie müssen nicht alles entschlüsseln, sondern immer nur eine Spalte. Die Buchstaben in jeder Spalte des oberen Abschnitts füllen die Leerstellen in der gleichen Spalte des unteren Abschnitts. Hier ist ein Beispiel:

In Spalte 1 befinden sich die Buchstaben S, C und T. Diese drei Buchstaben gehören in einer unbekannten Reihenfolge in die Zeile darunter. Wenn aber alle Buchstaben in der richtigen Reihenfolge eingetragen werden, ergibt die untere Zeile, von links nach rechts, etwas Logisches. Hier ist die Lösung:

Die Buchstaben S, C und T in Spalte 1 werden darunter in der Reihenfolge T, S und C eintragen. Sie sind also jeweils die ersten Buchstaben der Wörter in „The Script Center“. Das eigentliche Rätsel ist etwas schwieriger, weil es länger ist und weil das Endergebnis ein vollständiges Skript darstellt.

Tipp: Das endgültige Skript beginnt mit einem vollen Pfad zu einer Datei, wird dann geparst und zeigt nur den Dateinamen an.

Viel Glück!

ANSWER:

Der Scripting Perplexer von Dr. Scripto

Antwort: Drop-In Scripting, November 2007

In diesem Rätsel müssen Sie die Buchstaben innerhalb einer Spalte in die richtigen Felder darunter eintragen, damit die unteren Zeilen ein Skript ergeben. Hier ist das eigenständige Skript:

name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
        

So sieht es im Rätsel aus:

Die Scripting Guys von Microsoft arbeiten für Microsoft (oder sind zumindest dort angestellt). Wenn sie nicht gerade ihrem Hobby, dem Baseball (oder verschiedenen anderen Aktivitäten) nachgehen, betreiben sie das TechNet-Skriptcenter. Besuchen Sie es unter www.scriptingguys.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.