Windows – Martins Blog

Was nicht alles mit dem schönen alten CMD.EXE geht: Ein Verzeichnis mit dem Datum im Format YYYY.MM.DD anlegen

Man lernt nie, aus. In dem Fall betrifft es ein wenig die Batch-Programmierung mit CMD.EXE.

Für einen Batch, der einen Teil eine Datensicherung eines Hyper-V Servers machen sollte benötigte ich ein Verzeichnis mit dem Tagesdatum, aber im Format YYYY-MM-DD. %date war mir bekannt und auf unseren Rechner liefert das aber, DD.MM.YYYY.

Ein wenig Suche im Netz brachte mich zu Substring-Funktionen bei der Variablenersetzung, die ich noch gar nicht kannte. Hängt man hinter eine Variable Doppelpunkt und Tilde kann man Startposition und Länge eines Substrings angeben.

Entsprechend ist der Batch also ganz schnell geschrieben 😉 :

SETLOCAL
SET TargetDir=D:\BackupHyperV %date:~6,4%.%date:~3,2%.%date:~0,2%
MD "%TargetDir%"

Einen SBS 2003 außer Betrieb nehmen bzw. umziehen in eine „normale Dömanenstruktur“

Vor langer Zeit erschien es uns als gut einen SBS 2003 zu verwenden. OK. Es gibt Entscheidungen, die hat man getroffen und muss damit leben. Probleme gibt es eigentlich erst, wenn man alles anders machen will. 🙄

Wir wollten unseren SBS 2003 außer Betrieb nehmen und in eine normale Domäne umwandeln. Dazu alle Server virtualisieren etc. etc. Alles wurde neu eingerichtet, aber unser SBS 2003 war immer noch DER DC. Nachdem fast alle lebenswichtigen Dinge im Lauf der letzten Jahre und Monate schrittweise umgezogen waren, die mal auf der Kiste gelaufen sind (File-Server, Drucker-Server, Fax-Server, SQL-Sever, Exchange, RAS), blieb nur noch das AD übrig.

Nun einfach wäre es einen anderen Server als DC einzurichten kurz mal DCPromo aufrufen und gut ist es. Aber der SBS mag das ja gar nicht… 😳
Sobald der SBS einen anderen DC entdeckt, dauert es nicht lange und er fährt einfach herunter. Zuerst mal war ich etwas baff, als eine Kollegin sagte sie käme an ein paar alte Ordner nicht mehr heran. Als ich in den Server Raum ging musste ich feststellen, dass die Kiste einfach so ausgeschaltet herumsteht.
Ich rechnete mit Fehlermeldungen aber nicht mit einem brutalen Shutdown.
Dokumentiert ist das natürlich auch in der MSDN hier. ❗

Etwas Recherche im Netz brachte dann die vorübergehende Lösung, mit der ich bis zur kompletten Abschaltung dieses Servers weiterarbeiten konnte.
In Kürze geht man wie folgt vor:

Den Prozess C:\WINDOWS\system32\sbscrexe.exe mit dem Sysinternals Prozess Explorer suspenden. Abschießen geht nicht, denn der Prozess startet sich sofort neu.
Im Regedit dem Administratoren Rechte auf den Ast HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SBCore geben. Das geht auch nicht bei laufenden Dienst, denn der entzieht einem sofort die Rechte wieder.
Danach die Anzeige aktualisieren mit F5 damit die verborgenden Untereinträge sichtbar werden.
Nun das DWORD Start von 2 auf 4 ändern. Dadurch wird der Dienst deaktiviert und startet nicht erneut.
Neustart und das war es erstmal.

Die Beschreibung findet sich auch hier.

So das war Schritt 1 und nun ging es darum den AD von diesem Rechner zu entfernen.
Also mal eben wie geplant DCPromo aufgerufen um das AD von diesem Rechner zu entfernen. Es wäre zu schön gewesen, wenn das nun einfach gegangen wäre. DCPromo verweigerte den Dienst mit der folgenden Meldung:

Die Verwaltung der Netzwerksitzung mit Dem-Tollen-Neuen-Server ist fehlgeschlagen.
Das Netzlaufwerk ist nicht erreichbar. Weiter Informationen

😕 Ich hatte vergessen, das dieser Server immer noch einen DNS Dienst hatte und in den Einstellungen der Netzwerkkarte wurde dieser Server auch noch verwendet. Die Fehlermeldung ist natürlich nicht zielweisend, wie so oft leider. Nachdem ich den neuen DNS Server in der Netzwerkkarte eingetragen hatte lief der DCPromo klaglos durch und zurück blieb ein normaler Windows 2003 Server.

Nachdem auch die letzten Dateien gesichert bzw. umgezogen waren und der Streamer ausgebaut wurde steht da nur noch ein kilo-schwerer Schrotthaufen, der jahrelang klaglos seinen Job gemacht hat.

Fehlercode 9C47 auf einem Windows Server 2008 R2 x64 beim Update auf den IE 11

Bei einer Routinekontrolle stellten wir fest, dass einer unserer virtuellen Windows Server 2008 R2 keine Windows Updates mehr einspielte.
In der Anzeige des Windows Updates standen zwei Fehlercodes:

Fehlercode 9C47
- und -
Fehlercode 80072ee2

Auch das Wiederholen der Updates brachte nichts. Löschen der Download Verzeichnisse brache auch nichts. Auch das Ausblenden des Updates für IE 11 nützte nichts.
Teilweise konnte man manuell eines der ausstehenden Updates einspielen. Beim zweiten Update kamen aber meistens wieder entsprechend gleiche Fehler.

Als Ursache würde ich jetzt das Update für den Internet Explorer 11 ausmachen. Meistens wurden diese Fehlercodes auch in anderen Artikeln im Netz bei genau diesem Update gemeldet. Also habe ich versucht das Update manuell durchzuführen.

Dazu habe ich zuerst das IE 11 Installationspaket manuell heruntergeladen.
http://windows.microsoft.com/de-de/internet-explorer/ie-11-worldwide-languages

Der Installationsversuch meldete dann fast wie zu erwarten, dass Windows Updates ausstehen würden, die für die Installation des IE 11 Voraussetzung sind. Dazu ein Link auf diese Seite: http://support.microsoft.com/kb/2847882

Ich habe dann manuell jedes dieser Updates ausgeführt. Die ersten waren alle bereits installiert. Nur die letzten beiden fehlten, ließen sich aber problemlos installieren. Danach erfolgte ein Neustart und dann lies sich auch der IE 11 mit dem heruntergeladenen Installationsprogramm installieren und danach funktionierte auch Windows Update wieder korrekt und installierte die verbleibenden ausstehenden Updates.

Windows 8.1 und der Leistungsindex

Ich habe den Leistungsindex eigentlich gemocht. Auch wenn Hardware Hersteller speziell für ihn gecheatet haben, war er doch zumindest ein kleiner leicht verfügbarer Indikator.
Auf Windows 8 konnte man ihn noch sehen, nun ist er weg auf Windows 8.1.

Aber eigentlich ist er nicht weg. Nachdem ich einen neuen Laptop mit Windows 8.1 und der Rechner nach der Installation neu gestartet wurde lief ein Prozess in der Eingabeaufforderung, der mir erst mal nichts sagte: WinSAT.exe (Das Windows-Systemberwertungstool)

Ein weinig Recherche brachte folgendes ans Tageslicht:

Mit diesem Tool wird der Leistungsindex berechnet. Die Befehle für das ertsellen des Leistungsindex sind:
winsat formal oder winsat prepop (es versteht sich, dass diese Befehle als Administrator ausgeführt werden müssen).
Mit winsat query kann man sich die Ergebnisse der Leistungsprüfung detailiert ansehen.
Will man die alten bekannten Bewertungszahlen wieder haben, die man seit Windows Vista kenn, dann geht das mit der Powershell und dem Befehl:
Get-WmiObject -Class Win32_WinSAT
Das sieht dann so aus in den letzten Zeilen:
```
...
CPUScore              : 7,6
D3DScore              : 7,3
DiskScore             : 7,9
GraphicsScore         : 7,3
MemoryScore           : 7,6
```

Der Gesamtleistugsindex ist, dann der niedrigste dieser 5 Werte.

PS: Nicht das Ihr neidisch werdet. Der abgebildete Leistungsindex ist nicht der des Laptops, sondern der meines Desktop PCs.

Workaround für Patchday Bug vom 12.04.2011: Wenn unter Windows 2000 der Einsprungpunkt FindActCtxSectionStringA nicht gefunden wird

Hintergrund siehe hier:
BUG: Schwarzer Patchday für Windows 2000 – MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) DLLs sind nicht mehr lauffähig nach Installation von KB2467174 bzw. KB2467175
BUG: Schwarzer Patchday für Windows 2000 2.- MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) Static Libraries erzeugen auch inkompatiblen Code für Windows 2000 durch KB2465367 bzw. KB2465361

Unter Windows 2000 kann man wie folgt vorgehen und das Problem beheben:

Am Besten macht man das nachdem man das System neu gestartet hat und noch keine Anwendung gestartet hat.
Alle betreffenden Hotfixe entfernen (für Runtime-2005 KB2467175, Runtime-2008 KB2467174, für VS-2007 SP1: KB2465367, VS-2008 SP1: KB2465361).
Die betroffenen C/C++ Runtimes des Visual Studio, die deinstalliert werden müssen, haben die folgenden Versionsnummern
– VC-2005 8.0.50727.5592 (KB2467175)
– VC-2008 9.0.30729.5570 (KB2467174)
Um VS-2005/2008 wiederherzustellen ist zwingend eine Deinstallation des Patches nötig.
Die Dateien für das Visual Studio sollten dann wieder denen des letzten Fix aus 2005/2008 entsprechen.
Eigentlich sollte die Deinstallation des Patches genügen.
Sofern es sich nur um ein Problem mit den Runtimes handelt und sich das Problem nicht behoben hat kann man mit den nächsten Schritten weiter machen und versuchen die alten Dateien wieder herzustellen.
(Man kann diese Schritte auch ohne Deinstallation durchführen)
Für VS-2008: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
a. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_…
b. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4148_…
c. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.1_…
Man wählt das Verzeichnis, dass man zuerst findet.
Für VS-2005: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
a. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4053_…
b. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4027_…
c. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.1833_…
d. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_…
Man wählt das Verzeichnis, dass man zuerst findet.
Alle Dateien aus diesen gefundenen Verzeichnissen in das C:\WinNT\System32 Verzeichnis kopieren.

Hope that helps ❗

PS: Ich habe den Artikel mehrfach überarbeitet während er bereits veröffentlicht war und immer neue Infos eingebaut bzw. die Vorgehensweise besser erklärt.

Nach der Installation des SP1 von Wndows 7 / Windows Server 2008 R2 lässt sich wieder einiges an Speichplatz freigeben

Auch durch die Installation des SP1 für Windows 7 und Windows Server 2008 R2 kann man durch das Aufrufen der Datenträger Bereinigung 0,8GB bis 2,5GB an Speicher freigeben.

Entfernen der SP1 Backupdateien für Window 7

Dazu startet man einfach die Datenträgerbereinigung (CLEANMGR.EXE) als Administrator. Oder man startet die Datenträgerbereinigung normal und klickt dann auf den Schalter Systemdateien bereinigen. Nur wenn man das Programm als Admin startet erhält man auch Zugriff auf die Backupdateien des SP1.
Bei mir wurden hier zwischen 0,5GB und 0,8GB freigegeben.

Entfernen der SP1 Backupdateien für Windows Server 2008 R2

Das Löschen der Backup Dateien des SP1 für einen Windows Server 2008 R2 ist hier beschrieben:
http://technet.microsoft.com/en-us/library/ff817650(WS.10).aspx (ziemlich weit unten unter To remove service pack backup files).

Der Befehl zum Entfernen der Backupdateien für ein durchgeführtes Online-Update lautet entsprechend:
DISM.exe /online /Cleanup-Image /spsuperseded

bzw. bei Verwendung eines Offline-Images:
DISM.exe /Image:<path_to_offline_image> /Cleanup-Image /spsuperseded

Auf meinen Servern konnte ich durch diese Operation im Schnitt ca. 2,4GB freigeben.

Nachtrag (09.03.2011):
Es sollte klar sein, dass man die Installation des SP1 nach Löschen der Backup-Dateien nicht mehr rückgängig machen kann.

Shell-Extension für die „alte“ Versionsanzeige in Vista+Windows7

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!

Warum unter Vista und Windows 7 C:\Programme nicht genau dasselbe ist wie C:\Program Files

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.

Texte von deutschen Meldungen in Microsoft Produkten auf englisch finden

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.

Eventlog Einträge mit der Ereigniskennung 675 im Sicherheit Ereignisprotokoll

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