blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

Windows Server 8 Resilient Filesystem ReFS

Microsoft geht es wieder einmal an: Das nächste Windows (Windows Server 8) wird ein neues Filesystem mitbringen: ReFS. Die Abkürzung steht für Resilient File System, also sinngemäß ein "elastisches, belastbares" Dateisystem, so schreibt das Windows engineering team in seinem Blog Post Building the next generation file system for Windows: ReFS. ReFS (Codename Protogon) basiert vollständig auf dem derzeitigen NTFS Filesystem und wird mit dem neuen Windows 8 Server eingeführt werden. Der Zugriff auf ReFS Daten von Clients aus wird genauso unterstützt werden wie NTFS-Zugriff.. NTFS-Funktionen wie "BitLocker encryption, access-control lists for security, USN journal, change notifications, symbolic links, junction points, mount points, reparse points, volume snapshots, file IDs, and oplocks" werden natürlich genauso unterstützt. Wichtig für Developer: Die File APIs werden kompatibel sein. Die Verbesserungen in ReFS gehen von der Unterstützung von extrem großen Speichergrößen bis hin zu selbstkorrigierenden Daten und "Shared storage pools across machines for additional failure tolerance and load balancing". Alle Details im Building Windows 8 Blog. Wir dürfen also gespannt sein auf Windows Server 8!

Hyper-V cool stuff

Hyper-V ist die eingebaute Virtualisierungstechnologie in Microsoft Windows. Auch wenn Hyper-V sehr rasch und einfach einzusetzen ist, gibt es doch viele interessante Themen für alle IT-Pro´s, die Hyper-V optimieren und warten müssen. Im partnerblog.at hat Christian Decker dazu einen sehr guten Link-Tipp gepostet: partnerblog.at: Interessante Webseite Eine feine Tipp-Sammlung! Und auch gleich eine gute Idee, interessante Hyper-V Links durchzugehen und meine kleine Link-Sammlung zum Thema Hyper-V zusammen zu stellen. Here it is! Microsoft.de: Microsoft Hyper-V Server 2008 R2 TechNet: Einführung in Hyper-V in Windows Server 2008 Microsoft.com: Microsoft Hyper-V Server 2008 R2 faq-o-matic.net faq-o-matic.net: Unsere Adventstipps 2011 zu Hyper-V server-talk.eu - Der Schweizer Blog rund um Server Lösungen msdn.com: Clustering and High-Availability msdn: Virtual PC Guy's Blog - Ben Armstrong, Hyper-V Program Manager TechNet: John Howard - Senior Program Manager in the Hyper-V team TechNet: Jose Barreto's Blog TechNet: germanvirtualizationblog rachfahl.de: Podcasts rund um Private und Public Cloud Windows Sysinternals: Disk2vhd searchservervirtualization.techtarget.com TechNet: Virtualization tools and stuff. By Matthijs ten Seldam PowerShell management Library for Hyper-V TechNet: Ask the Core Team - Windows Server Core Team Viel Spaß beim Lesen!

Microsoft kündigt Fix für ASP.NET #hashDoS an-Azure wird automatisch gefixt

Wie gestern in "Workaround gegen Denial of Service Attacke in ASP.NET #hashDoS #28C3" gewarnt, besteht bei Webservern (Windows Servern mit IIS) eine Verwundbarkeit gegen "hash collision attacks" #hashDoS. Angreifer können mit speziell präparierten HTTP-Requests eine Hash-Tabelle mit einer großen Zahl von Werten befüllen, deren Keys in demselben Hash-Code aufgelöst werden - damit sinkt die Performance der HashTable auf eine simple Linked List. Das kann bei repetitiven Requests zu einer Überlastung des Webservers führen, sinngemäß so: Betroffen ist auch ASP.NET. Microsoft arbeitet bereits an einem Fix, so schreibt ScottGu in seinem Blog: Ab heute, 29. Dezember, etwa 19h (unsere Zeitzone) wird ein Fix verfügbar sein! ASP.NET Security Update Shipping Thursday, Dec 29th ..."We are releasing the security update via Windows Update and the Windows Server Update Service.  You can also manually download and install it via the Microsoft Download Center. We will release the update on Thursday, December 29th at approximately 10am Pacific Time (US and Canada). We are announcing it ahead of time to ensure that administrators know that the security update is coming, and are prepared to apply it once it is available." Der Fix wird per Windows Update, Windows Server Update Service und im Microsoft Download Center verfügbar sein. Gestern bekannt gegeben - heute gefixt. Wow, das nenn ich wirklich rasch! Achja, betrifft die #hashDoS Verwundbarkeit Windows Azure Kunden? Nein, ScottGu schreibt: "Customers on Azure that have their Hosted Services OS servicing policy set to "Auto" (which is the default) will have their environments automatically updated to include the security update. There is no action required for this." Sehr praktisch, diese Cloud Services... Alle IT-Pros mit eigenen Webservern: Bei Verfügbarkeit Fix einspielen!!

Workaround gegen Denial of Service Attacke in ASP.NET #hashDoS

Achtung Web-Developer und Web-Hoster! Seit kurzem ist eine DoS-Attacke gegen Webserver bekannt, die zur Überlastung von Websites führen kann. Die Verwundbarkeit läuft unter #hashDoS und #28C3, sie führt "hash collision attacks" gegen Websites durch. Wie funktioniert #hashDoS? Technisch gesehen werden durch einen HTTP Request "teure" Hash Table Berechnungen ausgeführt, die - selbst auf sehr leistungsfähigen CPU´s - abertausende Form-Werte berechnen und so zu einer Überlastung = Stillstand des Webservers führen können. Selbst kleine HTTP-Requests können sehr rechenintensiv werden: Die Verwundbarkeit kann von anonymen Angreifern ausgenutzt werden, um in ASP.NET einen speziell präparierten HTTP-Request mit beispielsweise 100kB abzusetzen. Dieser Angriff kann eine CPU zu 100% auslasten und zwischen 90 und 110 Sekunden dauern. Durch mehrfache Wiederholung der Angriffe kann ein Stillstand erzeugt werden. (siehe 3.) CPU-Grafik von 3. Hier liegt die CPU-Last eines 4-Core Servers kontinuierlich bei 25% - nur durch einen WorkerProcess. Weitere Informationen finden Sie in 4. Wen betrifft es? Eigentlich alle Webserver im Internet. Alle Versionen des .NET Frameworks sind verwundbar. (siehe 1.) #hashDoS betrifft nicht nur Microsoft-Technologie (ASP.NET), sondern es sind alle Systeme gefährdet: Java, Python, Ruby 1.8, PHP, etc. Wann sind Windows Server betroffen? Verwundbar sind Windows-Systeme mit IIS-Rolle, wenn ASP.NET Websites mit diesen Content-Types (siehe 2.) verwendet werden: "application/x-www-form-urlencoded" oder "multipart/form-data" Andernfalls droht keine Gefahr durch #hashDoS. Wie können ASP.NET Websites geschützt werden? Eigentlich simpel - durch Limitierung des HTTP-Requests: Hier die Empfehlungen aus TechNet: Wenn Ihre Applikation ViewState verwendet: In web.config die maximale HTTP-Request Größe auf 200KB beschränken: <configuration> <system.web>   <httpRuntime maxRequestLength="200"/> </system.web> </configuration> Wenn kein ViewState verwendet wird: In web.config die maximale HTTP-Request Größe auf 20KB beschränken: <configuration> <system.web>   <httpRuntime maxRequestLength="20"/> </system.web> </configuration> ...abhängig vom Szenario. Nicht vergessen: Eventuelle File Uploads in der App! Die Empfehlung: Wenn Sie befürchten, Ziel eines Angriffs durch #hashDoS zu werden, führen Sie obige Schritte durch. (siehe 3.) Gibt es einen Fix? Ein Fix ist in Arbeit: "Our teams are working around the clock worldwide to develop a security update of appropriate quality to address this issue." (siehe 1.). Auch an Forefront wird gearbeitet. Es werden zwei neue "Rules" hinzugefügt werden, welche den Content Type prüfen und die Anzahl der Form values im HTTP-Request prüfen (> 1000 = Deny): "Microsoft's own Forefront Threat Management Gateway (TMG) will receive an update containing a signature for this issue today. (Vulnerability: Win/ASPNET.POST.DoS!NIS-2011-0001)" (siehe 3.) Hier alle Links mit weiterführenden Informationen gesammelt: Microsoft releases Security Advisory 2659883, offers workaround for industry-wide issue TechNet: Microsoft Security Advisory (2659883) -  Vulnerability in ASP.NET Could Allow Denial of Service More information about the December 2011 ASP.Net vulnerability Eine sehr feine Erklärung liefert Effective DoS attacks against Web Application Plattforms - #hashDoS Allgemein: Microsoft Security Response Center (MSRC) Home

Cannot connect to WMI provider error

Zu den Weihnachtsfeiertage sieht man nichts Böses ahnend per VPN im 350km entfernten Büro nach ... und macht ein paar Server Wartungsarbeiten. Wie Murphy´s Law so treffend formuliert: Wenn etwas schiefgehen kann, dann wird es auch schiefgehen. Ganz nach diesem Motto hat sich einer der Windows Hyper-V Hosts verabschiedet und hängt. Nur Strom-aus (Remote Console sei dank!) half, den Host wieder zum Leben zu erwecken. Das RAID baut sich in den nächsten Stunden also wieder auf und synct sich - wenigstens muss der Rechner auch arbeiten... aber das ist eine andere Geschichte. Hilft wirklich, wenn man nicht vor Ort ist und nichts mehr geht: Restart per Remote Console. Nun gut, auf zur Kontrolle der Virtual Machines. Einige der VMs auf dem Host haben den Neustart per Power Recycle etwas übel genommen und sind reparaturbedürftig. Eine davon ist eine SQL Server 2008 Maschine, die als Database Mirror fungiert. Das SQL Management Studio verbindet sich brav zum SQL Server Dienst und dieser läuft. Gut, der Database Mirror arbeitet wieder... aber: Der SQL Server Configuration Manager verweigert seinen Dienst: "Cannot connect to WMI provider. You do not have permission or the server is unreachable." An den Berechtigungen dürfte es nicht liegen - schließlich wurde nichts geändert. Der Hinweis, dass nur SQL Server 2005 und später verwaltet werden kann ist zwar nett, aber ebenso nicht zutreffend. Also liegt es wohl an der Verbindung zu WMI - Windows Management Instrumentation (WMI) ist eine grundlegende Windows-Verwaltungstechnologie. Damit können lokale Computer als auch Remotecomputer verwaltet werden. Zum Glück hat die Suche rasch ein Ergebnis geliefert: Es gibt einen Microsoft Knowledge Base Artikel 956013, der sich mit diesem Problem befasst: http://support.microsoft.com/kb/956013/en-us Die Ursache wird hier so beschrieben: "This problem occurs because the WMI provider is removed when you uninstall an instance of SQL Server 2008.". Das ist in meinem Fall zwar nicht passiert, aber das Problem dürfte dasselbe sein: Die Verbindung des SQL Server Configuration Managers zu WMI klappt nicht. Die Reparatur erfolgt in der CommandLine mit dem mofcomp Tool: mofcomp ist ein Dienstprogramm des Betriebssystems zum Kompilieren von MOF-Dateien, durch das die Informationen in diesen Dateien dem WMI-Repository hinzugefügt werden - siehe auch  Geheimnisse von Windows Management Instrumentation. Wenn das entsprechende MOF File im SQL Verzeichnis vorhanden ist, kann das Problem so behoben werden: cd "C:\Program Files (x86)\Microsoft SQL Server\100\Shared" mofcomp sqlmgmproviderxpsp2up.mof Dadurch wird die Konfiguration des SQL Server Configuration Manager repariert. Die Konsole funktioniert nun wieder: Die "WMI Provider" Fehlermeldung war  - zur Abwechslung - mal einfach zu lösen, mofcomp sei Dank. Achja: Für alle IT-Pro´s, welche die (hoffentlich) ruhige Zeit nutzen wollen, noch ein paar (Download-) Tipps zum Evaluieren: Microsoft Virtual Academy Download von Windows Server 2008 R2 mit Service Pack 1 Download Microsoft Hyper-V Server 2008 R2 mit Service Pack 1 Download von Microsoft System Center 2012 Vorabversion So, fortsetzen mit dem Fixen der weiteren VMs ... Stoff für weitere Artikel.

IIS7 Websites übersiedeln - Teil 3 (HTTP Error 503, Service Unavailable)

Im besten Fall funktioniert IIS7 Websites übersiedeln - Teil 2 problemlos und die Websites laufen ohne weitere Anpassungen auf der Zielmaschine. Es gibt jedoch auch ein paar Fallstricke: Die Konfiguration von Quellserver und Zielserver müssen ident sein. Das bedeutet, dass alle Windows Komponenten und Module ebenso auf der Zielmaschine vorhanden sein müssen. Das ist - gerade wenn die Windows Server 2008 Maschinen von unterschiedlichen Personen oder zu unterschiedlichen Zeiten installiert wurden - selten der Fall. Ist die Konfiguration unterschiedlich, folgt nach der Übernahme mit hoher Wahrscheinlichkeit der HTTP Fehler 503 beim Ansurfen eines Webs: HTTP Error 503. The service is unavailable. Die erste Quelle der Fehlersuche stellt meist die Ereignisanzeige dar. Hier ist es recht "rot": Bei der Fehleranalyse sind vor allem Beschreibung und Event-ID wichtig: Ereignis-ID: 2280 Beschreibung: Fehler beim Laden der Modul-DLL C:\Windows\System32\inetsrv\redirect.dll. Die Daten enthalten Fehlerinformationen. Aha. Beim Nachsehen im Verzeichnis stellt man so rasch fest: Die Datei redirect.dll fehlt... Da würde ich mich als Webserver auch beschweren, wenn Module in der Konfiguration verwendet werden, die gar nicht installiert sind. An dieser Stelle noch ein Tipp: In TechNet findet sich eine Beschreibung des Internet Information Services (IIS) 7.0 - mit allen abhängigen Modulen und Error Codes (in den Subknoten der Module, z.B. IIS Worker Process Tracing etc.). Was passiert, wenn Komponenten fehlen? Meistens beendet sich der Application Pool beim ersten Aufruf von selbst - das ist auch in meinem Szenario passiert. Der App Pool kann gestartet werden, beendet sich jedoch wieder beim Ansurfen. Siehe auch: Where did my IIS7 server go? Troubleshooting 503 "service unavailable" errors Die Lösung: Nachinstallieren der fehlenden Komponenten! Das Nachinstallieren können Rollen oder auch Features sein. Am besten vergleichen Sie die Konfigurationen beiden Maschinen (manchmal denke ich, genau dafür wurden die breiten Flachbildschirme entwickelt...). In meinem Fall hatte ich "Webserver/URL Redirect" und auch Komponenten aus dem Web Platform Installer nachzuinstallieren (Media Services, URL Rewrite sowie einige weitere Funktionen...). Bei mir war noch ein weiterer kleiner Stolperstein vorhanden: Die Rollen konnten nicht hinzugefügt werden. Das Setup endete mit einem Fehler: This problem can be caused by system corruption on your computer. This occurs for various reasons, including but not limited to other applications overwriting of .NET files or corrupted hard disk sectors. Es gab anscheinend ein Problem mit dem .NET Framework. Ge-bing-t. Microsoft FixIt konnte dem abhelfen: You receive "0x80070643" or "0x643" error codes when you try to install .NET Framework updates through Windows Update or Microsoft Updates (KB976982) Danach klappte die Nachinstallation der erforderlichen Rollen ohne Fehler: Nach Installation Web ansurfen und Fehler analysieren. Wieder nachinstallieren bzw. Konfiguration anpassen. So kann man sich Schritt für Schritt an die weiteren Fehler (fehlenden Module) herantasten und diese beheben. Noch ein Hinweis: Alternativ können natürlich auch die fehlenden Module direkt in der Datei C:\Windows\System32\inetsrv\config\applicationHost.config editiert werden und die fehlenden Module (Zeilen) entfernt werden - vorausgesetzt, man weiß, was man tut... (Backup des Config-Files versteht sich da von selbst). Das wars! Mit dieser kleinen Reihe sollte das Übersiedeln von Websites mit IIS7 rasch erfolgen können. Auch hier mein Tipp: Wenn Sie das oder ähnliche Szenarien selbst in einer Testumgebung ausprobieren wollen, folgen Sie einfach dem Link Windows Server 2008 R2 mit Service Pack 1 und laden und installieren Sie die aktuellste Windows Server Version aus dem TechNet Eval Center! Viel Erfolg!

IIS7 Websites übersiedeln - Teil 2

Wie in IIS7 Websites übersiedeln - Teil 1 beschrieben, können Webseiten einzeln übersiedelt werden. Wie funktioniert nun die komplette Übernahme aller Websites und Einstellungen zwischen zwei Windows Server 2008 R2 Maschinen? Hier ein Weg zur Schritt-für-Schritt Übernahme. Übersiedeln eines Webservers Mit Windows Server 2008 R2 klappt das recht schnell durch den Export der Konfiguration des IIS7. Zunächst wird auf der Quellmaschine der IIS Manager geöffnet und der Webserver ausgewählt. In der Verwaltung wird nun das Modul "Freigegebene Konfiguration" (Shared Configuration) ausgewählt: In obigem Screenshot existieren auf der Maschine (work12) einige Webs mit konfiguriertem FTP. In der TaskPane rechts kann die "Konfiguration exportiert" werden: Wählen Sie in der folgenden Dialogbox den Pfad für die Export-Files aus und vergeben Sie ein sicheres Kennwort. Hinweis: Das Kennwort muss tatsächlich "sicher" sein, d.h. Sie können nur fortsetzen, wenn es lang genug ist, Groß- und Kleinschreibung und Zahlen enthält. Nachdem ich mehrmals vergeblich Kennworte eingetragen habe hier mein Tipp: Ein Kennwort wie  "MeinGeheimesKennwort%2011" entspricht den Richtlinien - huch jetzt habe ich mein Kennwort verraten - aber so klappts. Als Ergebnis werden im Exportverzeichnis diese drei Files erstellt. Die .config Dateien sind lesbar und änderbar, das .key File enthält das verschlüsselte Kennwort. Diese Dateien müssen nun auf den Zielrechner B kopiert werden. Eine kleine Warnung vorweg: Beide Windows Server müssen dieselben Komponenten installiert haben, damit die Übernahme klappt (siehe auch Teil 3). Und noch ein Tipp: Es ist keine schlechte Idee, den Sicherungsvorgang wie oben auch auf dem Zielrechner durchzuführen, um ein Backup der IIS-Konfiguration zu haben - falls etwas schiefläuft... Auf dem Zielrechner öffnen Sie genauso IIS Manager und wählen den Serverknoten (hier: work13) aus und klicken auf "Freigegebene Konfiguration" (wie oben). Hier markieren Sie den Schalter "Freigegebene Konfiguration aktivieren" und wählen Sie den Pfad aus, wo Sie die drei Dateien hin kopiert haben (hier: C:\Temp\export): Geben Sie wieder das gemerkte, sichere Kennwort ein: OK. Bestätigen Sie die Informationsmeldung (die aktuellen IIS Keys werden gebackupt): Und noch einmal OK: Danach beenden Sie den IIS Manager und starten diesen neu und restarten Sie den Webserver (rechts in der TaskPane): Die gesamte Konfiguration des Quellservers sollte nun auf dem Zielserver sichtbar sein. Jetzt muss nur die "Freigegebene Konfiguration" wieder deaktiviert werden: Und den Schalter wieder ausschalten und "Übernehmen": Jetzt folgt die Sicherheitsabfrage: Wollen Sie die (importierten) Einstellungen aktivieren? Wählen Sie "Ja". Dabei werden diese Konfigurationsdateien nach C:\Windows\System32\inetsrv\config kopiert - damit wird diese Konfiguration wirksam. Jetzt noch einmal bestätigen: Und IIS erneut starten (wie oben). Jetzt sollte die komplette Konfiguration auf dem Zielrechner vorhanden und lauffähig sein. Hinweis: Die Webs (Files) müssen bei dieser Methode selbst auf den Zielserver kopiert werden (möglicht in denselben Pfad - sonst müssen die XML Files vor dem Import selbst angepasst werden. Eventuelle NTFS-Rechte müssen ebenso neu gesetzt werden, z.B. Rechte auf die ASP.NET Verzeichnisse App_Data o.ä.) Wenn alle Webs funktionieren ist das Übersiedeln erledigt! Coole Sache, die viel Arbeit ersparen kann. Wenn nein: Lesen Sie Teil 3 (HTTP Error 503. Service Unavailable)! Auch hier mein Tipp: Wenn Sie das selbst in einer Testumgebung ausprobieren wollen, folgen Sie einfach dem Link Windows Server 2008 R2 mit Service Pack 1 und laden und installieren Sie die aktuellste Windows Server Version aus dem TechNet Eval Center!

IIS7 Websites übersiedeln - Teil 1

Windows Server 2008 R2 ist eine großartige Anwendungsplattform, auf der viele große und kleine Websites betrieben werden. Ich hatte letztes Mal das Szenario, Webs von Maschine A auf Maschine B zu übersiedeln. Das ist grundsätzlich auch leicht möglich. Es stellt sich nur die Frage: Soll ein einzelnes Web, oder der ganze Webserver mit all seinen Webeigenschaften übersiedelt werden? Beginnen wir zunächst mit der einfachsten Variante: Übersiedeln eines Webs Die Commandline Tools des Webservers befinden sich in C:\Windows\System32\inetsrv. Um eine Liste aller konfigurierten Webs zu erhalten eignet sich der Befehl appcmd: CD C:\Windows\System32\inetsrv appcmd list site Ganz praktisch: Mit appcmd list site > C:\Temp\weblist.txt wird die Liste gleich in ein File geschrieben. Mit demselben Befehl wird ein einzelnes Web exportiert: appcmd list site /name:meinweb.at /config /xml > C:\Temp\meinweb.xml Das erzeugte File sieht dann beispielsweise so aus: Dieses XML-File kann nun auf den neuen Webserver B kopiert werden und dort importiert werden. Hinweis:  Das Web selbst (die Files) müssen natürlich ebenfalls auf den Zielserver kopiert werden. Wenn die Pfade zw. Quellserver und Zielserver unterschiedlich sind, müssen diese noch im XML-File angepasst werden! Nun wird das Web in den neuen IIS7 importiert: CD C:\Windows\System32\inetsrv appcmd add sites /in < C:\Temp\meinweb.xml Das Tool meldet dann, dass "MeinWeb" importiert wurde. Achtung: Der zugehörige ApplicationPool wird damit NICHT automatisch angelegt! Daher muss der AppPool noch selbst erstellt werden: Am besten mit dem Namen des ursprünglichen Webs anlegen: Und am Ende noch die Zuweisung des Webs zum richtigen AppPool kontrollieren (sinngemäß wie unten) und danach das Web neu starten. Fertig. Das Web sollte laufen (sofern die DNS-Einträge richtig auf den neuen Webserver umgeleitet wurden). Bei Problemen: Prüfen Sie die Namensauflösung mit nslookup und die Firewalleinstellungen (ev. SQL Server Port 1433 etc., um dieselbe Umgebung wie auf dem Quellserver herzustellen). Übrigens: Wenn Sie das selbst ausprobieren wollen, folgen Sie einfach dem Link Windows Server 2008 R2 mit Service Pack 1 und laden und installieren Sie die aktuellste Windows Server Version aus dem TechNet Eval Center! In Teil 2 übersiedeln wir dann die gesamte Website-Struktur mit allen Einstellungen.

Metro Snap-Feature auch bei kleiner Screen-Auflösung und mit Beamer nutzen

In Windows 8 Metro gibt es bei einer kleineren Auflösung als 1366x768 keine Snap-Funktion: Normalerweise ist eine Metro-App ja immer bildschirmfüllend, jedoch können zwei Metro-Apps nebeneinander angezeigt werden - wenn der Bildschirm (sprich die Bildschirmauflösung) - breit genug ist und die App es unterstützt. Corrado´s Blogs beschreibt einen Workaround für Geräte mit geringerer Auflösung (z.B. XGA 1024x768), wie es trotzdem klappt: Enable Snap feature in Windows 8 Hier die Schritte: Registry Editor: Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell Create a new Key named AppPositioner Add into new key a 32bit DWORD value named AlwaysEnableLSSnapping with value 1. Restart the machine. Achja, noch ein Hinweis aus der Praxis: Beim Anschluß des Build Samsung Slate PCs per HDMI (Adapter) an einen Beamer muss - je nach Projektor - eine kleinere Auflösung wie 1024x768 gewählt werden. Sonst können in der Developer Preview "internal errors" beim Starten von Apps auftreten...! Das Heruntersetzen der Auflösung ist der Workaround! Danke an @DerAlbert für den Tipp! Und dafür braucht man wieder obigen "Hack". Happy Metro working!

"Hacks" for Windows 8 Developer Preview

Da freut man sich über die neue Metro-Oberfläche der ersten Windows 8 Developer Preview Version am neuen Samsung Slate PC (siehe auch "Das war die Build Windows Konferenz") - und schon tauchen die ersten Hacks auf, wie man Metro ausschalten kann und angeblich "hidden features" aktivieren kann... BluePoison Disables Windows 8 Immersive Start Menu, Unlocks Hidden Features Ich halte nicht sehr viel davon und sehe es eher wie viele andere Developer: "The Developer Preview was specifically released so that developers could get early access to Metro and program apps for it." Dafür ist sie da.