In einer Teamviewer Session bekam ich beim übertragen der Datei, den Hinweis, dass es ca. 357.020 Jahre dauern wird bis die Datei übertragen ist
Das Ganze obwohl der Fortschrittsbalken zügig voran geschritten ist. Das Ganze hatte wirklich nur 25 Sekunden gedauert und ich musste mich sputen das Bild einzufangen.

Berechnungen über die Dauer von Operationen führen immer wieder zu erstaunlichen Ergebnissen in unserer Branche…

Was nun? Ja wenn man genau wüsste wie die selbe Meldung in englisch lautet, besonders wenn man keine Fehlernummer oder keine ID aus dem Ereignisprotokoll hat…

Die Lösung für MSDN Nutzer ist einfacher als man denkt:
Es gibt die Glossaries, d.h. die entsprechenden Übersetzungstabellen komplett zum Download

In der entsprechenden ZIP-Datei befinden sich 276 csv Dateien mit allen möglichen Produkten. Das schließt die Windows Server Produkte ein, wie auch VisualStudio.
Alleine die Windows 7 Datei umfasst 56 Megabyte an Texten.

In der letzten Zeit hatte ich schon das Gefühl, dass der erste Kontakt zum TFS ziemlich langsam war, bzw. auch das erste Speichern eines Tasks, oder Bugs.

Vor einigen Tagen dann bekam ich eine Meldung, dass kein Backup mehr durchgeführt wurde.
Eine Analyse ergab, dass auf dem TFS mit einem 100GB Raid5 Laufwerk nur noch 200MB frei waren. Eine Suche ergab, dass sich im Verzeichnis C:\Programme\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\12\LOGS\ weit über 22GB an Daten angesammelt hatten.

Eine weitere Analyse ergab, dass alle 15 Sekunden ca. 4000 Zeilen mit dem folgenden Text erzeugt wurden.

Alle 15 Sekunden ca. 4000 Einträge

11/02/2009 11:59:14.87  OWSTIMER.EXE (0x0F30)                    0x049C Windows SharePoint Services    Timer                          5uuf Monitorable Die vorhergehende Instanz des Timerauftrags ‘Config Refresh’, ID {0CA4803D-1621-49F4-BEFC-1BA2B441AC28} für den Dienst ‘{8B6CADF9-8ECE-409C-8D32-E336A5564C04}’ wird noch ausgeführt. Die aktuelle Instanz wird deshalb übersprungen. Sie sollten eine Vergrößerung des Intervalls zwischen den Aufträgen in Erwägung ziehen.

Einiges suchen im Internet ergab, dass ich nicht alleine an diesem Problem leide. Es gibt sogar einen KB Artikel dazu: http://support.microsoft.com/kb/941789/en-us/

Letzten Endes kann man die Warnungen unterdrücken, indem man den Logging Level verändert. Das geht einmal wie beschrieben über die SharePoint 3.0 Central Administration. Aber weitaus einfacher geht es auch über die Befehlszeilentools.

stsadm -o setlogginglevel -category timer -tracelevel unexpected 

Das ganze kostet aber immer noch einiges an Performance, denn dies unterdrückt nur die Protokollierung des Problems. Ein Refresh des Caches ist aber wirklich nicht alle 15 Sekunden notwendig, wie es die Standardeinstellungen vorsehen. Den Prozess alle 5 Minuten laufen zu lassen langt auch.
Das erreichen wir durch:

stsadm -o setproperty -propertyname job-config-refresh -propertyvalue "Every 5 minutes between 0 and 59"

Die entsprechende Doku dazu findet sich hier:
http://technet.microsoft.com/en-us/library/cc424971.aspx
http://technet.microsoft.com/en-us/library/cc261740.aspx

Die Standardwerte kann man wieder setzen durch die Befehle:

stsadm -o setlogginglevel -default -category timer
stsadm -o setproperty -propertyname job-config-refresh -propertyvalue "Every 15 seconds"

Ich hatte zu dem Problem auch den Microsoft Support bemüht, allerdings erfuhr ich hier auch nicht mehr, als ich selbst schon ermittelt hatte. Allerdings wurde mir angedeutet, dass es zu diesem Problem auch einen “noch” inoffiziellen Fix gibt. Mal sehen ob sich hier mal noch etwas tut.

Mein fix behebt zumindest das Problem mit den extrem vielen Log-Datei Daten- Und auch die Performance des TFS ist wieder etwas besser geworden, nachdem der entsprechende Timer Job nur noch alle 5 Minuten läuft.

Weitere Links zu OWSTIMER und den Timer Jobs des Sharepoint 3.0

• SSP and OWSTIMER Service – Hob Description Used for Synchronisation
  http://blogs.msdn.com/gregmcb/archive/2008/03/05/ssp-and-owstimer-service-job-descriptions-used-for-synchronization.aspx
• SharePoint Timer Job Reference
  http://technet.microsoft.com/en-us/library/cc678870.aspx
• Best Practices: SharePoint Timer Jobs
  http://www.alexbruett.net/?p=69

Ich war extrem überrascht welche Aufmerksamkeit dieser Artikel erregte. Das ging so weit, dass ich weitere Kommentare blocken musste und in meinem überfüllten Email-Postfach zu einem Standardtext greifen musste für Leute, die nach der Case Id fragten.

Endlich ist ein offizieller Fix für den KB947319 verfügbar

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=95c94c9a-6aca-42fb-9679-3234f06c72f7

Im Updateverlauf steht folgendes:

Sicherheitsupdate für Microsoft Office Web Components (KB947319)
Installationsdatum: ‎13.‎08.‎2009 10:29
Installationsstatus: Fehlgeschlagen
Fehlerdetails: Code A95

Ich habe danach versucht den Hotfix direkt herunter zu laden und die office2003-KB947319-FullFile-DEU.exe auszuführen. In diesem Fall erhielt ich die Fehlermeldungen:

Fehler 2709: Ein internen Fehler ist aufgetreten.
(Global_PIA_OWC11 )

und

Sicherheitsupdate für Office Web Components 2003 (KB947319)
Das Update konnte nicht angewendet werden.

Das eigentümliche ist allerdings, dass Office 2003 auf diesen Rechner selbst nicht installiert ist.
Da dieses Problem konsequent auf einer einer ganzen Reihe von Rechner auftrat habe ich den MS-Support bemüht. Jetzt nach einigen Tagen sieht es so aus, dass das ganze an einer Installation der MS-Access 2003 Runtime liegt.
Auch die MS-Access 2003 Runtime wurde als Ziel für diesen Patch eingetragen obwohl diese gar nicht betroffen ist.
Ich zitiere einfach mal den MS-Support:

Das Update KB947319 besteht aus 2 MSPs, OWC10.MSP und OWC11.MSP. Beide haben unter anderem die Access Runtime 2003 als Target eingetragen. Allerdings hat die Access Runtime 2003 gar keine OWC11, sondern nur die OWC10, insofern scheitert OWC11.MSP mit der Fehlermeldung:
Error 2709. An internal error has occurred. (Global_PIA_OWC11 )

Error 2709 heisst: “The specified Component name (‘[2]‘) not found in Component table” was ja auch der Tatsache entspricht, denn die Komponente OWC11 ist ja tatsächlich nicht in Access Runtime 2003 enthalten.

Das Problem in diesem Fall ist, dass die Access Runtime 2003 in OWC11.MSP überhaupt als Target eingetragen ist. Das bedeutet für Sie zunächst einmal, dass trotz des Problems bei der Installation des Fehler im Moment kein  Sicherheitsrisiko besteht, durch den Umstand, dass OWC11.MSP in der Access Runtime 2003 nicht installiert werden kann, da es keine OWC11 gibt, die man updaten könnte.

Es geht momentan noch darum, dass KB947319 von der Patch Detection weiterhin als applicable angezeigt wird, solange der Patch für die OWC11.MSP bezüglich der Access Runtime 2003 einen Fehler zurückliefert.

Wir sind aktuell dabei, einen Regression Hotfix für diesen Patch zu beantragen.

Aktuell habe ich dieses Sicherheitsupdate ausgeblendet. Bis die Regression durch ist.

Nachtrag 07.09.2009:
Ich bitte davon abzusehen weiter nach Informationen bei mir persönlich nachzufragen. Ich werde über die Veröffentlichung eines öffentlichen Fixes zu gegebener Zeit berichten.
Man kann sich ohne Probleme selbst an den Microsoft Support wenden und seine Probleme bzgl. des KB947319 schildern. Die Probleme sind hinlänglich bekannt und sofern die Indikatoren übereinstimmen sollte man auch einen provesorischen Fix vom Microsoft Support erhalten können.

Mit Datum vom 07.09.2009 sperre ich weitere Kommentare.

Nachtrag 26.10.2009
Endgültiger Fix für die Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95

Es ist nicht ganz so wie Live Meeting und kann auch nicht alles was Live Meeting kann (Voice Übertragung, Aufzeichnung etc.). Und die Geschwindigkeit ist auch nicht soooo der Kracher.
Aber Microsoft Shared View ist auf jeden Fall für mich eine heiße Entdeckung und ein Tipp für all diejenigen, die evtl. auch mal dem/der 80 jährigen Vater/Mutter am PC Remote unterstützend unter die Arme greifen wollen, weil der was am PC nicht versteht und gerade keinen NetViewer oder Live Meeting Account haben und es erscheint mir einfacher und effektiver als die Windows Remoteunterstützung.

Hier ein paar Features und Möglichkeiten:

• Jeder Nutzer entscheidet welche Programme er freigibt, oder ob er gar (für einen Supportfall) den ganzen Desktop freigibt. Nicht nur derjenige, der die Session gestartet hat.
• Jeder Nutzer verfügt automatisch über die Steuerung seiner freigegebenen Anwendung oder des freigegebenen Desktops.
• Es ist möglich das jeder Sitzungsteilnehmer die Steuerung anfordern kann, sodass man aktiv beitragen und eingreifen kann.
• Derjenige, der die Freigabe gestartet hat, erhält automatisch die Steuerung wieder wenn er mit der Maus klickt oder eine Taste auf der Tastatur betätigt.
• Jeder Teilnehmer hat einen personalisierten Mauszeiger, mit dem er auf Bereiche hinweisen oder auch Bereiche hervorheben kann – ideal geeignet, um jeden Teilnehmer einzubeziehen und sicherzustellen, dass keine Details übersehen werden.
• Und es gibt ein weiteres praktisches Feature: jeder Teilnehmer kann so genannte “Handzettel” bereitstellen. Das sind einfach Dateien, die sich andere Teilnehmer sofort herunterladen können.
• SharedView integriert sich in den Messenger
• …

Mehr hier unter diesem Link:
http://www.connect.microsoft.com/site/sitehome.aspx?SiteID=94

Es lohnt sich wirklich einen Blick auf dieses Stück Software zu werfen

In den letzten zwei Jahren hat sich bei mir ein klarer Favorit heraus gebildet:
Acronis in Verbindung mit meiner externen 500GB Festplatte.
In der Firma setzt ich Acronis True Image Echo Workstation ein. Zu Hause auf meinem Desktop und Laptop Acronis True Image Home Version 11. Beide Versionen unterstützen natürlich Vista.

Speziell die Home Version bekommt von mir die Note 1+. Die knappen Euro 50,– die das Programm kostet sind wirklich gut angelegt.

Es ist extrem einfach komplette Backups zu ziehen sind und die auch wirklich einfach zu verwenden sind wenn mal was zu restaurieren ist, man öffnet sie einfach im Explorer als Pseudo-Laufwerk. Differenzielle Backups (die ich bevorzuge) und inkrementelle Backups sind auf DiskImage Ebene möglich. D.h. man kann jederzeit auch seinen ganzen Rechner sofort wieder auf einen zuvor gesicherten Stand bringen. Zum Glück habe ich das noch nicht benötigt.
Durch eine versteckte Partition (Secure Zone), kann man auch das entsprechende Recovery-Modul direkt installieren. Oder aber man erzeugt sich ein bootbares Medium (CD). USB Laufwerke werden in diesem Recovery Modus erkannt und bedient. Für mich sind das die elementar wichtigen Dinge die ich von einem Backup Programm erwarte.
Darüber hinaus bietet die Acronis Software noch einiges mehr. Besonders Try&Decide hat es mir hier angetan. Einfach erstmal Software im Probiermodus testen, bevor Änderungen tatsächlich am System durchgeführt werden.

Einziger Wermutstropfen ist mein Rechner in der Firma mit einem Intel SATA-Raid Controller. Bei diesem funktioniert das entsprechende Recovery Modul nicht.

Ich habe in den letzten Wochen zig-Fehler in den Compilern und Libraries von VC gefunden. Das fängt mit VC-2003 an und den hier geschilderten Fehlern in der MFC (siehe CPropertyPage Bug).
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=270493

Dann habe ich schon mehrere Bugs in VC-2005 gefunden. Unter andrem einige Probleme mit Attributed ATL.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98753
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=275256

Oder auch Fehler im Resource Compiler in allen VC-Versionen.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252616

Ganz zu Schweigen von so netten Sachen wie nicht funktionierende MT.EXE etc.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=258108 

Diese Liste ist bei weitem nicht vollständig, sondern zeigt nur die Erfahrungen der letzten beiden Monate. Ganz schweigen möchte ich von den Bugs, bei denen ich mich eingemischt habe, weil ich sie bestätigen konnte.

Meine Erfahrungen der letzten Zeit machen mich absolut frustig:

1. Extrem viele Bugs werden einfach so geschlossen als “Nicht reproduzierbar”
2. Bugs werden geschlossen ohne auch nur einen Kommentar!
3. Bugs aus VC-2003 werden grundsätzlich abgewiesen, wenn sie in VC-2005 gelöst sind. Meistens werden sie als “nicht reproduzierbar” gekenzeichnet.
4. Bugs aus VC-2005 werden auch nicht mehr angenommen, wenn diese in Orcas gefixt sind. Meistens werden auch sie als “nicht reproduzierbar” gekenzeichnet.
5. Ideen, werden oft sofort abgetan, erst wenn man etwas mehr Druck als MVP dahinter legt (was ein normaler User nicht kann), wird etwas mehr darüber nachgedacht.
6. Liefert man einen Workarround zum Bug eines anderen, wird der Bug oft sofort als gelöst geschlossen.

Stellt sich die Frage: Was gehört denn nach Connect?
Na es gibt ja eine Beschreibung. Auf der Seite: https://connect.microsoft.com/availableconnections.aspx
lesen wir zumindest noch folgenden Text:

Bleibt aber die Frage warum VC-2003 und VC-2005 nicht mehr in diese Kategorie zu fallen scheinen. Ist also nur noch das neueste VC (also Orcas) das eigentliche VC, selbst wenn sich das noch in der Beta befindet?

Für was ist also http://connect.microsoft.com noch gut?

Scheinbar weiß bei Microsoft selbst auch niemand so genau, welche Bugs bei Connect eigentlich eingereicht und wie bearbeitet werden dürfen. Aktuell habe ich eine Anfrage laufen, die klären soll, welche Policy eigentlich hinter Connect steht.

Mein Rat: Verwendet den direkten Weg über den Support. Als MSDN-Abonnement  hat man einige Support-Anfragen frei. Als Certfied Partner 5. Nutzt diese, alles andere scheint aktuell eher Zeitverschwendung und bringt einen nur zur Weißglut.

Es ist frustig, frustig, frustig…