Automatisieren des Build-Prozesses für neue Workstations und Server
Die Einrichtung neuer Workstations und Server umfasst häufig sich wiederholende Aufgaben, die traditionell mit einer Checkliste und einem hohen Zeitaufwand für einen Techniker verbunden sind. Diese Aufgabe erledigen viele MSPs manuell. Glücklicherweise können Benutzer der Datto RMM-Lösung (Remote Monitoring and Management) den größten Teil des Prozesses mit Hilfe des Initial Audits oder des On-Connect Job Schedulers automatisieren.
Schauen wir uns an, wie man diese Art der Automatisierung einrichtet.
Starten des Build-Prozesses für neue Workstations und Server
Nachfolgend finden Sie eine Beispiel-Checkliste mit Elementen für einen neuen Build-Prozess:
- Symbolleisten und Software von Drittanbietern entfernen
- Deaktivieren Sie das Gastkonto
- Erstellen Sie ein neues lokales MSP-Administratorkonto
- Java, Shockwave, Adobe Reader und Chrome installieren
- Aktivieren Sie Bitlocker und verschlüsseln Sie das Laufwerk - notieren Sie sich unbedingt den Wiederherstellungsschlüssel
- Notieren Sie sich den Windows-Lizenzschlüssel
- Installieren Sie alle verfügbaren Windows-Updates
Es gibt jedoch bestimmte Dinge, die Sie nicht tun sollten, wenn es sich bei dem neuen Gerät beispielsweise um einen Server handelt.
Nur Workstations:
- Symbolleisten und Software von Drittanbietern entfernen
- Java, Flash, Shockwave, Adobe Reader und Chrome installieren
- Aktivieren Sie Bitlocker und verschlüsseln Sie das Laufwerk - notieren Sie sich den Wiederherstellungsschlüssel
Sowohl Server als auch Workstations:
- Deaktivieren Sie das Gastkonto
- Erstellen Sie ein neues lokales MSP-Administratorkonto
- Notieren Sie sich den Windows-Lizenzschlüssel
- Installieren Sie alle verfügbaren Windows-Updates
Das Drehbuch: Nächste Schritte
Als Nächstes können wir etwas PowerShell-Code in unserer neuen Build-Komponente verwenden. Damit können wir den Betriebssystemtyp ermitteln. Diese Information bestimmt die nächsten Schritte, die das Skript ausführt.
Lassen Sie uns mithilfe von PowerShell feststellen, ob wir auf einem Server oder einer Workstation ausgeführt werden.
$osInfo = Get-WmiObject -Class Win32_OperatingSystem
Wir können nun den Produkttyp aus dem Objekt Produkttyp extrahieren:
$osInfo.ProduktTyp
Arbeitsstation (1)
Domänencontroller (2)
Server (3)
Der nächste Schritt besteht darin, den Rückgabewert unserer Abfrage nutzbar zu machen. Dazu müssen wir die Variable $osInfo.ProductType mithilfe einer IF-Anweisung auswerten.
Es gibt zwei Operatoren, die wir mit der IF-Anweisung verwenden können
-eq Entspricht
-nicht gleichwertig
Feststellen, ob das Skript auf einem Workstation-Betriebssystem ausgeführt wird
wenn ($osInfo.ProductType -eq 1){
write-host Workstation OS erkannt
}
Feststellen, ob das Skript nicht auf einem Workstation-Betriebssystem ausgeführt wird
wenn ($osInfo.ProductType -ne 1){
write-host Server OS erkannt
}
Wenn wir wollten, könnten wir weiter definieren, auf welchem Servertyp das Skript läuft (Domain Controller oder Mitgliedsserver), indem wir auf einen Rückgabewert von 2 oder 3 testen, wie oben beschrieben.
Verwendung von ELSE in Ihrer IF-Anweisung
Um den PowerShell-Code zu vereinfachen, könnten wir ELSE in unserer IF-Anweisung verwenden, anstatt nacheinander für jeden Betriebssystemtyp zu testen. Wenn das Skript beispielsweise nicht auf einem Server-Betriebssystem ausgeführt wird, muss es daher auf einem Workstation-Betriebssystem ausgeführt werden.
wenn ($osInfo.ProductType -ne 1){
write-host Server OS erkannt
}
sonst {
write-host Workstation OS erkannt
}
Da wir nun wissen, für welchen Betriebssystemtyp das Skript ausgeführt wird, können wir damit beginnen, die automatisierten Aktionen durchzuführen...
wenn ($osInfo.ProductType -eq 1){
write-host Workstation OS erkannt
<insert your custom PowerShell code here>
}
Als Nächstes müssen Sie dies automatisch für alle neuen Geräte durchführen, die einer Site beitreten. Nutzen Sie die Plattform bereits seit einiger Zeit? Wenn ja, haben Sie wahrscheinlich Standorte mit bestehenden Agenten, für die Sie Ihr Skript zur Vorbereitung neuer Computer nicht ausführen möchten.
Dazu könnten Sie einen neuen Standort namens „Workshop“ anlegen und diesen als Zwischenablage für alle neuen Builds nutzen, wobei Sie die Geräte nach Abschluss des Build-Prozesses in den richtigen Standort verschieben. Hinweis: Denken Sie daran , alle Überwachungsrichtlinien für den neuen Standort „Workshop“ zu deaktivieren und sicherzustellen, dass keine Synchronisierung mit externen Anwendungen stattfindet!
Laden Sie den Agent-Installer für die neue "Workshop"-Site herunter und verwenden Sie diesen für alle neuen Geräte, die Sie erstellen. Dadurch wird sichergestellt, dass alle neuen Geräte zuerst der "Workshop"-Site beitreten.
Wählen Sie die neue "Workshop"-Site aus und klicken Sie dann auf das Symbol "Geplanter Auftrag".
Benennen Sie den Auftrag und klicken Sie auf die Schaltfläche "Planen".
Für unsere Zwecke ist es unerheblich, ob Sie die Option "On Connect" oder "Initial Audit" wählen. Dies liegt daran, dass wir PowerShell verwenden, um zu steuern, welche Teile des Skripts für welche Art von Betriebssystem ausgeführt werden. Wir verwenden nur eine dieser Optionen als Auslöser, um zu erkennen, dass ein neues Gerät hinzugefügt wurde.
Fügen Sie Ihre neue benutzerdefinierte Maschinenvorbereitungskomponente hinzu.
Stellen Sie sicher, dass der Auftrag niemals abläuft - wir wollen sicherstellen, dass er ausgeführt wird, wenn das Gerät verfügbar ist.
Legen Sie schließlich die Benachrichtigungsoptionen fest, wenn Sie informiert werden möchten, wenn das Skript zur Maschinenvorbereitung nicht ausgeführt werden kann.
Sobald die Vorbereitungskomponente der Maschine abgeschlossen ist, können Sie das Gerät vom Standort "Werkstatt" zum richtigen Kundenstandort verschieben.
