Berilia Blog

Nach einem Treiberupdate am Wochenende hatte ich das nervige Problem, daß mit jedem anmelden, aufwachen aus dem Ruhezustand, etc. die “SmartAudio.exe” gestartet wurde. Soweit kein Problem, es funktioniert (auch wenn es meiner Meinung nach unnötig Ressourcen verbraucht). Schlimm wirds erst, wenn man die Funktion “Benutzer wechseln” benutzt – dann läuft SmartAudio nämlich schon, wird aber nochmal gestartet und meckert dann rum.

Was nun? Eine Google-Suche brachte wenig erhellendes. Also Hirn anschmeißen und selber eine Lösung suchen.

Erste Idee: Das Ding steht im Autostart. Stimmt auch, ist so (Unter HKLM\Software\Microsoft\Windows\CurrentVersion\Run).

Also flott gelöscht und gefreut – aber weit gefehlt, das Problem bleibt, nur daß die SmartAudio.exe plötzlich nicht mehr in meinem Userkontext läuft, sondern als “LOCAL SYSTEM” (!). Huppsa, ein Control Panel für die Audiokarte mit Systemrechten? Das geht mal ü-ber-haupt nicht.

Also habe ich als Workaround erstmal die SmartAudio.exe umbenannt. Leider ohne Erfolg, jetzt meckert die SAIICpl.exe, daß es die SmartAudio.exe nicht gibt. Außerdem tut auch das SmartAudio Control Panel nicht mehr, das hätte ich aber schon gerne behalten. Also: Nochmal genauer suchen, wo das Zeug gestartet wird.

Der Fehler ist schon mal ein schöner neuer Hinweis, es wird also irgendwo die SAIICpl.exe gestartet, die dann die SmartAudio.exe nachstartet. Damit ist klar, warum die Suche nach der SmartAudio.exe keine weiteren Ergebnisse brachte. Nur: Wo wird das Ding gestartet?

Nach einiger Suche bin ich dann in der Registry fündig geworden – beim Lenovo Power Management Treiber. Der kann nämlich – um z.B. nach dem Ruhezustand eine Karte neu zu initialisieren – Programme anstarten. Das macht er dann auch mit der SAIICpl.exe, und zwar nicht nur bei einem Powemanagement-Event, sondern auch beim an- oder abmelden.

Um das Problem loszuwerden, reicht es folgenden Schlüssel zu löschen:

HKEY_LOCAL_MACHINE\SOFTWARE\LENOVO\Energy Management\SmartAudio

Damit ist dann endlich Ruhe – ganz ohne umbenennen der Dateien und ohne die Funktionalität zu verlieren. Und dank jetzt nicht mehr permanent laufender SmartAudio.exe spart man auch noch Ressourcen.

Irgendwelche Einschränkungen konnte ich nicht feststellen, bei mir tut alles wie bisher auch.

Wir haben heute in der Firma einen Fileserver umgezogen – von Server 2003 auf Server 2008 R2. Dabei hatte ich wiedermal ein Erlebnis der 3. Art mit der beschissensten Idee, die Microsoft je hatte: Der User Account Control, kurz UAC.

Erstmal eine kurze Erklärung, was die UAC überhaupt ist:

Die UAC ist Microsofts Antwort auf den Schrei nach Sicherheit. Leider ist das Konzept dahinter grundlegend falsch aufgebaut. Windows ist ab NT 3.1 aufwärts ein Multiuser-Betriebssystem, das eine recht ausgefeilte Steuerung von Benutzerrechten zuläßt. Man kann Benutzer mit fast jeder beliebigen Kombination von Rechten auf alles mögliche bauen. Zu den von daheim bekannten Standard-Typen Administrator, Hauptbenutzer, Benutzer und Gast kommen in Active-Directory-Umgebungen noch unzählige weitere dazu, da gibt es dann z.B. Backup-Operatoren oder Schema-Administratoren. Das würde es prinzipiell erlauben, Benutzer zu bauen, die genau die Rechte haben, die sie brauchen. Zudem kann man jedem Benutzer die Rechte auch erweitern, indem man auf entsprechende Objekte (Dateien, Registry-Keys, Dienste, etc.) einzeln Rechte gemäß den Anforderungen einer Anwendung selektiv vergibt.

Microsoft hat leider aber in der Vergangenheit schon bei der Installation alle Benutzer zu “Administratoren” gemacht. Unix/Linux-Admins lächeln darüber schon, seit es Windows gibt, unter Unix ist es nämlich üblich, daß “root” nur ausgewählte Personen bekommen, und selbst die nutzen “root” nur im Ausnahmefall. Alle anderen bekommen normale Benutzerrechte, die ggf. erweitert werden.

Um jetzt möglichst “rückwärtskompatibel” zur “Alle sind Admin”-Ära zu bleiben, hat Microsoft was neues erfunden: Die UAC.

Die UAC ist ein Dienst, der überwacht, welche Rechte ein User zu verwenden versucht. Will er Administrieren, dann fragt die UAC “Wollen Sie das wirklich?” und erlaubt oder verweigert das Ausführen der Funktion. Microsoft geht hier also den Weg, daß der User Administrator ist, dann aber diese Rechte doch nicht ausüben darf.

Das hat zur Folge, daß zum einen sehr seltsame Verhaltensweisen des Betriebssystems entstehen (kommt später, das hatten wir heute…) und zum anderen der User noch immer zu viele Rechte hat – sie werden ihm ja nicht genommen, nur das Ausführen eines Programmes, das sie anfordert, wird ggf. verhindert.

Viel besser wäre es gewesen, echte eingeschränkte Benutzer zu erstellen – Ab Vista kann man sich problemlos zweimal anmelden, mit der schnellen Benutzerumschaltung kein Problem. Will man was installieren, meldet man sich als Admin an, installiert, meldet sich wieder ab und macht mit der anderen Sitzung einfach da weiter, wo man aufgehört hat. Kein Problem. Alternativ hätte auch Microsoft ein Tool wie SuRun entwickeln können, das bei Bedarf für einzelne Applikationen Admin-Rechte aktiviert, auch wenn der Benutzer nur eingeschränkte Rechte hat, analog einem “SU” unter Unix. Die Funktionen, um es richtig zu machen, sind seit NT 3.1 da, also warum nutzen sie sie nicht, sondern erfinden was neues?

In meinen Augen ist die UAC die dämlichste Erfindung, die Microsoft jemals gemacht hat. Man doktort im Namen der heiligen Rückwärtskompatibilität wieder nur an den Symptomen rum, statt das zugrundeliegende Problem zu beheben. Was ist so schwer daran, es einfach richtig zu machen und den Supprt für Uralt-Apps endlich mal über Bord zu werfen? Zumal es für die ja seit Windows 7 den äußerst praktischen XP-Mode gibt, über den man das ja auch elegant lösen könnte. Also hätte man es ja wenigstens mit Windows 7 endlich richtig machen können.

So, jetzt zu meinem Erlebnis. Wir haben wie gesagt die Fileserver von 2003 R2 auf 2008 R2 umgezogen. Das ging soweit auch glatt. Wir haben die alten Maschinen runtergefahren, die Maschinenaccounts in der Domäne zurückgesetzt, die neuen Server mit den Accounts verbunden, im SAN die LUNs (Platten) umgehängt. Alles soweit kein Problem. Server neugestartet, Platten da. Soweit sah alles gut aus – noch schnell die Laufwerksbuchstaben umgebaut, fertig. Shares anlegen.

Soweit kamen wir. Der erste Klick im Explorer brachte die Ernüchterung: Die Platten waren zu sehen, aber beim Klick drauf: “Access Denied”. Hm. Wieso jetzt das? Wir haben die Maschinenaccounts – also auch die SID – übernommen. Das muß gehen. Wir haben alles probiert, inklusive ändern des Besiters der Dateien. Kein Zugriff.

Zum Glück hatte ich einen Consultant vorgewarnt, daß wir evtl. Hilfe brauchen. Er schaute sich das an, hat kurz nachgedacht, ein paar Sachen probiert und meinte dann: “Habt ihr die UAC abgeschaltet”?

Ich wäre nicht mal drauf gekommen, daß es die auf einem Server überhaupt gibt, geschweige denn, daß sie für einen Domänen-Admin-Account aktiv ist. Aber: Sie ist es. Und sie verhindert zuverlässig jeglichen Zugriff auf korrekt eingebundene und berechtigte Laufwerke, nur, weil sie nicht mit diesem Rechner erzeugt wurden.

Ich habe daraus wieder etwas gelernt: Ich werde morgen als erstes eine Domänenrichtlinie bauen, die die UAC für Server zwangsweise deaktiviert. Nochmal passiert mir das nicht.

Auf dem Arbeitsplatzrechner ist die UAC schon fragwürdig, aber auf einem Server ist sie störend und verursacht nur Probleme. Das ist in etwa wie die unselige “Verstärkte Sicherheitskonfiguration” für den Internet-Explorer. Das Ding macht auch mehr Probleme, als es löst, weil man – ist die Option aktiviert und installiert man danach einen IE7 oder IE8 – plötzlich einiges nicht mehr tun kann, was im ersten Moment nicht mit dem IE in Verbindung zu bringen ist, z.B. das Ausführen von Executables auf einem Netzlaufwerk im LAN.