Microsoft hat die Windows Support Tools (mit nützlichen Programmen wie filever.exe) nicht mehr auf die Windows Vista und Windows 7 sowie auf die Windows Server 2008 Datenträgern gepackt.

Funktionstüchtig sind die Support Tools vom Windows Server 2003 SP2 32 Bit, die auch auf 64 Bit Systemen laufen. Sie können entweder Ihren Windows Server 2003 Datenträger nehmen, und die Tools von dort benutzen, oder Sie können Sie hier herunterladen:

http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B-9A772EA2DF90&displaylang=en

Wenn ein Windows Computer mit einem sogenannten Blue Screen Of Death (BSOD, Blauer Schirm des Todes) abstürzt, dann werden die Fehlerinformationen in einem Speicherabbild gespeichert. Dieses wird als Datei im Verzeichnis C:\Windows\Minidump abgelegt. Das Verzeichnis existiert in der normalen Windows-Ordnerstruktur nicht, sondern wird beim ersten BSOD angelegt.

Minidump-Dateien sind kompilierte Dateien, die man mit den Debugging Tools für Windows, die kostenlos auf der Microsoft-Seite verfügbar sind, öffnen, einsehen und interpretieren kann. Zusätzlich zu den Tools benötigen Sie noch Symbol-Dateien. Diese können Sie ebenfalls kostenlos von Microsoft herunter laden. Hier die Speicherorte:

• Debugging-Tools: http://www.microsoft.com/whdc/devtools/debugging/default.mspx (unter Using Debugging Tools for Windows finden Sie die Links zu den Downloads für Ihre jeweilige Plattform (x86 oder x64)
• Symbols: http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx

Bei den Symbol-Dateien müssen Sie sich die entsprechenden Dateien für das jeweilige Betriebssystem, das abgestürzt ist, herunterladen. Installieren Sie dann die Tools und danach die Symbols. Bitte beachten Sie auch, dass Sie mit einem 64-Bit Debugger sowohl 32-Bit als auch 64-Bit Dateien debuggen können, nicht aber mit einem 32-Bit Debugger 64-Bit Dateien (also Minidumps, die von 64-Bit Maschinen generiert wurden).

Den Windows-Debugger WinDbg einrichten

• Nach der Installation starten Sie das Programm WinDbg.
• Dann gehen Sie auf Files->Symbol File Path… (alternativ drücken Sie Strg+S)
  
  • Hier geben Sie den folgenden Wert ein:
    SRV*C:\Windows\Symbols*http://msdl.microsoft.com/download/symbols
    • Wobei Sie C:\Windows\Symbols bitte mit dem Pfad ersetzen, unter dem Sie die Symbols installiert haben.
• Danach gehen Sie auf Files->Image File Path… (alternativ drücken Sie Strg+I)
  
• Hier geben Sie den folgenden Wert ein:
  C:\Windows\System32
  • Wobei Sie C:\Windows durch das Windows-System-Verzeichnis ersetzen.

Die MiniDump Datei öffnen

• Gehen Sie auf Files->Open Crash Dump (alternativ drücken Sie Strg+D)
• Wählen Sie die .dmp Datei aus und öffnen Sie diese
• Der Debugger startet und verbindet sich mit der Datei. Sobald er fertig ist, sehen Sie am Ende des Vorgangs einen Link !analyze -v. Klicken Sie diesen und warten Sie den Debug-Vorgang ab.

Im Video erkläre ich Ihnen, wie Sie die Ergebnisse interpretieren können.

Somit wünsche ich Ihnen noch viel Erfolg bei der Fehlersuche und freue mich auf Ihre Meinung, Anregungen und Kommentare.

Hoppla, da ist mir beim Umzug doch ein Fehler unterlaufen! Ich habe die Links für das neue Blog falsch eingrichtet, so dass die meisten Google-Suchanfragen auf eine fehlende Seite verlinkt waren und die berüchtigte 404-Fehler-Seite angezeigt wurde.

Ich möchte Sie hierfür um Verzeihung bitten, da mir das eben erst aufgefallen ist. Meine Statistiken hatten mir zwar angezeigt, dass einige Treffer auf die 404-Seite liefen, doch hatte ich zuerst angenommen, dass dies mit dem DNS-Umzug des Domain-Namens (blog.pmd-media.com) zu tun hatte. Ich habe die Links allerdings sofort korrigiert und sie sollten nun wieder alle funktionieren.

Also, das Blog ist wieder auffindbar und ich freue mich auf Ihre Kommentare.

Beste Grüße aus Korbach,

Frank Piotrowsky

Es kann vorkommen, dass durch Fehlkonfiguration ein Namespace in einem Verteilten Datei System (Distributed File System, DFS) zerstört wird. Er kann dann nicht mehr abgerufen oder gelöscht werden. Die einzige Option, die bleibt, ist, den Namespace aus der Anzeige zu nehmen. Da ich nun den Namespace benutzen wollte, wollte ich ihn wieder herstellen bzw. neu anlegen. Doch dieses quittierte mir der Server immer wieder mit der Aussage, dass der Namespace bereits vorhanden wäre und deswegen wahrscheinlich nicht richtig funktionieren würde.

Wie kann also ein solcher Namespace per Hand gelöscht werden?

Die Freigabe eines Namespaces besteht aus 3 Komponenten:

* Ein Verzeichnis, das freigegeben wird

* Eine Freigabe auf dem Server auf das Verzeichnis

* Die Freigabe im Namespace auf dem DFS

Die ersten beiden Komponenten bleiben in dieser Betrachtung außen vor, da sie sowieso vorhanden sein müssen. Uns interessiert hier die Freigabe im Namespace auf dem DFS.

Ein Domänen-Namespace besteht aus den folgenden Komponenten:

* Eintragung im Microsoft Active Directory

* Verzeichnis auf dem Server, der DFS hostet

* Freigabe auf dieses Verzeichnis

* Microsoft Windows Server 2000 legt (laut Microsoft) auch noch spezielle Registry-Keys an (Server 2003 konnte ich nicht überprüfen)

Das Vorgehen sieht so aus:

1. Den DFS-Dienst stoppen

• Für Server 2000/2003: Startmenü->Ausführen (oder Windows-Taste und R gleichzeitig drücken), cmd eingeben und Enter drücken
• Für Server 2008: Startmenü (oder Windows-Taste drücken) cmd eingeben und Shift+Strg+Enter (startet jedes Windows-Programm mit erhöhten Rechten – als Administrator ausführen) drücken
• net stop dfs eingeben und Enter drücken

2. Registry bearbeiten (nur Microsoft Windows Server 2000 und wahrscheinlich 2003)

• Registry-Editor öffnen (das Programm heißt regedit oder regedit32, gleiche Vorgehensweise wie beim Starten der Kommandozeile aus Punkt 1)
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft öffnen
• Den DFSHost Unterschlüssel löschen (laut Microsoft – Wenn dort einzelne Einträge vorhanden sind, sollte man vielleicht nur den betroffenen Namespace löschen. Wie gesagt, konnte ich leider nicht testen. Vielleicht hat damit ja schon jemand Erfahrungen gemacht. Ich würde mich sehr über entsprechende Kommentare freuen).
• Danach HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSDriver\LocalVolumes öffnen
• Dort jeden (laut Microsoft – möglicherweise auch nur die jeweils betroffenen) Unterschlüssel löschen. Auf gar keinen Fall den LocalVolumes Unterschlüssel löschen!

3. Active Directory Bearbeitung

• Active Diretory-Benutzer und -Computer Konsole (kann per Ausführen gestartet werden: dsa.msc) starten
• Auf Ansicht->Erweiterte Features klicken
• Im System-Ordner den Dfs-Configuration Container öffnen
• Im rechten Bereich den betroffenen Namespace löschen

4. DFS neustarten

• Der DFS kann dann über die DFS-Verwaltung (dfsmgmt.msc) neu gestartet werden

5. Dateien und Freigaben löschen

• Das Standardverzeichnis liegt unter C:\DfsRoots
• Hier das betroffene Verzeichnis nebst Freigabe löschen (um die Konfiguration sauber zu haben)

Den entsprechenden Microsoft-Artikel finden Sie hier: http://technet.microsoft.com/en-us/library/cc962150.aspx.

Natürlich sollten Sie sämtliche Vorsichtsmaßnahmen treffen – besonders bei der Bearbeitung der Registry. Immer den Schlüssel vorher wegsichern, bevor Sie ihn löschen.

Über Kommentare, Anregungen und weitere Tipps würde ich mich freuen.

Gestern habe ich mit ExMerge gekämpft, um einzelne Postfächer aus einem Microsoft Exchange Server 2003 in PST-Dateien zu exportieren. Also habe ich die Konfiguration aufgesetzt, die exmerge.ini Datei ausgefüllt, eine mailboxes.txt Datei angelegt, etc. Also, alle Vorarbeiten getroffen, die durchzuführen waren.

Dann ging es an die Ausführung:

exmerge -b -d

-b startet ExMerge im Batch-Mode (ohne GUI) und -d zeigt während der Ausführung ein Fenster mit einem Fortschrittsbalken an.

Soweit die Theorie. In der Praxis funktionierte das nicht. Ich bekam im Logfile folgende Fehlermeldung:

Error! Server server.domain.local is not listed as an Exchange 2000
server in the Active Directory on server SERVER.
(CADRoutines::GetExchangeServerNameInfo)

Das Web gab hierzu nicht wirklich was her. Ich habe gesucht und gesucht. Und folgende Vorschläge überprüft:

• Receive As (Empfangen als) und Send As (Senden als) Erlaubnis für den ausführenden User auf dem Exchange Server (Administratoren haben bei diesen Punkten sowohl die Erlaubnis als auch die Verweigerung)
• ob Exchange-Dienste ausgeführt werden
• verschiedene Einstellungen in der exmerge.ini ausprobiert
• eine Gruppe und einen User angelegt (es sollte laut Foren eine Gruppe Exchange Services geben, die ich aber nicht finden konnte. Dieser Gruppe sollte der User zugeordnet werden. Angeblich weil ExMerge nicht mit dem Administrator Konto ausführbar sei – sobald aber die Einstellungen bzgl. Receive As und Send As geändert waren und der Informationsspeicher neu gestartet wurde, ist das aber kein Problem!)

Lösung

Zu diesem Fehler gab das Web leider nicht mehr her. Heute habe ich das Problem gelöst: Der Servername! Ich hatte den FQDN (Full Qualified Domain Name, Voll qualifizierter Domain-Name) angegeben. ExMerge nutzt zur Überprüfung aber LDAP, um das Active Directory abzufragen und erwartet hier den reinen Servernamen. In meinem Fall also nicht server.domain.local, sondern schlicht und einfach nur server. Im Active Directory findet er weder unter der IP etwas, noch unter localhost.

Danach lief alles wie gewünscht und problemlos.

Haben Sie Ähnliches erlebt mit ExMerge? Ich freue mich auf Ihre Kommentare.

Das Problem

Microsoft Office Outlook 2007 kann nicht gestartet werden. Das Outlook-Fenster kann nicht geöffnet werden.

Die Lösung

Das ist die Meldung, mit der der Benutzer empfangen wird. Lange hatte ich diese Fehlermeldung. Ein Post von Martin Bauer auf http://www.bauer-martin.com hat mir dann die Nadel im Heuhaufen verraten: die Datei Outlook.xml. Hier speichert Outlook nach einer Sitzung Konfigurationsdaten ab. Wenn diese Datei korrumpiert wurde (nicht sauber gespeichert beim Schließen von Outlook, oder Fehler bei der Synchronisation, etc.) kann Outlook nicht mehr starten.

Hier die Pfadangaben:

XP
C:\Dokumente und Einstellungen\%Benutzername%\Anwendungsdaten\Microsoft\Outlook\

Vista
C:\Benutzer\%Benutzername%\AppData\Roaming\Microsoft\Outlook\

Bitte beachten Sie, dass bei Profilen, die mit einem Server synchronisiert werden, die entsprechenden Netzwerkpfade angegeben werden müssen:

XP
\\%ServerName%\%UserDataFreigabename%\Dokumente und Einstellungen\%Benutzername%\Anwendungsdaten\Microsoft\Outlook\

Vista
\\%ServerName%\%UserDataFreigabename%\Benutzer\%Benutzername%\AppData\Roaming\Microsoft\Outlook\

Löschen Sie in dem Verzeichnis die folgende Datei:

• outlook.xml

(Wenn Sie die Variablen [die Namen, die in %-Zeichen eingeschlossen sind] durch die entsprechenden Speicherorte ersetzen, können Sie den Pfad direkt in die Adress-Zeile des Windows Explorer einsetzen. Um dorthin zu navigieren, müssen Sie unter Versteckte Dateien und Ordner unter Extras->Ordneroptionen->Ansicht Alle Dateien anzeigen auswählen, damit die versteckten Ordner angezeigt werden. Das Menü Extras erhalten Sie unter Windows Vista und Windows 7 durch Drücken der F10-Taste im Windows Explorer.)

Ich habe wirklich hart kämpfen müssen, obwohl die Lösung ganz einfach war…. Hinterher ist man immer schlauer .

Konfiguration

• Microsoft Windows 7
• Microsoft Visual Studio 2010 Beta 2
• Parallels 4.0
• Apple MacBook

Vorgehensweise

Nachdem die Software auf der virtuellen Maschine installiert war, habe ich den Remotedebugger auf dem Server mit den ASP.NET-Anwendungen installiert und als Dienst gestartet.

Firewallkonfiguration

In der Windows-Firewall muss auf dem Host das Progamm Microsoft Remotedebugger, auf dem Client das Programm Microsoft Visual Studio als Ausnahmen deklariert sein, bzw. in einer Firewall müssen die folgenden Ports geöffnet sein:

• TCP 139
• TCP 445
• UDP 137
• UDP 138

Sollten Sie IPSec benutzen müssen, benötigen Sie auch die folgenden Ports:

• UDP 4500
• UDP 500

Fehlermeldung

Als ich brav alles eingestellt hatte, quittierte mir das System meine Debugging-Bemühungen mit folgender Fehlermeldung:

Unable to start debugging on the web server. The Visual Studio
debugger cannot connect to the remote computer. A firewall may
be preventing communication via DCOM to the remote computer.
Please see Help for assistance.

Remotedebugging - Unable to start debugging on the web server

Diese Fehlermeldung blieb mir selbst bei der Ausschaltung sämtlicher Firewalls erhalten.

Lösung

Der Trick: Mein Netzwerk-Adapter in der Parallels-Maschine war auf “Shared” einstellt und hatte so eine IP, die in einem anderen Netzwerkbereich lag. Da der Domänencontroller diesen nicht kannte, konnte der Microsoft Visual Studio Remotedebugger keine Verbindung zu der Client-Maschine aufbauen.
Setzen Sie den Modus für den Adapter auf “Bridged”. Dann wird es als eigenständige Netzwerkkarte betrachtet und bekommt vom DHCP-Server der Domäne eine eigene IP. Mit dieser kann sich der Remotedebugger dann auch connecten.

Wenn Sie Fragen, Anregungen oder Wünsche zu weiteren Themen in diesem Bereich haben, nutzen Sie bitte die Kommentare. Ich freue mich auf Ihre Feedback…

Die ASP.NET-Anwendungen eines Microsoft Internet Information Server 7.0 (IIS 7) ließen sich in der Domäne nicht remote debuggen. Es kam die Meldung:

Unable to Start Debugging on the Web Server. Das System kann die
angegebene Datei nicht finden.

Die Meldung (halb englisch, halb deutsch) wurde vom Microsoft Visual Studio 2010 Beta 2 Remotedebugger ausgegeben. Daher wahrscheinlich der Sprachenmix.

Lösung

Der IIS muss die Integrierte Windows-Authentifizierung aktiviert haben. Danach lief alles so, wie es sollte.

Vorgestern Morgen empfing mich der Hyper-V-Manager eines Microsoft Windows 2008 Servers mit der Meldung, dass sämtliche virtuellen Maschinen angehalten wurden, da der Status kritisch sei.

Warum?

Ist auf dem Laufwerk, auf dem die virtuellen Festplatten gespeichert sind, nicht mehr genügend Platz für die Vergrößerung derselben, dann werden die virtuellen Maschinen angehalten.

Die Lösung:

Also habe ich Platz geschaffen und siehe da – es lief wieder anstandslos.

Wie sind Ihre Erfahrungen? Ich freue mich auf Ihre Kommentare.

Frage:

Wie kann man eine Windows 7 Virtual Machine auf einem Virtual Server 2005 R2 zum Laufen bringen?

Antwort:

Man braucht die neueste Version von Microsoft Virtual Server 2005 R2.

Frage:

Und wenn die nicht über die Windows Update Services mit installiert werden?

Antwort:

Dann hast Du ein Problem!

Dieses Problem hatte ich, nachdem ich die Virtual Machine Addons in der virtuellen Windows 7 Maschine installiert hatte. Das System fuhr nicht mehr hoch, sondern kam mit der Meldung, dass das System repariert werden müsse. Dieser Reparaturvorgang ist allerdings niemals erfolgreich verlaufen.
Also habe ich Windows Update bemüht: Ohne Erfolg! Windows Update bescheinigte mir, dass mein System auf dem neuesten Stand sei.
Dann tat ich das, was jeder gute Administrator tut: ich fing an zu googlen. Und nach stundenlanger Recherche bin ich endlich drauf gestoßen:
Update zu Microsoft Virtual Server 2005 R2 SP1 (KB956124)
Meine Microsoft Virtual Server 2005 R2 Version war 1.1.603. Und durch dieses Update wird die Version 1.1.653 aufgespielt.
Nachdem ich dieses durchgeführt hatte, lief Windows 7 inkl. Virtual Machine Addons (13.820) problemlos.

Frage:

Warum hat Windows Update Services dieses Update nicht gefunden?

Was denken Sie? Ich freue mich auf Ihre Kommentare.