Ich hatte heute das Problem, das die Benutzer eines Kunden bei Terminen, die in dem Kalender eines Raumpostfachs eingetragen worden sind, nicht länger als 1440 Minuten (24 Stunden) sein durften und die Benutzer angefangen haben, die Termine zu stückeln.

Die genauen Fehlermeldung lautete:

Diese Ressource akzeptiert keine Besprechungen, die länger als 1440 Minuten dauern.

Das ist natürlich keine Lösung des Problems, deshalb habe ich mich kurz auf die Suche gemacht und auch mehrere direkt mehrere Treffer bei Google gefunden, bei der das Problem mit Hilfe der Powershell gelöst wurde. Problem war nur, das es ausschließlich bei Exchange 2007 gelöst wurde, der Befehl war der folgende:

Set-MailboxCalendarSettings -Identity “Kalendername” -MaximumDurationInMinutes 5760

Problem bei Exchange 2010 ist, das es das cmdlet “Set-MailboxCalendarSettings” nicht mehr gibt, es gibt nur noch das cmdlet “Set-MailboxcalenderConfiguration”. Mit diesem cmdlet kann man allerdings die Zeit nicht erhöhen.

Die Lösung bei Exchange 2010 ist:

Man muss die Einstellungen in der Exchange Verwaltungskonsole ändern, und zwar in den Eigenschaften des Raum-Postfachs unter

Empfängerkonfiguration => Postfach

Dort gibt es einen Reiter “Ressourcenrichtlinie” und in diesem Reiter die Option “Höchstdauer (Minuten)”. Standardmäßig steht dort 1440, man kann diesen Wert nun auf den gewünschten erhöhen.

Es ist soweit, das Service Pack 1 des Exchange Server 2010 ist verfügbar. Infos zum Service Pack 1 gibt es direkt bei den Jungs, die das ganze Ding produziert haben, und zwar hier:

The Microsoft Exchange Team Blog: The Future of Exchange Starts Here: Exchange Server 2010 SP1 Is Now Available

Der Download ist unter der folgenden Adresse verfügbar:

Download: Microsoft Exchange Server 2010 Service Pack 1 (SP1)

Hier noch Bilder des Setups, denn wie immer sind wir einer der ersten, die die neuen Produkte selbst produktiv einsetzen…

Wie man in den Screenshots erkennen kann fordert das Service Pack diverse Updates an, die man manuell herunterladen und installieren muss sowie weitere Komponenten des IIS.

Die benötigten Update sind:

• Office 2010 Filter Pack
• KB977020
• KB979744
• KB982867
• KB983440

Edit 27.08.10, 11:26:

Soeben ist auch das zweite Update eines Exchange 2010 erfolgreich beendet worden. Bei der zweiten Installation musste ich noch den Dienst des Backup Exec-Agenten beenden, das Setup hat sich beschwert das sich Dateien im Zugriff von einem anderen Programm befinden. In meinem Fall war es wie gesagt der Backup Exec-Agent. Nach dem Beenden des Dienstes lief das Setup fehlerfrei durch und nach einem Neustart kann der Exchange wieder problemlos genutzt werden, der Zugriff per Outlook, per Browser (OWA) und per mobilem Endgerät (zwei Android-Telefone und ein iPhone) funktioniert ebenfalls problemlos.

Ich hatte bei einem Kunden das Problem, das ein Client in einem Branch-Office (Außenstelle im Ausland) über eine VPN-Verbindung keine Verbindung mit dem “Remote Desktop Services” (RDS) –Server in der Zentrale aufbauen konnte. Der Client hat Windows 7 als Betriebssystem und ist nicht Mitglied der Domäne in der Zentrale. Mit einem Windows XP funktionierte die Verbindung ohne Probleme, wenn man über Windows 7 eine Verbindung versuchte, erschien die folgende Fehlermeldung:

Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden.

Der Verbindungsaufbau wird dann abgebrochen, eine Verbindung ist nicht möglich. Ich habe dann überprüft ob der Sperrlistenverteilungspunkt der PKI (per HTTP) erreichbar ist, dies war der Fall, ich konnte sowohl die Sperrliste als auch die Delta-Sperrliste herunterladen.

Das Problem ist eine Einstellung auf dem (oder den, falls mehrere vorhanden sind) RDS-Server. In der “Konfiguration des Remotedesktop-Sitzungshostserver” unter “Verbindungen” in den “Eigenschaften von RDP-Tcp” gibt es den Punkt “Sicherheitsstufe.

In der Info unter der Option sieht man den folgenden Text:

Sie sicherste vom Client unterstützte Stufe wird verwendet. Sofern unterstützt, wird “SSL (TLS 1.0)” verwendet.

Bei einem Windows XP ist die höchste Stufe, die gemeinsam genutzt werden kann, die “RDP-Sicherheitsstufe”. Bei Windows 7 ist die höchste gemeinsam nutzbare Sicherheitsstufe aber die besagte “SSL (TLS 1.0)”-Verschlüsselung. Es ist scheinbar so, das bei dieser Art der Verschlüsselung der Abruf der Sperrliste nicht über HTTP erfolgt (Ob über LDAP weiß ich nicht) und deshalb die Verbindung nicht aufgebaut werden kann. Falls der Abruf über LDAP passieren soll funktioniert dies aufgrund fehlender Domänenzugehörigkeit nicht.

Eine Lösung des Problems ist, das man die Sicherheitsstufe in den Eigenschaften auf “RDP-Sicherheitsstufe” setzt. Danach funktioniert eine Verbindung auch von einem Windows 7 ohne Domänenzugehörigkeit.

Sicherheitstechnisch halte ich das persönlich nicht für kritisch, da ja bereits die Verbindung zwischen den beiden Standorten über eine gesicherte VPN-Strecke aufgebaut wird.

Nach Änderung der Permalinkstruktur auf /%category%/%postname%/ funktionierten die einzelnen Kategorien nichtmehr, stattdessen wurde eine 404-Fehlerseite generiert.

Das Problem dabei ist, dass WordPress automatisch das Wort category vor die eigentliche Kategorie setzt, was wir in unserem Fall aber nicht möchten.

Das kann man in den Permalinkeinstellungen beheben, indem man als Kategoriebasis einen Punkt eingibt. (siehe Screenshot)

Ich hatte heute ein Problem mit DirectAccess das mich einige Nerven gekostet hat: zwei DirectAccess Clients die schon funktioniert hatten konnten nicht mehr auf die interne Struktur zugreifen. Ich habe mehrere Stunden nach dem Problem und damit auch nach der Lösung gesucht: Ergebnis die ActiveDirectory Controller hatten ihre IPv6 DNS-Einträge verloren.

Aber hier das Phänomen und die Lösung:

Nachdem ich viele mögliche Fehlerquellen auf dem Client ausgeschlossen hatte blieb ich an der Ausgabe des Befehls:

nltest /dsgetdc: /force

Fehler beim Abrufen des Domänencontrollernames: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

hängen. Mit diesem Fehler als Hinweis testete ich die IPv6 Namesauflösung der internen Domain: Ergebnis diese funktionierte auch nicht.

Nach Aufwahl auf den DirectAccess Server entdeckte ich dann in der “DirectAccess Verwaltung” im Punkt “Überwachung” das die DNS Server einen Fehler aufweisen. Der Fehler lautet:

Keiner der internen DNS-Server <IPv6 Addresse> von den DirectAccess-Clientcomputern für die Namensauflösung verwendet werden, reagiert. Dadurch wird verhindert, dass mithilfe der DirectAccess-Clients Namen im internen Namespace aufgelöst und Verbindungen muss dem internen Netzwerk hergestellt werden können. Stellen Sie sicher, dass die DNS-Server online sind und auf Namensauflösungsabforderungen reagieren

Ursprung dieses Fehlers ist, dass die Nameserver zwar über IPv4 angesprochen werden können aber nicht über IPv6. Wenn man sich auf den DNS Server die Auflösung der ADS Controller anschaut, dann bemerkt man das nur die IPv4 Adressen registriert sind und nicht auch die IPv6 Adressen wie im Beispiel beim DirectAccess Server vDirectAccess.

Diese kann man beheben indem man sich an den ADS Controller anmeldet, dort eine administrative Kommandozeile startet und dann mit den Befehlen:

net stop iphlpsvc

net start iphlpsvc

den IP-Hilfsdienst neustartet. Dieser sollte dann die IPv6 Adressen des Rechners wieder in den DNS-Server eintragen. Danach sehen die Einträge im DNS-Server folgendermaßen aus:

Auch das Tool “DirectAccess Verwaltung” zeigt dann an das alles in Ordnung ist:

Fazit: wer mal ab und zu in die mitgelieferten Tools schaut der kann sich einige Zeit bei der Problemsuche sparen

Ich hatte bei einem Kunden das Problem, das Benutzer A an Benutzer B keine Mail mehr schicken konnte. Benutzer A erhielt einen “Non Delivery Report”, trotz korrekt eingegebener Adresse. Was ist passiert?

Vor einiger Zeit haben wir bei diesem Kunden den Exchange Server 2003 abgelöst und einen Exchange Server 2010 eingeführt. Das allein konnte ja nicht der Grund sein, deswegen bin ich auf die Suche nach dem Fehler gegangen.

Erster Anhaltspunkt war natürlich der NDR, der wie folgt aussieht:

Was mich hier stutzig gemacht hat ist die Adresse, an die es geschickt werden soll:

IMCEAEX-_O=Domäne_OU=First+20administrative+20group_cn=Recipients_cn=benutzer@domain.de

Der Wert “First Administrative Group” sollte nicht mehr auftauchen, da dies auf den Exchange Server 2003 hinweist. Wenn man sich auf dem Domänencontroller in “Active Directory-Benutzer und –Computer” einmal in den Eigenschaften des Benutzers die Attribute anschaut, sieht das Attribut “legacyExchangeDN” wie folgt aus:

Wie man sieht, ist das Attribut anders als die Adresse, an die die Mail hingeschickt werden soll. Woher also kommt nun der falsche Wert?

Die Lösung ist der automatische Vervollständigungs-Cache (auto-complete cache). Dieser nutzt X.500-Adressen, und wenn der gespeicherte Wert (gespeichert zu Zeiten des Exchange 2003) genutzt wird (was gemacht wird, egal ob man die Adresse nur anfängt zu tippen und dann die gespeicherte Adresse nutzt oder ob man die komplette Adresse neu tippt), dann will die Email an die alte zwischengespeicherte Adresse gesendet werden.

Wie kann man den Fehler nun beheben? Auf dem Exchange 2010-Server in den Eigenschaften des Benutzers (an den die Email gesendet werden soll) trägt man eine zusätzliche X.500-Adresse ein. Das sieht dann wie folgt aus:

Wichtig ist, das man hier den Haken bei “E-Mail-Adressen automatisch basierend auf der E-Mail-Adressrichtlinie aktualisieren” entfernt.

Nach dem Eintragen dieser Adresse kam die Email an, trotz Auto-Vervollständigung :)

Hallo, wir schwören schon seit einiger Zeit bei unseren Blogs auf WordPress. 

WordPress ist zur Verwaltung von Inhalten auf einer Website wie z.B. Bilder, Texte und vieles mehr.

Viele User die WordPress kennen updaten dieses sicherlich manuell statt die eingebaute WordPress Upgrade Funktion (die mittlerweile wirklich klasse ist) zu benutzen.
Ich habe mir in der vergangen Zeit eine Reihenfolge erarbeitet mit der ich bisher stets gute Erfahrungen gemacht habe.

1. Zuerst sollte ein Backup der Dateien sowie eine Sicherung von der Datenbank gemacht werden.
Jan Kappen hat hier (WordPress: Automatische Datenbank-Sicherung)einen Artikel geschrieben zur Sicherung von WordPress Datenbanken.

2. Alle Plugins die zusätzlich installiert worden sind Deaktivieren da einige Plugins ab und an nicht mit einer neuen Version funktionieren und es dann zu Problemen kommen kann.

3. Dateien löschen bis auf wp-content, wp-config und die .htaccess. In einigen Versionen wurden allerdings auch Sicherheitslücken in der wp-config verändert, somit sollte man diese selbstverständlich auch updaten und nachher wieder manuell anpassen.

4. Neue Dateien einfügen und ggf. die alten Dateien überschreiben.

5. im Browser die www.DOMAIN.??/wp-admin/upgrade.php aufrufen und die Struktur aktualisieren.

6. im Dashboard anmelden und die Plugins sofern notwendig updaten. Falls nicht notwendig die Plugins nacheinander wieder aktivieren.

In einigen Blogs habe ich gelesen das viele User ähnlich updaten wie ich, falls jemand ein besseres vorgehen hat lasst es mich wissen :).

PS.: Diese Erfahrungen beziehen sich auf einschließlich Version 3.0.

1. Der einfache Weg (mit UAG und hohen Kosten)

2. Der steinige Weg (mit Windows 2008 R2 Bordmitteln und überschaubaren Kosten)

Wir wählten aus zwei Gründen Variante 2:

Erstens schließt sich im SMB Umfeld „der einfache Weg“ aus Kostengründen aus (das UAG kostet alleine schon über 6000 €) und zweites ist das ein Projekt für die ITHer0s. Also machte sich Jan Kappen daran einen Weg zu erarbeiten, wie man DirectAccess in einer relativ “normalen” IT Umgebung (nämlich unserer) ans Laufen bringen kann.

Das daraus schließlich  mehr als 1 Mannwoche werden sollte hatte im Vorfeld keiner gedacht. Trotzdem hat sich das Ergebnis gelohnt. Wir können nun unterwegs unsere Notebooks aufklappen und losarbeiten. Etwas das man, wenn man es erst mal benutzt hat, nicht mehr missen möchte. Aber lesen Sie selbst die Anleitung von Jan, in der er aufzeigt, wie man DirectAccess in einer normalen Umgebung ohne UAG implementiert.

Die Grundvoraussetzungen

Da wir soeben erfolgreich Direct Access bei uns implementiert habe, möchten wir das ganze natürlich hier auch dokumentieren bzw. für andere zur Verfügung stellen, die sich ebenfalls mit dem Thema beschäftigen. Die komplette Einrichtung hat sich mehrere Tage hingezogen, inkl. Testumgebung, Fehlersuche und Nachstellen in der Testumgebung.

Hilfreich waren uns bei der Einrichtung die folgenden Dokumente:

Test Lab Guide: Demonstrate DirectAccess

DirectAccess Design, Deployment, and Troubleshooting Guides

Der oben verlinkte Test Lab Guide hat bei uns sofort nach der Einführung anstandslos funktioniert, allerdings gab es während der Installation in unserer Umgebung das eine oder andere Problem bzw. diverse Voraussetzungen, die zwar erfüllt sein müssen, in dem Test Lab Guide aber nicht erwähnt wurden. Die komplette Installation ist ein ziemlich großes Projekt, was nicht mal eben an einem Nachmittag durchgeführt werden kann und bei dem einige Überlegungen vor Beginn der Installation anstehen. Aus diesem Grund haben wir uns dazu entschieden, die komplette Dokumentation in mehrere Teile zu gliedern. In diesem ersten Teil geht es um die Grundvoraussetzungen, die für eine erfolgreiche Implementierung erforderlich sind.

Die einzelnen Funktionen und die Anzahl der Server

Wer sich das oben erwähnte Test Lab Guide angeschaut hat (und das empfehlen wir ausdrücklich!) wird feststellen, das Microsoft sechs Systeme benötigt, vier Windows Server 2008 R2 und zwei Windows 7 Enterprise. Ein Windows 7 fällt in einer “normalen” Umgebung weg, da hier ausschließlich ein Router simuliert wird, und solch ein Gerät in der Regel an nahezu jedem Internet-Anschluss für den Aufbau der Internetverbindung verantwortlich ist. Das zweite Windows 7 ist der Direct Access Client, hier ist nur wichtig, das es sich um eine Enterprise- oder Ultimate-Version handelt. Ob 32 Bit oder 64 Bit ist egal.

Bei den Servern wird ein Domänencontroller benötigt, der gleichzeitig DNS-Server (für die Domäne) und DHCP-Server ist, zusätzlich wird er für eine PKI benötigt und hat die Rolle “Active Directory-Zertifikatdienste” aktiviert. Als zweites System wird der Direct Access-Server benötigt, ebenfalls zwingend ein Windows Server 2008 R2. Der dritte Server im Test Lab fungiert als Dateiserver und als Network Location Server. Server Nummer Vier wird genutzt, um einen externen DNS-Server zu simulieren. Diese Aufgabe wird in den meisten Fällen vom Internet-Provider übernommen, daher ist diese Maschine nur in der Demo-Umgebung nötig und fällt in einem Live-Szenario raus (nur der Server als Hardware/Lizenz, nicht die Funktionalität).

Nun die entscheidende Frage: Wie viele Server brauche ich für mein Projekt?

Wir haben für mein Projekt zwei neue Systeme benötigt, wären zur Not aber auch mit einem ausgekommen. Hier die Auflistung der Server inkl. Rollenverteilung:

Server1:

Windows Server 2008 R2, Domänencontroller, DNS-Server, DHCP-Server, Zertifikatdienste

Server2:

Windows Server 2008 R2, Direct Access-Feature

Server3:

Windows Server 2008 R2, Network Location Server, PKI Sperrlisten-Verteilungspunkt

Server4:

Debian Linux, externer DNS-Server

Server5:

Windows Server 2008 R2, File-Server

Server2 und Server3 haben wir im Zuge des Projekts neu installiert, die restlichen Server waren schon vorhanden und wurden nur angepasst.

Wichtige Dinge, die man vor Beginn der Installation wissen sollte

• Die interne Domäne und die externe Domain müssen unterschiedlich sein. Es ist nicht möglich Direct Access erfolgreich einzurichten, wenn sowohl Domäne als auch Domain gleich sind. Was allerdings funktioniert ist, wenn die Domain contoso.com ist und die Domäne corp.contoso.com. Contoso.com als Domain und Domäne hingegen funktioniert nicht.
• Es werden zwei aufeinanderfolgende, öffentliche IPs benötigt. Adressen, die genatet werden, funktionieren nicht!
• Bevor man automatisch Computer-Zertifikate ausrollt oder sonstige Zertifikate erstellt sollte man sicher gehen, das die PKI so funktioniert wie sie soll und das nichts mehr verändert werden muss. Falls etwas geändert werden muss (In meinem Fall die URL des Sperrlisten-Verteilungspunktes), müssen die Zertifikate teilweise oder komplett neu erstellt werden, da die Änderungen nicht in den vorher ausgestellten Zertifikaten enthalten sind und es somit zu Fehlern kommen kann.
• Ob ein Gerät sich per Direct Access mit dem Firmennetz verbindet oder nicht wird durch eine Gruppe in der Active Directory festgelegt. Wir empfehlen in diese Gruppe zuerst ein Gerät zu stellen, was nicht gerade dem Geschäftsführer oder einer anderen wichtigen Person gehört. Wir hatten durch eine Fehlkonfiguration das Problem, das mein Notebook (als einziges Mitglied der Gruppe) die Direct Access-GPO gezogen hatte, und danach keine Kommunikation mehr zum Domänencontroller aufbauen konnte, und somit auch keine Änderungen mehr mitbekommen hat. Das Problem ließ sich nur lösen, indem ich mein Notebook aus der Domäne entfernt habe und neu hinzugefügt habe.
• Es ist nur möglich eine Verbindung zu Maschinen im Firmennetzwerk aufzubauen, die per IPv6 kommunizieren können. Bei Windows Server 2003 kann man IPv6 nachinstallieren, Windows 2000 ist zu alt. Man kann Programme von Drittherstellern installieren die diese Funktion nachrüsten, aber möchte man wirklich sein mittlerweile zehn Jahre alten Server per Direct Access seinem Windows 7 verfügbar machen?
• Der “Forest Functional Level” muss nicht zwingend “Windows Server 2008 R2” sein wie in dem Guide beschrieben, das schließt Domänencontroller mit Systemen älter als Windows Server 2008 R2 nicht aus, Bedingung ist nur mindestens einen Windows Server 2008 R2 als Domänencontroller und als DNS-Server
• Es wird kein SSL-Zertifikat benötigt, was z.B. von GoDaddy oder VeriSign gegengezeichnet wurde. Es reichen die Zertifikate aus, die von der eigenen PKI erstellt werden.

Der Domänencontroller

Nachdem wir nun in Teil 1 besprochen haben welche Anforderungen an die Umgebung und die Systeme bestehen, fangen wir nun mit der Installation bzw. Einrichtung des Domänencontrollers an.

Das System muss ein Windows Server 2008 R2 sein, und es müssen die folgenden Rollen aktiviert werden:

• Active Directory-Domänendienste
• Active Directory-Zertifikatdienste
• DHCP-Server
• DNS-Server

Wie man in dem Screenshot sehen kann ist auf unserem System noch die Rolle “Webserver (IIS)” aktiviert, dies ist zur Anforderung von Zertifikaten per Web-Browser.

Active Directory-Domänendienste

Diese Rolle wird automatisch installiert, wenn man “dcpromo” ausführt, um den Server zum Domänen-Controller hochzustufen. Wenn man die Domäne neu aufsetzt, kann man während des Wizards ruhig “Windows Server 2008 R2” als “Forest Functional Level” nehmen, bei einer vorhandenen Active Directory muss der Level nicht auf “Windows Server 2008 R2” erhöht werden. Wie schon in Teil 1 erwähnt, darf der Name der Domäne nicht gleich dem Namen der Internet-Domain sein. Wenn Domain und Domäne gleich sind, funktioniert Direct Access nicht. Rachfahl.de und rachfahl.loc hingegen sind kein Problem, ebenso (wie in dem Step by Step-Guide beschrieben) contoso.com und corp.contoso.com.

Sonst ist weiter bei der Installation nichts zu beachten, alle wichtigen Änderungen bzw. Erweiterungen werden im Laufe der Implementierung durchgeführt und dann dokumentiert.

Active Directory-Zertifikatdienste

Diese Rolle muss installiert werden, damit die benötigten Zertifikate ausgestellt werden können. Während der Installation werden die folgenden Dinge angefragt (Screenshots von Maschine aus dem Step by Step-Guide):

DHCP-Server

Bei der Installation des DHCP-Servers ist eigentlich nichts weiter zu beachten, außer das man bei der Nachfrage zur “Konfiguration des statusfreien DHCPv6-Modus” die Option “Statusfreien DHCPv6-Modus für diesen Server deaktivieren” auswählt.

DNS-Server

Schon während der Hochstufung des Servers zum Domänencontroller wurde angeboten, die DNS-Rolle mit zu installieren. Dies sollte gemacht werden, da man sonst nach der Hochstufung erneut Hand anlegt und die DNS-Server-Rolle installiert. Wenn es der erste Domänencontroller ist, muss man die DNS-Server-Rolle eh installieren. Weiter müssen keine Einstellungen gemacht werden, es müssen lediglich Einträge erstellt werden. Hierzu allerdings später mehr.

Anlegen einer Sicherheitsgruppe in der Active Directory

Wir legen nun in der Active Directory eine neue Sicherheitsgruppe an, in die später die PC-Konten kommen, die eine Verbindung per Direct Access aufbauen sollen. Ich habe die Gruppe “DirectAccess_Clients” genannt, das ist aber jedem selber überlassen. Wichtig ist, das die folgenden Einstellungen verwendet werden:

Erstellen einer eigenen Zertifikats-Vorlage

Als nächstes erstellen wir eine neue Zertifikats-Vorlage, die wir später benutzen, um Zertifikate für z.B. den “Network Location Server” anzufordern. Hierzu öffnen wir uns den Server-Manager, erweitern den Punkt “Active Directory-Zertifikatdienste” und gehen zum Punkt “Zertifikatvorlagen”. Dort werden alle vorhandenen Vorlagen gelistet, ziemlich weit unten finden wir die Vorlage “Webserver”.

Ein Rechtsklick auf “Webserver” und “Doppelte Vorlage” erzeugt eine Kopie des Zertifikats. Hier in Screenshots die Einstellungen der neu erzeugten Zertifikatvorlage:

Wichtig ist hier die Einstellung “Exportieren von privatem Schlüssel zulassen”!

Unter “Sicherheit” muss in den Berechtigungen der “Authentifizierten Benutzer” das Recht “Registrieren” hinzugefügt werden, weiterhin muss die Gruppe “Domänencomputer” hinzugefügt werden, die ebenfalls die Rechte “Lesen” und “Registrieren” erhält.

Nach Erstellung der Vorlage muss man diese noch in die Vorlagen der Zertifizierungsstelle hinzufügen, dies macht man wie folgt:

In dem darauf erscheinenden Fenster wählt man die soeben erstellte Vorlage aus (In meinem Fall “Web Server 2008 (DirectAccess)”), und schon ist die Vorlage verfügbar.

Erstellen einer Firewall-Regel um ICMPv6 zu erlauben

Direct Access kann nur funktionieren, wenn sich bestimmte Systeme untereinander über IPv6 anpingen können. Aus diesem Grund erstellen wir nun eine Firewall-Regel, die per Gruppenrichtlinie ausgerollt wird und auf allen Systemen die nötigen Einstellungen setzt. Auf dem Domänencontroller öffnen wir die Gruppenrichtlinienverwaltung, und erstellen ein neues Gruppenrichtlinienobjekt (Ich habe es “ICMPv6-Firewall-Policy” genannt, wie man es nennt ist egal). Wir navigieren zu

Computerkonfiguration / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Windows-Firewall mit erweiterter Sicherheit / Windows-Firewall mit erweiterter Sicherheit

Unter “Eingehende Regeln” legen wir eine Regel “Inbound ICMPv6 Echo Requests” an. Die Einstellungen sind wie hier gezeigt:

Unter ausgehende Regeln legen wir ebenfalls eine Regel anhand der oben gezeigten Einstellungen an, der einzige Unterschied ist der, das wir die Regel nicht “Inbound ICMPv6 Echo Requests” nennen, sondern “Outbound ICMPv6 Echo Requests”.

Nach der Erstellung der GPO darf man natürlich nicht vergessen, diese auch mit der Domäne zu verknüpfen!

Entfernen von ISATAP aus der DNS global block list

Als nächstes muss man den ISATAP-Eintrag aus der “DNS global block list” entfernen. Hierzu ruft man sich eine Kommandozeile als Administrator auf (Im weiteren Verlauf “administratives cmd-Fenster”)

In der Kommandozeile rufen wir den folgenden Befehl aus

dnscmd /config /globalqueryblocklist wpad

Dieser Befehl bewirkt, das in der Registry unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters

in dem REG_MULTI_SZ-Wert “GlobalQueryBlockList” nur noch der Wert “wpad” steht, und nicht mehr “wpad” und “isatap”.

Damit die Änderungen greifen ist der “IP-Helper Dienst” neu zustarten. Das kann man durch die Befehle:

net stop iphlpsvc
net start iphlpsvc

erreichen.

Der Direct Access-Server

Grundeinrichtung:

Nachdem wir nun unseren Domänencontroller weitestgehend eingerichtet bzw. angepasst haben, kommen wir nun zur Einrichtung des Direct Access-Servers. Geplant ist, das auf dem Direct Access-Server zusätzlich noch der IIS-Server installiert wird, um dort die Sperrlisten der CA abzulegen bzw. abzurufen.

Nach der Grundinstallation des Windows Server 2008 R2 müssen auf dem einen Netzwerk-Interface eine interne Adresse vergeben werden, und auf dem zweiten Interface müssen die beiden öffentlichen Adressen eingerichtet werden, die für den Betrieb von Direct Access benötigt werden. An dieser Stelle empfiehlt es sich, die beiden Interface umzubenennen in “intern” und “extern”, da man die Netzwerkkarten später in der Konfiguration auswählen muss und nur den Namen sieht.

Wichtig ist, das man bei der internen Netzwerkkarte in den erweiterten TCP/IPv4-Einstellungen unter DNS bei “DNS-Suffix für diese Verbindung” den internen Domänen-Namen einträgt, da sonst später das Direct Access-Setup diesen Punkt anmäkelt.

Nach dem einstellen der Netzwerkadressen muss der Server in die Domäne aufgenommen werden.

Wichtig: Es ist notwendig, dass die interne IP-Adresse des DirectAccess Servers über den Namen “isatap” aufgelöst werden kann. Hierzu müssen wir in die DNS Konfiguration Ihres DNS Servers wechseln, dort die interne Domaine auswählen (in unserem Beispiel “corp.contoso.com”) und dann einen A-Record mit dem Namen “isaptap” und der IPv4-Adresse der internen Netzwerkschnittstelle des DirectAccess-Servers ergänzen.

Einrichten eines webbasierten Sperrlistenverteilungspunktes

Zuerst installieren wir die Rolle “Webserver (IIS)”  über den “Server-Manager” nach. Im Internetinformationsdienste-Manager navigieren wir nun unter “Sites” zur “Default Web Site”, klicken mit rechts darauf und wählen “Virtuelles Verzeichnis hinzufügen…”

Im darauf erscheinenden Fenster wählen wir unter “Alias” den Alias-Namen aus, in unserem Fall “CRLD”. Bei “Physikalischer Pfad:” muss der Pfad auf der Festplatte eingetragen werden, in dem die Dateien gespeichert werden. Dies ist auch der Pfad, der gleich freigegeben wird, damit der CA-Server dort seine Dateien speichern kann (Mehr dazu unter “Konfiguration der CA”).

In den Eigenschaften des Verzeichnises “CRLD” im IIS-Manager wählen wir “Verzeichnis durchsuchen” und aktivieren die Funktion rechts in der Aktions-Leiste.

Im Konfigurations-Editor unter “system.webServer/security/requestFiltering” setzen wir die Option “allowDoubleEscaping” auf “True”

Erstellen der Windows-Freigabe

Als nächsten Schritt müssen wir nun den soeben angelegten Ordner freigeben. Hierzu gehen wir zu dem Ordner, wählen “Eigenschaften”, “Freigabe” und dann “Erweiterte Freigabe”:

Konfiguration der CA

Vorbemerkung zur Sperrlistenverteilungspunkt-Konfiguration

Wir kommen nun zu einem sehr wichtigen Punkt. Wir richten nun einen Sperrlistenverteilungspunkt ein. Unsere CA pflegt eine Sperrliste, in der alle Zertifikate aufgeführt werden, die gesperrt sind. Diese Datei wird von dem Server, auf dem die CA läuft, in eine UNC-Freigabe kopiert, und kann dann per http abgerufen werden. Wenn man an der Konfiguration der CA (wie in diesem Fall) etwas ändert, kann es sein das zuvor ausgestellte Zertifikate (bzw. die Kommunikation mit Hilfe dieser Zertifikate) nicht mehr funktionieren. In unserem Fall mussten wir die Zertifikate für unsere RDS-Farm neu erstellen, da die “alten” Zertifikate noch nicht den Sperrlistenverteilungspunkt eingetragen hatten, und dadurch ein Verbindungsaufbau nicht erfolgreich war.

Da das mehrfache Erstellen von Zertifikaten ziemlich zeitaufwendig ist, sollte man sich vor der Einrichtung einer CA bzw. dem Sperrlistenverteilungspunkt genaue Überlegungen machen, welche Einstellungen man tätigt, um eventuelle Mehrarbeit zu vermeiden.

DNS-Einträge erstellen

Als ersten Schritt muss man einen DNS-Eintrag für den Webserver eintragen (lassen), auf dem die Sperrlisten-Dateien liegen (in unserem Fall der Direct Access-Server). Dieser Eintrag wird in der Regel bei dem zuständigen Provider gemacht, oder wenn man die Möglichkeit hat, kann man ihn auch selbst eintragen. Da wir für unsere DNS-Auflösung selbst zuständig sind, kann ich die Eintragung selbst durchführen. Dazu muss ein Name gewählt werden, wir halten uns da an den Step by Step-Guide und verwenden “crl” als Hostname.

Neben dem Eintrag “crl” benötigen wir ebenfalls noch einen Hostnamen, mit dem die Verbindung zum Direct Access-Server aufgebaut wird. Diesen haben wir direkt mit eingetragen, in unserem Fall war es “vdirectaccess”. Diesen Namen merken, wir benötigen ihn später noch.

Wichtig: Als IP-Adresse für den Hostname muss die erste der beiden öffentlichen Adressen eingetragen werden, nicht die zweite und nicht beide!!!

Sperrlistenverteilungspunkt einrichten

Auf dem Server, auf dem die Zertifizierungsstelle (CA) installiert ist, öffnen wir nun die Konsole “Zertifizierungsstelle” unter “Start” => “Verwaltung”.

Im Reiter “Erweiterungen”  im Punkt “Sperrlisten-Verteilungspunkt” fügen wir nun zwei Einträge hinzu, und zwar einmal die Verbindung per http (extern) und einmal per UNC-Freigabe (intern).

Externe Verbindung:

Nach einem Klick auf “Hinzufügen…” tragen wir unter “Ort” die Adresse des Webservers ein, ein unserem Fall

http://crl.contoso.com/crld/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Wichtig: Man darf hinter den Variablen nicht das “.crl” vergessen, sonst werden Dateien ohne Endung angelegt!

Nach einem Klick auf “OK” wählen wir die folgenden Optionen

Interne Verbindung:

Wir klicken erneut auf “Hinzufügen…” und tragen nun die Adresse der Freigabe ein, die wir im vorherigen Schritt erstellt haben:

\\servername\crldist$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Nach dem Klick auf “OK” wählen wir die folgenden Optionen

Wichtig hier ist, das wir nicht die Optionen

“In Sperrlisten einbeziehen. Wird z. Suche von Deltasperrlisten benötigt”

und

“In CDP-Erweiterung des ausgestellten Zertifikats einbeziehen”

wählen, da die Freigabe sonst auch von dem Client abgefragt wird, was wir nicht wollen!

Nach einem Klick auf “OK” möchte der Dienst der CA neustarten, wir bejahen die Anfrage und warten bis der Dienst neugestartet wurde.

Überprüfung der Veröffentlichung

Wenn wir nun auf dem Server, auf dem die CA installiert ist, die Freigabe öffnen, dürften wir noch keine Dateien sehen. Wenn man nun in der Zertifizierungsstelle-Konsole unterhalb der CA einen Rechtsklick auf “Gesperrte Zertifikate” macht und den Punkt “Veröffentlichen” im Menüpunkt “Alle Aufgaben” wählt, veröffentlicht die CA ihre Sperrliste und ihre Deltasperrliste an dem soeben angegeben Ordner. Dort liegen nun zwei Dateien, eine heißt so wie die CA, und die andere hat noch ein “+” im Namen.

Konfiguration des Auto-Enrollment der Computer-Zertifikate

Für den nächsten Punkt müssen wir auf einen Domänen-Controller. Dort gehen wir in die “Gruppenrichtlinienverwaltung” und erstellen ein neues Gruppenrichtlinienobjekt, in meinem Fall heißt es “Autoenrollment”.

Unter

“Computerkonfiguration / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Richtlinien für öffentliche Schlüssel”

stellen wir in dem Objekt “Zertifikatsdienstclient – Automatische Registrierung” die folgenden Einstellungen ein:

Als zweiten Punkt müssen wir unter “Einstellungen der automatischen Zertifikatsanforderung” noch die “Computer-Zertifikats-Vorlage” hinzufügen:

Wichtig: Auch hier bitte nicht vergessen, die soeben erzeugte GPO mit der Domäne zu verknüpfen!

Anfordern eines weiteren Zertifikates für den Direct Access-Server

Auf dem Direct Access-Server öffnen wir eine mmc, fügen “Zertifikate” als Snap-In hinzu (Zertifikate für “Computerkonto”) und navigieren zu “Eigene Zertifikate” => “Zertifikate”.

Dort wählen wir im Kontextmenü unter “Alle Aufgaben” => “Neues Zertifikat anfordern…”. Unter “Zertifikate anfordern” in dem Wizard wählen wir die Vorlage aus, die wir im Teil “Der Domänencontroller” erstellt haben, in meinem Fall “Web Server 2008 (DirectAccess)”.

Wie in der Warnung schon ersichtlich, werden zusätzliche Informationen benötigt. Mit einem Klick auf die blaue Schrift gelangt man in das folgende Fenster:

Die Einstellungen bei “Typ” müssen “Allgemeiner Name” und “DNS” sein, als Wert muss hier jeweils der Name des Direct Access-Servers eingetragen werden (Den Namen haben wir weiter oben in unserem DNS-Server eingetragen!). Außer diesen beiden Eintragungen muss hier nichts weiter gemacht werden, nach einem Klick auf “OK” kann man den Wizard weiter durchklicken, und am Ende hat man ein neues Zertifikat, ausgestellt auf den Namen, der aus dem Internet erreichbar ist.

Tipp: Nachdem das Zertifikat erstellt wurde, sollte man in den Eigenschaften des Zertifikats unter “Anzeigename” etwas eintragen, Vorschlag von Microsoft ist “IP-HTTPS Certificate”. Dies dient zur besseren Orientierung, während der Konfiguration des IIS auf dem NLP-Servers wird man sehen, wozu dieser Eintrag hilfreich ist :)

Der Network Location Server

Als nächsten Schritt richten wir einen “Network Location Server” (NLS) ein. Dieser Server spielt bei der Überprüfung des Clients eine Rolle, da diese ihren Standort (intern oder extern) danach bestimmen, ob sie den NLS-Server erreichen können oder nicht. Aus diesem Grunde ist es wichtig, das der Server per HTTPS nur von intern erreichbar ist.

Für die Funktionalität muss kein eigener Server aufgesetzt werden, es wird lediglich ein System benötigt, welches Mitglied der Domäne ist, und auf dem die IIS-Rolle entweder schon aktiv ist, oder auf dem sie aktiviert werden kann.

Auf dem Server öffnen wir uns in einer mmc das Snap-In “Zertifikate” und erstellen unter “Eigene Zertifikate” wie schon auf dem Direct Access-Server ein eigenes Zertifikat. Als Vorlage benutzen wir ebenfalls “Web Server 2008 (DirectAccess)”.

Auch hier müssen wir weitere Informationen hinterlegen, die wir durch einen Klick auf die blaue Schrift eintragen können. Die Einstellungen hier sehen wie folgt aus:

Wichtig: Die hier hinterlegte Adresse muss der interne Domänenname sein, NICHT ein externer Name. In dem Step-by-Step Guide ist “corp.contoso.com” die Domäne, “contoso.com” die Internet-Domain!

Als nächstes wechseln wir in den IIS-Manager und wählen unter “Default Web Site” (Oder da, wo die https-Bindung hinzugefügt werden soll) “Bindungen hinzufügen”.

Im nächsten Menü wählen wir “Hinzufügen…”, wählen “https” aus und unten das vorhin erzeugte Zertifikat.

Später in der Konfiguration des Direct Access werden wir nach der Adresse des NLS-Servers gefragt. Wenn man diese Seite aufruft muss der Code, den der Server zurückgibt, der Statuscode 200 sein. Es darf keine Abfrage von Benutzerdaten oder ähnlichem kommen, d.h man kann hier nicht die interne Adresse des “Outlook Web Access” oder ähnlichen Seiten nehmen…

Falls man keinen Fileserver hat oder diesen während der Einrichtung noch nicht verändern möchte, kann man auf diesem Server noch eine Datei-Freigabe erstellen, um später den Zugriff von einem Client aus auf diese Freigabe zu testen. Hierzu legt man einfach einen Ordner an (im Guide wird der Ordner “Files” genannt). Dann legt man eine beliebige Textdatei in diesem Ordner an und gibt den Ordner anschließend frei. Zum Test kann “Jeder” Lesezugriff haben, man kann die Freigabe-Rechte aber auch einschränken, so das nur die Admin-Gruppe Zugriff hat oder nur der Benutzer, mit dem das Direct Access später getestet wird.

Die Einrichtung des Direct Access

Nach all den Vorbereitungen sind wir nun an dem Punkt angelangt, an dem wir mit der Konfiguration bzw. der Einrichtung des Direct Access beginnen können. Als erstes müssen wir im Server-Manager unter “Features” das Feature “DirectAccess-Verwaltungskonsole” aktivieren.

Zusätzlich wird noch automatisch das Feature “Gruppenrichtlinienverwaltung” installiert. Weiter braucht man nichts zu bestätigen oder einzutragen, man kann den Wizard einfach durchklicken. Ein Neustart wird nicht benötigt, nach der Installation kann man direkt mit der Einrichtung starten.

Nach dem Aufruf der Konsole sollte einen das folgende Bild erwarten:

Falls dies nicht der Fall ist, wird einem der Grund für den Fehler angezeigt. Die Fehler die wir bisher hatten waren:

• In den Netzwerkeinstellungen war unter “Erweitert” => “DNS” kein DNS-Suffix eingetragen
• Die GPO mit der Firewallregel war noch nicht aktiv und der Wizard hat erkannt, das ICMPv6 noch nicht in den Ausnahmen war
• Die externe Netzwerkkarte hatte keine DNS-Server eingetragen (Diesen Fehler hatte ich nur in einer frühen Phase unserer Umgebung, das die externe Karte keine DNS-Server hat ist an sich in Ordnung, wenn die Auflösung über das interne Interface gemacht wird)

Schritt 1:

Nach einem Klick auf “Bearbeiten” wählen wir die Gruppe mit den Computerkonten aus, die wir im Teil “Der Domänencontroller” angelegt haben:

Schritt 2:

In Schritt 2 werden die Schnittstellen des Systems eingetragen und die benötigten Zertifikate hinterlegt.

An dieser Stelle erweist sich die erwähnte Benamung der Netzwerkschnittstellen (“extern” und “intern") als Vorteil, da man hier nur den Namen der Schnittstelle in der Auswahlliste sieht, nicht die dazugehörigen Adressen. Wenn alle Einstellungen für den Wizard korrekt sind, erscheint unten nur ein Info-Feld, keine Warn- oder Fehlermeldung. Nach einem Klick auf weiter muss man die Zertifikate auswählen, die benötigt werden.

Das obere Zertifikat ist das der CA, das untere ist das Zertifikat, welches wir im Teil “Konfiguration der CA” angefordert haben (“vdirectaccess.contoso.com” war der Beispiel-Name, zur Verdeutlichung haben wir es “IP-HTTPS” genannt). Nach einem Klick auf “Fertig stellen” endet der Wizard für Teil 2.

Schritt 3:

Hier wird als erstes die Adresse des Network Location Server angegeben

Durch einen Klick auf “Überprüfen” stellt man die Funktionalität sicher. Zur Info: Dies ist die Adresse, die wir im Teil „Der Network Location Server“ definiert haben.

Nach einem Klick auf “Weiter” wird automatisch der Namenssuffix der Domain sowie der Name des NLS-Servers (ohne IP eines DNS-Servers) eingetragen. All die Namen, die hier eingetragen werden ohne IPv6-Adresse eines DNS-Servers, werden grundsätzlich nicht über die Direct Access-Verbindung aufgerufen. Da durch den NLS-Server überprüft wird ob man sich intern oder extern befindet, steht dieser hier mit in der Liste ohne IPv6-Adresse eines DNS-Servers um sicherzustellen, das der Name nur aufgelöst werden kann, wenn man sich im Firmennetzwerk befindet.

Weiter unten in dem Fenster kann man die Optionen für die Namensauflösung eingeben, die mittlere Option sollte in den meisten Fällen die richtige sein.

Nach einem Klick auf “Weiter” kann man die IP-Adressen der Systeme eingeben, die aus dem Firmennetzwerk heraus eine Verbindung zu den Direct Access-Clients aufbauen dürfen. Typischer Anwendungsfall wäre z.B. die Verteilung von Updates über einen WSUS-Server.

Nach einem Klick auf “Fertig stellen” ist Schritt 3 auch schon beendet.

Schritt 4:

Im letzten Schritt kann man eine zusätzliche End-to-End-Authentifizierung einstellen.

Dies wird in unserem Fall allerdings nicht benötigt, und nach einem Klick auf “Fertig stellen” sind wir eigentlich schon komplett durch mit der Konfiguration des Direct Access.

Wenn man nun in der Konsole unten rechts auf “Fertig” klickt, bekommt man eine Zusammenfassung der Einstellungen, und nach einem Klick auf “Übernehmen” werden die GPOs erstellt.

Wenn man sich auf einem Domänencontroller die Gruppenrichtlinienverwaltung anschaut, sieht man zwei neue GPOs, die mit der Domäne verknüpft worden sind.

Der Client und ein bisschen Troubleshooting

Wenn die Verbindung per Direct Access sich nicht aufbauen lässt oder wenn es anderen Probleme gibt, hier der Link zu dem offiziellen Troubleshooting-Guide von Microsoft:

DirectAccess Design, Deployment, and Troubleshooting Guides

Nachdem wir nun alle benötigten Einstellungen getätigt haben, ist es Zeit sich um den Client zu kümmern. Als ersten Schritt müssen wir das Computerkonto des Gerätes zu der Sicherheitsgruppe “DirectAccess_Clients” hinzufügen.

Nun machen wir auf dem Client in einem administrativem cmd-Fenster ein “gpupdate /force”. Nach einer Ab- und erneuten Anmeldung überprüfen wir die Einstellungen, ebenfalls in einem administrativen cmd-Fenster, mit “gpresult /R”:

Wie man in dem Screenshot sieht, ist mein Computer Mitglied der Gruppe “Direct Access” und auf ihn wird eine der beiden Direct Access-GPOs angewendet. Das nur eine angewendet wird ist korrekt, die andere ist exclusiv für den Direct Access-Server.

Der Verbindungsaufbau

Wenn man sein Notebook nun zuhause oder wo auch immer an einen DSL-Anschluss hängt, sollten die Netzwerkeinstellungen wie folgt aussehen:

Wir sehen hier, das das Interface “Teredo Tunneling Pseudo-Interface” eine IPv6-Adresse hat, die mit 2001 anfängt. Man kann sich die Einstellungen auf dem Client auch mit den folgenden Befehlen anschauen:

netsh name show pol

netsh name show eff

Ein Ping auf unterschiedliche Systeme sieht wie folgt aus:

Man erkennt hier sehr gut die Direct Access-Verbindung, da die ping-Werte selbst bei Zugriff auf einen eigentlich im gleichen Netzwerk stehenden Server (Storage2) bei 74ms liegen, was einer normalen ping-Zeit zu einem System im Internet beträgt.

Ein Zugriff auf den Storage2 per Explorer sieht wie folgt aus:

Das DNS-Suffix

Bei uns läuft das Direct Access nun schon etwa eine Woche, und ich war während dieser Zeit schon bei ein paar Kunden, und hatte dort auch die Gelegenheit, Direct Access zu testen.

Als erstes muss ich sagen: Coole Sache! :) Notebook aufklappen, anmelden, evtl. noch Desktop Authority laden lassen, und man ist intern. Ich kann mit meinem Outlook arbeiten wie intern, ich habe meine Netzlaufwerke, ich komme auf nahezu alle Systeme drauf (da bei uns intern der älteste Server ein Windows Server 2003 ist für die Telefonanlage) und kann mich viel ungestörter und zwangloser bewegen wie in einem VPN, das evtl. mal abbricht, sich nicht richtig verbindet, teilweise den gesamten Traffic durch den Tunnel schickt wenn man nicht seine Einstellungen anpasst usw…

Was mir allerdings aufgefallen ist:

Wenn man in einer Umgebung ist, in dem ein Domänencontroller DHCP-Adressen herausgibt, stellt der Client keine IPv6-Adresse (2001:……) ein und Direct Access funktioniert nicht. Wenn ich in der gleichen Umgebung mir eine feste Adresse zuweise, funktioniert es. Andere Möglichkeit ist, das man sich auf dem Client in den erweiterten IPv4-Einstellungen unter “DNS” ein DNS-Suffix einträgt, welches entweder nur ein Name der internen Domäne (ohne Endung) oder der eigene Name (Ich habe z.B. “Jan” genommen) ist. Mit dieser kleinen Änderung funktioniert Direct Access auch bei DHCP-Adressen in einer Domänen-Umgebung.

Wenn Ihnen diese Dokumentation gefällt, Sie Kritik, Anregungen oder Lob haben wäre ich froh von Ihnen zu hören.

Die komplette Dokumentation gibt es auch noch als PDF-Datei für einen einfacheren Ausdruck bzw. um sie zu speichern und offline zu verwenden:

Download – Howto: Einrichtung von Direct Access

Wenn Sie Hilfe bei der Einrichtung benötigen, einen externen Blick auf ihre Umgebung bei einem Problem oder wenn wir für Sie Direct Access bereitstellen sollen, stehen wir Ihnen gerne zur Verfügung.

Unsere Kontaktdaten:

Tel.: 02984-9292 0

Fax: 02984-9292 50

Mail: technik [at] rachfahl . de | j.kappen [at] rachfahl . de | c.rachfahl [at] rachfahl  de

Internet: technikblog.rachfahl.de | www.rachfahl.de

Juli 2010 | Jan Kappen | Rachfahl IT-Solutions GmbH & Co. KG

In diesem Artikel möchte ich einmal beschreiben wie es funktioniert.

Unter der Website Microsoft Online Services

Verwaltungskonsole unter dem Punkt
“Migration” –> “Migration des Postfachinhalts” sind auch nochmal alle Informationen, Links und Tools aufgelistet die zur Migration benötigt werden.

Zur Migration eines Pop Postfaches werden die Microsoft Online Services-Migrationstools benötigt welche bei Microsoft kostenlos in einer 32 bit und in einer 64 bit Version zum Download bereitstehen.

Nach der Installation der Migrationstools wird folgende Maske geöffnet wo der Microsoft Online Services Benutzername und Passwort abgefragt werden.

Anschließend muss eine CSV Datei mit den Daten des Pop Postfaches erstellt werden, dazu kann z.B. einfach Excel verwendet werden. Dazu wird ein leeres Office Excel-Arbeitsblatt erstellt wo in fünf Spalten folgende Werte gepackt werden.

• SourceIdentity
• SourceServer
• SourceLoginID
• SourcePassword
• TargetIdentity
• SourceRootFolder 

Jetzt muss für jedes Postfach die entsprechenden Kontoinformationen hinterlegt werden.

So könnte das aussehen.
SourceIdentity,SourceServer,SourceLoginID,SourcePassword,TargetIdentity

Nils[at]Kappen.de,pop.kappen.de,nilskappen,Password,n.kappen[at]rachfahl.de

Sobald die Datei erstellt worden ist kann diese über den Punkt “Postfächer hinzufügen” eingebunden werden, der Punkt “ausgewähltes Postfach migrieren” wird klickbar und dieses Fenster öffnet sich.

Im darauf folgenden Schritt kann noch ein Zeitpunkt ausgewählt werden von welchen Datum die Daten migriert werden oder ob alle Daten migriert werden sollen.

Anschließend kommt noch eine Zusammenfassung der eingestellten Punkte und die Migration der Daten beginnt.

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 :)

Ich hatte auf einen iMac eine Bootcamp Partition erstellt und diese mit Windows 7 Ultimate installiert.
Nachdem ich die Festplatte via Acronis Disk Director weiter bearbeitete und ein neues Betriebssystem installieren wollte bekam ich immer folgenden Fehlermeldung:

Die Festplatte kann nicht partitioniert werden, weil einige Dateien nicht bewegt werden können.
Legen Sie eine Sicherung der Festplatte an und formatieren Sie sie mit dem Festplatten-Dienstprogramm als Einzelvolume mit Mac OS-Extended (Journaled). Stellen Sie anschließend die Informationen von der Sicherung wieder her und starten Sie den Boot Camp-Assistenten erneut.

Nach Recherche im Internet bin ich in Foren auf verschiedene Möglichkeiten gestoßen, ich will mal meinen Weg beschreiben wie ich das Problem lösen konnte.

• iMac via Macintosh CD starten und die Festplattendienstprogramme öffnen.
• Dort die Macintosh HD überprüfen und anschließend reparieren.
• Nachdem die Reparatur abgeschlossen ist müssen noch die Zugriffsberechtigungen überprüft und angepasst werden.
• Start des MacOS

Sobald dieses Erfolgreich abgeschlossen wurde sollte das Bootcamp wie gewohnt partitioniert werden können.

Ich habe heute mein Kaspersky Internet Security auf die aktuelle Version, die Version 2011 aktualisiert. Dies ist bei einem gültigem Wartungsvertrag problemlos möglich, das Update dauert knapp10 Minuten und einen Neustart für die Installation, danach sieht man die neue Konsole.

Direkt nach der Installation und Einrichtung habe ich dann bemerkt, das meine bisherigen (Firewall-) Einstellungen der Version 2010 nicht übernommen wurden. Das ist schlecht, denn ich würde gerne selber entscheiden, welche Programme nach außen kommen, und welchen ich die Kommunikation mit was auch immer verbieten möchte.

In den Firewall-Einstellungen gibt es die Möglichkeit, die Nachfrage für die einzelnen Netzwerke zu aktivieren, was ich dann auch getan habe, und zwar unter

Einstellungen => Firewall => Einstellungen => Regeln für Anwendungen

Dort kann man für die einzelnen Netze einstellen (siehe Screenshot)

Wenn man dem Netzwerk “Vertrauenswürdig” die Einstellung “Aktion erfragen” gibt, sollte man ja davon ausgehen, das jedes Programm nachfragt, bevor die Verbindung erlaubt wird.

Dies ist aber leider nicht der Fall, einige Programme die ich nach setzen der Einstellung gestartet habe, konnten trotzdem eine Verbindung nach außen aufbauen. Dies liegt an der Einstellung “Aktion automatisch wählen” unter “Allgemeine Einstellungen”. Erst nach Deaktivieren dieser Option erschien das von mir geforderte Fenster mit der Abfrage, ob das soeben gestartete Programm Verbindung ins Internet aufnehmen darf oder nicht.

In unserem momentanen Migrationsszenario hat der Kunde ein gemeinsames Kontaktarchiv mit um die 150 Ordner und Unterordner. Da bei den Öffentlichen Ordner die Rechte nicht vererbt werden, muss man diese in Outlook auf jedem Ordner manuell setzen oder man bedient sich der Powershell. Da das nicht unsere erste Migration mit einigen gemeinsamen Kontakten ist hatte wir uns schon etwas in der Powershell gebastelt. Hier der PowerShell Befehl (Erklärung was er macht weiter unten):

Get-PublicFolder "\Oeffentliche Adressen\" -recurse | Add-PublicFolderClientPermission -User crachfahl -AccessRights Editor

Unser “Script” versagte aber in diesem konkreten Fall und wir erhielten folgende Fehlermeldung:

Die maximale Anzahl an Sitzungen für den aktuellen Benutzer wurde erreicht.
+ CategoryInfo          : NotSpecified: (97:Int32) [AddPublicFolderClientPermission], MapiLogonFailedException
+ FullyQualifiedErrorId :A26D4084,Microsoft.Exchange.Management.MapiTasks.
AddPublicFolderClientPermission

Es werden bei dieser Menge an Ornern einfach zu viele parallele MAPI Sessions aufgemacht. Zum Glück fanden ich in einem guten Buch auf SafariOnline dann einen Hinweis auf das Microsoft PowerShell Script “AddUsersToPFRecursive.ps1”. Diese PowerShell Script befindet sich, in guter Gesellschaft mit vielen anderen nützlichen Scripts, auf dem Exchange 2010 Datenträger unter dem Verzeichnis Scripts. Mit dessen Hilfe ist es ohne Probleme möglich Rechte rekursiv über alle Ordner und Unterordner hinweg zu setzen. Damit man die Skripte anwenden kann kopiert man diese in ein Verzeichnis auf dem Exchange Server (z.B. C:\Tools\Exch-PSScritps”). Dann öffnet man die Exchange Management Shell und führt z. B. den Befehl

C:\Tools\Exch-PSScripts\AddUsersToPFRecursive.ps1 –TopPublicFolder “\Oeffentliche Adressen” –User “crachfahl” –Permission Editor

aus. Was macht der Befehl? Es werden dem Benutzer “crachfahl” ab dem PublicFolder “Oeffentliche Adressen” rekursive das Recht “Editor” auf diesen Ordner und alle Unterordner gesetzt.

Es ist mal wieder soweit, Microsoft bringt mal wieder Updates für den Monat Juni heraus. Dieses Mal sind es gegenüber dem Mai recht viele. Weitere Infos zu den Updates gibt es hier:

Heise.de : Juni-Patchday bei Microsoft

Computerbase: Patchday: Microsoft veröffentlicht zehn Bulletins

Microsoft Security Bulletin Summary für Juni 2010

Auf einem Windows 7-Client sieht es folgendermaßen aus diesen Monat:

Auf einem Windows Server 2008 R2 sieht es wie folgt aus:

Um dieses Problem zu beheben habe ich mithilfe der Windows 7 DVD die Kommandozentrale gestartet und folgende Datei entfernt.
c:\windows\system32\drivers\atikmdag.sys.

Sobald das geschehen ist startete Windows wie gewohnt :).

Fehler bei der Nachrichtenzustellung an folgende Empfänger oder Gruppen:

‘j.kappen@rachfahl.de’ (j.kappen@rachfahl.de)
Die Nachricht überschreitet die maximal zulässige Größe. Verkleinern Sie die Nachricht, und senden Sie sie erneut.

Die Konfiguration ist momentan (auf Grund der Migrations-Phase) so, das auf dem Exchange 2010 ein Relay-Connector eingerichtet worden ist, und der David-Server all seine Emails über den Exchange-Server sendet.

Ich habe mir dann die erweiterte Fehlermeldung mal angeschaut und folgendes gesehen:

Diagnoseinformationen für Administratoren:

Generierender Server: EXCHANGE.xxx.xxx

j.kappen@rachfahl.de
#550 5.3.4 ROUTING.SizeLimit; message size exceeds fixed maximum size for route ##

Wenn man nach dieser Fehlermeldung schaut, findet man ziemlich viele Informationen zu dem Thema. Das Problem in diesem Fall ist, das der Relay-Connector nur Emails bis zu einer gewissen Größe verschickt. Diese Größe kann man sich mit dem folgenden Befehl in der PowerShell-Console anschauen

get-receiveconnector | select identity,maxmessagesize

In meinem Fall (und bei jeder anderen Standard-Installation wahrscheinlich auch) war die Größe auf 10 MB eingestellt. Um den Wert zu ändern, benutzt man den folgenden Befehl

set-receiveconnector “Name des Connectors” -maxmessagesize 30MB

Nachdem ich die Befehle in der Console ausgeführt habe, funktionierte auch ein Versenden von Emails mit Anhängen größer als 10 MB.

Weitere Infos zum Thema gibt es direkt bei Microsoft, und zwar unter folgender URL

Modify Exchange 2003 Global Message Size Limits in Exchange 2007 RTM

In der Systemsteuerung unter “Programme und Funktionen” wechselt man auf die Office-Installation und klickt oben auf “Ändern”

Nach dem Aufrufen von “Ändern” erscheint das folgende Fenster

Nach einem Klick auf “Weiter” kann man seinen neuen Key eintragen. Wenn dieser Vorgang vollendet ist bestenfalls einen Windows Neustart durchführen, da es sonst beim Aktivieren zu Problemen kommen kann bzw. nicht funktioniert

Nach einer kurzen Suche bin ich auf diverse Foren gestoßen, wo Benutzer das gleiche Problem hatten, und zwar nicht nur mit dem Exchange 2010, sondern auch mit Exchange 2007 – Update Rollups. Die Lösung in meinem Fall hat mir der folgende Tipp gebracht:

Exchange 2007 OWA stops working with “reason=0” error

Auf der folgenden Seite wird als mögliche Fehlerquelle ein gestoppter oder deaktivierter IIS-Dienst genannt. Der Dienst auf unserem System ist nicht deaktiviert, ob er zum Zeitpunkt der Installation gestartet war weiß ich nicht, da ich das System ja nach der Installation neugestartet habe. Die Lösung in meinem Fall war die Deinstallation des Update Rollup 3, ein Neustart, eine Überprüfung der Dienste und eine erneute Installation (über Windows Update). Nach einem erneutem Neustart funktionierte sowohl OWA als auch Active Sync wieder.

Falls eine Neuinstallation nicht den gewünschten Erfolg bringt, lohnt es sich vielleicht in die Kommentare auf exchangeserverpro.com zu gucken (obiger Link), dort werden weitere Möglichkeiten und Fehlerbilder diskutiert.

Unser Grund für die Änderung der Vorlage war, das der Haken bei “Nicht automatisch neu registrieren, wenn ein identisches Zertifikat bereits in der Active Directory vorhanden ist” nicht gesetzt war, und so für jeden Benutzer an jedem PC ein neues Zertifikat ausgestellt wurde.

Der erste Schritt ist der, das man eine vorhandene Zertifikatsvorlage zurückzieht. Dies passiert, indem man unter “Zertifikatsvorlagen” in der Zertifizierungsstelle die abzulösende Vorlage löscht, in unserem Fall “Benutzer-Rachfahl”.

Als nächsten Schritt gehen wir unter “Active-Directory-Zertifikatsdienste” in die Zertifikatsvorlagen. Dort klicken wir auf die Vorlage “Benutzer-Rachfahl” und wählen “Doppelte Vorlage”.

Wir haben die Vorlage in unserem Fall “Benutzer-Rachfahl 2” genannt. In dieser Vorlage stellen wir alles so ein wie wir es brauchen, inkl. aller Einstellungen aus “Benutzer-Rachfahl” (d.h. nicht nur die Änderungen / Abweichungen gegenüber der zu ersetzenden Vorlage). Wenn alle Einstellungen gesetzt sind (Diese werden erklärt in dem Artikel Einrichten einer Microsoft PKI mit Windows Server 2008 (R2) ), muss die alte Vorlage als abgelöst gekennzeichnet werden. Dies passiert, indem man im Reiter “Abgelöste Vorlagen” die alte Vorlage hinzufügt.

Als letzten Schritt muss man nun noch in der Zertifizierungsstelle die neu erstellte Vorlage ausrollen, dies passiert unter “Zertifikatsvorlagen”

Nachdem dies passiert ist, dauert es einige Zeit, bis alle Benutzer die neuen Einstellungen erhalten. Wir haben zwei Tage nach der Implementierung nachgeschaut, und alle Zertifikate, die auf der alten Vorlage beruhten, wurden aus den Zertifikaten des Benutzers gelöscht, und es tauchte nur noch ein Zertifikat auf, welches auf der neuen Vorlage beruht.

Sie haben Fragen zu Microsoft PKI oder Sie stoßen auf Probleme? Dann rufen Sie uns an – gerne sind wir ihnen im Support behilflich.

Die Installation per GPO hat den Vorteil, das sie unbemerkt im Hintergrund stattfindet und keinerlei Aktion des Benutzers erfordert. Dies hebe ich besonders als Vorteil heraus, da ich vorher versucht habe die Programme per Desktop Authority zu verteilen (Application Launcher), dies führte allerdings immer zu Nachfragen der UAC, was nicht das gewünschte Ergebnis war.

Ich habe bereits zwei RDS-Server sowie einen RD Connection Broker installiert, es läuft ein Network Load Balancing-Cluster und auf den RDS-Servern ist bereits Office 2010 und der C-Entron-Client installiert. Auf beiden RDS-Servern müssen nun die gewünschten Programme im RemoteApp-Manager freigegeben werden, und es muss für jedes Paket, was freigegeben werden soll, ein Windows Installer-Paket erstellt werden.

Zur Erstellung der Installer-Pakete ein paar Infos und Tipps:

• Der Name der Desktop-Verknüpfung und der Name im Startmenü ist der, der im RemoteApp-Manager eingetragen ist. Ich habe zur Verdeutlichung, das es sich um RDS-Programme handelt, an den Namen ein “- RDS” angehangen.
• Das Zertifikat, was hier eingetragen ist, wird mit in das Paket gepackt. Wir haben bei uns und bei den Kunden, bei denen wir die Remote Desktop Services im Einsatz haben, eine PKI (Private Key Infrastruktur) laufen, mit der wir Zertifikate erstellen können, die ein Single-Sign-On erlauben. In meiner Umgebung ist es besonders wichtig, das für den Namen des Clusters ein Zertifikat erstellt wird, d.h. meine RDS-Umgebung hört auf den Namen “RDSFarm.rachfahl.de”. Wenn ich das Zertifikat nicht ändere oder ein Zertifikat nehme, welches auf den Namen des Servers ausgestellt wird, kommt es zu Problemen. Daher muss VOR der Erstellung der Pakete ein funktionierendes Zertifikat erzeugt und eingespielt werden!
• Wenn man einen Doppelklick auf eines der Programme macht, bekommt man das Eigenschaften-Fenster angezeigt. In diesem Fenster gibt es das Feld “Alias”. Die msi-Datei wird später den Namen haben, der im Feld “Alias” eingetragen wurde, standardmäßig steht oder der Name der Datei, z.B. “Winword.exe”.
• Man kann mehrere Windows Installer-Pakete gleichzeitig erzeugen, einfach alle Programme markieren und den Menüpunkt “Windows Installer-Paket erstellen” auswählen.

Hier noch zwei Screenshots von den Einstellungen, die vorgenommen werden können:

Nachdem wir die benötigten msi-Dateien erstellt haben, gehen wir auf einem Domänen-Controller in die “Gruppenrichtlinienverwaltung”. Dort erstellen wir unter “Gruppenrichtlinienobjekte” ein neues Objekt, ich habe es “RDS-Installation – Paketname” genannt.

Wichtig: Ich hatte mit der Installation der Pakete nur Erfolg, wenn ich pro GPO nur ein Paket installiert habe. Ist laut Microsoft auch Empfehlung.

Wir öffnen nun das Objekt und navigieren zu “Benutzerkonfiguration” – “Richtlinien” – “Softwareeinstellungen” – “Softwareinstallation”

Dort gehen wir im Kontextmenü auf “Neu” – “Paket…”

Es öffnet sich ein Fenster, in dem wir das zu installierende Paket suchen und auswählen. Im sich öffnenden Fenster wählen wir die Option “Zugewiesen” aus.

Das Paket erscheint nun, und wir können mit einem Doppelklick die Eigenschaften des Pakets sehen. Als einzige Einstellung, die angepasst werden muss, wählen wir unter “Bereitstellung von Software” die Option “Anwendung bei Anmeldung installieren”. Das Fenster wird mit OK geschlossen, ebenso der Editor.

Das soeben erstellte GPO muss nun noch einer OU zugewiesen werden, und zwar dort, wo sich die Benutzer befinden, die das Paket bekommen soll. Weiterhin muss wahrscheinlich eine Sicherheitsfilterung erstellt werden die bestimmt, welche Benutzer das Paket erhalten. In meinem Fall sieht das ganze wie folgt aus:

Nun werden die Pakete ausgerollt, und die betreffenden Benutzer erhalten die Pakete.

• Benutzer A hat 150 Kontakte
• Benutzer A hat seine Kontakte freigegeben für Benutzer B
• Benutzer B sieht von diesen Kontakten 140
• Von den 150 (eigenen) Kontakten und den 140 Kontakten (über die Freigabe) sind aber nur 130 Kontakte gleich, d.h. Benutzer B sieht Kontakte (in einer Freigabe wohlgemerkt), die der eigentliche Besitzer nicht sieht

Das allein war schon recht komisch, noch komischer wurde es dann, als ich die folgenden Versuche gemacht habe, um das Problem zu finden:

• Benutzer A legt einen Kontakt an. Benutzer B kann ihn sehen
• Benutzer B löscht den Kontakt, Benutzer A sieht ihn weiterhin
• Benutzer B legt einen Benutzer an, Benutzer A sieht ihn ebenfalls nicht

Nach kurzem Überlegen bin ich dann darauf gekommen, das vielleicht der “Exchange-Cache-Modus” ein Problem hat (Benutzer A hat ein Notebook und dadurch einen aktivierten Cache-Modus). Nach dem Ausschalten des Cache-Modus war der Stand synchron, d.h. Benutzer A hatte genau so viele Kontakte wie Benutzer B in der Freigabe und es waren auch die gleichen Kontakte. Nach dem erneuten Einschalten des Cache-Modus war das Problem wieder vorhanden, also habe ich folgendes gemacht:

1. Im Outlook nachschauen wo die lokale Kopie der Mails abgespeichert wird
2. Outlook schließen
3. Die Datei “j.kappen@rachfahl.de.ost” umbenennen in “j.kappen@rachfahl.de.ost.alt”
4. Outlook wieder öffnen

Dies bewirkt, das die lokale Kopie der Exchange-Daten neu erstellt wird. Nach einer kurzen Zeit war der Stand wieder offline verfügbar, und die Kontakt-Daten waren sowohl beim Besitzer als auch in der Freigabe bei Benutzer B gleich.

Herausgefunden das es mit den Kontakten zu tun hat habe ich es übrigens dadurch, das ich mir die Meldungen im Ordner “Synchronisierungsprobleme” in der Ordner-Ansicht angeguckt habe. Dort habe ich unter anderem die folgende Meldung gefunden:

Die Verbindung mit der Remotesitzung wurde getrennt, da keine Terminalserver-Clientzugriffslizenzen für diesen Computer vorhanden sind. Bitte wenden Sie sich an den Systemadministrator.

Ich habe mir die Anzahl der ausgegebenen Lizenzen im “Remotedesktoplizenzierungs-Manager” angeschaut, dort musste ich aber feststellen, das nur Sechs von Zehn vorhandenen Lizenzen ausgegeben wurde, es waren also noch freie Lizenzen verfügbar.

Nach einer kurzen Suche bei Google habe ich die folgende Technet-Seite gefunden:

Problembehandlung bei Lizenzierungsfehlermeldungen des Remotedesktops

Die Lösung in diesem Artikel, und zwar das Umstellen des Terminalserver-Lizensierungsmodus von “Pro Gerät” zu “Pro Benutzer”, hat sofort geholfen und an dem Client war es wieder möglich, RDS-Programme aufzurufen.

ICA Seamless Host Agent: Sie haben Windows-Explorer in Ihrem ICA-Seamless-Sitzungsfenster gestartet. Dadurch wird Ihr lokaler Explorer-Desktop abgedunkelt. Wenn Sie die ICA-Seamless-Verbindung reaktivieren möchten, melden Sie sich bitte ab und starten Sie die Remoteanwendung im Seamless-Modus erneut

Selbst das Abmelden der Sitzung in der Citrix-Konsole brachte keine Besserung, ein anderer Benutzer an dem gleichen PC hatte dieses Problem nicht. Nach einer kurzen Suche habe ich dann das Problem bzw. dessen Lösung gefunden:

Auf der Citrix-Support-Seite befindet sich der folgende Eintrag:

http://support.citrix.com/article/CTX112134

Auf der Seite ist beschrieben, das es sein kann, das der Benutzer durch ein Programm oder einen Link in einer Datei die “Explorer.exe” aufgerufen hat. Genau dies war das Problem, nach einer kurzen Suche im Taskmanager auf dem Citrix-Server bin ich auf zwei “Explorer.exe” gestoßen, die von dem betroffenen Benutzer aufgerufen worden ist. Nachdem ich die beiden Prozesse beendet habe, war wieder ein Aufruf der Programme in einem Seemless-Fenster möglich.

• Anlegen eines DWord-Registry-Wertes:

Unter

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

muss der Wert

DWORD: NoCDBurning

mit dem Wert “1” angelegt werden.

• Die Windows-Sidebar muss deaktiviert werden
• Deinstallation von Programmen zur Laufwerk-Emulation, z.B. Daemon Tools
• Deaktivierung der AutoPlay-Funktion in der Systemsteurung
• Ändern eines Registry-Wertes:

Unter

HKEY_Local_Machine\System\CurrentControlSet\Service\cdrom

muss der Wert

AutoRun auf “1” gesetzt werden.

Ich hoffe hiermit die wichtigsten und scheinbar besten Lösungsvorschläge gegeben zu haben, weitere erfolgreiche Lösungen können gerne als Kommentar hinzugefügt werden. “Windows 7 installieren” ist übrigens keine Lösung ;) Win7 war nämlich der Inhalt der DVD, die nicht gelesen werden konnte… :)

Daniel Melanchton: Welche Office 2010-Version soll ich nehmen: 32-bit oder 64-bit?

Ich hatte gestern das Problem, das ich mit zwei WRT54GL-Geräten keine Repeater-Bridge aufbauen konnte. Hier die Konfiguration der beiden Geräte:

Gerät 1: WLAN konfiguriert als AP, G-only, Verschlüsselung WPA2-Personal (AES+TKIP)

Gerät 2: WLAN konfiguriert als Repeater-Bridge, G-only, Verschlüsselung WPA2-Personal (AES+TKIP), zusätzlich noch einen AP mit einer anderen SSID für Notebooks

Mein Problem war nun, das die Brücke aufgebaut wurde laut Management-Seite, aber ich konnte keine Geräte auf der Gegenseite anpingen. Ich habe Gerät 2 dann mal auf “Client-Bridge” gestellt (wodurch der zweite AP für Clients wieder verschwand), und nach wenigen Sekunden funktionierte der Ping zu Gerät 1 auch. Nach dem Umstellen auf “Repeater-Bridge” ging wieder nix.

Mein Problem war, das ich in den Einstellungen für den zweiten AP ein anderes WLAN-Passwort eingetragen hab als bei den Einstellungen für die Brücke. Wenn beide WLANs das gleiche Kennwort haben, wird die Brücke problemlos aufgebaut, Clients können sich verbinden und alles funktioniert.

Hier noch ein Screenshot der Einstellung, die gleich sein muss:

Nach einer Systemwiederherstellung auf ein paar Tag zurück, konnte man Word auch wieder starten.
Nach Installieren der aktuellsten Windows-Updates, trat der selbe Fehler aber wieder auf.

Um das Problem zu lösen, folgende Punkte ausführen:

1. “Windowstaste + R”
2. “regedit” eintippen und auf OK klicken

An dieser Stelle geht der “Registrierungs Editor” auf und man navigiert in folgenden Ordner:

3. HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\
4. Den Ordner “Data” aus dem Verzeichnis löschen.

Word 2007 sollte sich jetzt wieder normal starten lassen.

In unserem Fall ist die Permalink Struktur wie folgt:

Die wp-contact-form-7.php kann somit die index.php nicht finden und sendet deshalb keine eMails raus.

Eine Lösung von mir ist das in der wp-contact-form-7.php folgende Zeile ersetzt wird:

$url = parse_url($_SERVER['REQUEST_URI']);
in
$url = ‘/index.php/’.parse_url($_SERVER['REQUEST_URI']);

alternativ kann auch die Permalink Struktur in geändert werden.

Dies verändert allerdings die ganze Blog Struktur.

Wir haben einen englischen “Windows Storage Server 2008” bei uns laufen, der wie der Name schon sagt Fileserver ist. Dieser Server hat zusätzlich noch einen Ultrium3-Wechsler angeschlossen, und es ist die aktuelle Version des Backup Exec von Symantec installiert, Backup Exec 2010.

Wir haben hatten das Problem, das der Dienst “Backup Exec Server” während der Sicherung andauernd abgestürzt ist, und dadurch die Sicherung nicht ordnungsgemäß abgeschlossen werden konnte.

Nach dem Durchforsten der Ereignisanzeige habe ich den folgenden Fehler gefunden

Nach einer kurzen Suche nach der Fehlermeldung bin ich auf die folgende Seite gestoßen:

In Backup Exec 2010, the Backup Exec Server Service terminates during/after the Backup Exec internal Database Maintenance has run

Dort wird beschrieben, das sämtliche Sprachen und Eingabeschemen auf “english (United States) stehen müssen, da es sonst zu einem Fehler kommt. Bei uns war es der folgende Eintrag:

Die “Language for non-Unicode programs” war bei uns auf “Deutsch” eingestellt. Ich habe das dann geändert auf “English (United States)”, und nach einem Neustart des Servers war das Problem dann behoben.

Wir haben bei einem unserer Server seit einiger Zeit des Öfteren in der Ereignisanzeige die folgende Fehlermeldung:

Nach einem kurzen Suchen bei Bing habe ich einige Leute gefunden, die genau das gleiche Problem haben, und in den meisten Fällen hing das Problem mit einem USB-Kartenleser (an einem Client, meistens ein eingebautes Gerät) oder einer USB-Festplatte zusammen. An unserem System hing ebenfalls eine USB-Festplatte. Nach dem Entfernen der Festplatte als USB-Gerät im Server selber und abziehen des Kabels tauchte das Problem nicht mehr auf.

um bei einem Netgear 3G Broadband Wireless Router (MBR624GU) per Websessions (Prepaid oder auch “Web and Walk” genannt) ins Internet zu gelangen muss man folgende Einstellungen vornehmen, welche mir der Support leider nach zwei Anläufen nicht annähernd beibringen konnte “=(”

Um in den wirklichen Administrationsbereich ohne “Wizard” zu gelangen, musste ich ersteinmal folgendes eingeben, da der Wizard keine Verbindung herstellen konnte und mich auch nicht weitergeleitet hat: http://192.168.0.1/start.htm

Als erstes sollte man hier auf die aktuellste Firmware updaten und danach einen Hard-Reset durchführen.
Also das Gerät nochmal auf den Ursprungszustand der Firmware setzen.

Unter dem Punkt “Broadband Account Settings” diese Einstellungen vornehmen und “apply” klicken.

Nach setzen der Einstellungen kann man wie gewohnt per Browser die Websession buchen oder auch auf der Vodefone Homepage surfen. (auch ohne ein Ticket zu buchen)

Die Netzwerkeinstellungen lassen sich wie folgt zurücksetzen:

1. Drucker ausschalten
2. Netzwerkkarte ausbauen
3. Jumper von SW1 und SW2 auf SW2 und SW2 stecken
4. Karte einbauen und Drucker einschalten
5. Drucker ausschalten und Jumper wieder zurück auf SW1 und SW2 stecken
6. Drucker wieder einschalten, nun sollten die Netzwerkeinstellungen wieder auf Default stehen.

Diese Anleitung bezieht sich auf die IB-23 Netzwerkkarte

Zunächst öffnen wir die php.ini und suchen nach folgenden Eintrag “upload_tmp_dir”.
Dort werden nun die Semicolons vorne entfernt und der Pfad zum Upload Verzeichnis angegeben.
Beispiel: upload_tmp_dir = “c:\inetpub\wwwroot\WEBSITE\wp-content\uploads”.

Anschließend geben wir dem User IUSR “Ändern” rechte  auf auf das Upload Verzeichnis.

Zum Schluss muss in dem WordPress Dashboard unter Einstellungen -> Verschiedenes der Upload Pfad angepasst werden.

Nachdem der IIS dann Neugestartet worden ist sollte der Bild Upload funktionieren.

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… :)

Die Umgebung, in der wir uns in diesem Szenario befinden, ist eine Firma mit knapp 60 PC-Arbeitsplätzen. Das Unternehmen ist in letzter Zeit stetig gewachsen, und die Aufgaben an die EDV bzw. der Einsatz von PCs zur Erledigung von Aufgaben wird immer wichtiger. In dem Unternehmen befinden sich drei Server: Ein Small Business 2003 Standard mit Exchange 2003, ein Datenbank-Server und ein Server, der für einen Teilbereich der Firma bereit steht. Der SB-Server ist gleichzeitig Fileserver, Domänen-Controller und Mail-Server.

Geplant ist eine Migration der Daten auf einen eigenen File-Server, die Anschaffung eines Exchange 2010-Servers und der Einsatz von zwei Hyper-V-Servern. Es sollen zwei Domänen-Controller eingesetzt werden, weiterhin soll ein eigener Server für “Desktop Authority” und für die Anti-Viren-Software zur Verfügung stehen. Nach bzw. während der Migration soll der SB-Server komplett abgelöst und ausgeschaltet werden, die Domäne soll beibehalten werden.

Hierbei ergibt sich die “Schwierigkeit”, das ein Small Business-Server der primäre Domänen-Controller sein muss. Da wir eine Ablösung eines SBS 2003 noch nie mit einer Übernahme der Domäne gemacht haben, habe ich eine virtuelle Testumgebung aufgesetzt mit einem SBS 2003 und einem Server 2008 R2. Ziel ist es, mit dem SBS 2003 eine Domäne aufzusetzen inkl. Exchange 2003, den Server 2008 R2 als weiteren Domänen-Controller hinzuzufügen, einen Exchange 2010 aufzusetzen, die Daten zu übertragen und dann den SBS 2003 abzurüsten bzw. zu deinstallieren. Auf geht’s! :)

Die Installation des neuen Domänen-Controllers

Als erster Schritt muss ein Windows Server 2008 R2 installiert werden. Nach der Installation werden alle vorhandenen Windows-Updates eingespielt, der Server bekommt eine feste IP und wird Mitglied in der Domäne. Nach einem Neustart wird der neue Server per “dcpromo” als weiterer Domänen-Controller zur vorhandenen Domäne hinzugefügt. Nach dem hinzufügen und einem weiteren Neustart ist der Server nun en vollwertiger Domänen-Controller.

Die Installation des Exchange Server 2010

In dem Kundenprojekt habe ich nun einen weiteren Server 2008 R2 installiert, den Server als Mitglied zur Domäne hinzugefügt und dort den Exchange Server 2010 installiert. In der Testumgebung habe ich mir das Aufsetzen eines weiteren Servers gespart, ich habe den Exchange 2010 einfach mit auf den Server 2008 R2 installiert. Nach der Installation und Einrichtung kann man damit beginnen, die Postfächer der Benutzer zu verschieben.

Das Verschieben der Postfächer von Exchange Server 2003 nach Exchange Server 2010

In der Testumgebung hatte ich nur einen einzigen Benutzer, den ich verschieben konnte, das hat problemlos geklappt, in der Produktiv-Umgebung gab es bei der Durchführung allerdings auch keine Probleme, Ausnahme war das diverse Benutzerkonten wieder aktiviert werden mussten, da kein Exchange-Postfach eines deaktivierten Benutzers verschoben werden kann.

Nach dem Verschieben der Postfächer muss man gucken, ob Öffentliche Ordner vorhanden sind und ob diese Ordner übernommen werden sollen. Microsoft möchte weg von Öffentlichen Ordnern, deswegen wäre es empfehlenswert, im Zuge der Umstellung die Öffentlichen Ordner hinter sich zu lassen, falls dies möglich ist.

Deinstallieren von Exchange 2003

Nachdem alle Benutzer mit dem neuen Server arbeiten, ist es an der Zeit, den Exchange Server 2003 zu deinstallieren. Hierzu geht man auf dem SBS 2003 in der “Systemsteuerung” auf “Software” und wählt “Ändern/Entfernen” bei dem Punkt “Windows Small Business Server 2003”.

Durch das Aufrufen von “Ändern/Entfernen” gelangt man in den “Windows Small Business Server Setup-Wizard”. Dieser ist nicht nur zum Konfigurieren der Installation, sondern auch zum Anpassen bzw. deinstallieren von vorhandenen Komponenten. Nach einer Überprüfung der Installation erscheint ein Fenster, in dem man wählen kann, welche Komponenten installiert bzw. deinstalliert werden sollen.

Die Deinstallation funktioniert allerdings auf Anhieb nicht so wie wir wollen, es erscheint der folgende Fehler:

Die beiden Probleme lassen sich wie folgt beheben:

Problem 1:

Sie können einen Server, der Zielbridgehead für einen Routinggruppenconnector ist, nicht entfernen. Dieser Server ist Zielbridgehead für die folgenden Connectors:
W2K8R2-TEST-SBS2003-TEST

Lösung: Im Exchange System-Manager auf dem SBS2003 muss man den Connector löschen, der die Routinggruppen verbindet. Auf dem Exchange 2010 funktioniert das ganze per Powershell.

Problem 2:

Bei diesem Server handelt es sich um den Server für die Empfängeraktualisierung der Domäne “Contoso.local”. Sie können diesen Server erst deinstallieren, nachdem Sie einen anderen Server für Empfängeraktualisierung dieser Domäne ausgewählt haben.

Im  Exchange System-Manager auf dem SBS2003 muss man unter “Empfängeraktualisierungsdienste” für die vorhandenen Aktualisierungsdienste sowohl den Domänencontroller als auch den Exchange-Server ändern.

Nach dem Umstellen sieht der Eintrag wie folgt aus:

Wenn man nun im “Windows Small Business Server Setup-Wizard” auswählt, das der Exchange-Server deinstalliert werden soll, erscheint eine kurze Zusammenfassung der Komponenten, die entfernt werden sollen, und die Deinstallation kann beginnen.

Hier ein kleiner Überblick auf die Deinstallation:

Nach der Deinstallation taucht der Exchange Server 2003 in der Active Directory nicht mehr auf, ein telnet auf Port 25 bringt ebenfalls keine Antwort. Der Exchange 2003 ist Geschichte :)

Verschieben der FSMO-Rollen

Nach der Deinstallation des Exchange Server 2003 ist es an der Zeit, die FSMO-Rollen von dem SBS2003 auf den Server 2008 R2 zu verschieben. Da ich das Rad nicht mehr neu erfinden möchte, hier eine klasse Beschreibung der Vorgehensweise:

LDAP://Yusufs.Directory.Blog/ – Die FSMO-Rollen verschieben

Hier die ganze Vorgehensweise von mir, zusammengefasst in einem Album:

Herunterstufen des Small Business Server 2003

Nach dem Übertragen der Rollen kann der SBS2003 heruntergestuft werden. Das ganze passiert per “dcpromo”. Es erscheint die folgende Warnung:

In den Screenshots unter “Verschieben der FSMO-Rollen” sieht man auf einem Bild, das beide Domänencontroller in meiner Testumgebung einen “Globalen Katalog” haben, von daher betrifft mich die Warnung hier nicht bzw. ich habe sichergestellt, das andere globale Kataloge verfügbar sind.

Die Frage, ob dies der letzte Domänencontroller in der Domäne ist, verneinen wir:

Es muss noch ein neues Administrator-Kennwort angegeben werden, damit man sich nach dem herunterstufen als lokaler Administrator anmelden kann:

Nun wird der Server heruntergestuft, und es kommt zu einer Fehlermeldung:

Ich habe den Server dann neugestartet und das Herunterstufen wiederholt, diesmal mit Erfolg. In diversen Foren habe ich nachher allerdings auch noch Leute gefunden, die diesen Fehler ebenfalls hatten, und einfach den Wizard noch einmal haben durchlaufen lassen, ohne Neustart. Beide Methoden scheinen zum Ziel zu führen. Nach dem Neustart funktionierte das “dcpromo” schließlich:

Nach dem Neustart des Servers begrüßte mich das folgende Bild:

Die Migration hat in der Testumgebung hervorragend funktioniert, bei unserem Kunden bin ich momentan noch in der Migrationsphase. Die Exchange-Postfächer sind alle migriert, als nächstes müssen die Rollen übertragen werden, der Exchange 2003 muss deinstalliert werden, die Dateien auf dem SBS 2003 müssen übertragen und ausgelagert werden auf den neuen Fileserver, und dann kann der SBS 2003 heruntergestuft werden.

Remote Desktop Services – Single Sign-On für XP SP3”). Da ich in letzter Zeit einige Microsoft PKIs implementiert habe und trotzdem immer wieder auf meine Dokumentation zurückgreifen musste, ist es an der Zeit, die Schritte in unserem Blog für uns, aber auch für Sie zu dokumentieren.

“Active-Directory Zertifikatsdienst” Rolle installieren

Alles beginnt mit der Installation der “Active-Directory Zertifikatsdienst” Rolle. Dazu gehen wir in den Servermanager, wählen Rollen aus, klicken auf “Active-Directory Zertifikatsdienste” und wählen die “Rollendienste Zertifizierungstelle” und “Zertifizierungstellen-Webregistrierung” aus. Im darauffolgenden Dialog “Installationstyp” wählen Sie  “Unternehmen” an. Danach müssen wir als Zertifizierungstellentyp “Stammzertifizierungsstelle” wählen. Im nächsten Schritt erstellen wir mit “Einen neuen Privaten Schlüssel erstellen” denselben. Im

Kryptografiedialog akzeptieren Sie dann die Standard Einstellungen. Im Fenster Zertifizierungsstelle haben Sie die Möglichkeit den vorgeschlagenen Namen zu akzeptieren. Ich mag nicht, dass der Name des Rechners mit in der Zertifizierungstelle steht, weswegen ich nur den Namen der Domäne mit angehängtem “-CA” bevorzuge (z.B. Rachfahl-CA). Im letzten Fenster vor der Installationszusammenfassung können Sie noch die Gültigkeitsdauer der CA ändern, was wir auch tun, indem wir die vorgeschlagenen Zeit von 5 auf 10 Jahre ändern.

Schlüsselwiederherstellungs-Agent implementieren

Im nächsten Schritt erstellen wir einen  Schlüsselwiederherstellungs-Agenten (im Englischen “Key Recovery Agent”). Dies ist eine Person die Zertifikate aus der Active-Directory im Falle eines Verlustes wieder

herstellen kann. Installiert wird der KRA, indem wir im Servermanager die frisch installierte “Active-Directory Zertifikatsdienste” Rolle öffnen und darunter die Zertifikatsvorlagen anklicken. Dann suchen wir im rechten Fenster die “Schlüsselwiederherstellungs-Agenten” Zertifikatsvorlagen und rechtsklicken darauf, um sie zu duplizieren. Im erscheinenden Fenster wählen wir “Windows Server 2003 Enterprise” aus und benennen dann das Duplikat um (Namensvorschlag: Namen der Vorlagen und hängen dann den Domainnamen mit einem Bindestrich an also z.B. “Schlüsselwiederherstellungs-Agent-Rachfahl”). In den Eigenschaften wechselt man auf “Sicherheit” und fügt hier den Benutzer hinzu, der dann die Funktion des Schlüsselwiederherstellungs-Agenten ausüben soll. Dieser Benutzer erhält zusätzlich zu “Lesen” die Rechte “Registrieren” (im Englischen Enroll) und “Automatisch registrieren” (im Englischen

Autoenroll). Danach speichern wir die Vorlagen ab. Die Vorlage rollen wir in der Domäne aus, indem wir Sie in den Vorlagenspeicher laden. Das geschieht indem wir in “IhreDomain>-CA” wechseln und dort die Zertifikatsvorlage mit rechtsklick auf “Zertifikatsvorlage” –> “Neu” –> “Auszustellendes Zertifikatsvorlage” auswählen. Dann aktivieren wir die soeben erstellte Zertifikatsvorlage.

Autoenrollment per GPOs erlauben

Im nächsten Schritt müssen wir das automatische Ausrollen der Benutzer- und Computer-Zertifikate per GPO erlauben. Dazu öffnet man die “Gruppenrichtlinienverwaltung”. Hier legen wir auf dem Domainlevel eine neue GPO an (wie Sie das ganze nennen, bleibt Ihnen überlassen, bei uns heißt Sie “PKIundKRA”). Dazu klicken Sie auf den Domainnamen und

wählen “Gruppenrichtlinienobjekt hier erstellen und verknüpfen…” aus und benennen sie nach Ihren Vorstellungen. Jetzt rechtsklicken Sie auf die soeben erstellte Gruppenrichtlinie und wählen “Bearbeiten…” aus. Zuerst konfigurieren wir den Benutzerteil der GPO. Dazu navigieren wir nach  “Benutzerkonfiguration”-> “Richtlinien” –> “Windows-Einstellungen” –> “Sicherheitseinstellungen” –> “Richtlinien für öffentliche Schlüssel”. Hier doppelklicken wir auf “Zertifikatdienstclient – Automatische Registrierung“ und stellen die GPO auf “Aktiviert”. Danach wählen wir alle drei Optionen aus (siehe

Screenshot rechts) und bestätigen die Änderungen mit “OK”.

Jetzt konfigurieren wir den Computerteil der GPO. Dazu navigieren wir nach  “Computereinstellungen” –> “Richtlinien” –> Windows-Einstellungen” –> “Sicherheitseinstellungen” –> Richtlinien für öffentliche Schlüssel”. Hier doppelklicken wir auf “Zertifikatsdienstclient – Automatische Registrierung” und stellen auch diese GPO auf “Aktivieren”. Dann wählen wir die beiden möglichen Optionen aus (Screenshot rechts)und bestätigen auch diese Änderung mit “OK”.

Im nächsten Schritt wählen wir an der gleichen Stelle den Punkt “Einstellungen der automatischen Zertifikatsanforderung” aus , rechtsklicken im rechten Teil

und wählen dann “Neu…” und dannach “Automatische Zertifikatsanforderung…” aus. Daraufhin erscheint der “Assistent für die automatische Zertifikatsanforderung”.  Hier klicken Sie auf “Weiter” und wählen “Computer” aus. Danach klicken Sie nochmal auf “Weiter” und die erscheinende Zusammenfassung beenden Sie mit “Fertig”.

Zertifikat für den Schlüsselwiederherstellungs-Agent erzeugen

Damit wir die Funktion des Schlüsselwiederherstellungs-Agenten nutzen können, müssen wir für diesen ein Zertifikat ausstellen. Das machen wir am einfachsten, in dem wir uns an einem Rechner als dieser Benutzer anmelden (in unserem Fall mit dem Benutzer “KeyRecoveryAgent”), dann öffnen wir die MMC (über Ausführen MMC eingeben) wechseln in die

Snapinverwaltung über “Datei” –> “Snapin hinzufügen/entfernen…” und fügen das “Zertifikate Snapin” hinzu (durch Auswahl von “Zertifikate”). Jetzt können wir ein Zertifikatrequest bei unsere CA einstellen. Dies passiert indem wir auf “Eigene Zertifikate” rechtsklicken und “Alle Aufgaben…” –> “neues Zertifikat anfordern…” klicken. Hier wählen Sie dann, aus den Vorlagen, den von Ihnen erstellten “Schlüsselwiederherstellungs-Agent-<Domain>” aus und klicken zweimal “Weiter” ohne etwas anderes einzustellen. Das System erzeugt mit

diesem Vorgang einen Zertifikatsrequest, den wir dann auf der CA manuell bestätigen müssen. Dazu wechseln wir auf unseren Server mit der CA, rufen die “Active-Direktory Zertifikatsdienste” auf, öffnen unsere CA und klicken auf “Austehende Anforderungen”. Hier sollten Sie den von uns erstellten Zertifikatsrequest sehen. Diesen rechtsklicken Sie und wählen “Alle Aufgaben…” -> “Austellen” aus. Damit wird der Request bestätigt und Sie können nach etwas Zeit auf dem Rechner unter “Eigene Zertifikate” das Zertifikat finden.

Autoarchivierung für die CA einschalten 

Im nächsten Schritt schalten wir die Autoarchivierung in unserer CA ein. Dies tun wir wieder in der “Active-Direktory Zertifikatsdienste” Rolle. Hier rechsklicken wir auf unsere CA und wählen “Eigenschaften…” aus. In dem sich öffnenden Dialog wechseln wir auf den Reiter “Wiederherstellungs-Agent” und wählen den Radiobutton “Schlüssel archivieren” aus. Jetzt müssen wir einen Benutzer auswählen, der berechtigt ist die Schlüssel zu archivieren. Dazu klicken wir auf “Hinzufügen…” und ergänzen das eben erstellte Zertifikat unseres “Schlüsselwiederherstellungs-Agenten”.

Erzeugen einer Benutzer Zertifikatsvorlage zum Automatischen Registrieren

Im letzten Schritt erzeugen wir eine Zertifikatsvorlage,

mit der unsere Benutzer automatisch, ohne Interaktion, ein Benutzer-Zertifikat erstellt bekommen.  Die Erstellung ist ähnlich, wie bei der “Schlüsselwiederherstellungs-Agenten-Vorlagen”. Hierzu rufen wir wieder auf unserer CA die Rolle “Active-Direktory Zertifikatsdienste” auf. Hier wechseln wir in die “Zertifikatsvorlagen”,  suchen die Vorlage die wir Duplizieren wollen heraus, rechtsklicken auf “Benutzer” und wählen “Doppelte Vorlage” aus. In dem sich öffnenden Dialog wählen wir

“Windows Server 2003 Enterprise” aus und benennen die Vorlage dann in “Benutzer-<Domain>” (also z.B. Benutzer-Rachfahl) um.  Jetzt wechseln wir auf den Reiter “Anforderungsverarbeitung”.  Hier wählen wir zusätzlich das Feld “Private Schlüssel für die Verschlüsselung archivieren” aus. Dann wechseln wir in den Reiter “Sicherheit”. Hier klicken wir auf die Sicherheitsgruppe “Domänen-Benutzer” und geben dieser die Rechte “Lesen”, Registrieren” und “Automatisch Registrieren”. Im Reiter “Allgemein” ist es sinnvoll einen Haken bei “Nicht automatisch neu registrieren, wenn ein identisches Zertifikat bereits in der Active Directory vorhanden ist” zu setzen, da sonst für jeden PC, an dem sich ein Benutzer anmeldet, ein neues Zertifikat ausgestellt wird. Bei 1000 Mitarbeitern, die sich im Laufe eines Jahres an 10 PCs und an 15 RDS-Servern anmelden kommt schon eine riesige Anzahl von Zertifikaten zusammen.

Zuletzt noch der Reiter “Antragsstellername”. Hier wählen wir die Felder “E-Mail-Name im

Antragstellername” und “E-Mail-Name” ab so das nur noch das Feld “Benutzerprinzipalname (UPN)” angewählt ist. Bestätigen Sie nun das Erstellen der Vorlage mit “OK”.  Was jetzt noch fehlt, ist das Ausrollen der Zertifikatsvorlage.  Dazu wählen wir die CA aus und rechtsklick auf “Zertifikatsvorlagen”. Jetzt klicken wir auf “Neu” –> “Auszustellende Zertifikatsvorlage” und wählen die eben erstellte Benutzerzertifikatsvorlage aus. Nachdem Sie in dem erscheinenden Dialog “OK” geklickt haben, fangen die Benutzer automatisch an Benutzer-Zertifikate anzufordern und die CA stellt diese Automatisch aus.

Prüfen ob Zertifikate ausgestellt werden

Nach den obigen Schritten sollten Sie eine PKI besitzen, die für Ihre Computer und Benutzer automatisch Zertifikate ausstellt. Jetzt stellt sich die Frage: Wie kann man das prüfen? Nun dazu wechseln Sie wieder in “Active-Direktory Zertifikatsdienste” und wählen Ihre CA aus (bei uns Rachfahl-CA”). Hier klicken wir auf  “Ausgestellte Zertifikate”. Jetzt sollten Sie einige Computer- und Benutzer-Zertifikate sehen. Wenn das nicht der Fall ist, dann wählen Sie “Fehlgeschlagene Anforderungen” aus. Falls Sie hier viele Einträge vorfinden, dann prüfen Sie, ob Sie alle Schritte, wie in diesem Post beschrieben durchgeführt haben. Wenn Sie in beiden Fällen nichts sehen, dann warten Sie einfach noch ein bisschen ab. Denn Sie wissen ja: “Gut Ding hat gut Weil”.

Sie haben Fragen zu Microsft PKI oder Sie stoßen auf Probleme? Dann rufen Sie uns an – gerne sind wir ihnen im Support behilflich.

Auf dem PDC geht man in die Registry und passt den folgenden Wert an:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters\Type

Eingestellt ist dort standardmäßig “NT5DS”, diesen Wert ersetzt man durch “NTP”.

Den zweiten Eintrag, den man anpassen muss, ist

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config\AnnounceFlags

Der Standard-Wert ist hexadezimal “a” (Dezimal 10), dieser muss angepasst werden auf “5”.

Der dritte Wert, der geändert werden muss, ist

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters\NtpServer

Standardmäßig ist dort “time.windows.com,0x9”, dieser Wert muss geändert werden auf einen Zeitserver Ihrer Wahl, ich habe dort “de.pool.ntp.org” eingetragen.

WICHTIG: Nach der Adresse muss ein “,0x1” angehangen werden!

Nun muss der Windows-Zeitgeber-Dienst neugestartet werden. Dies funktioniert mit den folgenden beiden Befehlen:

net stop w32time

net start w32time

Neulich hatte ich das Problem, das bei einem Kunden auf einen Schlag alle Outlook 2003 Clients nicht mehr mit dem Exchange 2003 Server kommunizieren konnten. Nach etwas Recherche stellte sich heraus, das alle Clients per HTTPS angebunden waren und das das selbstsignierte Zertifikat, das der Small Business Server 2003 bei der Installation ausstellt, abgelaufen war. Da der Kunde kein offizielles Zertifikat kaufen wollte dachte ich mir, ich könnte mit SelfSLL.exe aus den “IIS 6.0 Resource Kit Tools (IIS 6.0)” ein neues Zertifikat erstellen. Bei genauerem untersuchen des Zertifikats stellte sich allerdings heraus das darin mehrere Namen vorhanden sind. SelfSLL.exe ist nicht in der Lage SAN Zertifikate auszustellen. Also was nun? Beim Recherchieren bin ich dann unter folgender URL http://www.sbs-rocks.com/sbs2k3/sbs2k3-n2.htm auf die Lösung gestoßen: man kann mit dem im SBS2003 enthaltenen “Configure E-Mail and Internet Connection Wizard” (kurz CEICW) ein neues SAN Zertifikat, welches dann wieder 5 Jahre gültig ist, erstellen.

Exchange 2007 mit offiziellem SAN Zertifikat einrichten” habe wir ja schon beschrieben wie man Exchange 2007 mit einem günstigen offiziellen SAN Zertifikat betreibt. Jetzt ist Exchange 2010 offiziell verfügbar und da wird es Zeit diese Information auch für dieses System bereitzustellen. Vorweg: es ist einfacher geworden. Zur Konfiguration ist nur noch einen Powershell Befehl notwendig und den Rest kann man jetzt GUI basiert erledigen. Aber lesen Sie selber:

Mit Powershell Zertifikatsrequest erzeugen

Wir starten in dem wir auf dem Exchange 2010 Server die “Exchange Management Shell” aufrufen (bitte bit Administratoren Rechten). In ihr erzeugen wir mit dem Powershell CmdLet New-ExchangeCertificate einen Zertifikatsrequest der außer dem Hauptnamen hier “mmas.rachfahl.de” auch noch drei weitere Namen enthalt: “vexchange-1.rachfahl.de” (interner Namen mit ADS Domaine, “vexchange-1” (ohne interne Domaine) und “autodiscovery.rachfahl.de” enthält. Hier der Befehl für unser SAN-Zertifikat:

$ZertifikatReq = New-ExchangeCertificate -GenerateRequest -SubjectName "cn=mmas.rachfahl.de, o=Rachfahl IT-Solutions GmbH u. Co. KG, c=DE" -DomainName mmas.rachfahl.de, vexchange-1.rachfahl.de, vexchange-1, autodiscover.rachfahl.de -PrivateKeyExportable $True

Set-Content -path "C:\mmas.rachfahl.de.req" -Value $ZertifikatReq

Request bei Zertifizieren einreichen

Die erzeugte Datei (in diesem Beispiel “C:\mmas.rachfahl.de.req”)  öffnen wir mit Notepad, kopieren den Inhalt in die Zwischenablage und fügen ihn in das entsprechende Formular bei Ihrem SSL Provider ein (bei uns geschieht das natürlich über unsere

Resellerseite des Providers GoDaddy). Wenn der Request akzeptiert wird bekommen Sie bei GoDaddy eine Zusammenfassung des Zertifikats angezeigt. Bitte prüfen Sie hier alle Angaben noch einmal. Nach der Bestätigung versucht nun GoDaddy die Legalität des Antrags zu prüfen. Dies geschieht in der Regel über eine Mail an den Inhaber der Domain. Wer der Besitzer ist ermittelt GoDaddy aus dem RIP Eintrag der Domaine. Deshalb ist es ganz vorteilhaft vor dem Antrag beim DENIC “www.denic.de” nachzuschauen wer und vorallem welche E-Mail Adresse dort eingetragen ist. An diese E-Mailadresse sendet dann GoDaddy einen Link die dann bestätigt werden muss. Daraufhin wir das angeforderte Zertifikat generiert welches man dann als ZIP Archiv herunterladen kann. 

Zwischenzertifizierungsstelle und Zertifikat installieren

Nach dem Auspacken des Archiv findet man zwei Dateien auf der Platte: das eigentliche Zertifikat und und eine Zwischenzertifizierungsstelle. Die letztere muss man zuerst in den

Zertifikatsspeichern installieren. Hierzu öffnet man die MMC (Microsoft Management Console) und  fügt über “Datei” -> ”Snapin hinzufügen/entfernen” das Zertifikate Snapin für das Computerkonto hinzu (Achtung: hierzu benötigen Sie Administrator Rechte). Jetzt rechtsklicken Sie auf “Zwischenzertifizierungsstelle” und importieren mittels  “Aufgaben” –> “Importieren” die GoDaddy Datei. Danach können wir das eigentliche Zertifikat importieren. Dazu rufen Sie die Exchange-Verwaltungskonsole auf, klicken im linken Fenster auf  “Serverkonfiguration” und wählen dann im mittleren Bereich unter Exchange-Zertifikate ihren Zertifikatsrequest aus. Jetzt klicken Sie im rechten Fenster auf “Ausstehende Anforderung abschließen …” und es öffnet sich ein Wizard. Hiermit wählen Sie das Zertifikat aus (vorher stellen sie Dateiauswahlbox auf alle Dateitypen). Die “Exchange Management Console” führt darauf den Import durch. Nach erfolgreichem Import sehen Sie eine ähnliches Fenster wie in unserem Screenshot. In unserem Beispiel wurde das

Zertifikat nur für POP3 und IMAP aktiviert so das wir jetzt noch die Verwendung für SSL einschalten müssen. Dazu wählen wir das Zertifikat aus und klicken dann im rechten Bereich auf “Dem Zertifikat Dienste zuordnen…”.  In dem Wizard wählen wir der Server und können dann im nächsten Fenster die Internetinformationdienste  hinzufügen. Ein Klick auf Fertig und der Exchange Server 2010 verwendet ab jetzt das neue Zertifikat.

Zertifikat testen

Im letzen Schritt sollten Sie die Verwendung des Zertifikats überprüfen. Sie können dies tun in dem Sie entweder die interne Outlook Web Access Seite aufrufen (in unserem Beispiel währe das z.B.: https://vexchange-1/owa ) oder die externe OWA Seite (in unserem Beispiel mit https://mmas.rachfahl.de/owa).

Weitere interessante Informationen zum Thema Exchange 2010 und der Client Access Rolle findet man unter http://technet.microsoft.com/en-us/library/bb310795.aspx.

Mit mehreren Windows 7-Clients funktionierte die Einwahl, dann haben wir ein Notebook mit Windows Vista bekommen, dort funktionierte die Verbindung allerdings nicht. Es erschien die Fehlermeldung:

Fehler 800: Die VPN- Verbindung kann nicht hergestellt werden. Der VPN-Server ist eventuell nicht erreichbar oder doe Sicherheitsparameter sind für diese Verbindung nicht korrekt konfiguriert

Wir haben das ganze dann mit einem Windows XP getestet, dort funktionierte die Einwahl ebenfalls Fehlerfrei. Nach einer kurzen Recherche hier mein Lösungsweg:

• Auf Vista-blog.de habe ich jemanden gefunden, der das gleiche Problem hatte. Ich habe also die Treiber für den PPTP Miniport deinstalliert und neuinstalliert mit den folgenden Befehlen:

netcfg -u ms_l2tp

netcfg -u ms_pptp

netcfg -l %windir%\inf\netrast.inf -c p -i ms_pptp

netcfg -l %windir%\inf\netrast.inf -c p -i ms_l2tp

• Im Chip-Forum hatte ebenfalls jemand das gleiche Problem, dort wurde geraten in den erweiterten Einstellungen der Verbindung unter “Sicherheit” die “Sichere Verbindung / Verschlüsselung ist erforderlich” zu deaktivieren. Das habe ich nicht gemacht, dafür aber die weiteren Protokolle, die zur Verfügung stehen, aktiviert, damit sie genutzt werden können im Falle des Bedarfs.

Diese beiden Lösungsvorschläge haben in meinem Fall nicht genützt, es war so gesehen “simpler”:

• Auf dem PC war GData als Virenschutz und als Firewall installiert, und letzteres war das Problem. Es wurde in der Standardeinstellung der Firewall die svchost.exe komplett geblockt. Ich habe das IP-Netz des Kunden ziemlich weit oben eingetragen als erlaubte Verbindung, danach war eine Verbindung dauerhaft möglich (Vorher nur, als ich testweise die Firewall deaktiviert habe).

Ich hoffe ich kann mit dieser kleinen Auflistung der Lösungsmöglichkeiten jemanden helfen der das gleiche Problem hat, bei Google gibt es einige Leute, die Probleme mit dieser Fehlermeldung haben.

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

Call failure while determining connection state

Nach dem Bestätigen der Nachricht erschien die folgende Meldung:

The current DAConfiguration database version is “” and does not match expected database version of “8.0.8000.55011″

Die Lösung des Problems war ebenso simpel wie unlogisch:

Man muss den Proxy in den Internetoptionen deaktivieren!

So weit zum technischen Teil, allerdings gibt es zu dem Programm an sich auch was zu sagen:

Das Programm und die Arbeit, die einem abgenommen wird, ist wirklich gut und hilfreich. Die Installation und die Arbeit, bis man das Programm am laufen hat und mit der Konfiguration anfangen kann, ist der letzte Scheiß! Hier eine kleine Liste der Dinge die nicht gehen oder Fehler schmeißen:

• Wenn man DA auf einem deutschen Betriebssystem installiert und den Wizard komplett nutzt, wird während der Installation ein SQL Server 2005 Express in Englisch heruntergeladen und installiert. Das klappt aber nicht komplett, da die Installation mit Hilfe von Argumenten durchgeführt um ein Eingreifen des Benutzers unnötig zu machen, allerdings ist in diesen Argumenten ein Dienst-Konto-Name eingebaut, den es auf einem deutschen System nicht gibt! Somit ist die Installation des SQL Server 2005 Express durch die DA-Installation nicht möglich.
• Auf einem Windows Server 2008 erscheint die folgende Fehlermeldung
  

  sowie dieser Eintrag im Event-Log

  

  

• Der Absturz der SLMgr.exe passierte oben während der Datenbankeinrichtung, nach einem Neustart des Systems und einem Start des DA-Managers wird eine fehlerhafte Datenbank angemerkt, man muss manuell die beiden Datenbanken löschen und neu anlegen lassen. Bei dieser Anlegung schmiert die SLMgr.exe allerdings wieder ab.
• Beim Aufruf des OpsMgr (wenn man denn die Installation mal einwandfrei hinbekommen hat) erscheint bei einem deutschen Betriebssystem eine Fehlermeldung, weil der Pfad nicht stimmt, da der Pfad an ein englisches Betriebssystem angepasst ist.

Das Programm an sich ist wie schon gesagt sehr gut und es gibt meines Wissens nach auch keine wirklich gute Alternative, allerdings macht die Version 8 unter Windows Server 2008-Systemen (sowohl x86 als auch x64) keinen Spaß. Hoffentlich ändert sich das mit den kommenden Versionen!

Wer übrigens DA trotzdem auf einem deutschen Betriebssystem installieren möchte, dem sei mein Artikel von März 2009 nahe zu legen: Technikblog: Fehler bei Desktop Authority-Update

Fehler:
Fehler bei Active Directory-Vorgang mit xxxxx.xxxxxxx.loc. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus.
Active Directory-Antwort: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
.

Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte.

Eine Lösung zu dem Problem habe ich auf der folgenden Seite gefunden:

EX2K7 OWA – microsoft.public.exchange.setup

Lösung des Problems:

In den Sicherheitseinstellungen des Benutzer-Profils muss der Haken gesetzt sein bei “Vererbbare Berechtigungen des übergeordneten Objektes einschließen”.

Nach setzen der Einstellung funktionierte das Verschieben problemlos.

Den Wert anpassen kann man unter

“Organisationskonfiguration” => “Postfach” => “Datenbankverwaltung”

Dort die Werte im Punkt “Speichergrenzwerte” anpassen.

P.S.: Nettes Feature von Outlook 2010: Anzeigen der Kontingent-Informationen :)

Da ich ja ein HTC Hero habe und von daher eh eine Internet-Flat habe, kann ich mein Hero als UMTS-Modem nutzen. Die Installation war nicht so ganz wirklich “schlüssig”, deswegen hier eine kleine Beschreibung wie ich vorgegangen bin, um an’s Ziel zu kommen.

Als erstes schließt man sein Hero (oder ähnliches Gerät) per USB an den PC oder an das Notebook an. Nun erscheint im Gerät selber oben in den “Benachrichtigungen” ein USB-Zeichen. Man kann auf die Speicherkarte des Gerätes zugreifen wenn man das Gerät per USB-Verbindung, allerdings erst nach dem “freigeben” im HTC.

Sobald man die Freigabe erteilt hat, kann man die HTC-Sync-Software installieren. Der Installer liegt auf der Speicherkarte des HTC (Alternativ vorher die Software von der HTC-Seite besorgen, die Version auf meiner Karte war nicht mehr aktuell).

Nach der Installation kann man sein Gerät umschalten in den Modus, der die Nutzung des Gerätes als UMTS-Modem zulässt.

Die Option

Menü => Einstellungen => Wireless => Mobiles Netzwerk

und

Menü => Einstellungen => Wireless => Mobile Datenfreigabe

müssen eingeschaltet werden, danach erkennt das Windows eine neue Netzwerkkarte, bezieht automatisch eine IP-Adresse (192.168.100.0/24) und man ist online, ohne weitere Einstellungen oder Dinge, die man noch machen muss.

Die Anbindung in Köln war super, Seitenaufrufe waren sehr schnell, und ich konnte sogar nebenbei Internetradio hören :)

Fehler:

• System.IO.FileNotFoundException
• Microsoft.Office.Server.UserProfiles.UserProfileException

- System.IO.FileNotFoundException

Fehlerbeschreibung:

Der erste Fehler tritt gleich nach dem Start des Konfigurationsassistenten auf und man bekommt die folgende Meldung “Fehler beim erstellen der Konfigurationsdatenbank” und den Hinweis “System.IO.FileNotFoundException”. Dieser Fehler erscheint wenn man eine frühere Version des “Geneva”-Frameworks installiert hat.

Lösung:

Abhilfe schafft eine aktuellere Version die unter dem folgenden Link heruntergeladen werden kann. Download

- Microsoft.Office.Server.UserProfiles.UserProfileException

Fehlerbeschreibung:

Dieser Fehler tritt bei der Erstellung der Beispieldaten auf am Ende des Konfigurationsassistenten in Schritt 8 auf. Der Fehler erscheint wenn “WCF HTTP Activation” und “WCF non-HTTP Activation” auf dem Server nicht aktiviert sind. WCF=Windows Communication Foundation

Lösung:

Für diesen Fehler gibt es mittlerweile einen Hotfix (KB976462) von Microsoft das den Fehler behebt. Unter folgendem Link kann das Hotfix heruntergeladen werden Download

Quellen: SharePoint 2010 Beta 2 – Install error – System.IO.FileNotFoundException ; Error during SP2010 configure – Failed to create sample data

Es war mal wieder soweit, der zweite Dienstag im Monat war gestern. Aus diesem Grund wurden diverse Updates von Microsoft bereitgestellt, Windows 7 war dieses Mal auch dabei.

Weitere Infos zu den Updates, den Schwachstellen und Lücken gibt es auf den folgenden Seiten:

Heise.de

Winfuture.de

Golem.de

Microsoft.com

Wer die Windows Remote Desktop Services (vormals Terminal Services) aus Windows Server 2008 R2 einsetzt wird von der Leistungsfähigkeit überrascht sein. Viele Dinge die bisher nur mit Zusatz Produkten wie Citrix Presentationserver möglich waren sind jetzt in dem Produkt enthalten. Es ist unteranderem möglich die Anmeldeinformationen von einem Arbeitsplatzrechner direkt in die RemoteDesktop Session durchzureichen (Single Sign-On). Microsoft hatte dieses Feature zuerst nur für die neueren Betriebssysteme vorgesehen (Vista, Windows 7 und Windows Server 2008) sich allerdings nachträglich für die Unterstützung von Windows XP allerdings nur ab Services Pack 3 entschieden.

Im folgenden beschreibe ich wie man den dafür notwendigen Credential Security Support Provider (CredSSP) manuell in der Registry installieren.

1. Aufruf von Regedit
2. Öffnet des REG_SZ_MULTI Keys “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages” und ergänzen dort “tspkg”
3. Öffnet des REG_SZ_MULTI Keys “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SecurityProviders” und ergänzen dort “credssp.dll”
4. Öffnen Sie “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows”. Hier erzeugen Sie den Schlüssel “CredentialsDelegation”.
5. Dann erzeugen Sie hier das REG_DWORD “AllowDefaultCredentials” mit dem Wert 1
6. Am gleicher Platz erzeugen Sie das REG_DWORD “ConcatenateDefaults_AllowDefault” ebenfalls mit dem Wert 1
7. Erzeugen Sie  hier den Schlüssel “AllowDefaultCredentials” und darin  den REG_SZ Key “1” mit dem Wert “TERMSRV/*”
8. Regedit schließen und System booten

P.S.: Damit Single Sign-On funktioniert sind noch einige andere Dinge erforderlich: alle beteiligten Systeme und Benutzer müssen über gültige Zertifikate verfügen. Am besten installieren Sie dazu eine Microsoft PKI.

Quellen: Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3

Ich habe das System zunächst per Wiederherstellungskonsole auf einen Punkt zurückgesetzt als das System noch einwandfrei lief, leider gab das keinen erfolg.
Nach einigen Versuchen bin ich auf folgende Lösung gestoßen:

• Start -> Alle Programme -> Zubehör -> Eingabeaufforderung (als Administrator ausführen)
• “netsh winsock reset” eingeben und “Enter”
  falls eine Fehlermeldung kommt diese ignorieren
• “netsh int ip reset” eingeben und “Enter”
• Neu starten

Nachdem Neu starten sollten die Dienste wieder starten und der PC sollte über das Netzwerk eine DHCP Adresse beziehen.

Gestern bin ich mit dem Problem konfrontiert worden, das eine Windows Sharepoint Services 3.0 Server in der Zentraladministration den Dienst “Windows SharePoint Services-Webanwendung” nicht beendet hat. Auch ein Neustart des Servers hat daran nichts geändert. Nach etwas googeln bin ich dann auf die Lösung gestoßen: man kann den Dienst per Komandozeilenbefehl “stsadm” beenden. Der Befehl hierzu lautet:

“stsadm -o provisionservice -action stop -servicetype SPWebService”

Danach sollte man den Internet Information Server Neustarten:

“iisreset /noforce”

Danach sollte es möglich sein den Dienst über die Zentraladministration oder per Kommandozeile wieder zu starten. Der Komandozeilenbefehl lautet:

“stsadm -o provisionservice -action start -servicetype SPWebService”

Bei meinem Problem hat es geholfen.

Post in der ich die Lösung gefunden habe:  http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/1b96caf0-42ca-455b-a375-b0eacddff774/

Ich habe bei Google wenig zu dem Fehler gefunden, ein ziemlich guter Treffer war der folgende:

Error migrating mailboxes to Exchange 2007

Dort war ein mögliches Problem, das der Account des betreffenden Benutzers deaktiviert ist (in der AD) und deshalb das Verschieben nicht klappt. Nach einer kurzen Überprüfung stellte sich dann heraus das der Benutzer deaktiviert war, nach der Aktivierung und Replizierung funktionierte das Verschieben allerdings immer noch nicht.

Mein nächster Ansatz war nun, das ich den Verschiebe-Befehl nicht von dem Exchange 2007 aus initiiere, sondern von dem neuen Exchange 2010. Gesagt getan, in der Verwaltungskonsole des Exchange 2010 habe ich dann folgenden Befehl ausgewählt:

Nach dem Durchklicken des Wizards erschien eine Statusmeldung, das der Befehl erfolgreich angenommen und verarbeitet wurde. Allerdings nach knapp einer Sekunde. Ein kurzer Blick in den neuen Menüpunkt “Verschiebungsanforderung” zeigte mir folgendes Bild:

Das (Initiieren des) Verschiebens scheint also nur in der Verwaltungskonsole des Exchange 2010 zu funktionieren, nicht in der Konsole des Exchange 2007.

Die Installation der beiden Server erwiesen sich als völlig unkompliziert, nach der Installation wurde der erste Server per “dcpromo” zum Domänencontroller hochgestuft und es wurde eine neue Domäne in einer neuen Gesamtstruktur erstellt. Nach der erfolgreichen Installation wurde der zweite Server ebenfalls herauf gestuft und als sekundärer Controller in die Domäne aufgenommen.

Nach der Installation beherbergt der primäre Domänen-Controller (PDC) die folgenden Rollen:

• Active Directory-Domänendienste
• DNS-Server
• DHCP-Server
• Netzwerkrichtlinien- und Zugriffsdienste

In Teil 2 geht es um die Installation der Virenschutz-Software.

Einen ausführlicheren Bericht gibt es auf

Winfuture, hier ein paar Screenshots von Office 2010 Beta 2:

Download via MSDN oder Technet…

beim Hochfahren blieb er beim Updates konfigurieren hängen.

Da auch ein Start im abgesicherter Modus nicht möglich war blieb nur das booten der Server DVD.

Nachdem von der DVD gebootet worden ist auf Computer reparieren klicken.

Auf der Systemwiederherstellungsseite das BS auswählen welches repariert werden soll. Anschließend auf die Eingabeforderung klicken und in das Verzeichnis C:\Windows\winsxs wechseln dort ein rename der pending datei vollziehen ren pending.xml pending.old.

Nachdem wir die Datei unbenannt haben öffnen wir den Registrierungs Editor mit regedit und wechseln in die HKEY_LOCAL_MACHINE. Nun auf Datei auf Strucktur laden klicken und in folgenden Ordner gehen C:\windows\system32\config\components wenn hier nun ein Name abgefragt wird nennen wir diesen Offline_Components. Jetzt nur noch folgende Schlüssel suchen und löschen

HLKM\Offline Components\AdvancedInstallersNeedResolving
HKLM\Offline Components\PendingXmlIdentifier

Jetzt wurde das fehlerhafte Update rückgängig gemacht und der Server sollte normal hochfahren.

1783- Slot 0 Array Controller is in a lock-up state due to a hardware configuration failure (Controller is disabled until this problem is resolved)

Nach einer kurzen Suche bin ich auf den folgenden Beitrag gestoßen:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1257940588358+28353475&threadId=1150275

“Jonathan S.” (letzter Beitrag zu dem Thema") gab mir den entscheidenden Tipp => Entfernen des Cache von dem On-Board-Controller und erneutes Einsetzen. Nach diesem Vorgang funktionierte der Controller wieder und ich konnte mein Array einrichten und das Windows Server 2008 R2 installieren.

Gestern war es mal wieder soweit, es war der zweite Dienstag im Monat und somit Patchday bei Microsoft. Betroffen war diesmal besonders Office. Weitere Informationen zu den gestopften Sicherheitslücken gibt es direkt bei Microsoft.

Wie immer wird allen Anwendern empfohlen die aktuellen Patche zeitnah einzuspielen. Ich habe meinen Job bereits heute morgen gemacht ;)

Es ist soweit, pünktlich zur TechEd Europe in Berlin ist der Exchange Server 2010 beziehbar.

Weitere Infos gibt es unter anderem bei Golem, Heise und auf den Seiten von Microsoft.

Problem ist momentan nur die Download-Geschwindigkeit…

Da ich jetzt stolzer Besitzer eines HTC Hero-Gerätes bin und das Gerät natürlich direkt an meine Bedürfnisse mit Hilfe diverser Apps anpassen wollte, musste ich mir zwangsläufig ein Google-Konto einrichten. Das ganze funktioniert direkt über das Gerät, nach dem Absenden der Daten allerdings erschien nach einiger Zeit die folgende Fehlermeldung

Es kann keine stabile Datenverbindung zum Server hergestellt werden

Ich habe dann an meinem Notebook ein Google-Konto eingerichtet und die Daten in meinem Hero eingegeben, trotzdem gleiche Fehlermeldung.

Lösung des Problems:

Reset des Gerätes auf die Werkseinstellungen und Eingabe der Google-Konto-Daten direkt bei der Initialisierung des Gerätes. Nach diesem (manchmal vielleicht nicht so unproblematischen) Reset funktionierte das Anmelden sofort und ohne Probleme, danach ist auch eine Installation der Apps problemlos möglich.

Wir hatten heute morgen bei einem Kunden das Problem, das ein Zugriff auf die Freigaben des Windows Small Business Server 2003 nicht mehr funktionierte, es erschien die folgende Fehlermeldung:

Nicht genügend Server-Speicherplatz verfügbar,
um diesen Befehl zu verarbeiten

Auf dem Server selber tauchten in der Ereignisanzeige diverse Fehler auf, die darauf zurück zu führen waren, das auf einen Netzwerkpfad nicht zugegriffen werden konnte. Nach einer kurzen Recherche bin ich auf folgenden Microsoft-Artikel gestoßen:

http://support.microsoft.com/?scid=kb%3Ben-us%3B177078&x=11&y=13

Dieser Artikel beschreibt, wie man den Wert

IRPStackSize

unter

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

erhöht bzw. anlegt.

Ich habe auf dem betreffenden System nachgeschaut, dort existierte dieser Wert nicht. Nach dem anlegen des Wertes, eintragen der Dezimalzahl “15” und einem Neustart des Servers funktionierte der Zugriff immer noch nicht, zum Glück habe ich auf dieser Seite gelesen, das es nach einem Neustart nicht zwangsläufig gehen muss, sondern das man gegeben falls den Wert nach einem Neustart nochmal erhöhen muss und nochmal neustarten muss.

Nach dem erneuten erhöhen des Wertes und einem Neustart funktionierte der Zugriff auf die Netzwerkfreigaben dann auch wieder.

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

Wir haben bei der Erstellung unserer Domäne damals den Fehler gemacht, dass wir eine Domäne mit der Endung .de genommen haben, die dazugehörige Domain allerdings nicht besitzen. Wir stoßen nun immer öfters auf Probleme, insbesondere beim Thema Zertifikate. Aus diesem Grund haben wir uns überlegt, dass wir eine neue Domäne aufsetzen und die Server, soweit wie möglich, umziehen. In diesem Zuge werden wir unsere Domäne auch auf dem Level “Server 2008 R2” betreiben, was einige Vorteile mit sich bringt.

Ich werde den Umzug so gut wie möglich hier dokumentieren und wahrscheinlich pro Server / Produkt einen Beitrag schreiben mit Infos zum Umzug, werde Probleme beschreiben auf die wir gestoßen sind und hoffentlich wichtige Informationen für andere bereitstellen, die vor einer ähnlichen Aufgabe stehe. Im folgenden hier eine kleine Auflistung einiger Produkte und Server, die wir im Einsatz haben und die umgezogen werden müssen:

• Drei Domänencontroller
• Ein Exchange 2007-Server
• Zwei File-Server
• Zwei Datenbank-Server (SQL Server 2005 und SQL Server 2008)
• Einen Print-Server
• Zwei Terminal-Server
• Vier Hyper-V-Hosts
• Einen Swyx-Server

Hinzu kommen noch diverse andere Server, die z.B. unser Virenschutzprogramm beheimaten und für die Versorgung der Clients mit Pattern sorgen, sowie unsere Clients, die natürlich auch umgezogen werden müssen.

Geplant ist eine Installation der neuen Domäne parallel zu der bereits bestehenden und eine Umzug in mehreren Schritten, da manche Server z.B. nicht umgezogen sondern neu installiert werden, um entweder das Betriebssystem auf einen aktuellen Stand zu bringen oder weil ein Umzug einfach nicht möglich ist (Domänencontroller beispielsweise).

Wie Daniel Melanchton in seinem Blog berichtet, ist das Produkt “Security Essentials” von Microsoft fertiggestellt und  kann ab sofort gedownloadet werden. Ich spare mir mal die ganzen Infos hier ebenfalls wiederzugeben, “Microsoft Security Essentials” ist ein Viren- und Malware-Schutz von Microsoft. Ich habe ihn auf meinem Notebook schon installiert und werde ihn die nächste Zeit mal testen und beobachten was ich so Erfahrungen mit dem Programm gemacht habe. Der erste Eindruck ist der, das das Programm recht schlicht gehalten ist.

Hier ein Screenshot:

Da der Betrieb von PCs ohne Virenschutz in der heutigen Zeit ein Spiel mit dem Feuer ist brauche ich wohl nicht erwähnen. Der ebenfalls in Daniels Beitrag verlinkte Artikel zu dem Microsoft Security Intelligence Report ist ebenfalls sehr interessant und lesenswert.

Da ich ja ziemlich viel blogge (sowohl privat als auch beruflich), ist es immer recht hilfreich ein gutes Programm zu haben, mit dem man seine Beiträge schreibt. Das ganze sollte nicht zu kompliziert sein, es sollte recht schnell gehen und wenn möglich sollte ein einfaches Speichern der Beiträge bzw. Speichern im Offlinemodus (Im Zug hat man halt Zeit ;)) möglich sein.

Ich habe ziemlich lange nach dem richtigen Programm gesucht, jetzt bin ich fündig gworden: Der Windows Live Writer, Bestandteil der Windows Live Essentials.

Der Windows Live Writer ist Bestandteil von Windows 7 und kommt über per Windows Update, alternativ ist das Programm über folgenden Link beziehbar: Download Windows Live Writer

Viel Spass beim bloggen :)

Zunächst habe ich das PST-File von Outlook gesichert denn darin speichert Outlook alle Persönlichen Daten. Das File liegt unter C:\Users\XXX\AppData\Local\Microsoft\Outlook (wobei XXX für den Benutzernamen steht)
Anschließend habe ich unter Systemsteuerung -> Email die alten Daten gelöscht.
Nun habe ich noch die Konfiguration Datei von Outlook gelöscht die unter C:\Users\XXX\AppData\Roaming\Microsoft\Outlook liegt, nachdem die Datei gelöscht wurde konnte ich Outlook wie gewohnt starten und über die Import Funktion von Outlook konnte ich die alte PST-File Importieren.

Bei HP-PCs und Laptops der aktuellen Generation ist standardmäßig ein Virenschutz von McAfee vorinstalliert, der sich nach der Abfrage der AGBs (und einem Zustimmen eben dieser) komplett einrichtet und für einen Testzeitraum aktiviert. Wenn man aber nun diesen Virenschutz nicht benutzen möchte und stattdessen einen anderen installieren möchte, deinstalliert man das McAfee per Systemsteuerung => Software bzw. Programme und Funktionen. Wenn man nach der Deinstallation ein “Kaspersky Internet Security 2010” installieren möchte, erscheint eine Fehlermeldung. Eine Installation von Kaspersky ist aber trotzdem möglich…

Die Fehlermeldung bei der Installation sieht wie folgt aus:

Der besagte “McAfee Anti-Virus File System Driver” ist trotz einer “normalen” Deinstallation des McAfee-Programms noch auf dem System.

Lösung: Entfernen des Treibers mit dem Programm “MCPR” von McAfee (Link: MCPR.EXE (McAfee.com). Nach dem Ausführen und Durchlauf des Tools erscheint das folgende Fenster:

Nach dem Entfernen und einem Neustart kann das “Kaspersky Internet Security 2010” problemlos installiert werden.

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:

Seit dem 24. August 2009 ist das Service Pack 2 für den Exchange Server 2007 erhältlich. Da wir vorhaben möglichst schnell den Exchange Server 2010 bei uns einzuführen, sind wir quasi gezwungen ein Update auf SP2 zu machen, da eine Umgebung mit einem Exchange 2007 UND einem Exchange 2010 nur dann möglich ist, wenn das SP2 auf dem Exchange 2007 installiert ist (Exchange Server 2007 Service Pack 2 available in Q3 2009).

Nach der Sicherung unseres Exchange-Servers habe ich mich dann an die Installation von SP2 begeben. Nach dem Entpacken der .exe-Datei habe ich mir zuerst die Release-Notes angeschaut, allerdings waren keine äußerst wichtigen Informationen enthalten, das Setup erkennt automatisch ob bereits eine Exchange-Installation vorhanden ist und setzt sich selbst in den Update-Modus, falls nicht beginnt eine Grundinstallation. Voraussetzung für den Beginn des Updates ist ein Stop aller Exchange- und Forefront-Dienste, realisierbar über den “Server Manager” oder per “Dienste” in der “Verwaltung”.

In meinem Fall hat das Update knapp 40 Minuten gedauert, lief allerdings problemlos durch, und nach einem erfolgreichem Neustart des Servers starteten auch alle Dienste wieder problemlos. Ein Test des Empfangs und des Versands von Emails konnte ebenfalls erfolgreich abgeschlossen werden. Seit dem Tag des Updates läuft unser Exchange Server 2007 SP2 ohne Störungen oder Ausfälle.

Downloads:

Exchange Server 2007 Service Pack 2

Microsoft Exchange Server 2007 Service Pack 2 (SP2) – Anmerkungen zu dieser Version

Nach der Anmeldung an einem Windows Server 2008 mit den Remotedesktopdiensten kam die Meldung, das der aktuelle Benutzer nur mit einem temporären Profil angemeldet wurde und das alles Änderungen nach dem Abmelden wieder gelöscht werden. Bei einer Anmeldung am Server mit einem Nicht-Terminal-Server-Profil klappt alles super, das Profil wird angelegt, und alles ist gut. Nur bei Terminal-Server-Profilen funktioniert das Anlegen des Profils nicht, die Ereignisanzeige meldet folgendes Event

Das eigentliche Problem waren falsche Berechtigungen auf dem Profil-Ordner, allerdings erschien die Meldung noch nach dem Setzen der korrekten Einstellungen. Erkennen kann man das temporäre Profil an der Meldung direkt nach dem Login oder indem man sich den Inhalt des Ordners

C:\Benutzer

bzw.

C:\Users

anschaut. Dort exisitiert bei korrekt kopiertem Profil ein Ordner mit dem Namen des Benutzers, falls Fehler auftreten und man mit einem temporären Profil angemeldet wird werden dort Ordner mit den Namen “Temp”, “Temp.Domäne”, “Temp.Domäne.001″ usw angelegt.

Lösung des Problems:

In der Registry werden für jedes Profil Einträge hinterlegt. Solange diese Einträge nicht gelöscht werden funktioniert auch eine vernünftige Anmeldung nicht. Zu finden sind diese Einträge unter

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Dort wird pro Benutzer ein Ordner angelegt, man kann anhand des Wertes

ProfileImagePath

erkennen welche SID zu welchem Profil gehört.

Ich habe gestern bei uns einen neuen Printserver mit Windows Server 2008 R2 aufgesetzt und konfiguriert. Es funktionierte auch alles ganz gut, die Installation der Treiber klappte und die Drucker ließen sich wie gewohnt freigeben. Da der Windows Server 2008 R2 allerdings nur in der x64-Variante verfügbar ist, sind natürlich x64-Treiber auf dem Gerät installiert. Da einige Clients bei uns aber noch 32bittig sind, werden hierfür natürlich auch Treiber benötigt.

Das Hinzufügen des x86-Treibers funktioniert wie folgt:

So weit so gut. Das Problem war allerdings bei einem Xerox-Drucker (Nach der Installation von HP-Druckern), das nach dem Markrieren von "x86", dem Klick auf "OK" und der Pfadangabe des x86-Treibers ein weiteres Fenster aufging, in dem nach der Datei "ntprint.inf" bzw "ntprint.in_" gefragt wurde. Diese Datei liegt unter anderem unter "C:\Windows\System32\inf". Diese Datei hat er aber nicht genommen und hat mit der folgenden Fehlermeldung abgebrochen:

Printer driver was not installed Operation could not be completed (error 0×00000002)

Ich habe dann versucht mehrere "ntprint.inf"-Dateien dem System schmackhaft zu machen (Von einem Windows Server 2008 x86, einem Windows Vista x86, einem Windows 7 x86…), allerdings wurden keine der Dateien akzeptiert, die Fehlermeldung blieb gleich.

Ein manuelles Hinzufügen des Druckers auf meinem Windows 7-Client brachte ebenfalls eine Abfrage nach dem Treiber, die Frage nach der "ntprint.inf" blieb aber aus.

Lösung des Problems:

Man muss auf dem oben beschriebenen Weg dem "Server 2008 R2" den x86-Druckertreiber hinzufügen, und bei der Nachfrage nach der "ntprint.inf" verweist man auf den folgenden Ordner bei einem Windows Vista oder einem Windows 7-Client:

\\x86-Client\C$\Windows\System32\DriverStore\FileRepository\ntprint.inf_x86_neutral_xxxxxxxxxxxxxxxx

In diesem Ordner sind die folgenden Dateien:

Nach einem Klick auf "OK" arbeitet der Server und nach einiger Zeit wird das Fenster ohne Fehlermeldung geschlossen und der Treiber ist hinzugefügt. Ab diesem Zeitpunkt können die Drucker auch an x86-Clients hinzugefügt werden, in unserem Fall per "Desktop Authority".

Anmerkung 09. Juni 2010:

Ich habe während meiner Installationen folgendes festgestellt, allerdings nicht dokumentiert:

Ausgehend davon, das man den HP Universal Treiber installieren möchte, ist es bei der Installation so, das sowohl der x64 als auch der x86-Treiber aus der gleichen Quelle bzw. für das gleiche Betriebssystem sein muss. Das bedeutet, das wenn man den x64 Drucker-Treiber für Windows Server 2008 R2 installiert, braucht man auch den x86-Treiber für Windows Server 2008 R2. Da es diese Version aber nicht gibt, könnte man jetzt denken das man als x86-Treiber den Windows 7-Treiber nimmt. Dieser wird aber nicht angenommen.

Lösung dieses Problems ist, das man sowohl den x64 als auch den x86-Treiber für Windows 7 nimmt, da gleiche Code-Basis!

Das Öffnen der Systemsteuerung sah im Taskmanager so aus

Nach dem Kontakt mit dem Support und dem Senden einer Liste der installierten Programme

bekam ich als mögliche Lösung des Problems die Deinstallation der “Altiris Software Virtualization Agent”-Software. Laut Aussage des Supports beißt sich die Software mit dem TrendMicro-Agenten.

Gesagt getan, nach der Deinstallation der “Altiris Software Virtualization Agent”-Software laufen die Systeme wieder sauber und performant und haben eine durchschnittliche Auslastung von Zwei bis Fünf Prozent.