Folgendes ist mir vor kurzem auf einer Maschine mit Microsoft Office SharePoint Server aufgefallen:

Das Verzeichnis c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS nahm plötzlich 30GB an Speicher weg, was dazu führte, dass auf dem Server die gesamte C: Partition überlief…

Das ist das Verzeichnis, in dem der Microsoft SharePoint Server standardmäßig sein Trace Log ablegt.

Das Erste, was ich gemacht habe war, den gesamten Ordner sofort mit dem Attribut Compress contents to save disk space zu versehen, damit das NTFS-Dateisystem diese Text-Logfiles zumindest in komprimierter Form ablegt. Damit waren anschließend wenigstens wieder 20GB auf dem Datenträger verfügbar…

Das Tracelog-Verhalten lässt sich hier einstellen:

• SharePoint Central Administration
• Operations
• Diagnostic logging
• Trace Log
  (Hier habe ich die Number of Log Files zusätzlich noch von 96 auf 10 heruntergeschraubt…)

Solch ein Verhalten kann auch ein Anzeigen dafür sein, dass einige Timer Jobs zu beschäftigt sind auf dem System.

Man findet diese unter:

• Central Administration > Operations > Timer Job Status

Und kann sie beeinflussen unter:

• Central Administration > Operations > Timer Job Definitions

So etwas lässt doch Linux-Fans die Herzen höher schlagen

Linux: Prozentuale Fortschrittsanzeige bei Installation Open-VM-Tools

Windows-Fans sind hingegen nur immer falsch anzeigende grafische Fortschrittsanzeigen im Windows-Explorer gewohnt (die immer am längsten kurz vor Schluss brauchen *g)

Ich habe vor kurzem mal wieder ein Update der gesamten Distribution per apt-get dist-upgrade auf einem meiner Linux-Server gemacht. Lief alles wunderbar durch ohne Fehlermeldungen, bis zum nächsten Neustart…

Dann fuhr Ubuntu-Server erst gar nicht mehr hoch, sondern lief immer direkt in eine Kernel panic hinein:

Cannot open root device “sda2″ or unknown-block(0,0)

Please append a correct a correct “root=” boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Ich konnte das Problem dann schlussendlich wie folgt wieder lösen:

1. Booten über eine LiveCD und Verwendung von chroot (wie hier ausführlich beschrieben)
2. Ausführen von sudo update-grub

Danach lief der Bootvorgang wieder einfwandfrei.

Scheinbar wurde der GRand Unified Bootloader 2 – kurz GRUB 2 beim Distribution Update mit aktualisiert und dieser kam dann aber nicht mehr mit der bestehenden Konfiguration zurecht (welche natürlich im Rahmen des automatisierten Updates nicht gleich neu geschrieben wurde; wir sind ja nicht bei “Wünsch dir was…” *g)

Nun funktioniert alles wieder. Hat mich nur leider ein paar Stunden meiner Zeit gekostet…

Der Open Source VMFS Driver ist ein nützliches Tool um auf das Dateisystem eines VMware ESXi Servers zuzugreifen.

Das Tool lässt sich unter http://code.google.com/p/vmfs kostenlos runter laden.

Zur Ausführung wird Java benötigt.

Zuerst schließt man die Festplatte an den Windowsrechner an und öffnet die Datenträgerverwaltung. Dort erkennt man die Festplatte daran, dass bei den Partitionen kein Dateisystem angezeigt wird. Wichtig ist hier die Datenträger Nummer, diese ist links zu finden. Die müssen wir uns merken.

Jetzt öffnen wir eine Konsole im Administrator Modus.

Mit dem Befehl

java -jar fvmfs.jar \\.\PhysicalDrive4 info

können wir uns Informationen über das Laufwerk anschauen. (Hier die richtige Datenträgernummer nutzen)

Es stehen folgende Befehle zur Verfügung:

info
dir path
dirall path
fileinfo path
filecopy path [newname position size]
filedump path position size
webdav [host port]

eine genau Anleitung findet man unter: http://code.google.com/p/vmfs/wiki/CLI

Ich habe mich die letzten Tage mal wieder mit Drucken in .NET beschäftigt und habe dabei wieder festestellen müssen, dass Probleme, die schon seit langem bekannt sind, nach wie vor vorhanden sind.

1) PrintDialog und die x64 Welt…

Wer kennt ihn nicht, den guten alten Drucken-Dialog.

PrintDialog

Eigentlich denkt man sich, hier kann man nicht viel falsch machen.

PrintDialog pd = new PrintDialog();
pd.Document = myPrintDocument;
var result = pd.ShowDialog();

Das funktioniert auch alles wunderbar - solange man entweder in x86; oder aber auf AnyCPU kompiliert und die Anwendung auf einem 32-Bit Betriebssystem ausführt. Aber wehe, man kommt auf die Idee etwas x64 oder AnyCPU-kompiliertes auf einem 64-Bit Betriebssystem aufrufen zu wollen. Denn dann passiert beim Aufruf von ShowDialog() nämlich überhaupt nichts…

Es gibt ein Workaround:

pd.UseEXDialog = true;

Damit wird der alte XP Style für diesen Dialog verwendet und dann wird das Drucken Dialogfenster auch unter x64 korrekt aufgerufen:

Drucken-Dialog XP Style

Was wirklich traurig ist, dass dieses Fehlverhalten bereits seit dem .NET 2.0 Framework existiert. Es wurde weder in 3.0, noch in 3.5 oder 3.5 SP1 behoben. Aber: jetzt kommt die gute Nachricht, in .NET 4.0 hat man sich der Problematik endlich angenommen und es funktioniert dort nun auch ohne den XP Style Trick… Das wurde auch Zeit

2) PageSetupDialog und die metrische Welt

Seite einrichten Dialog

Auch beim PageSetupDialog denkt sich vielleicht der ein oder andere, dass man nicht viel verkehrt machen kann:

PageSetupDialog psd = new PageSetupDialog();
pd.Document = myPrintDocument;

Das funktioniert auch einwandfrei, aber wenn man nun den Dialog nacheinander mehrmals startet und mit OK bestätigt, werden die Ränder bei jedem mal kleiner, obwohl man keinerlei Änderungen (Links / Oben / Rechts / Unten) gemacht hat. Grund ist ein interner Umrechnungs-Fehler.

Das Problem ist seit langem bekannt, es gibt sogar einen Microsoft KnowledgeBase Artikel zu dieser Problematik: BUG: The margin value decreases every time PageSetupDialog is displayed.

Es wird darin allen Ernstes empfohlen, dass der Benutzer der Anwendung die Regionaleinstellungen seines Betriebssystems auf das Angloamerikanische Maßsystem umstellen soll, um den Fehler zu umgehen. Wenn man das aus Sicht des Entwicklers liest, fragt man sich aber, ob das so wirklich Sinn macht… *g

Andere Entwickler sahen das auch so und haben sich das ein oder andere dazu einfallen lassen, siehe z.B. hier in einem Artikel von 2004 über VB .NET, in dem eine Korrektur-Umrechnungsformel entwickelt wurde.

Was aber wirklich hilft, und auf was Microsoft eigentlich auch viel eher in ihrer KnowledgeBase hinweisen sollte, ist:

psd.EnableMetric = true;

Damit werden die Werte der Ränder auf einem metrischen System auch von Anfang an korrekt 1:1 angezeigt und nicht umgerechnet. Es empfiehlt sich, dieses Flag fallweise auf Grund der aktuell eingestellten Regionseinstellungen zu setzen, damit die Anwendung wirklich international funktioniert, also konkret:

psd.EnableMetric = System.Globalization.RegionInfo.CurrentRegion.IsMetric

PS: Diese “spezielle” Verhalten ist bis einschließlich .NET 4.0 vorhanden, ich denke mal Microsoft sieht das nicht als Fehler, da es im amerikanischen Raum eh nicht auftritt - und wer für Europa programmiert, muss das halt einfach wissen.

Durch das geniale Extension-Konzept der 2010er Version lässt sich Visual Studio nach Belieben um Funktionalitäten erweitern. Es gibt bereits eine Vielzahl verfügbarer freier Erweiterungen, auf die man zurückgreifen kann.

Folgende Extensions halte ich persönlich für die tägliche Arbeit äußerst hilfreich:

• Productivity Power Tools
  Erweitert VS2010 um viele kleine nützliche Funktionen (Solution Navigator, Quick Access, etc.), die einzelnen Features sind über Tools / Options / Productivity Power Tools einfach ein/auschaltbar.
• PowerCommands for Visual Studio 2010
  Erweitert VS2010 um sehr viele kleine nützliche Funktionen (Open Containing Folder, Close All, Copy Class, etc.)
• HelpViewerKeywordIndex
  Integriert Index und Suchfeld für die lokal installierte Hilfe (siehe auch diesen Blogeintrag).
• Visual Studio Color Theme Editor
  Ermöglicht die farbliche Anpassung des “neuen” Visual Studio 2010 Designs.
• Collapse Selection In Solution Explorer
  Fügt einen zusätzlichen Knopf (und eine Tastenkombination) in den Solution Explorer ein, der es ermöglicht alle Elemente (ab dem derzeit selektierten) einzuklappen.
• VS10x Code Map
  Navigierbare Code-Visualisierung (Methoden, Properties, etc.) des aktuell geöffneten Fensters.
• CodeRush XPRESS
  Bietet viele Refactoring-Möglichkeiten und visuelle Hervorhebungen des Codes (u.a. sehr nützliche vertikale Linien zwischen Blöcken). Optionen lassen sich mittels Ctrl-Alt-Shift-o einstellen.

Die Installation der Extensions ist denkbar einfach, entweder man lädt diese auf den angegebenen Seiten herunter und startet die entsprechende VSIX-Datei. Oder aber man ruft in Visual Studio 2010 über das Menü Tools den Extension Manager auf. Anschließend auf “Online Gallery” gehen und die gewünschte Erweiterung installieren (ggf. vorher über die Suchfunktion oben rechts filtern).

Wenn ich auf neue, äußerst hilfreiche Extensions stoße, werde ich diesen Blogeintrag entsprechend ergänzen

Was sich in Visual Studio 2010 drastisch geändert hat, ist die integrierte Hilfe. Diese läuft inzwischen entweder nur noch ausschließlich online auf dem Microsoft Webserver, oder alternativ (sofern man dies einstellt) auf einem Webservice auf der eigenen Maschine. Wählt man letzteres, so kann man ausgewählte Hilfsthemen lokal installieren.

Allerdings ist Ausgestaltung der Funktionalität in der derzeitigen Version leider noch recht mager - zumindest, wenn man sie an der früheren Hilfe misst. Es gibt kein Gesamtinhaltsverzeichnis (Table of Contents) mehr, keinen Index, keinen Filter, etc. Lediglich eine Volltextsuche ist noch vorhanden.

Es gibt aber glücklicherweise 3rd Party Tools, die zumindest Teile dieser Funktionalitäten wieder möglich machen.

Eine Variante ist der H3Viewer, ein externes Programm, welches sich auf die lokale Hilfe verbindet und die wichtigsten “Hilfsmittel” wieder zur Verfügung stellt (TOC, Index, Lesezeichen, u.s.w.) - es liest einem bei Bedarf sogar die Hilfe vor, wenn man dies denn möchte…

H3Viewer - Anzeige der Visual Studio 2010 Hilfe

Eine Alternative oder Ergänzung ist die VisualStudio 2010 Erweiterung HelpViewerKeywordIndex. Diese integriert sich direkt in Visual Studio 2010 und bietet zumindest wieder einen Index.

Visual Studio 2010 Extension: HelpViewerKeywordIndex

P.S.: Die Möglichkeit, Visual Studio 2010 mittels vorhandener Extensions beliebig zu erweitern und auch selbst welche zu schreiben, halte ich für eine der besten neuen Errungenschaften der 2010er Version.

Der neue Team Foundation Server 2010 Server ist schon eine tolle Sache, und man muss zugeben, dass sich seit der letzten Version einiges getan hat. Auch im Bereich vereinfachter Installation (selbst im “Advanced” Modus). Und er unterstützt endlich auch x64 Betriebssysteme wie Windows Server 2008 R2 x64.

Über eine Sache bin ich dennoch gestolpert, und zwar was das Anlegen von neuen Projekten aus dem Visual Studio 2010 Team Explorer unter bestimmten Benutzern angeht:

Visual Studio 2010 - Fehler beim Anlegen von TFS Projekten

Sprechen Sie auch Germisch? Ich “liebe” immer diese halb deutschen, halb englischen Sachen…

Folgende URL konnte mir bei der Behebung des Problems helfen:
How to: Set Administrator Permissions for Reporting Services

Denjenigen, die auch einmal ein bisschen mit dem neuen TFS 2010 herumspielen wollen, kann ich folgende Installations-Anleitung sehr ans Herz legen.

Wenn man Projekte im Team abwickelt, kommt es vor, dass die gleichen Dateien von mehreren Leuten gleichzeitig bearbeitet werden. So hat man selbst schon Änderungen vorgenommen, es liegen aber gleichzeitig bereits neue, widersprüchliche Änderungen in der Quellcodeverwaltung (Team Foundation Server, etc.) vor.

Visual Studio bietet hier bereits einige sehr brauchbare Mechanismen, insbesondere auch den automatischen Abgleich (Merge), der recht gut funktioniert.

Ab und an kommt man aber nicht umher, Dinge auch manuell abzugleichen bzw. Änderungen zwischen Versionen visuell zu inspizieren. Hier konnte ich mich noch nie wirklich mit dem in Visual Studio integrierten Tool anfreunden. Ein Kollege hatte mir vor kurzem einen guten Tipp gegeben:
das Freeware-Programm WinMerge.

WinMerge beim Vergleich/Abgleich von zwei Quelltexten

Es lässt sich auch vollständig in Visual Studio integrieren: Menü Tools / Options / Source Control / Visual Team Foundation Server / Configure User Tools…

Und hier dann zwei neue Einträge anlegen:

Visual Studio - WinMerge Integration Compare

Hier nochmal copy/paste freundlich: /x /e /ub /wl /dl %6 /dr %7 %1 %2

Visual Studio - WinMerge Integration Merge

Hier nochmal copy/paste freundlich: /x /e /ub /wl /dl %6 /dr %7 %1 %2 %4

Ab jetzt lässt sich WinMerge sowohl zum Vergleich von Quelltexten (z.B: über die History-Funktion), als auch zum Abgleich von widersprüchlichen Quelltexten (über Merge beim Checkin) verwenden.

Update: Es gibt noch ein alternatives gutes Freeware-Tool für den Job: DiffMerge

Teilweise kommt dieses mit dem Vergleich zweier stark restrukturierter Texte etwas besser zurecht (z.B. Quelltexte, in denen nur die Reihenfolge der Methoden geändert wurde, nicht aber deren Signaturen oder Inhalte). Eine Integration in VisualStudio ist damit ebenfalls möglich.

Microsoft Outlook, sowie auch Microsoft Exchange haben die schlechte Angewohnheit unter bestimmten Umständen anstatt einem regulären Dateianhang eine so genannte TNEF-codierte winmail.dat Datei anzuhängen, in der dann die eigentlichen Dateianhänge, Nachrichten, etc. enthalten sind.

Geht die E-Mail von Outlook zu Outlook, bekommt der Benutzer das im Normalfall niemals mit, für den Empfänger sieht die E-Mail und auch all ihre Dateianhänge ganz normal aus.

Aber wehe, die E-Mail geht an Empfänger anderer E-Mail Clients, wie Lotus Notes, TheBat!, etc. Hier kommt es regelmäßig vor, dass derjenige dann nur eine winmail.dat bekommt, mit der er dann recht wenig anfangen kann.

Ich habe vor kurzem ein nützliches Tool im Internet gefunden, welches genau bei dieser Problematik hilft - den Winmail Opener. Das kostenfreie Programm ermöglicht es, die
winmail.dat zu öffnen, deren Inhalte zu sichten und im Bedarfsfall auch abzuspeichern
(ähnlich wie ein Dateiarchiv).

Winmail Opener: Geöffnete winmail.dat

Das Programm lässt sich auch als Standard-Programm für alle .dat-Erweiterungen einstellen
(sofern man über ausreichende Rechte auf dem Windows-Rechner verfügt):

Winmail Opener: Als Standard einstellen

Dies hat den Vorteil, dass man dann direkt per Doppelklick auf eine solche winmail.dat sofort in dem Program landet und sich die Dateianhänge ansehen und ggf. woanders hin speichern kann.

Mehr zu dem Thema winmail.dat, und wie man es Outlook unter bestimmten Umständen auch ganz austreiben kann, solche Dateien überhaupt zu versenden, unter folgenden externen Blogs:

• How to Prevent Winmail.dat Attachments from Being Sent in Outlook
• Outlook: Winmail-Dat-Problem