Wer kennt es nicht: Der Rechner läuft nicht mehr so, wie er soll. Startet er gar nicht mehr, hat man nun zwei Möglichkeiten: Entweder ein vorhandenes und funktionsfähiges Backup wiederherstellen, oder eine Neuinstallation durchführen. Die Suche nach dem Windows-Installationsmedium steht in den meisten Fällen an…

Wer nun keine Lust hat, immer wieder die Windows-DVD zu suchen, oder das ISO neu zu brennen, für den bietet Microsoft das “Windows 7 USB/DVD Download Tool” an, womit man sich einen bootfähigen USB-Stick erstellen und von diesem aus die Installation durchführen kann.

An sich eine ganz praktische Sache, jedoch hat diese einen aus meiner Sicht gesehen gewaltigen Nachteil: Man kann mit dieser Variante nur eine Windows-Version auf den Stick übertragen. Hat man sich daheim ein kleines Netzwerk aufgebaut, müsste man diesen für die Installation von unterschiedlichen Clients und Servern immer wieder neu beladen.

Mancher, der sich mit den neueren Version von Windows und deren Setup auskennt, wird sich nun denken: “Hey, dann pack ich halt alle Images aus der install.wim einfach in ein neues wim-File!” Wird nur leider nichts, da noch Setup-Dateien von der DVD angezogen werden und somit die Installation zum Scheitern verurteilt ist.

Hier möchte ich euch nun einen etwas anderen Weg beschreiben, wie ihr euch einen entsprechenden Installationsstick zusammenstellen könnt. Zunächst die benötigte Software:

• Windows Automated Installation Kit (WAIK)
• GrubInst 1.1 (enthält Grub4DOS)
• HP USB Disk Storage Format Tool
• ImDisk (ein freier Drive-Emulator)
• 7-Zip
• und eure Windows ISOs

Als Hardware benötigt ihr:

• einen Windows-Rechner
• einen für eure Anforderungen entsprechend dimensionierten USB-Stick

Alles beisammen? Wunderbar, dann kann es ja losgehen

Zunächst einmal schließt ihr euren USB-Stick am Rechner an, und startet das HP USB Disk Storage Format Tool als Administrator. Wählt hier euren USB-Stick aus, und wählt als “File System”  “FAT32″. “Quick Format” für die ganz Eiligen noch aktivieren, dann auf “Start”.

Danach entpackt ihr GrubInst und startet die “grubinst_gui.exe” als Administrator. Nach dem Start wählt ihr unter “Device Name” den Punkt “Disk”. In der Auswahlliste müsst ihr nun euren USB-Stick auswählen (orientiert euch dabei am besten an der Größe des Sticks). Einen Klick auf “Refresh” neben der Auswahlliste “Part List”, wählt ihr dann in der Auswahlliste selbst “Whole Disk (MBR)”. Nun sind wir nur noch ein Klick auf “Install” von einem bootfähigen USB-Stick entfernt.

Als nächstes empfehle ich euch, eine geeignete Ordnerstruktur für die ISOs anzulegen. Die Batchfiles in diesem Artikel müsst ihr dementsprechend anpassen. Für meine Zwecke hat sich folgende Ordnerstruktur bewährt:

• \boot
  • \microsoft
    • \windows_7
    • \windows_server_2008
    • \windows_server_2008_r2
    • \windows_storage_server_2008
    • \windows_vista
• \imdisk
• \install
  • \microsoft
    • \windows_7
    • \windows_server_2008
    • \windows_server_2008_r2
    • \windows_storage_server_2008
    • \windows_vista

Nicht benötigte Windows-Ordner könnt ihr natürlich weglassen

Installiert nun 7-Zip auf eurem Rechner und entpackt damit die “imdiskinst.exe” auf euren USB-Stick in den Ordner “imdisk”.  Das WAIK ISO entpackt ihr ebenfalls mit 7-Zip auf eure Festplatte in ein temporäres Verzeichnis. Führt hier die “StartCD.exe” aus, wählt den Menüpunkt “Windows AIK-Setup” und folgt den weiteren Anweisungen des Assistenten.

Die nächsten Schritte sind nun für jede Windows-Version, die ihr in euren USB-Stick integrieren wollt, zu wiederholen.

Entpackt euch das Windows-ISO mittels 7-ZIP in ein temporäres Verzeichnis, Unterverzeichnis “DVD”. Löscht hier die “\sources\install.wim” – wir erstellen uns ein kleines Hilfs-Boot-ISO, in dem wir die install.wim nicht brauchen.

Öffnet aus dem Startmenü eine “Microsoft Windows AIK\Eingabeaufforderung für Bereitstellungstools” (als Administrator). Erstellt in eurem Temp-Verzeichnis ein neues, leeres Verzeichnis, und tippt in die Kommandozeile dann folgendes ein:

imagex /mountrw $TEMP$\DVD\sources\boot.wim 2 $TEMP$\$DIR$

Damit mountet ihr das zweite in der boot.wim enthaltene Image zum Schreiben in den neuen Ordner. Erstellt euch nun folgende zwei Dateien auf eurem Desktop.

Datei 1: winpeshl.ini

[LaunchApp]
AppPath = wpeinit.exe
[LaunchApps]
cmd.exe, "/q /c %SystemRoot%\System32\mntdrv.cmd"
%SystemDrive%\setup.exe

Datei 2: mntdrv.cmd

@ECHO OFF
CLS
FOR %%i IN (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %%i:\nul (
  IF EXIST %%i:\imdisk\imdisk.inf IF EXIST %%i:\imdisk\setupcdrom.cmd IF EXIST %%i:\imdisk\setupimdisk.cmd IF EXIST %%i:\install\microsoft\windows_server_2008_r2\x64.iso (
    echo Found necessary files on %%i:\>>%SystemDrive%\mntdrv.txt
    pushd %%i:\imdisk
    echo Setting um ImDisk>>%SystemDrive%\mntdrv.txt
    setupimdisk.cmd>>%SystemDrive%\mntdrv.txt
    echo Setting up virtual CD/DVD drive, mounting image>>%SystemDrive%\mntdrv.txt
    setupcdrom.cmd %%i:\install\microsoft\windows_server_2008_r2\x64.iso>>%SystemDrive%\mntdrv.txt
  )
)

Hier darauf achten, die Pfade zum ISO entsprechend anzupassen. Kopiert nun diese beiden Dateien nach “$TEMP$\$DIR$\Windows\System32″.

Hintergrund des Ganzen: Wir werden die ISOs am Ende in einem Grub-Menü einbinden. Die ISOs werden hierbei gemappt, so dass die Installation startet. Sobald aber Windows PE die Protected Mode Treiber lädt, können wir nicht mehr auf die gemappten ISOs zugreifen. Mit diesen beiden Dateien starten wir nun zuerst die “wpeinit.exe” (übernimmt z.B. die Initialisierung von Plug & Play). Danach durchforsten wir die verfügbaren Laufwerksbuchstaben nach Anwesenheit eines Datenträgers und der Existenz der benötigten Dateien. Wurden diese gefunden, wird ImDisk geladen und das Installations-ISO in das virtuelle Laufwerk eingebunden. Abschließend wird das Windows Setup aufgerufen.

Als nächstes führt folgenden Befehl in der Kommandozeile aus:

imagex /unmount /commit $TEMP$\$DIR$

Damit unmountet ihr das Image wieder und übertragt die durchgeführten Änderungen.

Nun erstellen wir uns unser Boot-ISO mit dem Befehl (wie schon im Beispiel oben für Windows Server 2008 R2 x64):

oscdimg -lLABEL -t02/15/2011 -b$TEMP$\DVD\boot\etfsboot.com -m -u2 $TEMP$\DVD $TEMP$\x64.iso

Das Label könnt ihr selbst bestimmen, das Datum muss im Format “DD/MM/YYYY” angegeben werden. Bei Windows Vista x64 ist es nötig, statt “etfsboot.com” die “bootsect.exe” anzugeben.

Das so erstellte ISO packt ihr nun in das entsprechende Unterverzeichnis unter “\boot\microsoft” auf eurem USB-Stick.

Das originale Installations-ISO kopiert ihr nun in das entsprechende Unterverzeichnis unter “\install\microsoft” auf eurem USB-Stick. Benennt es bitte entsprechend der Architektur zu “x86.iso” oder “x64.iso” um.

Wie oben geschrieben, müssen diese Schritte für die verschiedenen Windows-Versionen entsprechend wiederholt und angepasst werden.

Wir sind nun fast am Ziel, drei Dateien fehlen uns noch auf dem Stick. Die ersten beiden finden ihr neues Zuhause unter “\imdisk”:

Datei 1: setupimdisk.cmd

rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 132 .\imdisk.inf

Datei 2: setupcdrom.cmd

Set fullname=%~1
imdisk -a -f "%fullname%" -m #:

Die letzte Datei, unser Bootmenü, findet sein Ziel direkt auf dem USB-Stick:

Datei 3: menu.lst

color white/black dark-gray/light-gray white/black white/black
timeout 30
default /default

title Memtest86
find --set-root /boot/other/memtest86/mt420.iso
map /boot/other/memtest86/mt420.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Vista Setup (x86)
find --set-root /boot/microsoft/windows_vista/x86.iso
map /boot/microsoft/windows_vista/x86.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Vista Setup (x64)
find --set-root /boot/microsoft/windows_vista/x64.iso
map /boot/microsoft/windows_vista/x64.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Server 2008 Setup (x86)
find --set-root /boot/microsoft/windows_server_2008/x86.iso
map /boot/microsoft/windows_server_2008/x86.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Server 2008 Setup (x64)
find --set-root /boot/microsoft/windows_server_2008/x64.iso
map /boot/microsoft/windows_server_2008/x64.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Storage Server 2008 Setup (x86)
find --set-root /boot/microsoft/windows_storage_server_2008/x86.iso
map /boot/microsoft/windows_storage_server_2008/x86.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Storage Server 2008 Setup (x64)
find --set-root /boot/microsoft/windows_storage_server_2008/x64.iso
map /boot/microsoft/windows_storage_server_2008/x64.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows 7 Setup (x86)
find --set-root /boot/microsoft/windows_7/x86.iso
map /boot/microsoft/windows_7/x86.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows 7 Setup (x64)
find --set-root /boot/microsoft/windows_7/x64.iso
map /boot/microsoft/windows_7/x64.iso (0xff)
map --hook
chainloader (0xff)
boot

title Windows Server 2008 R2 Setup (x64)
find --set-root /boot/microsoft/windows_server_2008_r2/x64.iso
map /boot/microsoft/windows_server_2008_r2/x64.iso (0xff)
map --hook
chainloader (0xff)
boot

Die menu.lst müsst ihr natürlich entsprechend euren Vorstellungen anpassen. So braucht zum Beispiel nicht jeder noch zusätzlich Memtest86 auf dem Stick

Der größte Vorteil bei dieser Methode ist: Die Installations-ISOs liegen in ihrer Originalform auf dem USB-Stick vor und können so mit einem entsprechenden Brennprogramm einfach wieder auf DVD gebrannt werden (z.B. wenn ein Freund seine DVD verloren hat, der Key aber noch vorhanden ist).

So, ich hoffe, dass ich nichts vergessen habe. Ist einiges an Gefrickel, einiges könnte man evtl. noch eleganter lösen, aber nach diesem Prinzip solltet ihr erst mal in der Lage sein, euren eigenen Multi-Installations-Stick zu erstellen.

So stay tuned…

Ein neuer Tag, ein neues Projekt…

Ein Projekt mit etwas “verzwickteren” Anforderungen…

Wer kennt es nicht: Man meldet sich an seinen Rechner an, benutzt ein Programm, und beendet es wieder. Alles ganz normal. Was zum Teil für eine Technik dahintersteckt, wird einem nicht ersichtlich. Allein so eine feine Sache wie Single Sign-On ist vielen nicht bekannt, und diejenigen, die wissen, was dahinter steckt,  möchten es nicht mehr missen.

Gut, diese Story geht noch ein bisschen darüber hinaus. Soll aber auch nicht so wichtig sein. Fangen wir am besten mal an…

Für einen Kunden sollen wir eine Software-Lösung entwickeln. Es soll dabei aus zwei Teilen bestehen: dem Webservice, der die Daten bereitstellt, und ein Client, der auf die vom Webservice bereitgestellten Daten zugreift und diese dem Benutzer präsentiert. Zusätzlich befindet sich im Hintergrund eine Datenbank, in der sich die Daten, die vom Webservice bereitgestellt werden, befinden.

Soweit alles noch kein Problem, ist ja nichts Ungewöhnliches. Das Rollen-Rechte-Konzept sieht nun vor, dass der Benutzer des Clients mittels Windows-Authentifizierung am Service angemeldet wird und die Credentials dann benutzt werden, um sich an der Datenbank selbst ebenfalls per Windows-Authentifizierung anzumelden. Man ahnt nichts Böses…

Double Hop Issue

Doch genau hier steckt der Teufel im Detail: Die Credentials müssen vom Client an den WebServer und von diesem aus an den DBServer weitergegeben werden. Befinden sich diese auf verschiedenen physikalischen Maschinen, so hat man ein Problem: das Double Hop Issue. Standardmäßig ist es nämlich nicht möglich/erlaubt, die Credentials weiterzugeben. Hierzu müssen ein paar Anforderungen an die Infrastruktur erfüllt werden:

• Die Domäne befindet sich mindestens in der Domänenfunktionsebene Windows Server 2003
• Benutzer melden sich mittels Windows-Authentifizierung am Webservice an
• Autorisierte Benutzer der Datenbank werden mit der Windows-Authentifizierung eingetragen
• Das Kerberos-Token muss vom WebServer an den DBServer weitergegeben werden (Einrichtung der Delegation)

In welcher Domänenfunktionsebene die Domäne arbeitet, lässt sich relativ schnell im MMC-SnapIn “Active Directory-Benutzer und -Computer” herausfinden. Eigenschaften der Domäne öffnen, dort steht dann auch schon die Funktionsebene unter der Registerkarte “Allgemein”. Eventuell muss man sie noch heraufstufen; dies geschieht im Kontextmenü der Domäne.

Die Windows-Authentifizierung im IIS lässt sich unter den Eigenschaften der Website->Verzeichnissicherheit->Authentifizierung und Zugriffsteuerung aktivieren. Den anonymen Zugriff lassen wir zunächst noch aktiviert.

Die Einrichtung der Benutzer für die Datenbank erkläre ich jetzt nicht, da man hier selber entscheiden soll,  ob nun jeder Benutzer einzeln eingetragen oder man das lieber über eine eigene Gruppe, die im Active Directory hinterlegt ist, regelt.

Letzter Punkt: Einrichtung der Delegation. Damit das Kerberos-Token erfolgreich seinen Weg vom Client über den WebServer zur DB findet, müssen die “Service Principal Names” korrekt registriert und die Delegation zwischen den einzelnen Computerkonten eingerichtet werden. Hierzu auf dem Domain Controller folgendes ausführen:

setspn -l <dbserver>

Sollte man hier Einträge nach dem Schema “MSSQLSvc/<dbserver>” sowie “MSSQLSvc/<dbserver-fqdn>” finden, so ist dies schon mal nicht schlecht. Ansonsten müssen diese noch über folgende Befehle registriert werden:

setspn –a MSSQLSvc/<dbserver>:<Port bzw. Name der SQL Server-Instanz>
setspn –a MSSQLSvc/<dbserver-fqdn>:<Port bzw. Name der SQL Server-Instanz>

Ist dies geschehen, machen wir uns auf und suchen das Computerkonto des Rechners, auf dem der Webservice läuft. In den Eigenschaften des Kontos wählen wir die Registerkarte “Delegation”, und wählen hier “Computer bei Delegierungen angegebener Dienste vertrauen”->”Nur Kerberos verwenden”. Unter Hinzufügen->Benutzer oder Computer geben wir nun den Rechnernamen des DBServers ein, und wählen nach einem Klick auf OK den MSSQLSvc-Eintrag aus. Ein weiterer Klick auf OK, und die Konfiguration sollte damit fertig sein.

Anpassung der WCF-Webservices

Leider habe ich die genaue Konfiguration über HTTP nicht mehr vor Augen, es soll jedoch gesagt sein, dass wir als Binding das wsHttpBinding einsetzten. Die Umstellung des Bindings auf SSL gab dann aber Probleme: Sobald wir

<wsHttpBinding><binding name="wsHttpsBinding"><security mode="Transport"><transport clientCredentialType="Windows"></security></binding></wsHttpBinding>

als bindingConfiguration der Endpoints in der web.config benutzten, schmiss uns der Service eine Fehlermeldung entgegen, dass das Binding keine Sessions unterstützt oder diese nicht richtig konfiguriert seien. Die genaue Ursache ist uns bisher noch nicht klar, da es an sich zwei verschiedene Baustellen sind.

Die Lösung brachte uns ein CustomBinding mit folgenden Parametern:

<customBinding><binding name="customHttpsBinding"><reliableSession /><httpsTransport authenticationScheme="Negotiate" /></binding></customBinding>

Was noch zu erwähnen ist: Wenn die Endpoints mittels bindingConfiguration auf HTTPS umgestellt werden, sollten/müssen die Bindings der Metadata-Exchange-Endpoints (kurz: mex) auf “mexHttpsBinding” umgestellt werden. Hier ein kurzes Beispiel:

<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />

Dann noch unter

<behaviors><serviceBehaviors><behavior name="de.ecw.prunkster.TestService"><serviceMetadata httpsGetEnabled="true"></behavior></serviceBehaviors></behaviors>

sicherstellen, dass auch wirklich httpsGetEnabled auf true gesetzt ist. Das sollte es dann gewesen sein.

Mal wieder was ein bisschen schreiben, auch als kleine Gedächtnisstütze, da mir das ganze Prozedere ein weiteres Mal bevorsteht.
Heute möchte ich euch kurz zeigen, wie man seine Congstar-Box (oder baugleiche Geräte, es steckt in Wirklichkeit ein Speedport W701V bzw. FritzBox 7170 drin) ‘freetzt’. Dies bedeutet, die alte Firmware kommt runter, statt dessen wird die von AVM aufgespielt, inkl. dessen Web-Interface und Einstellmöglichkeiten.

Nicht lang labern, einfach mal zeigen

Die Anleitung im Forum von IP-Phone ist schon sehr detailliert, dennoch will ich hier kurz meine Herangehensweise erläutern.

Da ich nicht sofort meine Hauptbox flashen und so einen Wegfall unseres Internetzugangs riskieren wollte, musste ich zunächst etwas warten, bis die ersteigerte “Ersatzbox” den Weg zu mir nach Hause findet. Noch am selben Abend setzte ich mich dann daran, und bereitete zunächst alles vor.

Benötigt wurden ein aktuelles Linux-System (ich benutzte Ubuntu 9.10), am einfachsten erstmal in einer VM installiert. Die VM habe ich so konfiguriert, dass ich zwei Netzwerkverbindungen zur Verfügung stehen hatte: eth1 direkt an mein Kabel-LAN, an dem auch die Flash-Box hängt, eth0 dagegen NAT ohne zusätzliches Port-Forwarding, um meine Hauptbox erstmal nicht zu gefährden. Schnell Ubuntu installiert und mittels “sudo apt-get update && sudo apt-get upgrade” auf den aktuellen Stand gebracht.

Nachdem dies geschehen war, lud ich mir hier das aktuelle Speed-to-Fritz-Script herunter. Entpackt auf dem Desktop, öffnete ich ein Terminal, wechselte mittels ‘cd Desktop/’ in den entsprechenden Ordner, und führte per ‘./download_speed-to-fritz.sh’ das Script das erste Mal aus. Es begann, ein paar benötigte Paktete zu installieren (z.B. SubVersion), kurz darauf sah ich auch schon die Konfigurationsoberfläche des Flash-Tools.

Hier wählte ich zunächst nur unter “Hardware Type” den “Speedport W701V”  aus. Alle weiteren Pakete interessierten mich zu diesem Zeitpunkt noch nicht, erstmal wollte ich schauen, was schon ohne Erweiterungen nur mit der AVM-Firmware möglich ist.

Hat man den entsprechenden “Hardware Type”  gesetzt, kann man die Konfiguration auch schon mittels “Exit” verlassen. Die folgende Abfrage mit ‘Yes’ bestätigt, beginnt das Script, die aktuelle AVM-Firmware herunterzuladen und entsprechend ein bisschen umzubasteln. Nach zwei Bestätigungen und einem Neustart der Box (sollte automatisch geschehen) wird die Firmware auf die Box geladen.

Sobald dies geschehen ist, folgt eine Meldung “You should now reboot your box. Waiting for box to shut down for restart…”. Schön und gut, ob die Box bei mir nun einen automatischen Reboot hingelegt hat kann ich nicht mehr sagen, hab ich leider nicht mitbekommen. Jedenfalls fand das Script weder nach dem evtl. eingetretenen automatischen noch nach manuellen Reboots die Box wieder. Auch ein neuer DHCP-Request wegen des neuen IP-Adress-Bereichs brachte nichts, so dass ich das Script hier zunächst abbrach. Laut Anleitung sollten noch ein paar Umgebungsvariablen gesetzt werden, jedoch läuft meine Box auch so scheinbar ohne Probleme, deswegen mache ich mir da keine großen Sorgen drum.

Doch was bringt nun das Ganze?  Ein paar Sachen, die mir bei der AVM-Firmware aufgefallen sind, die (meiner Erinnerung nach) bei der Congstar-Firmware nicht vorhanden / möglich waren:

• mehr Informationen über den DSL-Anschluss
• Telefonbuch
• Weckruf
• Rufumleitung
• WDS mit WPA2
• Subnetmask <> 255.255.255.xxx
• statische Routen

Wichtig ist mir vor allem der Punkt -WDS mit WPA2-, da ich die Ersatzbox gerne zunächst als Repeater einsetzen wollte und WEP nicht “mehr” wirklich zeitgemäß ist.

Sicher habe ich noch einiges übersehen, werde demnächst mal beide Web-Interfaces direkt vergleichen. Muss ich dann aber machen, bevor ich die Hauptbox flashe

Auf alsbald

prunkster

Umso mehr freut es mich, euch heute wieder ein kleines Tool vorstellen zu können: eventcreatef.

Zunächst aber ein bisschen zur Vorgeschichte: Zum Sichern unserer wichtigen Daten auf unseren Maschinen benutzen wir ein eigenes Batchscript, das NTBackup antriggert und uns wöchentlich ein Full- sowie täglich ein Incremental-Backup erstellt. Diese werden xx Tage vorgehalten und danach verworfen.

Im Falle eines Fehlerfalles erfahren wir jedoch darüber nicht viel, dass das Backup nicht durchgelaufen ist, da die Logs etwas versteckt unter “%USERPROFILE%\Lokale Einstellungen\Anwendungsdaten\Microsoft\Windows NT\NTBackup\data” des angemeldeten Benutzers liegen und diese nicht unbedingt nach Erstellungsdatum durchnummeriert angelegt werden. Dies ist jedoch das kleinere Problem, vielmehr machten wir uns Gedanken, wo wir diese Logs einbinden können, damit sie zentral überwacht werden können.

Bei einer Raucherpause meinte Schakko dann, es wäre ganz angenehm, wenn die Logs in der Ereignisanzeige unseres Servers in einem neuen Protokoll angezeigt würden. Da dieser beim täglichen Routinecheck als erstes geprüft wird, werden die Fehler schnell gefunden. Eine kurze Recherche ergab, dass es hierfür von Microsoft ein Tool namens “eventcreate.exe” gibt, das auf nahezu allen Windows-Systemen bereits vorhanden ist. Hier der Link zum TechNet-Artikel zu eventcreate.exe.

Relativ schnell zu einem Ergebnis gekommen, eigene Ereignisse zu loggen, machte ich mich nun daran, den Inhalt von Textfiles als Beschreibung für das Event zu benutzen. Gar nicht so einfach, da eventcreate.exe für den Zeilenumbruch ein einfaches carriage return verlangt, die uns verfügbaren Möglichkeiten jedoch von cmd.exe als normaler String interpretiert werden. Etwas blöde…

Aus diesem Grunde ist dann auch eventcreatef.exe entstanden, da es genau hiermit aufräumt: es nimmt als Parameter alle in eventcreate.exe verfügbaren Parameter entgegen (und reicht diese einfach weiter, daher kommt es bei fehlerhaften Parametern auch zu einer Fehlermeldung von eventcreate.exe selbst), zusätzlich noch den Parameter “-f:” in folgendem Format:

[code language=bash]

eventcreatef.exe -f:c:\log.txt

[/code]

Hiermit wird die Datei “c:\log.txt” geparst, der Inhalt aufbereitet und anschließend als Beschreibung an eventcreate.exe weitergegeben. eventcreatef.exe wurde so entwickelt, dass man den Parameter “-f:” mehrmals angeben kann und die Dateien in der entsprechenden Reihenfolge übergeben werden.

Für die Hilfe von eventcreatef.exe ruft ihr das Programm ohne Parameter auf. Falls ihr die Hilfe zu eventcreate.exe braucht, könnt ihr diese oder alternativ wieder eventcreatef.exe mit dem Parameter “-h” aufrufen.

Ein kleines Beispiel eines Aufrufs, um eine Datei in die Ereignisanzeige eines anderen Rechners (%TARGETPC%) zu loggen (%SOURCE% ist die Quelle, die in der Ereignisanzeige verzeichnet wird):

[code language=bash]

eventcreatef.exe -t information -s %TARGETPC% -id 1000 -so %SOURCE% -f:c:\log.txt

[/code]

Genug geschrieben, hier soll nun die Source von eventcreatef.exe folgen. Es handelt sich dabei um ein kleines AutoIt-Script, das zu einer .exe kompiliert wurde. Wichtig hierbei ist nur, dass es sich um eine Konsolenanwendung handelt und dementsprechend als solche kompiliert werden muss.

[code language=plain]
#cs ----------------------------------------------------------------------------

AutoIt Version: 3.3.6.0
Author: Florian Weinert

Script Function:
Parsing textfile(s) for eventcreate.exe.

#ce ----------------------------------------------------------------------------

#include
#include

#RequireAdmin

If @Compiled = 0 Then
ConsoleWrite("This script needs to be compiled in order to run...")
Sleep(3000)
EndIf
If $CmdLine[0] = 0 Then
ConsoleWrite(@CRLF & @ScriptName & " Usage:" & @CRLF & @ScriptName & " -f:" & @CRLF & @CRLF)
ConsoleWrite("Example: " & @ScriptName & " -f:c:\backup.log" & @CRLF & @CRLF & @CRLF)
ConsoleWrite("This is some addition to eventcreate.exe by Microsoft Windows." & @CRLF)
ConsoleWrite("It parses textfile(s) in order to use them as description for an event message." & @CRLF & @CRLF)
ConsoleWrite("(C)opyright by Florian Weinert" & @CRLF)
Sleep(10000)
Exit
EndIf
Local $params = $CmdLineRaw
If StringInStr($params, "-f:") > 0 And StringInStr($params,"-d ") > 0 Then
ConsoleWrite("Please use either filename(s) or description for event message..." )
Sleep(3000)
Exit
EndIf
Local $command = "eventcreate "
Local $content = ""
Local $encapsulate = ""
If StringInStr($params, "-f:") > 0 Then
For $i = 1 to $CmdLine[0] Step 1
$filename = $CmdLine[$i]
If StringInStr($filename, "-f:") > 0 Then
$filename = StringReplace($filename, "-f:", "")
$params = StringReplace($params, "-f:" & $filename, "")
$params = StringReplace($params, "-f:" & Chr(34) & $filename & Chr(34), "")
If Not FileExists($filename) Then
ConsoleWrite($filename & " does not exist...")
Sleep(3000)
Exit
EndIf
$file = FileOpen($filename, 0)
If $file = -1 Then
ConsoleWrite("Unable to open file " & $filename)
Sleep(3000)
Exit
EndIf
While True
$line = FileReadLine($file)
If @error = -1 Then ExitLoop
$line = StringReplace($line, Chr(34), Chr(39))
$content = $content & $line & @CR
WEnd
$content = $content & @CR
FileClose($file)
EndIf
Next
$content = $content & @CR
$params = StringStripWS($params, 7)
$command = $command & $params & " /d "
$encapsulate = Chr(34)
Else
$command = $command & $params
EndIf
Local $process = Run($command & $encapsulate & $content & $encapsulate, @SystemDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)
Local $line
While True
$line = StdoutRead($process)
if @error Then ExitLoop
ConsoleWrite($line)
WEnd
While True
$line = StderrRead($process)
If @error Then ExitLoop
ConsoleWrite($line)
WEnd
[/code]

Hier ein Package mit allen notwendigen Dateien: Die Source eventcreatef.au3, die kompilierte eventcreatef.exe, sowie eventcreatef.cmd, Test1.txt und Test2.txt zum Ausprobieren.

Werde hier demnächst noch ein bisschen erweitern und ein kleines Tool einstellen, womit man eigene Protokolle in der Ereignisanzeige erstellen kann und ein Howto, wie man die entsprechenden Quellen den Protokollen zuweist.

So, ein bisschen Freizeit, daher hier mein Package zur Erstellung eigener Protokolle in der Ereignisanzeige und der Zuweisung der Quellen zu den Protokollen (Source & Binary). Sollte soweit selbsterklärend sein, EventLog entspricht dem späteren Namen des Protokolls in der Ereignisanzeige, EventSource der Quelle. Unter Umständen ist ein Neustart der Maschine notwendig, sollte die Zuweisung der EventSourcen nicht zur Laufzeit von Windows klappen.

Zunächst einmal meine Beweggründe, warum ich von VirtualBox zu VMWare wechseln wollte: dauernde Abbrüche der Netzwerkverbindungen zu den virtuellen Maschinen, kein einheitlich für mehrere Benutzer zugängliches Interface, und für mich auch wichtig, ein via Web zu bedienendes Management Interface. Da VMWare mir diese Sachen (und noch ein bisschen mehr) bietet, wollte ich nun also meine Maschinen entsprechend portieren. Hätte ich gewusst, auf was ich mich da einlasse…

Zunächst stand natürlich die übliche Google-Recherche an. Oft beschrieben, wie man von VMWare zu VirtualBox wechselt, aber den umgekehrten Weg konnte man an einer Hand (fast schon an zwei Fingern) abzählen. In den Tuts stand beschrieben, dass man über vboxmanage die Festplatte zuerst ins RAW-Format bringen soll und dann mittels qemu-img in vmdk konvertieren lässt.

Ins RAW-Format war sie auch (mehr oder minder schnell, eher zweiteres) gebracht, aber immerhin ohne weitere Probleme. Dies sollte sich jedoch nun ändern. Zunächst probierte ich mit der Windows-Portierung von qemu-img, die Festplatte zu konvertieren. Nicht von Erfolg gekrönt, dachte ich noch mal nach und mir fiel der VMWare Converter ein. Auf dem Server wollte er sich partout nicht installieren lassen, da ich angeblich nicht genügend Rechte hatte, die entsprechenden Dienste zu starten. Auf meinem Desktop dagegen funktionierte es einwandfrei. Wie ich dann jedoch feststellen musste, werden .vdi-Dateien davon nicht unterstützt.

Letzter Ausweg: Virtuelle Maschine mit Live-Ubuntu, qemu nachinstalliert, und diese dann auf die Konvertierung ansetzen. Schien auch zu klappen, zumindest wurden mir meine neuen Platten erstellt (was natürlich auch einige Zeit dauerte).

Gestern Abend kam ich dann schließlich zum Test, und fast wie erwartet, konnte ich von den konvertierten Platten nicht starten. In den Logs standen haufenweise Fehler, die mich vermuten ließen, dass die Konvertierung nicht hinhaut. Blöd…

So schnell gibt man(n) aber nicht auf. Meine modifizierte BartPE-CD in den VirtualBox-Maschinen gebootet, mittels Paragon Harddisk Manager ein Image der Festplatten gemacht, und diese wieder mit BartPE auf die (zuvor neu erstellten) Festplatten der VMWare zurückgespielt. Dann noch schnell die fehlenden VMWare Tools installiert, und alles lüppt

Die letzte LAN ist schon ein wenig her, umso mehr freuten wir uns alle auf ein gemeinsames Wochenende zusammen daddeln und Party machen. Also ging es am Freitag für meinen Bruder Sebastion und mich um ca. halb 7 los, die Sachen zusammenzupacken und ins Auto zu verfrachten. Kam mir zunächst so vor, als hätten wir was vergessen, war irgendwie nicht so viel zu schleppen wie sonst. Hat aber nichts gefehlt. Gegen 19:00 fuhren wir dann also aus Wolfsburg los und erreichten ca. 15 Minuten später unser Ziel in Flechtorf. Kenny, Timo und Dennis befassten sich bereits mit dem Aufbau, dem wir nach dem Ausladen unserer sieben Sachen beihalfen. Tische aufbauen, Switches & Router anschliessen, Kabel ziehen, Rechner anschliessen. Julian erschien auch recht zeitig und half mit.

Wie schon als Tradition ging es dann am Abend noch zu Real einkaufen. Man merkt, dass sich das Kaufverhalten von LAN-Junkies nicht wirklich geändert hat Noch einen Happen-Pappen bei Subway zum Essen eingekauft, wo auch Schakko dem Trupp beitrat, dann ging es zurück nach Flechtorf.

Späteren Abends kamen auch Jens und Tino von ihrer Weihnachtsfeier mit ihren Rechnern bewaffnet vorbei, womit der Trupp der Zocker vollständig war. Zusätzlich waren den Abend noch Marina, Tina und eine weitere Tina (!?) zu Besuch. Gegen glaube 5 ging es dann mit uns zu Ende und wir machten uns auf den Weg in unsere Betten.

Der Samstag verlief ähnlich, Einkauf bei Real und L4D2 standen auf dem Programm (nebenbei noch eine kleine Runde Q3A mit Basti). Gegen Abend wurde dann mit den eingetroffenen Gästen Party gemacht. Wie üblich wurde auch wieder bei Gyromaxx bestellt, wo wir komischerweise eine neue Kundennummer zugeteilt bekamen. Lässt sich leider nicht so leicht eine Eselsbrücke drauf finden, aber wird schon werden  Gegen 5 / halb 6 ging es dann wieder ins Bett, für einige auch etwas früher, wie z.B. Julian, der erschöpft aufs Sofa fiel und ziemlich direkt einratzte Musste sich jedoch noch ein paar “Tätowier-Versuchen” seitens Timo und Dennis erwehren…

Final Round: Der Sonntag wurde genutzt, um noch einen Döner zu verspeisen und einige Runden L4D2 zu zocken. Gegen ca. halb 5 war es dann soweit, der Abbau begann, es ging wieder zurück nach Hause.

Fazit: War wieder eine sehr gelungene LAN, und auch wenn das Wetter nicht immer mitspielte, hat das die Laune nicht wirklich gedrückt.

Teilnehmer:

• Jens / “Dokumentationengucker”  - Vollzeit
• Tino / ??? – (nahezu) Vollzeit
• Dennis / “Tino! … macht sich an Marina ran!” – Vollzeit
• Timo / Ruhezustand & laufender L4D2-Server, ne – Vollzeit
• Philipp / trotz Schnupfen immer eisern durchgehalten – Vollzeit
• Sebastian / trinkt neuerdings auch CaB!? – Vollzeit
• Julian / unser “Schnarchzeuger” – Vollzeit
• Gäste am Samstag: Sophie, Markus, Schakko, Tina, Marina, Sarah

Erinnerungswerte:

• Mars- / Twix- / Milkyway-Eis “selbstgemacht”
• Musel mag scheinbar keine Koalas
• Left 4 Dead 2 rockt!
• innere Verwesung (ist das erinnernswert? Naja…)
• “Drück endlich P / Keypad_Enter!”

Vorab: Bei UDA1.4 handelt es sich um eine VM, genauer gesagt um eine VMWare Maschine. Sobald diese gestartet ist, lässt sich das Deployment ziemlich komfortabel mittels Webinterface konfigurieren. Dabei ist das Interface relativ schlicht gehalten, tut aber doch genau seinen Zweck.

Da ich aber leider keine VMWare auf meinen Rechnern mehr laufen habe, sondern nur noch überall VirtualBox einsetze, musste ich UDA1.4 irgendwie dazu bringen, darauf zu laufen. Einfach die .vmdk in VirtualBox zu den virtuellen Medien hinzuzufügen brach leider mit einer Fehlermeldung ab, dass das Format scheinbar nicht erkannt werden konnte.

Nach einer kurzen Recherche im Programm-Ordner fand ich dann im VirtualBox-Ordner  das VBoxManage-CLI, mit dem man auch die virtuellen Platten konvertieren konnte. Also dann mal los! Folgender Aufruf brachte mich relativ schnell ans Ziel:

[sourcecode language="plain"]
“$path_to_virtualbox_folder\VBoxManage.exe” convertfromraw “$path_to_uda14_folder\uda14-flat.vmdk” “$path_to_uda14_folder\uda14-flat.vdi” –format VDI –variant Standard
[/sourcecode]

Hiermit wird die vorhandene .vmdk eingelesen und in eine neue .vdi konvertiert. Ich habe mich hier dafür entschieden, die Größe der .vdi dynamisch wachsen zu lassen, im Gegensatz dazu hatte die .vmdk eine feste Größe von 2GB. Hat aber keine weiteren Auswirkungen auf die Funktionalität gehabt.

Danach kann man die neue .vdi auch schon zu den virtuellen Medien hinzufügen, eine VM mit eben dieser virtuellen Platte erstellen und starten. Erstaunlicherweise machte es dem darunterliegenden Fedora auch keine Probleme mit dem Schwenker von einer SCSI auf IDE HDD.

Danach folgt das normale Geraffel halt, Netzwerkkonfiguration (standardmäßig horcht UDA1.4 auf die 10.0.0.104), ISOs ablegen, Verzeichnisse mounten, Templates anlegen, Treiber hinzufügen. Hierzu gibt es aber auch ein sehr hilfreiches Forum.

Noch eine kleine Sache für alle, die ihren bereits vorhandenen Microsoft DHCP Server weiterbenutzen wollen und nicht auf lost races stehen: guckt euch mal diesen Link hier an.

Schönen Abend noch!

MfG prunkster

templates-install.cmd:
[sourcecode language="plain"]
@echo off
for /F %%i in (‘dir /b *.wsp’) do (
cls
echo Installing Template: %%i
“%commonprogramfiles%\microsoft shared\web server extensions\12\bin\stsadm” -o addsolution -filename %%i
“%commonprogramfiles%\microsoft shared\web server extensions\12\bin\stsadm” -o deploysolution -name %%i -allowgacdeployment -immediate
pause
)
cls
echo Finished! If necessary, run iisreset (/noforce)!
pause
[/sourcecode]
Hat mir immerhin (geschätzt) knappe 30 Minuten Zeit eingespart, als wenn ich die Templates alle einzeln eingespielt hätte

Alles fing zunächst damit an, dass ein Kumpel mich fragte, ob ich bei ihm bei einem bekannten Hardwareversand etwas mitbestellen möchte. Er erklärte mir, dass er, wenn er zwischen Mitternacht und 6 Uhr Waren im Gesamtwert von glaube mind. 200 Euro bestellt, wären keine Versandkosten fällig. Nun ja, da ich ja schon lange mein kleines ITX Board haben wollte, kam dies recht gelegen Thx nochmal an BlackFog!

Bin leider nicht direkt nach Erhalt des Boards dazu gekommen, es zu testen, da mir noch RAM fehlte. Jetzt hab ich mir dann einfach einen Riegel aus meinem Rechner geschnappt und das Zotac startfertig gemacht.

Doch bereits die erste Schwierigkeit ließ nicht lange auf sich warten: Wie installiere ich nun meinen Windows Server 2003 R2 darauf? Das Board hat nur SATA-Anschlüsse, und das einzige SATA-CD/DVD-Laufwerk besitzt mein Bruder. Hmm, ne, ausbauen willste das jetzt nicht. Alternativlösung war das Booten und Installieren über Netzwerk (PXE). Schnell eine virtuelle Maschine aufgesetzt, RIS installiert, Image angefertigt. Alles bereit zum Start!

Pustekuchen. Erstmal musste ich PXE Enable im BIOS vom Zotac Board finden. Nicht dumm, wurde mir nach ca. 2 Minuten klar, wo ich zu suchen hatte (South Bridge Configuration). PXE an, erster Boot klappt, OS Auswahl kommt hoch. Doch nach der Auswahl des Betriebssystems ging es auch nicht sehr viel weiter, da mir laut Setup angeblich die Netzwerkkartentreiber fehlten. Mein Versuch, dieses noch im Image einzubinden, waren leider erfolglos.

Hmm, was nun? Kurz davor, meinen USB-Stick zu formatieren, bootfähig zu machen und die Windows-Install draufzupacken, fiel mir meine ehemalige Lösung für solche Probleme wieder ein: ICY Box mit IDE-CD/DVD-Laufwerk an USB anschließen und glücklich sein! Also WinServ03R2-CD auf DVD-RW gebrannt, eines meiner alten DVD-Laufwerke ausgekramt, angeschlossen, Bootreihenfolge geändert. Sollte laufen. Tat es aber nicht. Irgendwie kommen meine alten DVD-Laufwerke scheinbar nicht ganz mit dem Booten von DVD-RW klar. Also meinen Rechner beklaut, mit meinem Brenner ging es dann schließlich. Schwierige Geburt!

Windows Server 2003 R2 läuft nun also. Treiber installiert, soweit auch alles in Ordnung. Bis auf ein gelbes Fragezeichen im Gerätemanager, welches aber nicht weiter tragisch war. VirtualBox installiert, VM erstellt und Astaro Security Gateway v7 – c’t Home Edition installiert. Leider habe ich häufiger das Problem, dass ich einfach keine Verbindung zu den Bridged Interfaces der VM bekomme (nach einem gestrigen Test sowohl mit VirtualBox 3.0.8 als auch mit VMWare Server 1.0.9). Irgendwie keine Lust mehr auf dieses Geraffel, werde ich am Wochenende noch mal drüberschauen.

Dann kam ich zu der Hauptaufgabe, die das Zotac Board eigentlich übernehmen soll. Mein Plan war, dieses als HTPC zu verwenden und im Hintergrund als Server laufen zu lassen. Also schnell den CoreAVC Codec installiert (hatte damit die besten Erfahrungen gemacht), 1080p-Video rübergeschaufelt und ausprobiert. Das Ergebnis war zunächst ernüchternd: Das Video ruckelte, CPU-Last war auf Anschlag. Mein Verdacht, dass es am deaktivierten DirectDraw liegen könnte, bewahrheitete sich nicht. Blieb nur noch die Möglichkeit, dass die Decodier-Arbeit nicht wie gewünscht an den Grafikchip delegiert wird. Media Player Classic – Home Cinema heruntergeladen und installiert. Nun lief auch 1080p flüssig und mit einer CPU-Last des Players von 2 – 7%. Das alles nahezu geräuschlos. Eine einzige Sache nervt mich bei der Konstellation allerdings doch noch: Es wird leider kein Mehrkanalton an meinen Receiver ausgegeben, sondern nur ein stinknormales Stereo-Signal (Receiver ist per Toslink angeschlossen). Mal schauen, was ich da noch machen kann, aber ich denke, das wird schon

Insgesamt muss ich sagen: Ich bin von der Leistung des “Winzlings” überrascht, für meine Zwecke ist das Board vollkommen ausreichend. Wenn ich jetzt noch die Kleinigkeiten, welche oben aufgezählt sind, in den Griff bekomme, bin ich glücklich

P.S.: Derzeitig suche ich noch ein schönes Gehäuse für den HTPC, angeschaut habe ich mir schon einige (z.B. von JCP (besonders das MI 103 und 105), das Lian Li PC-Q07 (welches mir persönlich nicht zusagt, sieht aus wie ein kleiner Serverschrank), das Nesteq MS550 (auch recht schnuckelig), die APlus Cupid-Serie und einige SilverStones (sind mir leider etwas zu teuer)). Wenn hier wer noch ein anderes schickes Gehäuse im Auge hat, welches auch bezahlbar und mit ca. 60 Watt Netzteil, bitte einen Comment hinterlassen Thx!

//Edit[2009-10-26]: Mittlerweile entlocke ich dem Board doch ein DD / DTS Signal. Man merkt halt doch irgendwo, dass der Windows Server 2003 R2 eigentlich einen anderen Anwendungsbereich findet / finden soll als einen HTPC. Für alle, die wissen wollen, wie das Problem gelöst wurde: Hardwarebeschleunigung der Soundkarte auf Maximum, so hat es bei mir zumindest geklappt.

//Edi2[2009-10-28]: Auch die VM läuft Gott-sei-Dank mittlerweile stabil und ohne größere Aussetzer, heute Abend steht voraussichtlich ein Update an, dann hab ich erst mal Ruhe. Somit läuft eigentlich alles so, wie es soll, und ich kann nächste Woche während meines Urlaubs mal erste Tests meiner neuen Netzwerk-Umgebung machen…

Heute beschreibe ich kurz den Umbau der CPU-Lüfter auf meinem Tyan Tiger Board. Da es sich hierbei um ein Dual Xeon System handelt und die Lüfter zur Seite ausgerichtet sind, lässt es sich nicht in jedes Gehäuse einfach so unterbringen. Zum Glück gibt es noch die Möglichkeit, die Lüfter oben zu montieren.

Als erstes ein paar Bilder von der Ausgangssituation:

Bild 1

Bild 2

Die Käfige für die Lüfter sind mittels Schnappmechanismus an den Seiten angebracht. Diese muss man zum Entfernen der Käfige zur Seite drücken und den Käfig nach oben ziehen:

Bild 3

Bild 4

Nun hat man den Käfig vor sich liegen:

Bild 5

Der Lüfter wird durch die beiden Halterungen an der Seite festgehalten. Um diesen zu lösen, die Halterungen etwas zur Seite drücken und den Lüfter abziehen:

Bild 6

Die Seitenhalterungen werden nun nicht mehr benötigt und können entfernt werden. Dazu dreht man den Käfig um und drückt die beiden “Haken” zusammen:

Bild 7

Danach kann man die Seitenhalterung leicht nach unten hin abgewinkelt abnehmen:

Bild 8

Um den Lüfter nun oben auf dem Käfig anzuringen, muss die Schutzkappe entfernt werden (sprich herausbrechen):

Bild 9

Schließlich kann der Lüfter oben auf dem Käfig angebracht werden:

Bild 10

Es ist durchaus normal, dass der Lüfter nur mit zwei Haltenasen arretiert wird. Zum Schluss muss man nur noch den Käfig wieder auf dem Mainboard über den Kühlrippen anbringen und den Stromanschluss anschliessen. Fertig