Bei der Analyse stieß ich hauptsächlich auf die Ereigniskennung 675 mit dem Fehlercode 0×19. Meistens traten diese Eventlog Einträge im Viererpack auf, immer wenn ein Benutzer sich mit seinem PC im Netz angemeldet hat. Jeweils erschienen dann Einträge für den PC und den Benutzer, wie die nachfolgenden Beispiele beiden Beispiele aus dem Ereignisprotokoll meines Servers zeigen:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:33
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: COMPUTER$
  Benutzerkennung: DOMAIN\COMPUTER$
  Dienstname: krbtgt/domain.loc
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

sowie:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:52
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: Martin
  Benutzerkennung: DOMAIN\Martin
  Dienstname: krbtgt/DOMAIN
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

Nach einiger Recherche kam ich dahinter, dass dies nur Arbeitsplätze betraf, die Windows Vista oder Windows 7 einsetzten. Rechner mit Windows XP oder Windows 2003 Server tauchten hier nie auf.

Ein wenig weiteres Forschen brachte mich dann auf die Ursache:

Diese Event Id wird ausgegeben wenn, der Domänencontroller den Kerberos-Authentifizierungsversuch eines Rechners nicht versteht. Das nur Windows Vista und Windows 7 Rechner als Verursacher auftauchen liegt daran, dass mit Windows Vista AES (Advanced Encryption Standard) als Verschlüsselungsverfahren von den Clients bevorzugt wird.
Leider kennt aber der Windows 2003 Domänen-Controller dieses Verfahren noch nicht. Weil es aber einen Fallback auf das RC4-HMAC Verfahren gibt merkt der Anwender nichts davon.

Windows Systeme unterstützen die folgenden Verschlüsselungsverfahren für Kerberos:

• DES-CBC-CRC (Registrycode 0×1)
• DES-CBC-MD5 (Registrycode 0×3)
• RC4-HMAC (Registrycode 0×17)
• AES (Registrycode 0×12) Wird seit Windows Server 2008 unterstützt (d.h. auch Vista und Windows 7)

Die Standard Preauthentifizierung erfolgt bei Windows 2000, Windows Server 2003, Windows XP immer RC4-HMAC.

Die Lösung ist ein kleiner Workaround in dem man einfach dem Vista oder Windows 7 Rechner mitteilt er soll doch einfach auch die RC4-HMAC Verschlüsselung wählen. Das verhindert dann die Nutzung von AES  und die Fehler sind weg, die durch den vergeblichen AES Anmeldeversuch entstehen.
Das erreicht man in dem man den Code 0×17 (siehe Aufzählung oben) für den DefaultEncryptionType einträgt. Nachfolgend der entsprechende Auszug aus der REG-Datei, die ich auf die Clients verteilt habe.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"DefaultEncryptionType"=dword:00000017

Oder in anderen Worten gesagt:

• Man startet Regedit an den betroffenen Clients
• Man wählt den Ast HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Parameters
• Dort erzeugt man einen DWORD Wert mit Namen DefaultEncryptionType
• In diesen Wert setzt man 0×17 (bzw. 23 dezimal) ein

Nun ist Ruhe mit diesem Fehler

Weitere Links zum Thema Kerberos hier:
http://technet.microsoft.com/en-us/library/cc738673(WS.10).aspx
http://tools.ietf.org/html/rfc4757

Themenverwandte Beiträge:

• Windows Integrity Control: Schreibzugriff auf eine Named Pipe eines Services über anonymen Zugriff auf Vista, Windows 2008 Server und Windows 7 (2)
• Upgrade meines privaten Desktop PCs auf Windows 7 (0)
• Nett: Windows 7 und sein GodMode ;) (4)

Meine Software macht nun folgendes:

• Zuerst hat meine Ladeprozedur für die Daten, zuerst alle Controls erzeugt, oder überflüssige vernichtet und positioniert, oder evtl. nur ausgeblendet (ShowWindow(SW_HIDE). D.h. nach dem ersten Laden der Daten ändert sich am Layout evtl. nichts mehr.
• Anschließend wurde an alle Controls CWnd::SetRedraw/WM_SETREDRAW mit FALSE gesendet.
• Dann die Daten geladen.
• Nach dem Laden wird einfach wieder CWnd::SetRedraw/WM_SETREDRAW mit TRUE gesendet und ein Invalidate durchgeführt.

Das funktioniert für alle Controls, mit einer Ausnahme: Das RTF Control. Wenn man WM_SETREDRAW TRUE an ein RTF Control sendet, das nicht sichtbar ist, dann wird dieses sichtbar. Der Stil WS_VISIBLE wird also verändert.

Um das Problem zu isolieren habe ich hier ein kleines Testprogramm geschrieben. Der kritische Code sieht so aus. Das gesamte Projekt kann man hier auch herunterladen: Demoprojekt.

void CTestRTFSetRedrawDlg::OnBnClickedBtDoit()
{
 bool bWasVisible = (m_wndEdRTF.GetStyle() & WS_VISIBLE)!=0;
 m_wndEdRTF.SetRedraw(FALSE);
 m_wndEdRTF.SetWindowText(_T("Line 1\r\nLine 2\r\nLine 3\r\nLine 4"));
 m_wndEdRTF.SetSel(0,0);
 m_wndEdRTF.SetRedraw(TRUE);
 m_wndEdRTF.Invalidate();
 bool bIsVisible = (m_wndEdRTF.GetStyle() & WS_VISIBLE)!=0;
 
 // Check if the visible state changed
  if (bIsVisible!=bWasVisible)
  AfxMessageBox(_T("The visible state of the RTF control changed!"));
}

Nachtrag 16.01.2010 (Danke Sven für Deinen produktiven Kommentar):
Auch andere Controls wie Button-, Static- und Edit-Controls verändern den Visible Status wenn WM_SETREDRAW angewendet wird. Einzig Listbox- und Combobox-Controls behalten den Visiblestatus korrekt bei

Themenverwandte Beiträge:

• LVM_GETSUBITEMRECT mit LVIR_ICON liefert andere Ergebnisse unter Vista als unter XP (5)
• Aus zwei mach eins: Wie man zwei Cursor kombinieren kann (5)
• Wie man den Namen einer RegisterWindowMessage bekommt (0)

Ich habe die Erfahrung gemacht, dass die Virtualisierung durch UAC einiges leistet und dafür sorgt das einiges an Software unter Vista und Windows 7 laufen kann.
Ansonsten kann man manchmal nachhelfen, wenn man dem Programmen auf die entsprechenden Ordner in Program Files und HKLM in der Registry die Rechte für einen normalen Benutzer auf Vollzugriff setzt.
Ich mache dies nur für die Teiläste dieses Programmes, insofern kein allzu großes Sicherheitsrisiko, aber es wirkt oft Wunder. Unter XP habe ich damit ältere Siedler Versionen zum Laufen gebracht ohne das man Administrator sein musste

Leider gibt es aber auch Fälle in denen die Software schon die Installation verweigert. Auch hier kann man manchmal auf einem XP Rechner installieren und dann die Software kopieren.
Aber es gibt auch hier Tricks, wenn einfach nur die Versionnummer falsch geprüft wird (was leider ziemlich oft passiert).

In meinem Beispiel war es RC-WinTrans, dass die Installation schon unter Vista verweigert hat.
Ein Blick mit Orcas in die MSI Datei zeugt eine falsche Versionsprüfung:

Unschwer zu erkennen, dass hier explizit auf die unterstützten Versionen geprüft wird und die Version 6.x für Vista und Windows 7 eben nicht durch diesen Test abgedeckt sind.

Mit Orcas ist das schnell geändert:

Und siehe da. Nicht nur die Installation läuft einfach und glatt.
Die ganze Software arbeitet perfekt unter Vista und Windows 7.

BTW: Wenn man eine EXE hat, die die Installation ausführt, dann kann man versuchen über den Karteireiter Eigenschaften der EXE Datei, den Kompatibilitätsmodus auf Windows XP SP2/SP3 zu setzen. Auch dann gelingt einem oft die Installation selbst wenn eine falsche Versionsnummer intern im Setup geprüft wird.

Themenverwandte Beiträge:

• Nett: Windows 7 und sein GodMode ;) (4)
• Mein “Baby” ist nun “Kompatibel mit Windows 7″ (2)
• Windows Integrity Control: Schreibzugriff auf eine Named Pipe eines Services über anonymen Zugriff auf Vista, Windows 2008 Server und Windows 7 (2)

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 (0×0F30)                    0×049C 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

Themenverwandte Beiträge:

• Zwei Tools, die die interne Kommunikation über den TFS noch einfacher machen… (0)
• VS Tipps & Tricks: Ganze Solutions zu einer Master-Solutions zusammenfügen (4)
• Tipps & Tricks:TFS Undo Checkout für einen anderen Anwender/Workspace erzwingen… (1)

Durch eingeschränkte Rechte hat man normalerweise keinen Zugriff, aber wenn man eine elevated Session mit dem Explorer startet kann man herausbekommen was sie beinhalten:

$WINDOWS.~Q    2200 MB (2.364.075.683 Bytes)
$INPLACE.~TR    471 MB (  494.284.806 Bytes)

Die Dateien in diesem Ordner schienen auf den ersten Blick irgendwas mit dem Update zu tun zu haben.

• Der erste Schritt: Mal in der Systemsteuerung nachsehen ob man dort etwas deinstallieren kann. Nada.
• Zweiter Blick: Starten der Datenrägerbereinigung. Auch nichts auffälliges.
• Dritter Versuch: Starten der Datenträgerbereinigung als Administrator. Bingo

Siehe da:

Zwei Dateigruppen finden sich:
Beim Window-Upgrade verworfene Dateien – und -
Protokolldateien für Windows-Upgrades

Anhaken und Schwupps sind 3GB mehr Plattenplatz da…

Themenverwandte Beiträge:

• Windows Integrity Control: Schreibzugriff auf eine Named Pipe eines Services über anonymen Zugriff auf Vista, Windows 2008 Server und Windows 7 (2)
• Vista: Wo ist bitte die Option “Unterstrichene Buchstaben für Tastatur Navigation ausblenden” geblieben (4)
• Upgrade meines privaten Desktop PCs auf Windows 7 (0)

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

Themenverwandte Beiträge:

• Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95 (17)
• Was denn nun SwitchToThread(), Sleep(0), Sleep(1)? (2)
• VS-Tipps & Tricks: Springe zur nächsten Klammer funktioniert auch für #if, #elif, #else und #endif (1)

Kurz danach noch einige andere Meldungen und abschließend diese:
Snap-In konnte nicht initialisiert werden.

Am ISA-Server lag es nicht, denn mein Kollege konnte die ISA-Server Console, sofort starten. Also musste es mit meinem Account zusammenhängen.

Nach einigen Googeln fand ich die Lösung. Das Problem war die Managment Console selbst.
In der Registry werden bestimmte Daten zwischengespeichert. Und da schien etwas kaputt gegangen zu sein. Man kann diese Daten jedoch einfach löschen über Datei -> Optionen kommt man in die Datenträgerbereinigung. Dort einfach Dateien löschen auswählen und die abschließende Frage mit Ja beantworten und das war es.

Themenverwandte Beiträge:

• Keine themenverwandten Beiträge gefunden!

Heute habe ich den Mut gefasst und meinen privaten Desktop PC von Vista Ultimate 32bit auf Windows 7 Ultimate upzugraden. Kurz zuvor hatte ich mit meinem schönen Acronis Home 2010 noch ein Backup gemacht. Ohne würde ich es nicht wagen.
Und zuvor habe ich natürlich mit dem Upgrade Advisor geprüft ob es irgendwelche Probleme eben wird, dem war nicht so.
Zu einer Neuinstallation fehlt mir einfach die Muße, bis alles wieder läuft würden Stunden vergehen. Also wage ich das Upgrade!

Kurz vor dem Länderspiel um 17:00 habe ich das Setup gestartet, um ca. 21:45 war das Upgrade durch.

Gleich zu Anfang beschwerte sich das Setup über drei Programme:

• Adobe Reader 7 (der definitiv nicht auf meiner Maschine war)
• iTunes (mit dem ich die Musik für meinen IPod verwalte)
• VMWare (mein ultimatives Testtool)
• Cannon-EasyLayout Print (gehört zu meinem Drucker)

Windows 7 Update hatte mir empfohlen die Programme zu deinstallieren. Ich habe die Hinweise einfach ignoriert, denn alle drei Programm sind für mich nicht lebenswichtig und lassen sich nachinstallieren.

Da ich einige sehr große Dateien auf dem Rechner habe (ISO-Images etc.) hatte ich manchmal zwischendrin ganz schön Bammel ob das Setup durchläuft. Zwischendrin blieb die Prozentzahl der Fortschrittanzeige ziemlich oft und lange auf einem Wert stehen (10 Minuten lang).

Irgendwann war es so weit und ich konnte mich anmelden und … Spannung
Keine Probleme. Alles läuft auf Anhieb
Alle Treiber, alle Geräte inklusive WLAN, WebCam, SD-Kartenleser, Videokarte usw. sind sofort betriebsbereit.
Gleiches gilt für alle Software, Acronis 2010 Home, ESET Antivirus, Office etc.

Erster Eindruck:

• Windows 7 läuft wirklich flüssiger und flinker. Eindeutig auch weniger Festplattenaktivität zu hören.
• Grundsätzlicher Hauptspeicher Bedarf etwa 8% weniger als unter Vista zuvor. Windows 7 will 44% meines Speichers gleich nach dem Start, Vista wollte 52%.
• Das Upgrade von Vista auf Windows 7 ist vollkommen schmerzfrei. Alles wurde 1a übernommen.
• Sich mit dem Windows 7 Heimnetzwerk anzufreunden macht Spaß!

Ich kann ein Update nur empfehlen

Themenverwandte Beiträge:

• Windows Integrity Control: Schreibzugriff auf eine Named Pipe eines Services über anonymen Zugriff auf Vista, Windows 2008 Server und Windows 7 (2)
• Nett: Windows 7 und sein GodMode ;) (4)
• Nach Windows 7 Upgrade einige GB an Plattenplatz freigeben (0)

Wer den IconWorkshop 6.5 noch nicht hat, der hat die Chance bis morgen den 31.08.2009 noch 50% Rabatt zu bekommen. Die Sommerrabatt Aktion gilt auch für alle anderen Axialis Produkte.

Alles weitere bei Axialis:
http://www.axialis.com/purchase/

Themenverwandte Beiträge:

• VeriSign ‘Microsoft Authenticode’ Class 3 Code Signing Digital Certificate für $99,– (0)
• Tipps & Tricks: Mal ganz schnell das MS-SQL Server 2008 Managment Studio Express nachinstallieren (1)
• Nett: Windows 7 und sein GodMode ;) (4)

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

Themenverwandte Beiträge:

• Endgültiger Fix für die Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95 (1)
• Was denn nun SwitchToThread(), Sleep(0), Sleep(1)? (2)
• VS-Tipps & Tricks: Springe zur nächsten Klammer funktioniert auch für #if, #elif, #else und #endif (1)