Vista


SoftwareToolsVistaMartin Richter - Di 01 Mrz 2011 19:53

Seit Wochen klagten unsere Damen vom Vertrieb, dass Ihre Warenwirtschaft (Sage Office Line 4 – 2010)extrem langsam startet. Bis zu einer Minute wird für den Start benötigt. An unseren Rechner (Alles Quadcores mit Minimum 3GB und Vista) kann es nicht liegen.
Ich habe mich mit dem ProcessMonitor auf die Suche gemacht konnte aber eigentlich nichts auffälliges feststellen.

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.

ProgrammierenSoftwareVistaVista / Windows 7Windows 7Windows APIMartin Richter - Fr 21 Jan 2011 20:05

Es waren einmal die Zeiten in denen man in C:\WINDOWS\TEMP einfach mal eine Datei anlegen konnte und jeder darauf zugreifen konnte.
Seit Windows Vista hat sich ja einiges getan was Sicherheit betrifft, besonders auch die Rechtevergabe auf Dateien, die im C:\Windows\Temp Ordner angelegt werden.

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.

C++CommunityProgrammierenSoftwareVistaWindowsWindows 7Martin Richter - Di 19 Okt 2010 13:53

Seit Windows Vista ärgere ich mich über die Anzeige der Datei-Eeigenschaften.
Bei ausführbaren Dateien gibt es nicht mehr den schönen Versionsinfo Dialog aus XP, sondern eine Detailseite, die nicht auf den ersten Blick alle Infos liefert die man als Entwickler möchte. Zudem unterschlägt die Seite noch einiges Wissenswerte.

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!

ProgrammierenSoftwareVistaVista / Windows 7WindowsWindows 7Windows APIMartin Richter - Do 16 Sep 2010 20:03

Jeder kennt von Windows Vista und Windows 7 die Junctions „C:\Programme“ oder „C:\Dokumente und Einstellungen“.
Diese Verweise erlauben es auch älteren Programmen die evtl. hardcodierte Verzeichnisnamen haben oder auch Programmen, die die alten Verzeichnisstrukturen von Windows 2000 und XP nutzen korrekt zu arbeiten.

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.

OfficeProgrammierenSoftwareSupportVistaVista / Windows 7WindowsWindows 7Martin Richter - Sa 21 Aug 2010 10:16

 Wer kennt das nicht: Da hat man ein deutsches Microsoft-Produkt und bekommt eine Fehlermeldung, auf die Google nichts ausspuckt. Scheinbar ein seltener Fehler. Oder evtl. benutzen viel mehr Anwender die englische Version eines Entwicklerproduktes.

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.

SoftwareVistaWindowsWindows 7Martin Richter - Mo 10 Mai 2010 20:50

Auf meinem Windows Server 2003 R2 haben sich in der letzten Zeit Fehlereinträge im Eventlog für die Sicherheit angehäuft. Und das bis zu 200 Einträge und mehr täglich.

Bei der Analyse stieß ich hauptsächlich auf die Ereigniskennung 675 mit dem Fehlercode 0x19. 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 0x1)
  • DES-CBC-MD5 (Registrycode 0x3)
  • RC4-HMAC (Registrycode 0x17)
  • AES (Registrycode 0x12) 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 0x17 (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 0x17 (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

SoftwareVistaWindows 7Martin Richter - Do 07 Jan 2010 08:20

Alleine der Name macht einen ja schon neugierig…

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

SoftwareVistaWindowsWindows 7Martin Richter - So 13 Dez 2009 21:58

Jetzt wo sich Windows 7 langsam immer weiter verbreitet werden manche Benutzer feststellen, dass Windows 7 so viel anders als Vista nicht ist.
Insbesondere wenn es um Probleme mit älterer Software geht.
Ja es gibt den XP-Modus unter Windows 7, aber manchmal geht es eben doch mit ein paar Tricks und man die Software richtig installieren ohne XP-Mode-Overhead.

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:

Installation unter Vista Windows 7-1

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:

Installation unter Vista Windows 7-2

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.

InstallationSoftwareVistaWindowsWindows 7Martin Richter - So 01 Nov 2009 20:48

Nachdem ich vor einigen Tagen ein Update auf meinen Vista Rechner auf Windows 7  durchgeführt habe, sind mir zwei versteckte Ordner im Rootverzeichnis auf meiner Festplatte aufgefallen, die nicht klein sind.

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:

Datenträgerbereinigung

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

Anhaken und Schwupps sind 3GB mehr Plattenplatz da…

SoftwareVistaWindowsWindows 7Martin Richter - Sa 10 Okt 2009 23:00

Meinen neuen Samsung Laptop, den ich vor ca. 2 Monaten gekauft habe, wurde gleich platt gemacht und mit Windows  7 versehen.
Ich musste nicht einen Treiber nachinstallieren. Alles hat Windows 7 selber erkannt und es lief alles weitaus glatter als erwartet.

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 ❗

Nächste Seite »