Der Windows Treiberschutz unter Vista x64 unterbindet die Installation sämtlicher Treiber, die nicht signiert sind. Das ist auf der ersten Seite eine gute Sache, aber auf der anderen Seite kann es für Experten, die Software zum laufen bekommen wollen ein Hinderniss sein. Aktuell ist bei mir der VMWare Server die einzige Position, warum ich den Kernelschutz deaktivierten muss. Das muss basiert darauf, dass ich alle Virtuellen Maschienen auf VMWare laufen habe und mein PC 8GB Ram hat. Vista x32 akzeptiert nur 4GB Ram. Somit bliebe nur die Wahl Windows Server 2003 x32 Enterprise zu verwenden. Da der PC aber für den normalen Alltag genutzt wird und VMWare nur on Top läuft habe ich mich entschieden Vista x64 ohne Kernelschutz zu verwenden.

Hier die Anleitung:

Man deaktiviert die folgende GPO:

- Start -> Ausführen -> gpedit.msc
- Benutzerkonfiguration -> Administrative Vorgaben -> System -> Treiberinstallation -> Codesignatur für Gerätetreiber öffnen
- aktivieren und auf ignorieren stellen

Danach führt man die folgende Kommandozeile aus:

- Start -> Ausführen -> CMD
- bcdedit -set loadoptions \”DDISABLE_INTEGRITY_CHECKS”
- bcdedit.exe /set nointegritychecks ON

Danach kann man VMWare Server 1.0.3 installieren. Aber wehe man installiert das Patch mit der Nummer KB932596. In diesem Fall wird der PC nicht weiter machen. Daher nach der Update - Installation das Patch über Systemsteuerung -> Update das Patch wenn nötig deinstallieren oder aus der Liste ausblenden. Danach wird der VMWare Server bis zum SP1 wohl laufen. In der Zeit hat dann VMWare auch hoffentlich eine lauffähige Version 1.0.x auf dem Markt.

Eine Alternative ist noch die Treiber selbst zu signieren. Dies geht mit dem entsprechendem SDK und stellt einen heiden Aufwand dar, den ich nicht hier beschreiben möchte :))

Ich habe eine EXE Datei ein 2 DLL's die im selben Verzeichnis liegen. Die beiden DLL's haben je 2 Konfigurationswerte "Test1" + "Test2" / "Test3" + "Test4". Die Werte werden in der DLL beim kompilieren als Standardwerte eingebrannt. Nun habe ich nur die DLL Dateien und will die Werte Ändern... Wie geht das?

Unter der Voraussetzung, dass DLL's und EXE den selben Namensraum haben, kann man einfach "Test1", "Test2", "Test3" und "Test4" in der Config Datei der EXE angelegt werden. Die dort gesetzten Standardwerte überschreiben dann die kompilierten Standardwerte der DLL's.

Daher sollte in den DLL's unbedingt dokumentiert werden, welche Config Werte gesetzt werden müssen / können. Kommen hier Werte hinzu, so muss, man diese auch in die EXE einbauen.

Sind die Werte nicht im gleichen Namensraum vorhanden, muss ein Verweis auf den anderen Namensraum gesetzt werden, wie es Thomas Schissler in seinem Blog macht. Man beachte, dass sein Tipp nur für c# gilt und unter vb.NET ein anderer Zweig angelegt werden muss. Nämlich der im My.Settings Bereich.

Hier der Link zu Thomas Schisslers Artikel: http://www.artiso.com/ProBlog/PermaLink,guid,8c0f402f-5186-4b31-aaa1-778f57082fb9.aspx

2 Tage Arbeit hat mir eine Fehlende Exception in der Windows Workflow Foundation gebracht!

Ich habe einen einfachen Workflow gebaut und ihn mit SQL Persistence und SQL Tracking an einen SQL Server 2005 angebunden. Die Datenbank blieb jedoch manchmal leer und wurde nur in seltnene Fällen gefüllt. Wo sucht man da, wenn das Programm erfolgreich durchläuft und kein Fehler gemeldet wird? Im Quellcode. So habe ich 2 Tage gesucht und nichts gefunden. Doch wie durch ein Zufall habe ich die Bedingung Runtime.StopRuntime mitten drin als Auslöser für eine Exception gesetzt und diesmal kam auch eine, die mich zur Lösung des Rätsels brachte...

MSDTC nicht auf Server blub Verfügbar...

Tja, dann habe ich geschaut und den MSDTC Dienst eingeschaltet. Er war hier gestoppt worden. Tja, nachdem der Dienst lief, war erstens die Fehlermeldung weg und zum zweiten wurden nun immer alle Events geloggt. Daher bleibt nur die Frage, wo die Microsoft Entwickler die Exceptions für die WF versteckt haben. Für Tracking und Persistence sind sie auf jeden Fall zu sparsam gewesen und ich würde es gar als Bug bezeichnen.

FAZIT: VOR der Benutzung der Persistence und Tracking Services in der Windows Workflow Foundation MSSTSC Dienst starten!!! MSDTC steht übrignes nicht für Distributed Transaction Controller...

Ich hab den SQL Server 2008 installiert und habe keine großen Probleme bei der Installation gehabt. Der SQL Server 2008 ist nur eine Evolution zum SQL Server 2005 und auf den ersten Blick findet man keine großen Neuerungen.

• Was mir sehr gut ins Auge gestochen ist, ist dass auch weiterhin DTS Packages wohl unterstützt werden. Dies sollte ja eigentlich nicht mehr der Fall sein, aber es gibt ja noch haufenweise solche alten Packete. Hoffentlich bleibt das dann auch in der Final so!
• Was mir sehr negativ ausgefallen ist, dass der SQL Server 2008 sich nicht in das Visual Studio 2008 einklinckt, sondern das Visual Studio, was man gerade deinstalliert hat wieder installiert. Schlimmer noch ist aber, dass danach einem vom Windows Update wieder das SP1 um die Ohren bekommt. Das ist schade, denn das macht die Installation nicht kürzer. Dieser Punkt wird sich aber hoffentlich noch mit der nächsten Version ändern?!
• Im Inneren ist die XML Unterstützung aufpoliert worden, was nun die Nutzung alle XML Daten ermöglicht. Bisher war die XML Unterstützung ja noch nicht vollkommen ausgereift.
• Deutliche Verbesserung der Offline Fähigkeiten in Zusammenarbeit mit unterschiedlichen Clients und der Programmierung mit .NET 3.5 - in der Offiziellen Beschreibung steht zwar .NET 3.0 - aber das glaube ich nicht so ganz :)
• Die BI Funktionen haben sich laut Beschreibung deutlich erweitert. Dies ist aber nicht der Focus meines Tests gewesen.
• Das Policy Based Management von dem neuen SQL Server habe ich bisher noch nicht ausprobiert, es würde mich aber freuen, wenn die Berechtigungen noch weiter in ADS Kompatibilität gehen würden.

Alles in allem hat der SQL Server 2008 bis auf das XML noch keine "MUST HAVE" Features eingebaut. Aber vielleicht sehe ich das auch aktuell noch nicht so, wie man es schon bei der nächsten Beta sehen könnte :)

Ich verwende Windows Vista x64 als Hostsystem für VMWare Server, wie das geht, habe ich hier schon beschrieben :). Was gibt es aber für Probleme damit und was muss man beachten?

1. Kein Autosuspend der Virtuellen Maschinen bei VMWare
   Negativ ist mir beim VMWare Server aufgefallen, dass man beim Herunterfahren des Host Systems die Gast Systeme automatisch "abstürzen" lässt. Es gibt keine Funktion wie beim Virtual Server, dass alle Systeme in den Ruhezustand geschickt werden und dann erst der Server komplett zu Ende herunterfährt. Ein Skript hierfür ist allerdings in Arbeit. Wenn ich was Brauchbares habe, werde ist das hier einstellen.
2. Paralleleinsatz mit Virtual Server
   Der Paralleleinsatz vom Virtual Server war bisher immer problemlos möglich. Mit der aktuellen Version des Virtual Servers in Kombination mit VMWare Server und Windows Vista x64 bekomme ich aber immer Abstürze. Bisher habe ich nur herausfinden können, dass man Virtual Server Maschinen nur starten kann, wenn alle VMWare Maschinen gestoppt sind. Ob dies mit dem Zugriff auf die Hardwarevirtualisierung von 2 Programmen zu tun hat, kann ich leider noch nicht sagen. Sobald ich hier eine Lösung habe, schreibe ich die gleich mal.
3. Dateizugriff von einer Virtuellen Maschine mit Windows 2003 oder XP Betriebssystem
   Wenn ich von einer Virtuellen Maschine aus auf einen Netzshare auf dem Windows Vista x64 Host zugreife habe ich wiederholt Abbrüche bei größeren Dateien. Ich habe hier in der Liste der aktuellen Hotfixes einen gefunden und mir über das Formular des letzten Blogeintrages zusenden lassen. Fazit - nach 8 Stunden und ohne Komplikationen hatte ich einen Patch, der sehr sauber zu installieren war und das Problem auf Anhieb löst.
   http://support.microsoft.com/kb/931770/en-us
4. Fehlende Ressourcenzuweisung für die Prozessorlast
   Die Prozessorlast des virtuellen Systems lässt sich beim VMWare Server nicht begrenzen. Auf einer 2 Wege Maschine ist die Chance, dass der Server durch 2 virtuellen Maschinen Lahmgelegt wird aber noch nicht vorgekommen.
5. Netzwerkkarten auf Virtuellen 64 Bit Maschinen
   Die bei 64 Bit vorkonfigurierte Netzwerkkarte von AMD wird unter Windows Vista nicht weiter Supportet. In der Config Datei der virtuellen Maschine kann man jedoch manuell bearbeiten, dass es eine Intel 10/100/1000 Karte ist. Diese hat bei mir keine weiteren Probleme nach der Installation der VMWare Additons gebracht. Hierfür empfehle ich die Freeware VMX Builder und eine Sicherung der aktuellen Config Datei!

Bis auf die Punkte oben bin ich mit dem VMWare Server absolut zufrieden. Erst wenn die 64 Bit Virtualisierung von Microsoft verfügbar ist, wird wieder über einen Wechsel überlegt. Ob die Verteilung der Platten auf je 2 GB Teile dort funktioniert, was als 2. KO Kriterium für VWWare zählt dort auch geht, weiß ich nicht.

Aktuell schlägt VMWare Server auf jeden Fall das Microsoft Pendant!

Die Liste aller Hotfixes für Windows Vista ist bei der Fehlersuche extrem gut. Hier der Link mit deutschen Beschreibungen: http://www.drvista.de/vista-updates-and-patches/99-ubersicht-vista-hotfixes.html