Category Archives: WS 2008 (R2)

Active Directory: Weltmeisterlicher Import aus einer Exceldatei

Posted on by .
Leave a reply

Ich verwende häufig den Datenimport aus einer Exceltabelle für das einfache Erstellen von Benutzerkonten im Active Directory. Zu Ehren der vierten Weltmeisterschaft der deutschen Nationalmannschaft habe ich diese Arbeitsmappe aktualisiert. Zusammen mit zwei PowerShell-Scripts kann man diese Daten recht gut zur Demonstration bzw. zu Testzwecken verwenden.

Weltmeister, Darstellung in Excel

 

ZIP SymbolDas Downlaodarchiv enthält drei Dateien:

  1. Weltmeister.xls
    Enthält Namen und Daten der vier Weltmeisterschafter-Teams (1954, 1974, 1990, 2014) , siehe Abbildung oben.
  2. Export-TBXLStoCSV.ps1 -path <pfad zur XLS-Datei>
    Zeigt beispielhaft, wie man mittels PowerShell eine XLS-Datei in CSV-Dateien umwandelt. Natürlich kann man die Daten auch manuell “als CSV speichern”.
  3. Create-TBWeltmeister.ps1 -folder <pfad zu den CSV-Dateien>
    Erstellt die Weltmeister auf Grundlage der exportierten CSV-Dateien.

AD-Domäne lahmlegen für Anfänger

Posted on by .
Leave a reply

[[For an ENGLISH version, click this line!]]

Die Idee zu diesem Miniskript kam mir beim Lesen von Tweets in der Bahn; der Kollege Nils Kaczenski beklagte sich (zu Recht), wie leicht es in vielen Fällen doch sei, als Standardbenutzer ein komplettes Intranet lahm zu legen. Als ein in einem weiteren Tweet gefragt wurde, wie das ginge, war ich versucht die nachfolgenden Zeilen direkt zu twittern, aber das war mir dann angesichts der 140 Zeichenbegrenzung und der vielen Sonderzeichen doch ein wenig zu umständlich. Kommen wir nun also zum Kochrezept und bitte NICHT in der Produktivumgebung einsetzen!

$domain = (Get-ADDomain).Name
$dc = (Get-ADDomainController | Select-Object -First 1).Name
$me = $env:username
$t = (Get-ADDefaultDomainPasswordPolicy).LockoutThreshold

Get-ADUser -Filter { samaccountname -notlike $me } | % {
$user = $_.SamAccountName
0..$t | % { net use \\$dc /user:$domain\$user TEST }
}

Erklärung erforderlich? Eigentlich alles ganz einfach: Ich unterstelle, dass Nils Aussage auf die populäre Technik der Kontensperrungsrichtlinie abhebt. Von vielen als Sicherheitsfunktion betrachtet, hat dies leider den Seiteneffekt, dass jeder Anwender einen beliebigen anderen Anwender aussperren kann. Einfach den Benutzernamen des Kollegen oder der Kollegin eingeben und mehrfach ein falsches Passwort übergeben. Das kann jeder, der sich in irgendeiner Form mit einem Computer der AD-Domäne verbinden kann. Die Lösung des Problems ist also ebenfalls offensichtlich: einfach keine Kennwortsperrung konfigurieren.

Die Codezeilen können interaktiv in der Windows PowerShell (ab v2) mit geladenem Active Directory-Modul ausgeführt werden:
Zeile 1: Wir holen uns den Domänennamen, zB “contoso”.
Zeile 2: Wir holen uns den Namen eines einzelnen DC, zB “dc1”
Zeile 3: Wir holen uns den eigenen Anmeldenamen, zB “DoeJ”
Zeile 4: Wir holen uns den “LockoutThreshold”, zB “5”.
Zeile 5-8: Wir holen uns alle AD-Benutzerkonten, außer dem eigenen und verbinden uns dann mit jedem einzelnen Benutzer so oft gegen einen (grundsätzlich beliebigen) Server, dass die Konten gesperrt werden.

Abschließender Hinweis: Es ist nicht erforderlich von “0..$t” zu laufen, es reicht “1..$t”. Die eine Bonusrunde habe ich eingebaut, damit man den Effekt auch unmittelbar beobachten kann, wie man im nachfolgenden Bildschirmfoto sieht.

Kontensperrung

Kontensperrung erfolgt nach mehrfach fehlerfaften Anmeldeversuchen


Link zum Origional-Tweet.

“Run Windows Explorer as administrator”

Posted on by .
Leave a reply

[For an ENGLISH version, click this line!]

Seit Microsoft mit Vista die Benutzerkontensteurung (“User account control”) einführte, stellte diese sicherheitsrelevante Neuerung Administratoren vor Herausforderungen. Besonders fragwürdig erscheint es, dass sich der Windows Explorer nur dem ersten Anschein nach mit erweiterten Rechten starten lässt. In der Grundkonfiguration erscheint zwar der Erweiterungsdialog (“Elevation prompt”), die Rechte des Anwenders werden aber nicht erweitert. Gleiches gilt unabhängig davon, ob der Anwender mit einem administrativen Konto angemeldet ist (als “Protected Admin”) oder sich impersonifiziert. Das System unterscheidet auch nicht zwischen “Run as administrator” und “Run as different user”.

Gut versteckt im Betriebssystem findet sich ein Registry-Key, der es erlaubt, den Explorer.exe-Prozess mit erweiterten Rechten zu starten:

HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}\RunAs

Löscht oder ändert man den o.g. Schlüssel (zum Beispiel in “RunA_”) lässt sich der Explorer mit erweiterten Rechten starten.

Es lauern aber  weitere Fallen: Der Schlüssel ist vor leichtfertigen Änderungen dadurch geschützt, dass der “Trusted Installer” als Eigentümer eingetragen ist. Will man den Schlüssel modifizieren, muss man zunächst den Besitz übernehmen. Leider kenne ich kein Bordmittel, um diese Änderung script-gesteuert vorzunehmen: “regini.exe” kann keine Besitzrechte übernehmen, das PowerShell-Cmdlet “Set-ACL” scheitert an den vorgegebenen Zugriffsrechten (es sei denn man impersonifiziert sich zuvor als “SYSTEM”-Benutzer, was ebenfalls Zusatzwerkzeuge erfordert).

Ein Workaround bietet Helge Kleins Freeware-Werkzeug “setacl.exe”; diese populäre Werkzeug meistert, was die Bordmittel nicht schaffen.

Das vorliegende PowerShell-DemoScript “Enable-ExplorerRunAs.ps1” lädt Helges Werkzeug herunter, führt die nötigen Änderungen durch und löscht die temporären Dateien schließlich.  Das Script benötigt lokale Adminrechte, die Änderungen greifen unmittelbar.

Ein abschließender Tipp noch für Windows 8/Windows Server 2012:  Das Kontextemenü bietet standardmäßig keine Erweiterungsdialoge. Legt man jedoch eine Verknüpfung für “explorer.exe” neu an, so sind die nötigen Kontexteinträge sichtbar.

 

Download als Textdatei  “Enable-ExplorerRunAs.ps1“ oder Vorschau auf GitHub

 
Ein Artikel des Kollegen Helge Klein erinnerte mich an dieses Demoscript, das ich schon vor einiger Zeit veröffentlichen wollte. Helges lesenswerter Artikel über die Unzulänglichkeiten des Windows Explorer findet sich hier:

http://helgeklein.com/blog/2013/04/why-every-self-respecting-administrator-should-ditch-explorer-for-good/

Hyper-V wireless networking auf einem MacBook Air

Posted on by .
Leave a reply

Mit Hilfe von Apples Bootcamptreibern lässt sich auch auf einem MacBook Air ohne größere Probleme auch Windows Server 2008 R2 installieren, was die Möglichkeit eröffnet, Hyper-V zu nutzen. Dieses Szenario ist allerdings nur in wenigen Fällen sinnvoll: will man schlicht virtualisieren, so bieten sich Desktop-Lösungen für MacOS wie Parallels und VMWares Fusion an. Will man jedoch explizit Hyper-V nutzen, so ist eine Dual-Boot-Installation erforderlich.

Nach der Installation des Windows Server 2008 R2 ist man mit dem Problem konfrontiert, dass ein MacBookAir keine kabelgebundene LAN-Schnittstelle hat. Eigentlich unterstützt Hyper-V keine WLAN-Schnittstellen, das System lässt sich aber mit Hilfe einer einfachen Netzwerkbrücke (“Bridge”) vom Gegenteil überzeugen.

  1. Im ersten Schritt erstellt man mit dem “Virtual Network Manager” ein virtuelles Netzwerk vom Typ “Internal”:
    Hyper-V Virtual Network Manager
  2. Im “Network and Sharing Center” findet man anschließend eine neue LAN-Schnittstelle, über die der Hyper-V-Host und seine “Child partitions” ein rein internes Netzwerk aufbauen können:
  3. Markiert man gleichzeitig diese Schnittstelle und den WLAN-Adapter, so lassen sich diese zu einer einzelnen logischen Einheit “brücken“:

Alternativ kann kann man in einen USB-Ethernet-Adapter investieren, den Hyper-V wie jede traditionelle LAN-Verbindung akzeptiert. Hierzu sind lediglich die schon erwähnten Bootcamptreiber erforderlich, so dass Windows die Hardware erkennt.

Diese “LAN-Schnittsstelle” kann Hyper-V ohne Tricks nutzen. Typischerweise erstellt man ein “External”-Netzwerk, in der Folge erscheint ebenfalls eine virtuelle Netzwerkschnittstelle in der Netzwerkkonfiguration des Hosts. Entfernt man den Adapter anschließend physisch, bleibt die zuvor erzeugte VMBus-NIC (die Schnittstelle, die über die Konfiguration des “External”-Netzwerks entstanden ist) erhalten. Man kann diese Schnittstelle dann sogar verwenden, um die Netzwerkbrücke ohne den Umweg über das “Internal”-Netzwerk mt dem WLAN-Adapater zu verbinden, Hyper-V wird das in aller Regel akzeptieren, weil das System im Hindergrund die nötigen Anpassungen automatisch vornimmt. Empfehlenswert ist das aber nicht, da man sich dort sehr schnell einen “Knoten in die Netzwerklogik” konfiguriert. Dies sei also eher als Warnung verstanden.

Diese Vorgehensweise funktioniert natürlich nicht nur auf MacBooks, sondern auch auf anderen Notebooks. Es finden sich Beiträge zahlreicher Kollegen, die diese und alternative Vorgehensweisen beschreiben. Einige sind nachfolgend verlinkt.

“Dieses Programm wird nicht häufig heruntergeladen …”

Posted on by .
Leave a reply

Schon seltsam, welche Fehlermeldungen uns da manchmal begegnen:

“Dieses Programm wird nicht häufig heruntergeladen und kann auf dem Computer Schaden anrichten.”

Um welches Programm mag es sich wohl handeln, vor dem uns der Internet Explorer so nachhaltig warnt? Es ist der “Sharepoint Foundation Server 2010“. Dass das Programm “Schaden anrichten kann” haben einige ja schon immer behauptet, nun wissen wir aber auch (Achtung: Ironie!), dass es offenbar nicht sonderlich beliebt ist.

IErrungen

Posted on by .
Leave a reply

Mit dem Internet Explorer 9 hat Microsoft in zeitlicher Nähe zum Service Pack 1 ein reizvolles Update veröffentlicht, das man beim Setup von Windows 7 sinnvollerweise direkt in das Installationsmedium integrieren sollte. Beim automatisierten Bereitstellen warten aber einige Fallen, die es zu umschiffen gilt.

1. Offline Setup
Oblgeich man auf der Downloadseite zwischen zahlreichen Varianten wählen kann, benötigt man für die automatisierte Installation in der Regel nur den deutschen IE für Windows 7, in 32 und/oder 64 Bit, da mit ihm sowohl englische Windows-Versionen als auch der Windows Server 2008 R2 betankt werden können. Dem Installer “IE9-Windows7-x64-deu.exe” entlockt man mit “/?” Parameter, so zum Beispiel den Paramter “/x:<pfad>” zum Entpacken der Datei.  Das extrahierte Archiv gibt den Blick frei auf vier Dateien, von denen die Datei “ielangpack-DEU.CAB” das Sprachpaket repräsentiert. Es ist nicht erforderlich die separat angebotenen Sprachpakete herunterzuladen, sie sind in den landesspezifischen Installern integriert, Englisch ist in jedem Fall bereits in der Grundinstallation enthalten.

Die erste Ver-IE-rrung erlebt man bei dem Versuch, IE 9 ohne Internetzugang zu installieren. Obgleich der Parameter “/update-no” die Suche nach Updates vor der Installation unterbinden soll, kann der Installationsversuch fehlschlagen:

IE9 Setup verlangt nach Internetverbindung

Installiert man den IE 9 jedoch mittels “dism.exe”, so läuft die Installation zuverlässig durch:

dism /online /Add-Package /PackagePath:IE9-Win7.CAB

dism /online /Add-Package /PackagePath:ielangpack-DEU.CAB

Der zweite Befehl installiert das Sprachpaket. Auf einem rein englischen System kann man die Sprachdatei einfach ignorieren. Wie bereits erwähnt, ist es demzufolge nicht erforderlich, die “englische” Version herunterzuladen – man hat sie bereits vorliegen.

2. Offline Patching
Da sich “dism.exe” als geignetes Werkzeug zur Installation erwiesen hat, kann man den IE auch direkt in das Windows 7-Installationsmedium integrieren. Es bietet sich an, bei der Gelegenheit ein vollständig zweisprachiges (deutsch/englisch) Windows zu erstellen:

# 1: Den Inhalt einer deutschen Windows 7-Enterprise-DVD nach c:\depot\win7 kopieren, anschließend das Installationsabbild montieren:
dism.exe /Mount-Wim /WimFile:c:\depot\win7\sources\install.wim /index:1 /MountDir:c:\mnt\tmp

# 2: Das englische Sprachpaket nach c:\depot\LP_W7SP1 herunterladen , entpacken und integrieren:
dism.exe /Image:c:\mnt\tmp /Add-Package /PackagePath:”C:\depot\LP_W7SP1\en-us\lp.cab”

# 3: Den IE herunterladen, die Datei “IE9-Windows7-x64-deu.exe” entpacken(im Beispiel nach IE9-Windows7-x64-deu) und integrieren :
dism.exe /Image:c:\mnt\tmp /Add-Package /PackagePath:”C:\depot\ie9\IE9-Windows7-x64-deu\IE9-Win7.CAB”
dism.exe /Image:c:\mnt\tmp /Add-Package /PackagePath:”C:\depot\ie9\IE9-Windows7-x64-deu\ielangpack-DEU.CAB”

# 4: Das Abbild demontieren:
dism.exe /Unmount-Wim /MountDir:c:\mnt\tmp /commit

# 5: Das “Windows AIK für Windows 7” installieren und eine neue DVD erstellen:
c:\Program files\Windows AIK\tools\amd64\oscdimg.exe -n -m -b”c:\depot\win7\boot\etfsboot.com” c:\depot\win7 c:\depot\win7x64_de_en_ie7.iso

Führt man Schritt 1 mit einer anderen Windows 7-Edition aus, somuss man zunächst ermitteln, welcher Index der gewünschten Variante zugeordnet ist.

DISM.exe /Get-WimInfo /WimFile:”c:\depot\win7\sources\install.wim”

Schritt 2 entfällt bei  einer Home Premium oder Professional-Edition, da diese Editionen keine Mehrsprachigkeit erlauben (es sei denn, man möchte während des Setup zwischen verschiedenen Sprachen wählen können).

3. Gruppenrichtlinien/GPO
Nach der erfolgreichen Installation des neuen Internet Explorer sollte man einen Blick in das Verzeichnis “c:\Windows\PolicyDefinitions” werfen: dort sind nun drei neue Dateien vorhanden:

  • inetres.admx
  • de-DE\inetres.adml
  • en-US\inetres.adml

Der Installer hinterlegt die korrespondieren administrativen Vorlagen auf jedem Windows-System mit installiertem IE 9. Man erkennt die neue Version an der Kennzeichnung ‘revision=”9.0″‘ in den ersten Zeilen der Dateien. Diese ADMX/L-Dateien sollte man nun in den “Central Store” integrieren.

Überfällige Updates: RSAT, Windows Phone 7

Posted on by .
Leave a reply

Derzeit (Q1 2011) macht Microsoft leider wieder einmal mit fragwürdiger Updatepolitik von sich reden: nachdem Microsoft Mitte Februar das erste Service Pack für Windows 7 und Windows Server 2008 R2 veröffentlichte, stehen nun viele AdministratorInnen vor dem Problem, dass sich die RSAT (“Remote Server Administration Tools”) auf einem frisch aufgesetztem Windows 7 mit inkludiertem SP1 nicht installieren lassen. Fragwürdig ist dies insofern, als dass die RSAT problemlos mit dem SP1 harmonieren, wenn man die Installation der RSAT auf einer RTM-Version (mit allen Patches, aber ohne SP1) von Windows 7 vornimmt und anschließend das SP1 nachinstalliert.

Dass es sich offenbar um ein reines Installer-Problem handelt, zeigt der nachfolgende beschriebene Workaround:

How-To: Install RSAT (Remote Server Administration Tools) on Win 7 Sp1

Im Kern besteht der Trick darin, dass man anstelle der graphischen Installation oder der Installation mittels “dism.exe” die alten/klassischen Tools rund um “pkmgr.exe”  verwendet. Eine Technik, die wir eigentlich mit der Veröffentlichung von Windows 7 /R2 hinter uns zu lassen glaubten. Das Microsoft nun für April eine neue Version der RSAT angekündigt hat, wirft die Frage auf, wieso ein offenkundig geringfügiger Fehler am Installer eine dermaßen lange Wartezeit verursacht:

Installing the RSAT tools on Windows 7 SP1 installations (The Windows Servicing Guy) (Siehe auch KB 2517239)

Denkt man an die Veröffentlichung von Vista zurück, so wird sich mancher noch mit Schrecken erinnern, dass es dort etliche Monate dauerte, bis die erste RSAT-Version zur Verfügung stand. Mit dem Launch von Windows 7/R2 war es Microsoft nach über 10 Jahren dann wieder einmal gelungen, sowohl Client als auch Server plus Verwaltungswerkzeuge gemeinsam zu veröffentlichen.

Noch prekärer ist die Situation für alle Besitzer eines Windows 7 Phones: dort lässt das lange schon überfällige erste Update noch immer auf sich warten, was mittlerweile selbst die größten Fans in die Verzweiflung treibt:

Microsoft: Blah, blah, blah, very small update on update delays (Paul Thurrott)

Einer von mehreren Faktoren, die die junge (und anfangs erfolgversprechende) Plattform schon jetzt zum Scheitern verurteilt?

Warten wir es ab, ob man bei Microsoft in den nächsten Monaten diese Dinge wieder besser in den Griff bekommt.

Update: Am 7. April sind die RSAT für das Service Pack 1 erschienen.

Fun with loc

Posted on by .
Leave a reply

Wenige Dinge erfreuen den Administrator (außerhalb des englischen Sprachraums) mehr, als die Übersetzungsbemühungen US-Amerikanischer Softwarehäuser. Zwei kleine Stilblüten sollen hier gewürdigt werden.

a) SSL oder SSL?

Die Auflösung dieses kleinen “Intelligenztests” findet sich beim Klick auf die Grafik oben (PNG, 1756×447 px, 33 kB).

b) Features-Features-Functies

Das zweite Beispiel zeigt ein beabsichtigtes, aber nicht minder interessantes Phänomen:

Höchst interessant, dass im deutschen Server-Manager zwar “Roles” zu “Rollen” werden, “Features” aber “Features” bleiben (anstelle des naheliegenden Begriffs “Funktionen”). Auch der Vergleich zum Niederländischen ist spannend: dort werden beide Rubriken übersetzt, m. E. jedoch in leicht missverständlicher Manier: “Functies” = “Roles”, “Features” = “Onderdelen”.

Mythos KMS, heute: Aktivierung ohne Domänenmitgliedschaft

Posted on by .
Leave a reply

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.

KMS-SRV-Eintrag im DNS

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:

SLMGR.VBS -SKMS

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:

SLMGR.VBS -SKMS erzeugt einen Registryeintrag

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.

Autounattend.xml

Posted on by .
Leave a reply

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.