Server mit der PowerShell konfigurieren (1)

Lesezeit
2 Minuten
Bis jetzt gelesen

Server mit der PowerShell konfigurieren (1)

05.09.2016 - 00:00
Veröffentlicht in:
Unternehmen verfügen zwar meist über Software-unterstützte Installationsroutinen, die Server-Hardware oder virtuelle Maschinen von einer Bestellung bis hin zum Einsatz automatisiert aufsetzen. Doch mitunter sind auch Nacharbeiten nötig. Diese lassen sich mit der PowerShell erledigen. Auch für eine wichtige Server-Variante sind die Cmdlets von Bedeutung: Windows Server Core. Im ersten Teil des Workshops setzen wir das lokale Admin-Passwort und den Servernamen neu und präparieren die Festplatte.
Oft lassen sich viele oder gar alle Schritte der Installation eines neuen Servers automatisiert erledigen. Doch im seltensten Fall ist das Deployment mit der Installation und dem Einspielen von relevanten Betriebssystem-Updates beendet. Vielmehr sind erweiterte Konfigurationsschritte nötig wie die Partitionierung der Festplatte, die Basiskonfiguration der Netzwerkinterfaces, Anpassungen an der Firewall oder Änderungen in der Windows-Registrierung.

Die Zusatzkonfiguration weiterer Komponenten hängt dann auch vom Einsatzziel des Servers ab. Domänencontroller werden anders konfiguriert als Datei-, Druck- oder Terminalserver. Das erfordert eine Flexibilität der Deploymentlösung, die damit oft an ihre Grenzen stößt – wenn Abteilungen etwa zudem unterschiedliche Endkonfigurationen wünschen. Ein weiteres Szenario ist das Bereitstellen von Servern, für die kein automatisiertes Deployment existiert. Dies ist etwa in Entwicklungs-, Test- und Integrationsumgebungen der Fall.

Für diese Fälle sehen wir uns die Konfiguration von Windows mit der PowerShell genauer an. Die nachstehenden Beispiele und Skripte können dabei auf diversen Wegen eingesetzt werden: Als Skriptsammlung für Adhoc-Konfigurationen, zur Nachbesserung und Erweiterung des unternehmensweiten Server-Deployments oder als Aufbauskript für eine Testumgebung.

Lokales Administratorpasswort neu setzen
Wir beginnen unseren Workshop mit einem grundlegend aufgesetzten Windows-Server. Bevor Sie die weitere Einrichtung des Servers vornehmen, können Sie bei Bedarf das Administratorkennwort auf einen neuen Wert setzen. Wurde der Server etwa nicht durch Sie, sondern durch ein anderes Team installiert, ist die Chance groß, dass das Passwort bereits anderen Personen bekannt ist. Um den Built-in-Administrator zurückzusetzen, nutzen Sie den Befehl (achten Sie dabei auf die geforderte Komplexität des Passworts):
$admin = [ADSI]"WinNT://./Administrator"
$admin.SetPassword("Passwort")
Wir bedienen uns des WinNT-Providers, der mit wenig Aufwand lokale Benutzer und Gruppen suchen und ändern kann. Die Nomenklatur der Adresse ist WinNT: //Hostname/ObjektName[,ObjektTyp]. Die Nutzung des Punktes als Hostnamen führt die Anfrage auf dem lokalen Rechner aus. Anschließend wird die Funktion "SetPassword" aufgerufen, der das Passwort als Text übergeben wird. Wurde das System weder in Deutsch noch Englisch installiert und heißt der Standardadministrator nicht "Administrator", findet die PowerShell den Built-in-Administrator über die SID mit Hilfe von WMI:
$admin = (gwmi -query "Select * From Win32_UserAccount Where LocalAccount 
= TRUE AND SID LIKE 'S-1-5%-500'")
$builtinAdmin = [ADSI]"WinNT: //./$($admin.Name)"
$builtinAdmin.SetPassword ("NeuesPasswort")
Die SID des lokalen Administrators eines Rechners endet stets auf "-500" im RID-Teil. Der Mittelteil, nach "S-1-5", ist ein maschineneindeutiger Teil, der von Maschine zu Maschine anders lauten wird. Die Suche via WMI nach diesem Teil liefert aber zuverlässig den Namen des Administratorkontos, dessen Passwort sich dann zurücksetzen lässt.


Bild 1: Wenn die Passwörter in geschützter Form bereits vorliegen, kann eine kleine Skriptfolge – gesteuert über
eine CSV-Datei – das richtige Kennwort von allein finden.


Mit einer Maschine geht das ganz gut – aber wie sieht eine Kommandofolge aus, wenn Sie mehrere Server aufsetzen müssen und die Passwörter bereits vor-gegeben sind? Eine einfache Liste kann als CSV-Datei auf einem geschützten Server vorliegen.

In unserem Beispiel erstellen wir eine CSV-Datei, die zwei Spalten enthält: eine Spalte namens "ServerName" und eine namens "Password". Darunter tragen wir dann die Computer-Passwort-Kombinationen ein, die für die Erstellung einer Testumgebung oder mehrere Rechner genutzt werden.

Da Excel beim Speichern von Dateien als CSV das Semikolon als Trennzeichen verwendet, die PowerShell als Vorgabe aber ein anderes Trennzeichen, müssen Sie das beim Import explizit angeben. Ist das CSV-File an einer sicheren Stelle gespeichert, lässt sich die Passwortliste so auslesen:
$pwList = Import-CSV \\file.fabrika.com\Deployment\secure\passwords.csv 
-Delimiter ";"
$pass = $pwList | ?{$_.ServerName -eq $env:Computername }
$admin = (gwmi -query "Select * From Win32_UserAccount Where LocalAccount
= TRUE AND SID LIKE 'S-1-5%-500'")
$builtinAdmin = [ADSI]"WinNT: //./$($admin.Name)"
$builtinAdmin.SetPassword ($pass.Password)
Das bedingt allerdings, dass der Server, auf dem das Skript ausgeführt wird, bereits einen gültigen Computernamen besitzt. Ist das nicht der Fall, müssen Sie diesen zunächst setzen.

Seite 1: Lokales Administratorpasswort neu setzen
Seite 2: Servernamen setzen und Festplatte präparieren


Seite 1 von 2 Nächste Seite >>


dr/ln/Florian Frommherz

Ähnliche Beiträge

Im Test: Heimdal Patch & Asset Management

Ein zeitgemäßes Patchmanagement darf sich angesichts der vielfältigen Bedrohungen nicht allein auf die Microsoft-Produkte konzentrieren, sondern muss sich auch verbreiteten Drittanbieteranwendungen widmen. Der dänische Anbieter Heimdal Security geht noch einen Schritt weiter und hat eine ganze Suite zum Schutz vor Cyberbedrohungen im Programm. Mit dem Fokus auf das Patchen haben wir uns das cloudbasierte Angebot genauer angesehen.

Device-Management mit Microsoft Intune und Office 365 - Zwei Wege, ein Ziel

Um Geräte im Netzwerk oder mobile Geräte, die auf das Netzwerk zugreifen, zu verwalten, bietet sich für Unternehmen entweder Office 365 Mobile Device Management oder Microsoft Intune an. Ein Unterschied zwischen den beiden Lösungen besteht vor allem im Preis. Während das Device-Management zu vielen Abonnements in Office 365 gehört, muss Microsoft Intune gesondert abonniert werden. In diesem Beitrag stellen wir beide Ansätze vor.