Jul 26 2010

Nerviger „Connexant Smart Audio“ Treiber auf dem ThinkPad X200 Tablet

Category: Nerviges,Technik,Thinkpad,Windowsadmin @ 6:30 pm

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.

Schlagwörter: , , ,


Sep 16 2009

Und wieder mal ein neues Spielzeug.

Category: Techniktrekkie22 @ 8:31 pm

Ich habe mir ein neues Gadget geleistet. Nachdem ich oft Probleme mit meinem Palm hatte mit Abstürzen, PalmOS „out“ ist und der Pré noch nicht in Sicht, habe ich mir einen iPod Touch 2G mit 8GB Flash geleistet.

Mein erster Eindruck: Geil.

Mein zweiter Eindruck: iTunes nervt. Der iPod ist immer noch geil.

Der dritte Eindruck: iTunes nervt noch immer, der iPod selber ist noch immer geil… 😀

Ich werde wohl auf iPod + Handy umsteigen und den Palm Centro damit ersetzen. Ich habe im AppStore so ziemlich alle Apps gefunden, die ich auch auf dem Palm habe. Der Palm wird sicher als „Fallback“ bleiben, aber das Gerät der Wahl ist in jedem Fall der iPod. 🙂


Mrz 16 2009

Windows 2003 Domänencontrolller – Certificate AutoEnrollment schlägt fehl

Category: Arbeit,Technik,Windows Servertrekkie22 @ 5:33 pm

Und wieder mal hat es mich eingeholt. Wir haben eine neue Domäne in Betrieb genommen und prompt schlug wieder das Rechte-Problem beim Autoenrollment zu.

Event Type: Error
Event Source: AutoEnrollment
Event Category: None
Event ID: 13
Date:  16.03.2009
Time:  15:44:04
User:  N/A
Computer: <Servername>
Description:
Automatic certificate enrollment for local system failed to enroll for one Domain Controller certificate (0x80070005).  Access is denied.

Hintergrund: Der Domänencontroller hat seit Windows Server 2003 Servicepack 1 keine Rechte mehr, ein Zertifikat anzufordern. Die Rechteverwaltung der Zertifikatsdienste wurde mit Servicepack 1 verändert, es gibt jetzt eine neue Gruppe „CERTSVC_DCOM_ACCESS“, in der die Rechte für den DCOM-Access verwaltet werden.

Wenn man die Zertifizierungsstelle nun in die Stammdomäne installiert, wird die Gruppe angelegt und die Rechte für die Stammdomäne werden erteilt (Domänencomputer und Domänenbenutzer). Schon hier fehlen die Domänencontroller – will also ein DC ein Zertifikat anfordern, hat er Pech gehabt. In meinen Augen eine blödsinnige Konfiguration, da gerade die DCs doch eigentlich am dringendsten die Zertifikate brauchen.

Noch schöner wird es, wenn man Child-Domänen anlegt – die tauchen in der Gruppe nämlich per Default erstmal gar nicht auf, man muß sie manuell hinzufügen, ansonsten hat man in der kompletten Domäne auf jedem Rechner das Problem, daß das AutoEnrollment fehlschlägt. Konkret wären aus der betroffenen Domäne die Gruppen „Domänenbenutzer“, „Domänencomputer“ und „Domänencontroller“ hinzuzufügen.

Das AutoEnrollment kann man mit certutil -pulse auf der Kommandozeile manuell anstoßen, das Eventlog gibt dann umgehend Auskunft, ob es funktioniert hat.

Dazu gibt es natürlich auch einen Knowledgebase-Artikel: http://support.microsoft.com/kb/903220/en-us


Jan 29 2009

Exchange Domainprep

Category: Arbeit,Techniktrekkie22 @ 11:00 am

Gestern habe ich eine neue Domain im Active Directory in der Firma angelegt, um ein bischen besser mit einigen Berechtigungen jonglieren zu können. Prinzipiell ja kein Problem, DNS-Zone anlegen, auf dem ESX-Server schnell einen neuen Server deployen, dcpromo, domainprep für die Exchange-Umgebung, fertig.

Ja Pustekuchen. Die Domain an sich hat funktioniert, nur Exchange mochte nicht.

Ich konnte zwar eine Mailbox anlegen und auch die Eigenschaften bearbeiten, aber der RUS hatte immer ein kleines, aber unpraktisches Problem: Beim Erstellen der Mailadressen fiel er jedesmal auf die Schnauze – zu wenig Rechte. Äußert sich in einem Eventlog-Eintrag:

Ereignistyp: Fehler
Ereignisquelle: MSExchangeAL
Ereigniskategorie: LDAP-Operationen
Ereigniskennung: 8270
Datum:  28.01.2009
Zeit:  23:02:51
Benutzer:  Nicht zutreffend
Computer: <Computername>
Beschreibung:
LDAP gab beim Importieren der Transaktion
dn: <SID=Hier steht die SID>
changetype: Modify
member:add:<GUID=Folgt GUID des betroffenen Objekts>

den Fehler [32] Insufficient Rights zurück. DC=XXX,DC=YYY,DC=ZZZ

Davon gibts dann vier Stück mit leicht unterschiedlichem Inhalt, aber immer der selben Ursache und den selben Fehlercodes. Ich habe den Domainprep mindestens zwanzig mal mit verschiedensten Usern laufen lassen und jeden Hinweis aus der Microsoft-KB ausprobiert, den ich dazu finden konnte. Ohne Erfolg.

Die Lösung war am Ende allerdings ganz einfach – ich hatte durch Zufall in einem Forum beim suchen in einem Nebensatz den Hinweis gefunden, daß man einen DomainPrep nicht nur mit dem Setup von der Exchange-CD starten kann, sondern auch mit der update.exe aus dem Servicepack 2.

Nachdem ich das dann einmal ausgeführt hatte (pfad_zur_update.exe\update.exe /domainprep), stimmten plötzlich auch die Berechtigungen. Der Hinweis von Windows 2003 SP2, daß es mit dem „originalen“ Exchange-Setup Kompatibilitätsprobleme gibt, ist hier also wohl wirklich ernst zu nehmen. Der Domainprep scheint so jedenfalls nicht zuverlässig zu funktionieren.


Jan 27 2009

Umstieg auf WordPress

Category: Techniktrekkie22 @ 10:48 pm

Auch wenn WordPress immer wieder bei heise auftaucht, weils wohl doch recht buggy ist, ist es doch ein schönes, stabiles System. Deshalb habe ich mich entschlossen, das Blog auf WordPress umzumünzen und aus dem Layout der Hauptseite herauszulösen.

Erst hatte ich ja vor, nur das WordPress-Backend zu nehmen und mir die Posts aus der Datenbank zu holen und in mein schönes Typo3-Frontend zu integrieren, das scheitert aber an den Kommentaren. Außerden gab es da dieses eine Theme, das mir auf Anhieb so gut gefallen hat, also habe ich jetzt doch auch das WordPress-Frontend genommen…

Ich werde mir Mühe geben, in Zukunft mehr zu bloggen, damit hier auch mal aktuelle Sachen auftauchen.

Schlagwörter: ,