Archive for Januar 2013

Outlook Kommandozeilenparameter

22 Januar 2013

Wenn man Outlook.EXE direkt startet, kann man je nach verwendeter Version unterschiedliche Parameter mit angeben.

Hier ein schöne Auflistung der möglichen Parameter: http://www.howto-outlook.com/howto/commandlineswitches.htm

So kann man z. B. mittels

OUTLOOK /PROFILES

einen Auswahldialog erzwingen, welcher einen nach dem zu öffnenden Profil fragt.

Client Hyper-V in Windows 8

22 Januar 2013

Windows 8 enthält auch den Hyper-V Server allerdings wird im Zusammenhang mit einem lokalen Hyper-V auf Windows 8 von Client Hyper-V gesprochen.

Es gibt ein paar Dinge zu beachten und ein paar Einschränkungen, wie z. B., dass Client Hyper-V nur auf 64Bit Systemen läuft und Dinge wie Replikation nicht unterstützt.

Hier das Dokument mit den Infos: http://www.microsoft.com/en-us/download/details.aspx?id=36188

Windows 8 Godmode

19 Januar 2013

Wenn man mal wieder auf der Suche nach einem bestimmten Zusatzprogramm unter Windows ist, kommt einem der GodMode von Windows zuhilfe.

Auch unter Windows 8 funktioniert dieser noch, einfach

shell:::{ED7BA470-8E54-465E-825C-99712043E01C}

im Windows Explorer in der Adresszeile eingeben und los gehts.

Für uns DOSler gilt:

start shell:::{ED7BA470-8E54-465E-825C-99712043E01C}

und die Party beginnt.

Weitere Infos hier: http://support.microsoft.com/kb/978780/de und hier http://www.hanselman.com/blog/UnlockingWindows8GodModeAUseful
TrickButAlsoMysteriousNonsense.aspx

Schutzverletzungen durch ACLayers.DLL wegen Shims und Komptibilitätseinstellungen

19 Januar 2013

Wer Probleme mit abstürzenden Programmen bekommt, bei denen Aclayers.dll mit genannt wird, der hat es mit Problemen des Application Compatibility Toolkit (ACT) von Windows zu tun.

Einleitung
Bereits bei Windows 2000 findet man das Verzeichnis C:\WINNT\APPPATCH welches die Aclayers.dll beinhaltet. Unter Windows XP ist diese natürlich nach C:\WINDOWS\APPPATCH gewandert. Auch Unter Windows 8 findet man dort die AcLayers.DLL noch. In Verbindung mit Aclayers.dll werden immer wieder msimain.sdb, drvmain.sdb, pcamain.sdb und sysmain.sdb genannt. Dies sind die einzelnen Datenbanken, welche die Kompatibilitätseinstellungen bzw. Meldungen für Programme und Treiber enthalten.

Dass ein Programm im Kompatibilitätsmodus ausgeführt wird, kann man immer im sehr schön im ProcessExplorer von Sysinternals erkennen, indem man sich bei der Lower Pane View die DLLs die der einzelne Prozess geladen hat anzeigen lässt. Dort taucht dann immer Aclayers.DLL auf.

Wenn man Programme mittels ProcMon.EXE beobachtet bzw. aufruft, findet sich hier immer der Aufruf von C:\WINDOWS\SYSTEM32\APPHELP.DLL. AppHelp.DLL ist die API für die Kompatibilitätsanfragen. Windows steuert je nachdem was in den Kompatibilitätsdatenbanken hinterlegt ist, welche Umgebung die Anwendung vorgesetzt bekommt oder ob evtl. auch eine Meldung angezeigt wird oder gar der Start blockiert wird.

Eine gute Erklärung, was genau passiert, wenn ein Programm im Kompatibilitätsmodus ausgeführt wird, ist hier zu lesen: http://technet.microsoft.com/en-us/windows/jj863250.aspx. Dabei wird von Shims gesprochen worüber der eigentlichen Anwendung eine ältere Umgebung vorgegaukelt wird.

Komplette Erklärung der Möglichkeiten unter Windows XP: http://technet.microsoft.com/en-us/library/bb457032.aspx, unter dem Titel “Windows XP Application Compatibility Technologies”. Hier die aktuelle Fassung für Windows 8: http://technet.microsoft.com/en-us/library/hh825181.aspx.

Shim Database (.SDB) dumpen: http://blog.kalmbach-software.de/2010/02/22/the-shim-database/. Hier noch der Link zur API-Beschreibung für die Zugriff auf die .sdb-Dateien. http://msdn.microsoft.com/library/bb432182.aspx. Hier noch ein Utility zum Auslesen der SDB-Datenbanken: http://blogs.msdn.com/b/heaths/archive/2007/11/02/sdb2xml.aspx.

Übrigens ist die ganze Geschichte auch dafür verantwortlich, wenn ein Update von Windows7 auf Windows 8 nicht möglich ist, weil z. B. Programm XY installiert ist. Man kann davon ausgehen, dass in einer .SDB dann die betreffende Software erfasst ist und der Upgrade -Assistent genau dies prüft.

Ein guter Blog mit vielen Infos zum Thema: http://blogs.msdn.com/b/cjacks/.

Konkrete Problemlösung
Jetzt aber nochmal zurück zum Anfang. Bei einem Kunden kam es beim Aufruf eines Programms ständig zu Schutzverletzungen wegen AcLayers.DLL. Die Software welche bei der Schutzverletzung genannt wurde, war ein VB6 Programm, welches vor einem Update tadellos auf dem besagten Rechner lief. Bei der Recherche, was genau in dem Programm geändert wurde, stellte sich heraus, dass eine neuere Version von MSXML benutzt wurde. Diese neuere Version war anscheinend von AcLayers.DLL geblockt worden, blöderweise durch die Schutzverletzung. Warum, war erst nicht klar. Aber nach einigem Suchen stellte sich heraus, dass die Anwendung, welche die VB6-Anwendung aufrief, auf Kompatibilität zu Windows 95 eingestellt war. Damit wurde die Anwendung von MSXML verhindert, welches mindestens Windows 2000 benötigte. Ergo die Schutzverletzung mit AcLayers.DLL!

Mit dieser Version von Hyper-V-Manager können keine Server mit Hyper-V unter Windows Server 2008 oder Windows Server 2008 R2 verwaltet werden.

18 Januar 2013

Nach der Installation des Hyper-V Managers auf einem Windows 8 und der Einrichtung der Zugriffe via HVREMOTE.SWF, wie hier beschrieben https://newyear2006.wordpress.com/2012/07/10/hyper-v-3-0-remote-management-einrichtung-mit-hvremote-und-probleme-mit-windows-8/, sollte eigentlich ein Zugriff auf einen Hyper-V Server hergestellt werden.

Die ersten beiden Male, also den Meldungsdialog

[Window Title]
Hyper-V-Manager

[Main Instruction]
Fehler beim Versuch, eine Verbindung mit dem Server "MYHYPERV" herzustellen. Vergewissern Sie sich, dass der Verwaltungsdienst für virtuelle Computer ausgeführt wird und Sie zum Herstellen einer Verbindung mit dem Server berechtigt sind.

[Content]
Mit dieser Version von Hyper-V-Manager können keine Server mit Hyper-V unter Windows Server 2008 oder Windows Server 2008 R2 verwaltet werden.

[Schließen]

großzügig ignoriert und kurz nochmal die Aufrufe von HVRemote gecheckt. Aber alles OK. Wie immer, wenn was nicht klappt, fängt man dann das lesen an und da steht:

[Content]
Mit dieser Version von Hyper-V-Manager können keine Server mit Hyper-V unter Windows Server 2008 oder Windows Server 2008 R2 verwaltet werden.

Ja hallo, geht es noch? Merken die die Einschläge nicht mehr? Der Server ist ein Hyper-V Server R2 mit SP1.

Hier ein Thread im MSDN-Forum welches bestätigt, dass es für das Problem keine Lösung gibt: http://social.technet.microsoft.com/Forums/en/winserverhyperv/thread/4b3e7582-dc20-4dcb-8e71-fef9fecce19c

Kommen wir wieder mal zum Punkt: Muss das sein? Es gibt keinen logischen Grund warum Windows 8 nicht einen Server 2008 R2 unterstützen können sollte. Es sind nur einfach faule Pfeifen bei MS am Werk, die keinen Plan haben was draußen in der Welt so los ist. Es wird immer eine Technologie gepusht und gehypet und am Ende wird man im Regen stehen gelassen. Sollen Sie endlich den Handyschrott sein lassen und ihre Milliarden in Leute und Dienste investieren! Da läuft mir jetzt echt die Galle über.

Powershell 9 Arten ein externes Programm zu starten, mir sind aber 11 bekannt oder noch mehr?

7 Januar 2013

Dieser Artikel http://www.admin-source.de/BlogDeu/433/powershell-9-arten-ein-externes-programm-executable-zu-starten, dessen Grundlage, dieser Technet-Wiki-Eintrag ist http://social.technet.microsoft.com/wiki/contents/articles/7703.powershell-running-executables.aspx, spricht von 9 Arten externe Programme unter Powershell starten zu können.

Allerdings muss man bei Version 2 von Powershell sagen, es gibt eigentlich 10 Arten, denn es gibt das tolle Kommando Invoke-WSManAction http://technet.microsoft.com/en-us/library/hh849865.aspx. Mit den richtigen Parametern gefüttert:

Invoke-WSManAction -Action create -ResourceURI wmicimv2/win32_process -ValueSet @{commandline="notepad.exe";currentdirectory="C:\"}

führt dies auch zum Start von Notepad.exe!

Jetzt mag der eine oder andere einwenden, dass ja nur Win32_Process aufgerufen wird aber wird nicht auch bei den anderen Möglichkeiten im Hintergrund immer nur CreateProcess() aufgerufen?

Ach übrigens mit Powershell 3 gibt es noch eine weitere Variante! Die da wäre Invoke-CIMAction http://technet.microsoft.com/en-us/library/jj590759.aspx. Dies sind dann so aus:

$cim=Invoke-CimMethod -ClassName Win32_process -MethodName "Create" -Arguments @{ Commandline="notepad.exe";CurrentDirectory="C:\" }

Wenn ich allerdings jetzt nochmal genau darüber nachdenke, dann fallen mir noch weitere Möglichkeiten ein, wie z. B. ScheduledJobs, BackgroundJobs also Jobs allgemein, mittels Win32_ScheduleJob oder indem man einen Druckertreiber mit entsprechendem Monitorprogramm installiert und dann was ausdruckt. Dann wäre da noch die Möglichkeit über Win32_Service. Und es gibt noch soviel mehr, wenn man seine Kreativität walten lässt.

Man könnte ja auch Powershell benutzen, um mehr zu erfahren

gwmi -List | where if ($_.methods -ne $null) {($_.methods).name -contains "Create"}

listet unter anderem

Win32_Process
Win32_BaseService
Win32_Service
Win32_TerminalService
Win32_SystemDriver
Win32_ScheduledJob

Bei CIM wären die Invoke-Aktionen aber CIM ist noch so undurchschaubar. Gute, wenn auch alte Infos über CIM gibt es hier: http://klaus.jaehne.de/papers/cim/node6.html.

Ich glaub jetzt bin ich irgendwie übers Ziel rausgeschossen. Halten wir also fest: Es gibt mehr Methoden, als wir zu wissen glauben.

Windows Server 2008 R2 bzw. SBS 2011 Datensicherung Fehlercode 2155348061

5 Januar 2013

Mal wieder ein netter Fehlercode bei einem nicht funktionierenden Backup auf einem Server. Wo war das Problem? Wie immer weiß Windows nix genaues.

Zunächst hier die ausführliche Meldung im Windows Event Log

Fehler beim Starten der um ‎2013‎-‎01‎-‎03T22:00:17.422620800Z auszuführenden Sicherung. Fehlercode: "2155348061". Suchen Sie in den Ereignisdetails nach einer Lösung, und führen Sie die Sicherung erneut aus, nachdem das Problem behoben wurde.

Bei den Datensicherungszielen war das Laufwerk als Datenträger [1] angegeben. Also mal nach Datenträger 1 schauen. Aber in der Datenträgerverwaltung gab es keinen Datenträger 1. Wer war Schuld?

Das NAS war es. Denn per iSCSI war eine virtuelle Festplatte vom NAS eingebunden. NAS wie Windows zeigten aber eigentlich alles korrekt an. Nur wenn man unterm iSCSI-Initiator beim Register Ziele unter Geräte schaute, fehlte das betreffende Gerät!

Also beim NAS nachgeschaut aber dort war nichts besonderes geloggt und alles sah gut aus. In der Not im NAS den iSCSI-Dienst deaktiviert und neu aktiviert (zum Glück war nur eine Platte angebunden!). Danach hat wieder alles funktioniert.

Wifi Netzwerksicherheitsschlüssel unter Windows per Powershell auslesen

2 Januar 2013

Es gibt unter Windows zwar wohl eine Methode sich den hinterlegten Netzwerksicherheitsschlüssel für Wifi Netzwerke anzuzeigen aber die Methode ist nur über die GUI-Oberfläche möglich und ist recht umständlich, wenn man die Keys mehrerer Netze abfragen möchte.

Es gibt natürlich auch allerhand Utilities wie z. B. WirelessKeyview von Nirsoft http://www.nirsoft.net/utils/wireless_key.html. Aber wer vertraut per solch sicherheitskritischen Dingen schon gern unbekannter Software. Zumal diese oft von Virenscannern als Malware klassifiziert werden: http://blog.nirsoft.net/2012/10/10/amazing-difference-between-antivirus-false-alerts-on-32-bit-and-64-bit-builds-of-exactly-the-same-tool/.

Was liegt also näher, als die Sache selber mit Bordmitteln zu lösen. Das Thema ist allerdings etwas komplexer weshalb ich als Vorbereitung in den vergangenen Tagen bereits verschiedene Artikel geschrieben habe.

Zuerst werden die Berechtigungen vom Systemdienst benötigt: https://newyear2006.wordpress.com/2013/01/01/eingabeaufforderung-mit-lokalen-systemdienst-rechten-unter-windows-8-und-windows-server-2012/.

Dann ist wichtig, wie man mit SecureStrings in Powershell umgeht: https://newyear2006.wordpress.com/2012/12/30/spa-mit-net-securestring-und-powershell-oder-sicheres-speichern-und-einlesen-von-passwrtern/

Noch etwas mehr Hintergrund, wie man in den tiefen von SecureString die DPAPI benutzt: https://newyear2006.wordpress.com/2012/12/30/in-den-niederungen-von-securestring-mittels-powershell/

Dann braucht man noch die Idee für solch einen Artikel: http://securityxploded.com/wifi-password-secrets.php

So nun zum Script, am besten speichert man es unter WifiUtil.PS1:

# Warmup
ConvertTo-SecureString -AsPlainText -Force Hallo| ConvertFrom-SecureString

function Convert-HexStringToByteArray {
# http://www.sans.org/windows-security/2010/02/11/powershell-byte-array-hex-convert
################################################################
#.Synopsis
# Convert a string of hex data into a System.Byte[] array. An
# array is always returned, even if it contains only one byte.
#.Parameter String
# A string containing hex data in any of a variety of formats,
# including strings like the following, with or without extra
# tabs, spaces, quotes or other non-hex characters:
# 0x41,0x42,0x43,0x44
# \x41\x42\x43\x44
# 41-42-43-44
# 41424344
# The string can be piped into the function too.
################################################################
[CmdletBinding()]
Param ( [Parameter(Mandatory = $True, ValueFromPipeline = $True)] [String] $String )
#Clean out whitespaces and any other non-hex crud.
$String = $String.ToLower() -replace ‚[^a-f0-9\\\,x\-\:]‘,“

#Try to put into canonical colon-delimited format.
$String = $String -replace ‚0x|\\x|\-|,‘,‘:‘

#Remove beginning and ending colons, and other detritus.
$String = $String -replace ‚^:+|:+$|x|\\‘,“

#Maybe there’s nothing left over to convert…
if ($String.Length -eq 0) { ,@() ; return }

#Split string with or without colon delimiters.
if ($String.Length -eq 1)
{ ,@([System.Convert]::ToByte($String,16)) }
elseif (($String.Length % 2 -eq 0) -and ($String.IndexOf(":") -eq -1))
{ ,@($String -split ‚([a-f0-9]{2})‘ | foreach-object { if ($_) {[System.Convert]::ToByte($_,16)}}) }
elseif ($String.IndexOf(":") -ne -1)
{ ,@($String -split ‚:+‘ | foreach-object {[System.Convert]::ToByte($_,16)}) }
else
{ ,@() }
#The strange ",@(…)" syntax is needed to force the output into an
#array even if there is only one element in the output (or none).
}

function Get-WLANKeyFromProfile {
[CmdletBinding()]
param(
  [xml]$x)

if ($x -ne $null)
{
  $key=$x.WLANProfile.MSM.security.sharedKey.keyMaterial
         $eb=Convert-HexStringToByteArray $key
  $mbl=[System.Security.Cryptography.ProtectedData]::Unprotect($eb,$null,"LocalMachine")
  $key=[System.Text.Encoding]::ASCII.GetString($mbl)
  $key.Substring(0,$key.Length-1) # 0x0

}
}

function Get-SSIDFromProfile {
[CmdletBinding()]
param(
  [xml]$x)

if ($x -ne $null)
{
  $key=$x.WLANProfile.SSIDConfig.SSID.name
  $key
}
}

# C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces

$wifi=Get-ChildItem -Recurse|Select-String -pattern "01000000D08C9DDF0115D1118C7A00C04FC297EB"
$wifi | Add-Member -Type ScriptProperty –Name SSID -Value { Get-SSIDFromProfile $this.XMLProfileFile }
$wifi | Add-Member -Type ScriptProperty -Name WlanKey -Value { Get-WLANKeyFromProfile $this.XMLProfileFile }
$wifi | Add-Member -Type ScriptProperty -Name XMLProfileFile -Value { [xml](Get-Content $this.path) }

Wenn man auf dem Desktop des Systemdienst ist, geht man in das Verzeichnis

CD C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces

und ruft dort Powershell auf und importiert obiges Script mittels

Import-Module WifiUtil.PS1

Man hat nun in $Wifi alle auf dem System bekannten Wifi-Keys mit Angaben zu den SSIDs. Mittels Powershell 3.0 und Out-Gridview gibt es die perfekte Darstellung:

$wifi | Out-GridView

oder man verwendet die klassische Methode:

$wifi | select –Property SSID,WlanKey

So das war aber erst der Anfang mit dieser Methode lässt sich noch viel mehr anstellen.

Eingabeaufforderung mit lokalen Systemdienst-Rechten unter Windows 8 und Windows Server 2012

1 Januar 2013

Gerade erst gebloggt und doch schon nicht mehr aktuell. Blöd sowas aber wer konnte damit rechnen, dass Microsoft eine bestehende Funktionen die seit Ewigkeiten da ist, degradiert. Es geht um diesen Artikel: https://newyear2006.wordpress.com/2012/12/29/eingabeaufforderung-mit-lokalen-systemdienst-rechten-unter-windows/

Ausgehend von

sc create ntauthcmd binpath= "cmd /K start" type= own type= interact

und mittels

sc start ntauthcmd

konnte bisher eine Kommandozeile mit lokalen Systemdienstrechten gestartet werden und mehr oder weniger einfach darauf zugegriffen werden.

Dies funktioniert unter Windows 8 und Windows Server 2012 nicht mehr! Zumindest von Haus aus.

Wenn man unter diesen Systemen den Dienst startet, wird kein Icon in der Taskleiste angezeigt. Die Frage ist generell ob die Methode überhaupt noch funktioniert?

Mittels

TASKLIST /FI "IMAGENAME eq cmd.exe"

bekommt man jedoch schnell Klarheit. Denn mit jedem Aufruf von sc start ntauthcmd wird ein weiterer cmd.exe Eintrag hinzugefügt. Auch taucht die cmd.exe unter Services und mit Nummer 0 auf, also scheint dies noch perfekt zu funktionieren. Auch der Taskmanager führt die CMD.EXEs als Hintergrundprozesse.

Aber wie kommt man nun in die 0er Session?

Auf der Suche nach der Lösung hatte ich mir natürlich den Dienst UI0Detect, auch bekannt als “Erkennung interaktiver Dienste” oder in englisch “Interactive Service Detection”, angeschaut. Zunächst dachte ich, die Lösung wäre ganz einfach, denn dieser Dienst ist unter Windows 8 einfach auf manuellen Start eingestellt.

Mittels

sc qc UI0Detect

bekommt man die passenden Infos über den Dienst, hier die Ausgabe bei Windows 7

[SC] QueryServiceConfig ERFOLG

SERVICE_NAME: UI0Detect
        TYPE               : 110  WIN32_OWN_PROCESS (interactive)
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Windows\system32\UI0Detect.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Erkennung interaktiver Dienste
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

Was soll das? DEMAND_START ist Starttyp Manuell in der GUI! Also kein Unterschied, dennoch läuft das Ding auf Windows 7 automatisch aber bei Windows 8 nicht. Wer es startet? Keine Ahnung.

Aber man kann ja den Dienst einfach mal selber starten. Was scheren einen schon unzählige Programme die leider immer noch nicht sauber mit der Trennung von Diensten und UI umgehen können. Also

sc start UI0Detect

abgesetzt und dies erhalten

SERVICE_NAME: ui0detect
        TYPE               : 110  WIN32_OWN_PROCESS  (interactive)
        STATE              : 4  RUNNING
                                (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 6804
        FLAGS              :

Na also sieht doch gut aus, blöd nur dass

sq query ui0detect

dies zurückgibt

SERVICE_NAME: ui0detect
        TYPE               : 110  WIN32_OWN_PROCESS  (interactive)
        STATE              : 1 STOPPED
        WIN32_EXIT_CODE    : 1  (0x1)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Verdammt, es könnte alles so einfach sein. Unter der GUI heißt die offizielle Meldung:

Der Dienst "Erkennung interaktiver Dienste" auf "Lokaler Computer" konnte nicht gestartet werden.

Fehler 1: Unzulässige Funktion.

Supi und jetzt?

Die Suchmaschine meines Vertrauens förderte gleich beim ersten Eintrag einen brauchbaren Link hervor, nachdem man sie mit den richtigen Parametern gefüttert hatte. https://www.google.de/search?q="interactive+service+detection"+"error+1"

Der Link ist http://www.coretechnologies.com/WindowsServices/FAQ.html#UI0DetectFailsToStart und beschreibt genau obiges Problem. Dabei wird ein Registrierungseintrag beschrieben  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows mit Namen NoInteractiveServices beschrieben.

Also diesen mal kurz abgefragt mittels

reg query HKLM\SYSTEM\CurrentControlSet\Control\Windows /v N
oInteractiveServices

ergibt unter Windows 7

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows
    NoInteractiveServices    REG_DWORD    0x0

und unter Windows 8:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows
    NoInteractiveServices    REG_DWORD    0x1

Also tatsächlich ein Unterschied. Also diesen Wert mittels

reg add HKLM\SYSTEM\CurrentControlSet\Control\Windows /v N
oInteractiveServices /t REG_DWORD /d 0

geändert und nochmal den Dienst gestartet und flutsch, alles funktioniert wieder so wie gewohnt!

So das war mal wieder viel Geschreibsel für nichts. Aber die entscheidenden Zeilen unter Windows 8 sind:

sc create ntauthcmd binpath= "cmd /K start" type= own type= interact

reg add HKLM\SYSTEM\CurrentControlSet\Control\Windows /v NoInteractiveServices /t REG_DWORD /d 0

sc start ntauthcmd

Dabei ist anzumerken, dass die Änderung an der Registrierung nur einmalig gemacht werden muss. Danach reagiert Windows 8 wie Windows 7 und reagiert auf künftige sc start ntauthcmd automatisch.

Auf der Suche nach der Lösung bin ich noch über diese Blogeinträge gestolpert, welche einem das Thema mit UI0Detect und mögliche Problemlösungen nahebringen: http://blogs.msdn.com/b/patricka/archive/2010/04/27/what-is-interactive-services-detection-and-why-is-it-blinking-at-me.aspx und http://blogs.msdn.com/b/patricka/archive/2011/03/14/troubleshooting-interactive-services-detection.aspx. Wenn ich mir dabei die Kommentare so anschaue, dann scheint das immer noch aktuell ein Thema zu sein, dabei ist die Umstellung, wo mit Vista kam, jetzt schon so alt. Vielleicht hat MS die Funktion doch zu früh deaktiviert.