Dann bin ich auf die Idee gekommen mal unsere Antiviren Software (Symantec Endpoint Protection) auszuschalten. WOW… Die OfficeLine startet in nicht weniger als 3 Sekunden

Jetzt habe ich einfach die beiden Dateien “C:\Program Files\Sage\Office Line\4.2\Abf\OLABF_001.ADE” und “C:\Program Files\Sage\Office Line\4.2\Rewe\OLREWE_001.ADE“, der Warenwirtschaft bzw. des Rechnungswesen durch eine extra Regel in der Endpoint Protection ausgenommen und siehe da alles gut.

Die Endpoint Protection kenne ich sonst nicht so als Systembremse, aber wie man sieht lohnt sich manchmal ein kritischer Blick auf das eigene AV System.

Ein Programm  im Rentenalter (es ist gerade mal so um die 16 Jahre alt geschätzt) erzeugte in C:\WINDOWS\TEMP eine Datei, mit der bestimmte Zugriffe abgesichert wurden. Darunter auch wenn mehrere Instanzen des Programms auf einem Rechner liefen. Das funktionierte prima. Die Datei wurde unter einem festen Namen angelegt und nicht entfernt, nachdem das Programm beendet wurde.

Seit Vista gibt es aber nun ein kleines Problem.:
Seit Windows Vista darf in C:\WINDOWS\TEMP immer noch jeder User Dateien erzeugen. Auf diese Dateien hat er auch vollen Zugriff. Aber auf diese Dateien hat kein anderer Nutzer mehr Zugriff… … und selbst ein Admin muss erst hier erst den Besitz übernehmen, wenn er die Datei nicht erzeugt hat.

Und nun hat diese kleine alte Programm den folgenden Effekt:

• Benutzer A meldet sich an.
• Benutzer A startet das Programm Er arbeitet damit und die temporäre Datei wird in C:\WINDOWS\TEMP angelegt.
• Benutzer A meldet sich ab und beendet das Programm.
• Benutzer B meldet sich an.
• Benutzer B startet das Programm und … bekommt eine Fehlermeldung mit einem “Access denied!”.

Mit den neuen Rechten, die auf dem C:\WINDOWS\TEMP Verzeichnis liegen, kann der zweite Benutzer auf diese Datei nicht mehr zugreifen auf die eben nur der Erzeuger Zugriff hat, und der ist eben Benutzer A.

PS: Es Frage mich keiner warum C:\WINDOWS\TEMP aus GetWindowsDir und angehängtem Text TEMP zusammengesetzt wurde. Vermutlich um zu umgehen, dass ein privates temporäres Verzeichnis benutzt wird. Tja und CSIDL_APPDATA war dem damaligen Entwickler (evtl. noch unter Windows 3.1) nicht bekannt.

Jetzt hat “Fish” David B. Trout auf Codeproject eine Extension bereit gestellt, die die alte Versionsinfo wieder in den Explorer integriert.
Das Addin ist zwar nicht lokalisiert und zeigt die internen VERSIONINFO Tags an, aber das ist eigentlich kein Problem.

http://www.codeproject.com/KB/shell/VersInfoEx2.aspx

My vote: 5!

Jetzt könnte man meinen, dass es vollkommen egal ist ob man nun “C:\Programme” oder “C:\Program Files” benutzt.
Aber das ist es nicht Es gibt ein paar ganz feine Unterschiede.

Ein simpler DIR auf der Befehlszeile

C:\>dir C:\Programme
 Datenträger in Laufwerk C: ist C-LAPTOP
 Volumeseriennummer: D483-432C
 
 Verzeichnis von C:\Programme
 
Datei nicht gefunden

macht das Problem offensichtlich!
Und was geht hier ab?

Die Antwort liefert ICACLS für die Junction:

C:\>icacls C:\Programme
C:\Programme Jeder:(DENY)(S,RD)
             Jeder:(RX)
             NT-AUTORITÄT\SYSTEM:(F)
             ORDEFINIERT\Administratoren:(F)

Dagegen zeigt ICACLS für das Verzeichnis selbst

C:\>icacls "C:\Program Files"
C:\Program Files NT SERVICE\TrustedInstaller:(F)
                 NT SERVICE\TrustedInstaller:(CI)(IO)(F)
                 NT-AUTORITÄT\SYSTEM:(M)
                 NT-AUTORITÄT\SYSTEM:(OI)(CI)(IO)(F)
                 VORDEFINIERT\Administratoren:(M)
                 VORDEFINIERT\Administratoren:(OI)(CI)(IO)(F)
                 VORDEFINIERT\Benutzer:(RX)
                 VORDEFINIERT\Benutzer:(OI)(CI)(IO)(GR,GE)
                 ERSTELLER-BESITZER:(OI)(CI)(IO)(F)

Während man auf “C:\Program Files” die Rechte sieht, die man auch erwartet, liegt auf der Junction selbst eine Einschränkung:
Die Berechtigung zum “Ordner Auflisten” wird verweigert für “Jeder”
Jeder der neu eingeführten Junctions hat diese Einschränkung.

Meines Erachtens wurde dies gemacht um beim Durchsuchen von Verzeichnisstrukturen nicht unendliche Rekursionen zu erzeugen oder Verzeichnisse oder Dateien doppelt aufzuführen.
Eine Verzeichnis Rekursion ergäbe sich zum Beispiel durch die Junction Anwendungsdaten im Verzeichnis C:\Users\Username\AppData\Local, der exakt wieder auf das Verzeichnis C:\Users\Username\AppData\Local verweist.

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.

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

Was verbirgt sich dahinter?
Nichts anderes als eine Explorer Ansicht, die alles aus den Systemsteuerungspanels in einer Liste anzeigt. Nett…

Wie macht man das?

1. Man legt auf dem Desktop (oder sonst wo) ein neues Verzeichnis an.
2. Dieses Verzeichnis benennt man dann um in GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
   Wobei der Name vor dem Punkt keine Rolle spielt. Es geht nur um die Extension und die GUID.
3. Fertig! Das Symbol verändert sich dann auf das Symbol der Systemsteuerung.

Gefunden in: Understanding Windows 7′s ‘GodMode’

Nachtrag 1: Das Ganze geht sogar unter Vista 32bit!
Nachtrag 2: Es gibt Meldungen, dass dieser Link auf dem Desktop eines Vista 64bit Systems den Explorer zum Absturz bringt!
Evtl. sollte man den Ordner testweise in diesem Fall erstmal in einem Unterordner anlegen.
Nachtrag 3: Auch Kay Giza berichtete ausführlich über diesen Modus, ich hatte dies allerdings übersehen.
http://www.giza-blog.de/Windows7VistaErweiterteSystemsteuerungAktivierenED7BA4708E54465E825C99712043E01C.aspx

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.

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…

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