In York fand vom 25. bis 28. August das diesjährige MCT Summit statt. Ein Dank geht an alle Kollegen, die zum Gelingen der Veranstaltung beigetragen haben, insbesonders an Andrew Bettany.
Weitere Fotos aus (dem schönen) York gibt es hier.
Thorsten Butz
Schulung und Consulting
In York fand vom 25. bis 28. August das diesjährige MCT Summit statt. Ein Dank geht an alle Kollegen, die zum Gelingen der Veranstaltung beigetragen haben, insbesonders an Andrew Bettany.
Weitere Fotos aus (dem schönen) York gibt es hier.
IBM hat es einmal mehr geschafft der Serie “Lotus Notes Skurrilitäten” eine weitere Folge hinzuzufügen. Versucht man die Startverknüpfung der (derzeit aktuellen) Notes 8.5x-Version an die Windows 7-Taskbar zu heften (“pinning”), so ist dies manchmal nicht möglich, da einem der Kontexteintrag nicht den notwendigen Befehl anbietet (siehe Abbildung links unten). Skurril ist dies insbesonders, weil es mal auftritt, mal nicht – wofür es wiederum keine plausible Erklärung zu geben scheint. Zahlreiche Diskussionen in Internetforen ranken sich um dieses Phänomen.
Abhilfe kann der nachfolgende Workaround schaffen: Man wechselt auf dem fraglichen Windows 7-Client zu dem unten abgebildeten Registryschlüssel:
HKEY_CLASSES_ROOT\Applications\notes.exe
Es reicht aus den Wert “NoStartPage” kurzfristig umzubennen, zum Beispiel in “NoStartPag_” und das Pinning funktioniert wieder. Anschließend ändert man den Wert zurück auf den Ausgangswert, die Fähigkeit zum Pinning ist fort, der “Pin” bleibt erhalten! (Getestet mit Lotus Notes 8.51, Standardclient mit FP4.)
Noch eine abschließende Bemerkung zum “pinning”: Lotus Notes ist bei weitem nicht die einzige Anwendung, die beim “Heften an die Taskleiste” versagt. Häufig ist jedoch schlicht ein fehlender Registryeintrag für den Dateityp *.lnk Ursache des Problems. Wie man u. a. hier nachlesen kann, sorgt das fehlen des Schlüssels
HKEY_CLASSES_ROOT\lnkfile\IsShortcut
dafür, dass Verknüpfungen nicht als ausführbar erkannt werden und somit auch nicht angeheftet werden können. In diesem Fall sollte es reichen, den o. g. Wert einfach neu zu erzeugen, das Datenfeld kann leer bleiben.
Der KMS (Key Management Service) bietet reichlich Anlass für hitzige Diskussionen; oft missverstanden und unbeachtet, traut sich so mancher Admin nur unter Vorbehalt an dieses Thema heran. Eine beliebte Frage ist, in wie fern die Aktivierung über den KMS für ein Nicht-Domänenmitglied gesteuert werden kann.
Wie man an der Abbildung oben erkennt, wird ein KMS über einen SRV-Eintrag im DNS gefunden. Damit dieser vom Client nun aucht tatsächlich zum Zwecke der Aktivierung angefragt wird , muss das primäre DNS-Suffix des KMS-Clients so konfiguriert werden, dass es der DNS-Domäne entspricht, in der der “_VLCMS“-Eintrag erstellt wurde. Im Beispiel oben ist das “contoso.com“.
Das besondere ist hierbei, dass ausschließlich der Eintrag über die Systemeigenschaften relevant ist (rechte Maustaste auf den Arbeitsplatz bzw. “Computer”, Eigenschaften). DNS-Suffixe, die in der Netzwerkkonfiguration festgelegt werden, beachtet das System diesbezüglich nicht. Da beim Eintritt in eine Domäne genau dieser Wert automatisch festgelegt wird, ist bei vielen Admins der falsche Eindruck enstanden, dass der Eintritt in die Active Directory-Domäne erforderlich sei. Im Umkehrschluss ließe sich daraus eine Grundsicherung des KMS ableiten. Diese Annahme ist falsch.
Die zweite Möglichkeit, einen KMS ohne Domänenmitgliedschaft zu nutzen, zeigt die folgende Abbildung:
Dieser Fall wird in den Microsoft Whitepapern empfohlen. Durch den Aufruf von
slmgr.vbs -skms
wird ein Registrywert gesetzt, wie in der dritten Abbildung zu sehen ist:
Abschließend ist noch die Frage offen, wie man diese Aktivierung denn nun verhindern kann. Die Antwort ist: nicht über den KMS, der kennt keine Zugriffsbeschränkungen. Welche Clients aktiviert werden dürfen lässt sich nur über den beschränkten Zugriff auf das Intranet definieren. VLANs, 802.1X-Authentifizierung, IPSec etc. bieten Möglichkeiten der Absicherung des Datenverkehrs. Andererseits gibt es keinen Anlass für übertriebene Panik: ein KMS aktiviert unabhängig von der tatsächlich lizensierten Hardware prinzipiell unbegrenzt Clients. Man braucht also nicht zu fürchten, dass der KMS die Dienste ab irgendeinem Schwellwert einstellt.
Seit dem Erscheinen von Windows Vista lassen sich alle Windows-Betriebssysteme über eine Antwortdatei unbeaufsichtigt installieren; diese Datei kann mittels eines USB-Sticks parallel zur Installation von DVD dem System übergeben werden. Der Name der Datei muss “Autounattend.xml” lauten, in Windows XP und Windows Server 2003 entspricht dies der Datei “winnt.sif”.
Basic Unattended File: Autounattend.xml
Der “Windows System Imager Manger” aus dem “Windows AIK” vereinfacht das Erstellen solcher Dateien, die prinzipiell auch mit jedem Texteditor bearbeitet werden können. Um den Einstieg zu erleichtern listet das nachfolgende PDF jene Einträge, die zum Grundgerüst der Datei gehören, so dass Installationen vollständig ohne Benutzereingriff laufen. Grau hinterlegte Einträge sind optional (aber nützlich).
Beispieldateien finden sich hier zum Download:
Nach dem Download bitte die Dateien umbenennen in “autounattend.xml”. Beim Vergleich der Beispieldateien sollte sich schnell zeigen, welche Anpassungen vorgenommen werden müssen, um beispielsweise die (UI-) Sprache oder die Prozessorplattform zu wechseln.
Firstlogon/Startscripts
Eine Schlussbemerkung: in den Beispielen wird auf ein Script zur ersten Anmeldung verwiesen mit dem Namen “c:\setup1\setup1.cmd”. Von Haus aus sind weder das Verzeichnis noch die Scriptdatei vorhanden. Wird diese nicht gefunden, so ignoriert das Setup die Startanweisung. Es lohnt sich jedoch, die “install.wim” anzupassen und eigene Elemente zu integrieren. Noch flexibler ist es, in der “autounattend.xml” an Stelle eines lokalen Pfades einen Netzwerkpfad zu hinterlegen.
Seit der Veröffentlichung von Vista lassen sich alle Windows-Betriebssysteme sehr komfortabel evaluieren, ein Produktschlüssel (PID) ist in keinem Fall erforderlich. Jedoch sollte man wissen, wie man die eingebaute Evaluierungsphase effizient nutzen kann. In Windows 7 und dem Windows Server 2008 R2 hat sich diesbezüglich im Vergleich zu den Vorgängerversionen einiges geändert.
Autounattend.xml und Default-PIDs
In Vista/WS2008 musste man bei Verwendung einer Datei zur unbeaufsichtigen Installation einen Produktschlüssel hinterlegen; dazu eigneten sich die so genannten “OPK PIDs” vorzüglich (siehe OPK-PIDs Vista und WS 2008 ). Das Verwenden dieser Platzhalter ist in Win7/R2 nicht mehr erforderlich, aber noch immer möglich.
Automatische Aktivierung ausschalten
Nach der Installation der Enterprise-Editionen erwarten Win7/R2 einen KMS (“Key Management Service”) im Unternehmen. Aus diesem Grund sieht man im Dialogfenster “System” (Windowstaste + PAUSE), dass 3 Tage für die automatische Aktivierung verbleiben.
In Wirklichkeit stehen jedoch 30 Tage zu Einrichtung und Testen zur Verfügung. Die automatische Aktivierung lässt sich über den nachfolgenden Registry-Schlüssel deaktivieren:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\Activation]
“Manual”=dword:00000001
Anschließend sieht man den vollständigen Testzeitraum, das System aktiviert sich nicht mehr selbständig im Hintergrund:
Der o.g. Schlüssel wurde in Win7/R2 an diesen Ort verschoben, in Vista und WS 2008 befand sich der Registry-Schlüssel an dieser Stelle:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL\Activation]
“Manual”=dword:00000001
Neu laden
Mit dem allseits bekannten “slmgr.vbs -rearm” lassen sich nach Ablauf dieser 30 Tage weitere 30 Tage frei schalten. In Win7/R2 ist dies insgesamt drei mal möglich, so dass man auf einen Gesamtzeitraum von 120 Tagen kommt.
In Vista/WS2008 war dies nicht einheitlich: Vista ließ sich maximal 6 x 30 Tage evaluieren, WS 2008 4 x 60 Tage.
Sysprep
Wenn man die maximale Anzahl an “Rearms” erreicht hat, so lässt sich allerdings kein SYSPREP mehr ausführen.
(Siehe u.a. KB 929828)
Screenshot
Die verbleibende Anzahl der möglichen Verlängerungen ermittelt das “Microsoft Genuine Advantage Diagnostic Tool“.
Screenshot
Migration auf den R2 in der Praxis · 3 Tage · Inklusive Hyper-V als Virtualisierungsplattform
Kursbeschreibung
Der Workshop vermittelt die Neuerungen von Windows Server 2008 R2 für den betrieblichen Einsatz. Techniken zur Migration von Windows Server 2003 zur aktuellen Betriebssystemgeneration stehen im Mittelpunkt des praxisorientierten Seminars.
Im Verlauf des Workshops aktualisieren die Teilnehmer/-innen eine Windows Server 2003-basierende Active Directory-Gesamtstruktur. Die Virtualisierungslösung Hyper-V (Version 2) dient hierbei als zentrale Konsolidierungsplattform.
Weiterlesen:
Der Workshop für Windows XP-Experten · 3 Tage · Auf Wunsch: Überblick über die PowerShell in Windows 7
Kursbeschreibung
Der Workshop vermittelt die Neuerungen von Windows 7 für den betrieblichen Einsatz. Techniken zur Migration von Windows XP zur aktuellen Betriebssystemgeneration bilden einen Schwerpunkt des Seminars. Mit kritischem Blick auf die Besonderheiten und Feinheiten der Architektur wird das praxisrelevante Wissen zur sicheren und funktionalen Konfiguration von Windows 7 aufgebaut. […]
Weiterlesen: