Ich hatte bei einem Kunden das Problem, das ein HP LaserJet P3005n sich nicht beim Anmelden an einer RDS-Farm hinzufügen ließ. Es kam eine Fehlermeldung mit dem Error-Code oxooooooo7e, im Eventlog konnte ich die folgende Fehlermeldung sehen:

Product: 64 Bit HP BiDi Channel Components Installer — The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2753. The arguments are: ipm12.8444768D_9A2B_44BE_BD52_02FB1B25C55E, ,

Ich habe versucht den Drucker als Administrator zu verbinden in einer Remote Desktop-Sitzung auf einem der Terminal-Server, das funktionierte problemlos.

Ich habe dann den installierten HP Universal Driver ausgetauscht gegen den Treiber, der explizit für den P3005 gedacht ist, gleicher Fehler.

Nach einer kurzen Suche bei Google bin ich unter anderem auf den folgenden Beitrag gestoßen:

HP.com – HP LaserJet Printer Series – Discrete Driver, Bidirectional Components Channel, hpzbdi.dll or msi related issues

In diesem Dokument wird erklärt, wie man eine .msi-Datei auf dem Drucker im Verzeichnis

C:\WINDOWS\system32\spool\drivers\x64\3

überschreibt mit einer 0kb großen “Dummy”-Datei. Nachdem ich das gemacht habe und den Dienst “Druckwarteschlange” neugestartet habe, ließ sich der Drucker auch als Benutzer erfolgreich auf dem RDS-Server hinzufügen.

Das Problem scheint wohl damit zusammenzuhängen, das ein Benutzer nicht genügend Rechte für die Aktion hat, die während der Drucker-Hinzufügung passiert, dies aber nicht merkt und deswegen in einen Timeout läuft. Das ganze passiert auch nur be vier! Druckern/Druckerreihen im HP-Sortiment, und zwar bei

• LaserJet 4250/4350 Series
• LaserJet 9040/9050 Series
• LaserJet 5200 Series
• LaserJet P3005 Series

Ich hatte das Glück, genau einen davon zu erwischen :)

Als erstes habe ich den SBS2003 heruntergefahren und einen Export gemacht, um eine Sicherung in der Hand zu halten. Als nächstes habe ich den SBS2003 im abgesicherten Modus gestartet, um nur das nötigste an Diensten zu haben, um so der Performance-Bremse evtl. aus dem Weg zu gehen. Das hat auch geklappt, der Server war innerhalb weniger Minuten völlständig gestartet. Im Eventlog habe ich dann diverse Meldungen gefunden, Quelle waren die Exchange-Dienste. Ich habe dann die Exchange-Dienste auf manuell gesetzt und den Server erneut gestartet, diesmal allerdings ohne den abgesicherten Modus. Dieser Bootvorgang funktionierte ebenfalls in der gewohnten Geschwindigkeit. Somit waren die Exchange-Dienste irgendwie als die Schuldigen identifiziert. Ich habe dann im Eventlog unter “Verzeichnisdienst” ziemlich viele Fehler gefunden, die meisten davon waren

• Ereignis 2087 – NTDS Replikation
• Ereignis 1168 – NTDS General
• Ereignis 1238 – NTDS Replikation
• Ereignis 1913 – NTDS Backup
• Ereignis 1308 – NTDS KCC

Durch Google bin ich auf die folgende Seite gestoßen:

Troubleshooting Active Directory replication failures that occur because of DNS lookup failures, event ID 2087, or event ID 2088

Das Problem war in meinem Fall, das auf dem SBS in den TCP/IP-Einstellungen als DNS-Server nur der SBS2003 selbst und ein Internet-DNS-Server eingetragen war, und so scheinbar keine vernünftige Namensauflösung funktionierte. Nach ändern der Werte auf die internen DNS-Server erschienen die folgenden Meldungen im Eventlog:

Die Active Directory-Replizierung funktionierte also wieder, allerdings ließen sich die Exchange-Dienste immer noch nicht starten. Im Eventlog tauchten die folgenden Fehlermeldungen auf:

Diese Meldung machte mich ein wenig stutzig, an den Gruppen-Zugehörigkeiten hatte sich nichts geändert. Nach einer Suche nach der Event-ID bin ich auf den folgenden Beitrag gestoßen:

You receive a “Could not start the Microsoft Exchange System Attendant service on Local Computer” error message when you try to start the Exchange System Attendant service

Im Abschnitt “Cause” wird erwähnt, das das Computer-Konto des Exchange 2003 Servers in den Gruppen “Exchange Enterprise Servers”, “Exchange Servers” und “Exchange Domain Servers” sein muss, AUSSERDEM muss sichergestellt sein, das diese Gruppen in dem Standard-Container “Users” liegen.

If these groups are not in the default Users container, the System Attendant service determines that the groups do not exist. Therefore, if these groups are not in the Users container when you start the System Attendant service, the service does not start.

Dies war in der Umgebung nicht der Fall, der komplette Inhalt des Containers “Users” wurde verschoben in andere OUs. Nach dem Zurück-Verschieben der beiden Gruppen “Exchange Domain Server” und “Exchange Enterprise Servers” und einem Neustart des SBS2003 funktionierte auch der Start der Exchange-Dienste wieder problemlos.

Eigentlich sieht man ja auch, das man die Gruppen nicht löschen oder umbenennen oder verschieben darf… :)

Lösung dieses Problems: Man muss die Benutzer, die mit dem Programm arbeiten sollen, in die lokale Gruppe “Hauptbenutzer” hinzufügen.

Es ist mal wieder soweit, es ist der zweite Dienstag im Monat, und das heißt es gibt mal wieder Updates von Microsoft.

Diesen Monat sind es 13 Stück, mein Windows 7 war auch schon am schreien. Weitere Infos zu den einzelnen Patches gibt es unter folgenden Adressen:

Microsoft Technet: Microsoft Security Bulletin Summary for October 2009

Computerbase: Patchday: Microsoft veröffentlicht 13 Bulletins

Heise: Microsoft-Patchday: Alles neu macht der Oktober

Windows 7 (in den Varianten Professional, Ultimate und Enterprise) bietet die Möglichkeit des XP-Mode. Aber was genau ist der XP-Mode und wie funktioniert er?

Der Windows XP-Mode bietet die Möglichkeit, ein Programm, welches nur unter Windows XP funktioniert (und auch mit dem Kompabilitätsmodus nicht dazu überredet werden kann zu funktionieren), auch unter Windows 7 zu betreiben. Man benötigt dazu folgendes:

• Windows Virtual PC RC
• Windows XP Mode RC
• Das Programm, was man im XP-Mode ausführen möchte
• Ein System mit einer CPU, welches die Intel-/AMD-Virtualisierungstechnologie beherrscht

Nach der Installation des Virtual PC und des Windows XP Modes erfolgt die Einrichtung des Windows XP, bei der man ein Passwort für das virtuelle Windows XP angeben muss. Virtuell? Ja genau, die Funktionsweise des XP-Mode ist die folgende:

Man installiert das Programm “Virtual PC”, mit dem man in der Lage ist virtuelle Computer zu betreiben. Mit dem Download und der Installation des “Windows XP Mode” macht man eigentlich nichts anderes als das man eine vorgefertigte virtuelle Maschine mit Windows XP SP3 entpackt und zum “Windows Virtual PC” hinzufügt. Nach dem Start der Maschine wird sie auf das jeweilige Systeme angepasst, man muss z.B. ein Passwort für den Benutzer “XPMUser” eingeben.

Nach dem Start der virtuellen Maschine hat man ein Windows XP vor sich, genau so wie man es gewohnt ist. Um nun ein Programm im XP-Mode zu betreiben, muss man das betreffende Programm in dem Windows installieren. Hierbei muss man folgende Dinge beachten:

• Das Programm muss (wenn konfigurierbar) mit der Option “Für alle Benutzer installieren” installiert werden
• Eine Verknüpfung des Programms muss unter “C:\Dokumente und Einstellungen\All Users\Startmenü” liegen

Nachdem das Programm installiert wurde (Ich habe als Beispiel “Everest” genommen, hat den Vorteil das man sofort die Eigenschaften des Systems sieht und somit eindeutig erkennbar ist, welches System als Basis dient), taucht im Startmenü von Windows 7 eine Liste der installierten Programme auf:

Nach einem Klick auf “Everest Home Edition” (Windows XP Mode) erscheint die folgende Meldung:

Nach einem Klick auf “Fortsetzen” wird die Maschine “Windows XP Mode” heruntergefahren und startet in einem speziellen Modus, welcher die Nutzung von Programmen im “XP-Mode” zulässt.

Nach dem erfolgreichen Start der Anwendung erscheint folgendes Fenster:

Wie man erkennen kann, ist das Programm “seamless” und man merkt beim bloßen Betrachten nicht, das es ein Programm ist, welches im XP-Mode ausgeführt wird. Durch die Anzeige des Betriebssystems und der Grafikkarte erkennt man aber, das es sich um ein Programm handelt, welches in dem virtuellen PC “Windows XP Mode” ausgeführt wird.

Nach der Deinstallation von Everest taucht auch der Eintrag nicht mehr im Startmenü auf:

http://www.windowsblog.at/post/2009/06/02/Windows-7-RTM-Datum-T-Shirts.aspx

Vielen Dank für das T-Shirt, hier wie versprochen das Foto:

Vielen Dank nochmal für das T-Shirt, meine Mail mit der Anfrage habe ich an meinem Geburtstag geschrieben, nettes Geschenk nachträglich :)

Den so erstellten Certificate Signing Request öffnet man mit Notepad, kopiert den Inhalt in die Zwischenablage und fügt Ihn in das CSR Request Formular auf der GoDaddy Zertifikatsseite ein.

Im nächsten Schritt können weitere Namen, auf welche das Zertifikat ebenfalls ausgestellt werden soll, ergänzt werden. In unserem Beispiel ergänzen wir die internen Namen des Exchange Servers (mit und ohnen Domaine) zu autodiscover.rachfahl.de:

vexchange1
vexchange1.it-solutions.de
autodiscover.rachfahl.de


Danach erfolgt eine Überprüfung des SSL Antrags. Hierzu wird in den meisten Fällen eine Mail an den im Denic hinterlegten Domaineninhaber gesendet. Dieser muß dann die Legimität des Antrags über eine in der Mail befindlichen URL bestätigen. Nachdem die Bestätigung erfolgt ist, wird der Antragssteller benachrichtigt und er kann eine ZIP-Datei herunterladen. In diesem Archive befinden sich zwei Dateien (siehe Screenshot).

Es handelt sich um das eigenliche Zertifikat in unserem Beispiel die Datei “mmas.rachfahl.de.crt” und ein Zertifikat für die Zwischenzertifizierungsstelle in unserem Bespiel die Datei “sf_iis_intermediates.p7b”. Beide Dateien entpacken wir in das Verzeichnis C:.
Achtung: bevor das SAN Zertifikat installiert wird muß unbedingt die Zwischenzertifizierungsstelle mit Hilfe des MMC Plugins Zertifikate importiert werden. Beim Öffnen des Plugins Zertifikate wählen sie dazu “Computerkonto” aus, dann öffnen sie die “Zwischenzertifizierungsstellen” und klicken mit der rechten Maustaste auf “Zertifikate”. Jetzt wählen sie “Alle Aufgaben” und “Importieren…” aus und importieren die Datei “c:sf_iss_intermediates.p7b”.

Dannach kann das eigentliche SAN Zertifikat mittels des Powershell Cmdlets Import-ExchangeCertificate in den Zertifikatsspeicher importiert werden.

Import-ExchangeCertificate -Path c:mmas.rachfahl.de.crt


Als Ausgabe des Cmdlets wird eine Thumbprint angezeigt, welche das Zertifikat in dem Zertifikatsspeicher eindeutig identifiziert. Diesen verwenden wir letztendlich mit dem Powershell Cmdlet Enable-ExchangeCertificate um Exchange mitzuteilen, dass er diese Zertifikat zum Verschlüsseln der SSL-Verbindungen benutzen soll.

Enable-ExchangeCertificate -Thumbprint 2CB18AB4F489F2C45BD5E67E842DE31D947BF5DC -Services IIS


Im letzten Schritt prüfen wir durch Aufruf der “Outlook Web Access” Seite (in unserem Beispiel: https://mmas.rachfahl.de/owa ) in einem Webbrowser, ob das neue Zertifikat benutzt wird.

Heute war es mal wieder soweit: die Krankenkassen möchten ihre Meldungen aus der Dakota Schnittstelle  zugemailt bekommen. Dazu ist in unserer Software ein SMTP Mailrelay zu konfigurieren, über das die Mails dann versendet werden. Bei uns ist das ein Microsoft Exchange Server 2007 mit SP1. Da wir diese Maschine in unserer Virtualisierungsumgebung unter Hyper-V neu aufgesetzt haben, ist die Konfiguration aus unserem “alten” Exchange Server ( immerhin auch schon ein 2007er mit SP1) manuell übernommen worden. Heute dann die Überraschung: die Krankenkassenmeldungen kamen bei den Krankenkassen nicht an. Beim Durchsehen der Logs stellte sich heraus, dass unser Exchange 2007 SP1 Server, für den Dakota Rechner, nicht relayen wollte. Nach ein paar Minuten Internetrecherche bin ich dann in dem folgendem Microsoft TechNet Artikel des  Exchange Server Techcenter “Zulassen von anonymem Relay für einen Empfangsconnector” auf die vermeindliche Lösung gestoßen:

Wie dort zu lesen ist, muss man über die Exchange-Verwaltungsshell folgendes Recht dem SMTP Empfangsconnector zuweisen:

Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Obwohl der Microsoft Artikel in deutsch verfasst ist, quitierte mir unser deutscher Exchange 2007 Server, der auf einem deutschen Windows Server 2008 installiert ist, den Befehl mit folgender Fehlermeldung:

Add-ADPermission : Der Benutzer bzw. die Gruppe ‘NT AUTHORITY\ANONYMOUS LOGON’ wurde nicht gefunden. Stellen Sie sicher, dass der Wert richtig eingegeben wurde.
Bei Zeile:1 Zeichen:66 + Get-ReceiveConnector “interner SMTP Connector” | Add-ADPermission  <<<< -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-ExchSMTP-Accept-Any-Recipient”

Das fand ich dann doch ziemlich spannend. Also weiter nach dem Benutzer “NT AUTHORITY\ANONYMOUS LOGON” recherchiert. Ein paar Minuten später stellt sich heraus, dass dieser Benutzer auf deutschen Servern einfach “ANONYMOUS-Anmeldung” heisst. Mit diesem Wissen wird der Befehl aus dem Microsoft Artikel modifizieren in:

Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “ANONYMOUS-Anmeldung” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

und schon klappt der  Befehl und danach auch das Relaying für die Dakota Schnittstelle.

P.S.: Bitte in den obigen Befehlsschnipseln den Passus “Receiver Connector Name” durch den Namen des zu modifizierenden Empfangsconnector ersetzen.

Der Einstieg in die Office 2007 ist einfacher, als manch einer glaubt. Entdecken Sie die Möglichkeiten von: Outlook 2007, Word 2007, Excel 2007 und Power Point 2007. In kostenlosen Videos zeigen wir für Anfänger und Umsteiger die Grundlagen der Programme. In einer zweiten Kategorie finden Sie ab 2009 interessante Features von Office 2007.

Nach einer Eingewöhnungszeit für die Umsteiger auf die neue Bedienerführung mit der Multifunktionsleiste, werden Sie merken, wie viel einfacher sich oft auch komplexe Aufgaben mit Outlook 2007, Word 2007, Excel 2007 und Power Point 2007 lösen lassen. Sowohl was den Austausch der Programme unter einander, als auch die gemeinsame Arbeit an Programmen betrifft gibt es viele tolle Möglichkeiten. Sie werden sehen ein Umstieg oder Einstieg in die Office 2007 Welt lohnt sich.

Unser Hyper-V-Server Blog ist online. Schon seit langer Zeit beschäftigt uns das Thema Virtualisierung sehr intensiv. Für uns war das eines der spannendsten Themen bei der großen Microsoft Konferenz im Februar 2008 in Frankfurt. Aus diesem Grunde wird das Thema für uns im Jahr 2009 im absoluten Fokus stehen. Einige Installations Erfahrungen haben wir bereits hinter uns. Genauso stehen wir kurz vor der Verleihung der Virtualisierung Kompetenz durch Microsoft.

Sie fragen sich vielleicht warum wir gerade bei Microsoft das Thema so spannend finden? Wer uns schon länger kennt, weiß dass wir aus dem UNIX Umfeld kommen und auch heute noch gerne bei dem ein oder anderen Projekt damit arbeiten. Doch inzwischen sind wir Microsoft Fans. Jedes System, jede Software hat ihre Schwächen und Stärken. Was uns super gefällt ist die Zusammenarbeit von Microsoft mit HP und Intel. Das heißt die Virtualisierung wird nicht nur von der Software Seite angestoßen, sondern setzt komplett an der Hardware an. Erst wenn Hard- und Software bei der Virtualiserung zusammen arbeiten, wird es für unsere Kunden so richtig interessant. Schauen Sie vorbei auf unserem Blog. Lesen Sie von den ersten Erfahrungen mit Hyper-V und dem Hyper-V-Server und achten Sie auf unsere Veranstaltung im nächsten Jahr zum Thema Virtualsisierung.