“Die automatische Zertifikatregistrierung für “lokaler Computer” konnte ein Zertifikat “Domänencontroller” (0×800706ba) nicht registrieren. Der RPC-Server ist nicht verfügbar.”

Auf der Maschine ist neben dem DC auch ein ISA Firewallserver installiert.

OK, das war vielleicht nicht die beste Idee aber wer kennt das Problem knapper IT Budgets nicht?

EventID.net – sonst immer Quell guter Problembehebungsideen hatte nix passendes und so fing die Suche an. Der ISA protokollierte nix ungewöhnliches, die CA ließ sich pingen, die Namensauflösung stimmte vorwärts wie rückwärts und andere DCs hatten sich vorher auch schon ein eigenes Zertifikat abgeholt.

Dann der entscheidende Hinweis…

Laut eines Kommentars auf eventid.net läuft die Kommunikation des DCs mit der CA offenbar über DCOM.

Ein Forumsposting erzählte mir dann, man müsse im ISA temporär das RPC Filtermodul deaktivieren. Und so findet sich in den RPC Filteroptionen auch tatsächlich der Hinweis, wenn man den Filter aktiviert lasse, also die strikte RPC Einhaltung erzwinge, ständen einige Protokolltypen wie z.B. auch DCOM nicht zur Verfügung.

Deaktiviert man nun den ganzen Filter, muss anschließend die Firewall neu gestartet werden was im laufenden Betrieb in der Regel das Trennen jeglicher Verbindungen von und über die Firewall zur Folge hat.

Das würde im Umkehrschluss bedeuten: Aktiviere ich den RPC Filter wieder, könnte der DC nie wieder sein eigenes Zertifikat erneuern.

Glücklicherweise hat aber Microsoft auch hier eine Lösung:

Bei der Kommunikation zwischen DC und CA kommt die Systemrichtlinie 22 “RPC von ISA Server an vertrauenswürdige Server zulassen” zum Einsatz. Für diese kann man ebenfalls die strikte RPC Einhaltung abschalten. Dazu öffnet man den Systemrichtlinien-Editor, wählt den Punkt “Active Directory” und deaktiviert den Punkt “Strickte RPC-Einhaltung erzwingen”.

Nun musste ich nur noch den Domänencontroller (in diesem Fall einer untergeordneten Domäne) in die Gruppe CERTSVC_DCOM_ACCESS (in der Hauptdomäne, wo die CA “steht”) einfügen und die CA selbst durchstarten.

Anschließend sind der DC und die CA wieder Freunde.

Sure, I can use IE7pro with Internet Explorer 8 but the addon was written for IE 7 and – as far as I know - isn’t fully supported by Internet Explorer 8 by now. The only possibility (that I know of) is to add this by the Accelerator feature, introduced within Internet Explorer 8.

So how it works?

After installation, you do a right click on a selection within a website. Then choose “Link zu Tab” and it will open a new tab. Within this tab, Internet Explorer contacts a PHP script located on your website and send the selection as a parameter to it. Then, the PHP script will do a simple redirection.

Ok, and how to install this?

First of all, download the scripts from here: Link2Tab. You will find three scripts:

• link2tab.xml – this is the accelerator
• link2tab.html – this is the installer for the accelerator
• l2t.php – this is the redirection service

Open all three scripts and search for the term {YOUR_URI}. This needs to be changed to match your homepage, where you plan to put the scripts on. So for example, if your homepage is located under http://www.yoursite.com then change the whole term {YOUR_URI} (yes, with { and } ) to match http://www.yoursite.com .

Save all changes and upload the three scripts. Point your browser to {YOUR_URI}/link2tab.html and click on “Install Accelerator”. This will add the accelerator to your Internet Explorer 8 and you are ready to use it

After installation, you can delete the installer and the accelerator if nessesary.

You are free to modify or share this with any others. You are free to add some more security to the redirection service or use this all for your (non- / commercial) projects. The scripts are released as freeware and comes with absolute no warrenty!

Zwar schreibt Microsoft, dass der SQL Serverprozess den Speicher wieder freigibt sobald ein anderes Programm diesen benötigt, das kostet jedoch Zeit und zusätzliche Ressourcen.

Um diesem Treiben Einhalt zu gebieten gibt es mehr oder weniger elegante Methoden welche abhängig von der verwendeten SQL Serverversion arbeiten und der MSDE vorschreiben, wie viel Speicher die Instanz nutzen darf.
Für die MSDE 2000 (Version 8.x) biete Microsoft ein paar SQL Scripte an, welche über eine Kommandozeile eingespielt werden können.

Jedoch gibt es, seit der SQL Server 2005 raus ist, mit dem kostenlosen Management Studio Express eine sehr gute Verwaltung welche nicht nur die 2005er sondern auch die Version 8 verwalten und vom Speicherverhalten her begrenzen kann.

Dazu wählt man bei der Anmeldung die zu konfigurierende Instanz aus, öffnet im Objekt Explorer die Eigenschaften und wechselt zur Seite “Arbeitsspeicher”.

Dort kann dann der Wert für den maximalen Speicherverbrauch direkt angegeben werden.

Microsoft empfiehlt für eine ISA Server Instanz folgende Werte:

• Bei einem System mit einem Gigabyte Ram: 368 MB
• bei 2GB einen Wert von 512 MB
• bei 3 GB einen Wert von 768 MB
• bei 4GB Ram einen Wert von 1024 MB

Die Einstellungen werden mit OK Bestätigt und die SQL Instanz setzt sie sofort um. Ein Neustarten des Serverprozesses ist nicht notwendig.

Aus diesem Grund habe ich sein Script etwas modifiziert.

Das Script sichert den Computer über die Kommandozeile mit dem Programm NTBackup und sendet anschließend das Sicherungsprotokoll auf Wunsch per Email. So kann man mit Windows Bordmitteln und ein paar kleineren Programmen sehr effizient mit dem System arbeiten.

Grundlage ist ein Windows 2003 R2 Server, ob Standard oder Enterprise – das ist erst einmal egal. Angeschlossen an diesen Server wird ein Autoloader oder zumindest ein Bandlaufwerk benötigt. Zusammen mit dem Script nutze ich am Branchoffice einen HP 1×8 Autoloader G2 mit 8 Fächern und einem LTO Ultrium 2 Laufwerk.

Wir gehen jetzt einfach mal davon aus, dass die Datensicherungseinheit (ob Laufwerk oder Autoloader) in Windows eingebunden ist, der Wechselmediendienst gestartet wurde und die Datensicherungseinheit erkannt hat.

Ferner gehen wir davon aus, dass alle Bänder sich im Pool “Freie Medien” oder wenn sie bereits bespielt worden sind im „Backup“ Pool befinden.

Hinweis

Nutzt man keine Libary bzw. keinen Autoloader sondern nur ein Bandsicherungslaufwerk, müssen alle verfügbaren Bänder einmal eingelegt, und in den Pool “Freie Medien” importiert worden sein.

Eine letzte Voraussetzung ist das Programm ntbackup.exe selbst. Dieses muss wenigstens einmal gestartet worden sein (beim ersten Start werden einige Einstellungen generiert und Dateipfade angelegt) und es muss wenigstens ein Datensicherungsauftrag (*.bks Datei) definiert worden sein – am günstigsten ein Sicherungsjob (eine bks-Datei) pro Sicherungsjob/-tag.

Nun entpackt man das dasi-Script (DaSi = Datensicherung) am besten nach c:\temp\dasiscript oder einen anderen kurzen Pfad.

Anschließend nimmt man sich einen Editor, z.B. Notepad, oder den fantastischen Notepad++ und öffnet die Datei config.cmd.

Hier kann man das Datensicherungsscript an seine Umgebung anpassen. Zuerst benötigt man den Namen der Datensicherungseinheit (Parameter: DASILibaryByName). Dazu  öffnet man eine Shell und setzt den Befehl

ab. Diese Ausgabe zeigt den Namen der verwendeten Library bzw. des verwendeten Laufwerks an.

Als nächstes muss man den Medienpool definieren. Dazu kann man z.B. in der Computerverwaltung in die Wechselmedien schauen. Unter “Freie Medien” ist in der Regel ein Pool automatisch angelegt worden, welcher den entsprechenden Namen der Sicherungsbänder (den Typnamen) trägt:

In unserem Beispiel ist der Name “LTO Ultrium” (Parameter: DASILibraryPool)

Bei PATHtoJOB hinterlegt man den Pfad, in welchen NTBackup seine Sicherungsaufträge speichert. Dieser kann in der Regel so bleiben, es sei denn, der Sicherungsauftrag wurde an eine andere Stelle gespeichert.

Mit dem Parameter PATHtoScritpTEMP legt man fest, wohin man das DaSi-Script  (und den darin befindlichen Temp-Ordner kopiert hat. Dieses ist wichtig, da in den Temp-Ordner die Sicherungsprotokolle für den Emailversand aufbereitet werden.

Der Parameter PATHtoNTBackup legt fest, wo das Script das Sicherungsprogramm ntbackup.exe findet. Die weiteren Parameter erklären sich mehr oder weniger von alleine.

Wichtig für den Versand der DaSi Protokolle sind noch die Parameter USEsmtpServer wo man die IP Adresse oder den Hostnamen des SMTP Servers hinterlegen kann. USEsmtpDOMAIN gibt den Domainnamen an, von der aus die Mail versendet werden soll. Absenderadresse ist dann (computername)@(domainname).

Der Parameter SENDLogsTo gibt an, wohin die Daten gesendet werden sollen. Will man die Logs an mehrere Adressen senden lassen, kann man die Adressen mit einem Komma trennen (keine Leerzeichen verwenden!)

Der Aufruf einer Datensicherung über die Kommandoziele sieht dann so aus:

c:\temp\dasiscript\dasi.cmd Neu 1_Montag 1_Montag

wobei der Parameter Neu angibt, dass sich NTBackup sein Medium aus dem Freien Pool nimmt. Auch gibt der erste Parameter den Namen des Sicherungsjobs (der bks-Datei, siehe Parameter PATHtoJOB) an.

Der zweite Parameter gibt an, dass NTBackup das Medium “1_Montag” nennen soll (unser Namensschema sieht so aus: 1_Montag, 2_Dienstag, 3_Mittwoch, …). Der dritte Parameter dient der Sicherungsbeschreibung.

Der Einfachheit halber nutzen wir hier denselben Namen wie für das Band. Haben wir bereits ein Band im Backup Pool mit dem Namen 1_Montag liegen, rufen wir dasi.cmd wiefolgt auf:

c:\temp\dasiscript\dasi.cmd Alt 1_Montag 1_Montag

Dadurch schaut NTBackup nicht zuerst in den freien Pool sondern vermutet sein Band im Backup-Pool. Das Band wird dann gezielt rausgesucht, angefordert und mit der aktuellen Datensicherung überspielt.

Nun kann man als letzten Schritt noch über “Geplante Tasks” dasi.cmd zur Nachtzeit ausführen lassen.

Noch ein wichtiger Hinweis zum Schluss

Die Benutzung von dasi.cmd passiert auf eigene Gefahr, eigenes Risiko! Der Test der Backups auf Konsitenz sowie das Einspielen von Backups sollte elementarer Bestandteil eines Datenscherungskonzeptes sein. Ich hafte nicht für Schäden welche durch die Anwendung von dasi.cmd oder anderen beteiligten Komponenten entstehen!

Die Exchange Integration besteht aus dem Disk-Agenten, dem Media-Agenten und der MS Exchange Integration selbst. Diese drei Komponenten wurden entsprechend der Vorgabe aus der Anleitung installiert und die Umlaufprotokollierung der Exchange Speichergruppe wurde ausgeschaltet.

Zur Vorsicht starteten wir den Exchange Server noch einmal durch. Die Meldung verschwand jedoch nicht.

In einem HP Forum wurden wir dann fündig: Dort stand zu lesen, dass man die Variable EXCHANGE_HOME mit dem Pfad zum Exchange definieren sollte – und tatsächlich.
Ein anderer Standort, eine andere Sicherungszelle – hier war auf dem Exchange-Server das “bin” Verzeichnis des Exchange-Prozesses in den Pfad eingetragen.

Anstelle eine Variable EXCHANGE_HOME zu definieren, erweiterte ich den PATH um

C:\Programme\Exchsrvr\bin

und startete den DP Prozess auf dem Exchange-Server neu.

Nun ließ sich im DP Manager Exchange auswählen und ich konnte den Job erfolgreich anlegen.