Berilia Blog

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.

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 (0×80070005).  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

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.

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.