Quantcast
Channel: Edi Pfisterer - Schulnetz.info » Windows Deployment Services
Viewing all 12 articles
Browse latest View live

Installation der neuen PCs übernehmen bei mir die SchülerInnen selbständig ;-)

$
0
0

Step-by-Step-Anleitung: WDS UND RIS im Parallelbetrieb

Es ist möglich, RIS (bzw. WDS im Legacy-Mode) und Windows Deployment Service parallel auf 2 Domänencontrollern zu betreiben!
[Btw: eine detailreiche Anleitung zur Installation von WDS gibts hier]

Gründe für den Prallelbetrieb:

  • Während der Einführung (Testphase) von WDS sollte die OS-Verteilung über RIS weiterhin funktionieren!
  • Windows Deployment Service bietet mit Boardmitteln keine Möglichkeit, dem Client einen Namen zu vergeben. EDIT: Die Clients könnten im Parallelbetrieb unter RIS ins AD eingetragen und benannt werden. Möglich wäre aber auch die Benennung per WDS:
    Wenn man in der Unatted.xml folgenden Eintrag weglässt, dann können die Clients während des Rollouts benannt werden: <ComputerName>%machinename%</ComputerName>
     

Ausgangssituation

Bestand: 1 Domänencontroller mit DNS / DHCP / WDS im Legacy Mode
Neu: 1 zusätzlicher Domänencontroller mit DNS / WDS

Probleme beim Parallelbetrieb:
Ein zentrales Moment beim Betrieb von WDS nimmt der DHCP-Server ein. Leider hat Microsoft in keiner mir bekannten Dokumentation vorgesehen, dass es folgende Konstellation gibt:
Domänencontroller 1 : DNS / DHCP / WDS im legacy Mode
Domänencontroller 2: DNS / WDS

Die Schwierigkeit besteht nun darin, dem DHCP-Server mitzuteilen, dass (evtl. in bestimmten VLANs) der WDS auf einem anderen Server “lauscht”…

Konfiguration des DHCP, der auf einem DC mit WDS im Legacy Mode betrieben wird und der künftig die Clients des jeweiligen Subnetzes auf einen anderen DC mit WDS verweisen soll:

Der Screenshot zeigt eigentlich schon alle Einstellungen, die nötig sind, damit im jeweiligen VLAN der WDS am Domänencontroller (OHNE DHCP) aufgerufen wird.
Besonderes Augenmerk ist auf folgende Optionsnamen zu legen:
067 Name der Startdatei/
066 Hostname des Startservers/
060 PXE-Client/
das kryptische 043 Herstellerspezifische Information

Der Eintrag
043 Herstellerspezifische Informationen MUSS folgenden Eintrag enthalten
010400000000ff

Fazit: Nun steht dem Parallelbetrieb nichts mehr im Wege


WDS: Image wird nicht oder manchmal nicht kopiert

$
0
0

Problem: ein Image lässt sich per WDS nicht verteilen, es kommt zu folgender Fehlermeldung:

Windows could not parse or process unattend answer file
[unattend.xml] for pass [specialize].

Die Antwortdatei für die unbeaufsichtigte Installation [unattend.xml]
für Durchgang [specialize] konnte nicht analysiert oder verarbeitet werden.
Die Antwortdatei ist ungültig.

mögliche Ursache und Lösung:

Seit Windows Vista muss eine konsistente Situation zwischen C:\users\username\NTUSER.dat (.man) und dem jeweiligen Registry-Eintrag in ”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\” vorliegen.

Folgen einer Inkonsistenz:
a) der betreffende User kann sich nicht mehr einloggen (“Fehler bei der Anmeldung mit dem Benutzerprofildienst.”) oder:
b) der betreffende User wird mit einem temporären Profil angemeldet (Hinweis in der Taskleiste)
c) ein Image mit inkosistenten Profilen kann bei einer Verteilung über WDS zu obiger Fehlermeldung führen

mögliche Lösungen:

A) bevor SYSPREP das System für die Verteilung vorbereitet:

  • Profile vor der Vorbereitung mit SYSPREP über computer/rechte Maustaste -> Eigenschaften/erweiterte Systemeinstellungen/Benutzerprofile löschen [dadurch wird das Profil und der RegistryEintrag entfernt]
  • falls das Profil (=Ordner) bereits gelöscht wurde, müssen die RegistryEinträge manuell entfernt werden

B) wenn schon alles zu spät ist, dh, man hat das Image bereits auf den Server zurückgespielt (mit inkonsistenten Profilen)

  1. in der Unattend.xml die Zeile “<copy proflie>true</copy profile> löschen! dadurch wird obiger Fehler vermieden, das Image wird fehlerlos kopiert (Leider aber auch die inkonsistente Profilstruktur). Die dadurch entstehenden Konsequenzen habe ich schon oben beschrieben. Dies lässt sich aber durch folgenden Workaround lösen:
  2. mein Tool “Profil_Registry_Reparatur.vbs [1064 x heruntergeladen]” per Startscript auf den betroffenden Clients einmalig laufen lassen. Dadurch werden die entsprechenden Einträge aus der Registry entfernt bzw. falls noch Reste des Profils vorhanden sind (dh, “nur” die ntuser.dat beschädigt/fehlt) , wird dieses umbenannt.

PS: eine auch mit beschädigten Profilen funktionierende XML-Datei findet ihr hier

WDS 32-bit / 64-bit Wirr Warr

$
0
0

Nicht selten kommt folgendes Szenario vor:
64-bit [x64] Server mit Windows 2008 R2 – WDS
32-bit [x86] Clients, auf denen Windows 7 per WDS installiert werden soll

Um Multicast-Verteilung zu ermöglichen, muss das Startabbild boot.wim von einer Server 2008 Version verwendet werden.
Und genau hier beginnt die Misere…

Meiner Erfahrung zufolge booten z. B HP dc7900 (ein weit verbreiterter Client in Schulen) – obwohl 32-bit Struktur – auch mit dem Startabbild, das von einer Windows Server 2008 R2 (64-bit!!!) erstellt wurde.

das Problem dabei:
es werden keine 32-bit [x86] – Installationsabbilder nach dem Booten von PE angezeigt!!!

Lösung:
am WDS ein Startabbild von einer 32-bit Windows Server 2008 erstellen
in der Kommandozeile am WDS folgendes eingeben:
WDSUTIL /Set-Server /DefaultX86X64ImageType:both

dadurch wird die BCD (Boot Configuration Data) dahin gehend verändert, dass die BCD aus dem Pfad boot\x86-based and x64-based verwendet wird (die ihrerseits ein Konglomerat aus boot\x86\default.bcd + alle Startabbilder-bcd in boot\x86\Images und boot\x64\Images darstellt)
Weiterführende Infos hier

und weils gerade hier her passt, noch ein paar Tipps zum WDS:

  • hier wird beschrieben, wie man einfach und lässig ältere Treiber einer .wim unterjubelt
  • hier werden mehrere Lösungswege beschrieben, wenn die Fehlermeldung lauten sollte: “the system cannot find the file specified
  • nach dem booten von Windows PE öffnet SHIFT + F10 ein DOS-Fenster (ipconfig, net use ….)

Windows Deployment Service – Fehlermeldungen

$
0
0

Auch Spass muss sein ?!?

Eines der unschönen Eigenschaften von WDS besteht darin, dass Fehlermeldungen vom tatsächlichen Fehler ablenken.

Nachfolgend eine Liste mir bekannter Fehlermeldungen, deren Ursache und eine mögliche Lösung, um die Fehlerursache zu beseitigen…

Fehler [meldung] [mögl.] Ursache [mögl.] Lösung
Windows PE wird nicht geladen oder nach dem kopieren des Installationsimages bricht das Setup ab.
Fehlermeldung:
Unerwarteter Fehler bei der Windows-Installation, stellen Sie sicher, dass auf die Installationsquellen zugegriffen werden kann und starten Sie die Installation erneut
0xC0000005
wenn Windows PE abbricht:
zu wenig RAM
(mind. 512 MB für Windows PE)
wenn das Installationsimage abbricht:  RAM defekt
RAM austauschen / aufrüsten
(evtl. Test durch Booten mit Knoppix + “memtest”
es können keine Images auf den WDS kopiert werden; Abbruch mit der Meldung
the system cannot find the file specified
WDS wurde nicht richtig für x86 und x64-bit konfiguriertoderzuwenig freier Speicherplatz am WDS 
  • am Datenträger mit \\server\reminst]
  • im Ordner von TMP / TEMP [Umgebungsvariablen]
am WDS in einer CommandShell folgenden Befehl (in 1 Zeile) eingeben:
WDSUTIL /set-server /DefaultX86X64ImageType:both
bzw. 
  • Speicherplatz am WDS-Datenträger mit der Freigabe “reminst” schaffen
  • Systemvariablen TMP/TEMP auf ein anderes Laufwerk umlegen
x86 Installationsabbilder, die am WDS angezeigt werden, erscheinen nicht am x86 Client zur Auswahl
keine Fehlermeldung
x86 – Clients starten sowohl mit x64 als auch x86 Versionen von Windows PE;es werden aber nur die jeweiligen Installationsabbilder angezeigt, die
a) die selbe Architektur wie PE haben UND
b) zur jeweiligen Architektur des Clients passen
für Clients mit x86 MUSS [bei Verwendung der Multicast-Fähigkeit]Windows PE von einem x86-Datenträger verwendet werden (also von Server 2008 32-bit)
[2008 R2 gibts nur noch in der 64-bit Version!]wenn dieser Datenträger nicht vorliegt, dann kann Windows PE auch von einem Windows 7 32-bit genommen werden
(Achtung: es gibt dann keine Unterstützung von Multicasting)
Die Antwortdatei fuer die unbeaufsichtigte Installation [unattend.xml]
fuer Durchgang [specialize] konnte nicht analysiert oder verarbeitet werden.
Die Antwortdatei ist ungueltig. [windows could not parse or process unattend answer...]  

mit der Antwortdatei ist alles in Ordnung ;-)
das Problem besteht in Wirklichkeit im Image, das inkonsistente Profile aufweist
<copy proflie>true</copy profile>
aus der XML-Datei löschen oder besser noch Profile vor dem kopieren des Image auf den WDS reparieren
siehe hier
 Fehlermeldung beim Booten von Windows PE:
WdsClient: Fehler beim Abrufen einer IP-Adresse vom DHCP-Server. Stellen Sie sicher, dass in diesem Netzwerksegment ein funktionierender DHCP-Server in Betrieb ist.”

mit dem DHCP-Server ist natürlich alles in Ordnung;Es liegt kurioserweise an einer fehlerhaften Konfiguration des BIOS
(von mir gefunden bei einem DiMotion – Client mit einem American Megatrend – BIOS)
 Lösung:
BIOS auf “Standard-Default” (NICHT optimal Default) zurücksetzen,
Booten von der Netzwerkkarte wieder auf “enabled” setzen
fertig!

 

[... to be continued? ]

Windows Server Command-Line Reference

$
0
0

Weil ich soeben zufällig darüber gestolpert bin:
Windows Server Command-Line Reference

viele “alte Bekannte” aber auch – zumindest mir – neue Befehle…

mir persönlich hats der WDSutil – Teil speziell angetan…

[weil ich derzeit eine Software bastle, die mir das gesamte AD inkl OUs + zugehöriger Clients und deren MAC-und IP-Adressen einliest und mir dadurch ermöglicht, einzelne oder alle Clients einer OU
- zu rebooten
- herunterzufahren
- per WOL "aufwecken" und
- dann per WDS remote neu aufzusetzen...]

Image von WDS ohne PXE

$
0
0

Problem:
Ein Rechner, der nicht über PXE bootet (da die eingebaute Netzwerkkarte PXE nicht untersützt),  sollte dennoch via Windows Deployment Service (WDS) installiert werden

Lösung:
Es soll ein USB-Stick derart eingerichtet werden, dass man von ihm booten kann und damit auf den WDS zugreift

einzelne Schritte:

  1. geeigneten USB-Stick bereithalten (> 128 MB)
  2. USB-Stick einrichten, dass von ihm gebootet werden kann
    1. Stick einstecken
    2. Start/Zubehör/ CMD -> rechte Maustaste -> als Administrator ausführen
    3. folgendes eingeben diskpart

       

      list disk     >> aufgrund der Größenangaben ergibt sich die Nummer des USB-Sticks
      select disk [Nummer des USB-Sticks]
      clean
      create partition primary
      select partition 1
      active
      format fs=fat32 QUICK
      assign
      exit 

    4. am WDS-Server:
      1.) Ins Verzeichnis
      C:\Program Files\Windows AIK\Tools\PETools navigieren
      2.) Befehl starten: 

      copype.cmd x86 e:\winpe_usb

      (Anmkerung: x86, amd64, oder ia64 steht für die Architektur des Clients, der mit dem USB-Stick gebootet werden soll, e:\winpe_usb ist der Zielpfad, in dem die erforderlichen Datein erstellt werden)

    5. Inhalt des nun erstellten Ordners bzw. Unterorders “ISO” auf den USB-Stick kopieren: 

      xcopy E:\WinPE_USB\iso\*.* /s /e /f G:\

      wobei E:\WinPE_USB\iso dem Pfad entspricht, in den wir zuvor die Dateien mit copype kopiert haben und G:\ dem Pfad des USB-Sticks entspricht 

    6. ein Suchabbild in der WDS-Management-Konsole erstellen:

    7. das soeben erstellte Suchabbild auf den USB-Stick in das Verzeichnis “\SOURCESkopieren und umbenennen in boot.wim 

    8. FERTIG!!!
    9. AM CLIENT:
      USB-Stick einstecken, im BIOS die Bootreihenfolge verändern
      (ACHTUNG: es gibt BIOS, in denen ein USB-Stick als Festplatte erkannt wird!
      Daher kann es sein, dass man als die Festplatte als erste Startoption beibehalten muss, und in einem anderen Menü die Reihenfolge der “Festplatten” dahingehend verändert, dass der USB-Stick VOR der HD kommt)

Resumee:
Der Client bottet nun via USB-Stick ein Windows PE, holt sich dabei via DCHP eine IP-Adresse, verbindet sich zum WDS-Server und ab dann geht alles – wie gewohnt vom PXE-Boot – weiter.

KMS – Freund und Feind zugleich…

$
0
0

Key Management Service (KMS) – eine Übersicht

Wer von Windows XP auf Windows 7 migriert (hat), wird schon bemerkt haben, dass die Art der Lizenzierung / Aktivierung (bei XP zu Erinnerung: Campuslizenz mit einem Key, der bereits im geklonten Image bereitgestellt werden kann) rapide geändert wurde.

Grundsätzlich gibt es 2 Möglichkeiten:
Die zentrale Aktivierung via KMS-Server (und daher bessere) und die dezentrale mit Eingabe der MAKs auf den einzelnen Clients inkl. manueller Aktivierung (und daher wesentlich arbeitsintensivere und schlechtere.)

Da mein Credo zu allen Tages- und Nachtzeiten (in Ahnlehnung an die schweizer Kollegen) lautet “Real Men don’t click [more than necessarily]” verzichte ich auf die Besprechung der MAK-Variante völlig und wende mich nun in weiterer Folge der Konfiguration eines KMS-Servers (inkl. aller dabei auftretenden Schwierigkeiten) zu!

Step by Step Anleitung: “Installation eines funktionierenden KMS-Servers”

1.) Windows Server 2008 R2 installieren und manuell mittes des über die MS-ACH erhaltenen MAKs für Windows Server 2008 aktivieren (Start >> Systemsteuerung >> System >> Windows Aktivierung)

2.) KMS aktivieren
eine Command-Shell [= Eingabeaufforderung] als Administrator starten (rechte Maustaste >> “als Administrator ausführen”), dann folgende Befehle in der angeführten Reihenfolge absetzen:

cscript C:\windows\system32\slmgr.vbs /ipk <KMS Key>
cscript C:\windows\system32\slmgr.vbs /ato

Hinweis: nach jedem Befehl öffnet sich eine Meldung, die den Erfolg der Aktion ausgibt

3.) Firewall kontrollieren, ob der KMS auch “einen Passierschein hat”
[Stichwort: eingehende Regeln >> Schlüsselverwaltungdienst (TCP eingehend) >> Zulassen ]

4.) Eintrag am DNS-Server kontrollieren
DNS-Management-Konsole >> Forward-Lookupzonen >> FQDN >> _TCP >> _VLMCS (Eintrag des Servers, der
den KMS-Host darstellt
(Falls dieser Eintrag fehlt:
>> Forward-Lookupzonen >> FQDN >> _TCP >> rechte Maustaste >> weitere neue Einträge >> Dienstidentifizierung (SRV) >>  Dienst: _VLMCS // Protokoll: _tcp // Priorität: 0 // Gewichtung: 0 // Portnummer: 1688 // Host, der diesen Dienst anbietet = FQDN des KMS-Servers // beide Kontrollkästchen bleiben leer // Gültigkeit 0:1:0:0)

5.) KMS kontrollieren
Start / Ausführen:  slmgr.vbs /dli
Es erscheint – nach kurzem Warten – ein Popup mit einigen Daten, unter anderem der Zeile
aktuelle Anzahl: 7 (wobei hier 7 nur ein Beispiel ist…)

Sollten die Clients nicht innerhalb kürzester Zeit die Aktivierung erhalten, dann lohnt sich die weitere Lektüre dieses Artikels garantiert!!!!

Problemfelder bei der Lizenzierung mittels KMS
(Arbeitstitel: der Dreck funktioniert bei mir nicht…):

1.) Der KMS arbeitet erst ab einer durch ihn verwalteten Anzahl von 25 Clients!!!!

PROBLEM:
selbst, wenn man > 200 (z. B. mit WDS) geklonte Clients in Betrieb hat, kann es dennoch sein, dass den Clients die Aktivierung mit folgender Fehlermeldung verwehrt wird:

0xC004F038
Vom Softwarelizenzierungsdienst wurde gemeldet, dass der Computer nicht aktiviert werden konnte. Die vom Schlüsselverwaltungsdienst (Key Management Service, KMS) gemeldete Anzahl reicht nicht aus. Wenden Sie sich an den Systemadministrator.

die Ursache hierfür könnte nun darin liegen, dass wir zwar mehr als 25 Clients verwalten möchten, der KMS-Server aber keinen Unterschied zwischen unseren Clients erkennt…
Mit anderen Worten: für ihn gleichen unsere Clients wie ein Ei dem anderen…
Dies führt uns zu folgendem:

2.) mindestens 25 Clients müssen eine unterschiedliche CMID haben!
damit einhergehend:
3.) What the hell is a CMID?

Jeder Client generiert überlicherweise eine einzigartige Client Machine ID (CMID). Um dies zu gewährleisten, sollten Clients vor deren Klonen auch mit
sysprep /generalize [/oobe /shutdown]

darauf vorbereitet werden.

Sollte das Klonen per Windows Deployment Service (WDS) erfolgen, so ist zwecks Lite- bzw. Zerotouch-Deployment das Hinterlegen einer ImageUnattend.xml unumgänglich!

Sollte nun in dieser ImageUnattend.xml der Eintrag
<SkipRearm>1</SkipRearm>
vorhanden sein, dann werden – auch bei fehlerfrei ausgeführtem SYSPREP – keine neuen CMIDs generiert.

Daher zählt der KMS auch die Anzahl der Anfragen nicht hinauf, und dann wären wir wieder bei Problem Nummer 1: der KMS arbeitet erst aber einer Anzahl von 25 Clients!!!

4.) Zwischenfrage: Welche CMID hat der Client?

Grundsätzlich scheint die CMID auf, wenn man am Client slmgr.vbs /dli ausführt UND der Client bereits aktiviert ist!
Wenn der Client noch nicht aktiviert ist (was auch der Fall sein dürfte, sonst wäre uns die CMID nämlich ziemlich
všecko jedno) funktioniert dies aber nicht!

Um bei nicht aktivierten Clients die CMID zwecks Vergleichens zu ermitteln, ist ein Blick in die Ereignisanzeige anzuraten:

Protokollname: Application
Quelle:        Microsoft-Windows-Security-SPP
Datum:         20.02.2012 23:58:24
Ereignis-ID:   12288
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      DV101.hak-neusiedl.local
Beschreibung:
Vom Client wurde eine Aktivierungsanforderung an den Computer mit dem Schlüsselverwaltungsdienst gesendet.
Info:
0×00000000, 0×00000000, wicky.hak-neusiedl.local:1688, 586a12e2-5e2f-4c55-a6c0-0152af448ec4, 2012/02/20 22:58, 0, 3, 43200, ae2ee509-1b34-41c0-acb7-6d4650168915, 25

CMID in diesem Fall:586a12e2-5e2f-4c55-a6c0-0152af448ec4

Wenn nun alle geklonten Clients eine idente CMID haben, dann wäre es nun an der Zeit für folgendes:

4.) Holt mich hier raus, ich bin ein Star ;-)

3 Lösungsansätze stehen zur Verfügung (The Good, The Bad, The Ugly)

LÖSUNG – Variante 1
>> mindestens 25 Clients neu zu klonen:
(The UGLY!)

die richtige Vorgehensweise dabei:
Client vorbereiten mit
sysprep /generalize /oobe /shutdown
+
in der ImageUnattend.xml
<SkipRearm>0</SkipRearm>

Nachteil dieser Variante: Arbeitsintensiv, im laufenden Betrieb nicht machbar!

LÖSUNG – Variante 2
>> mindestens 25 Clients manuell mit neuen CMIDs versehen:
(The BAD)

Wenn slmgr.vbs /rearm am Client ausgeführt wird, so wird eine neue CMID generiert.
Btw: Dies kann auf jedem Client bis zu 3 mal wiederholt werden, die aktuell verbleibende Anzahl kann am Client mit slmgr.vbs /dlv abgelesen werden!

Da mindestens 25 Clients mit unterschiedlicher CMID zu einem funktionierenden KMS führen würde, könnten wir jetzt kurzerhand zu 25 Clients laufen, dort slmgr.vbs /rearm eingeben, jeden Client neu starten und der KMS läuft jetzt endlich!

Doch halte inne und bedenke:
Real Men don’t click (and – of course -  don’t run around)

LÖSUNG – Variante 3
>> mindestens 25 Clients per Startscript mit neuen CMIDs versehen:

(The GOOD!!!!)

Hier ein Script, das – per Gruppenrichtlinie als Starskript – für Dich die Arbeit erledigt:

'############## Edi Pfisterer -- 11/5/2012 -- REARM_IT ##############

on Error resume next
logdatei = "c:\rearm.txt"
Set fs = CreateObject("Scripting.FileSystemObject")
If NOT fs.FileExists (logdatei) then

'############################ just rearm it, baby ############################'

Set WshShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run("wscript ""c:\windows\system32\slmgr.vbs"" /rearm ")

'##########################   LOGDATEI schreiben, die anzeigt,
ob REARM schon einmal gelaufen ist ########################

    Set a = fs.CreateTextFile(logdatei, True)
    a.WriteLine("rearmed wurde am " & now())
    a.Close
END IF

Funktionsweise:
Es wird auf C:\ eine Datei namens rearm.txt angelegt, weiters wird slmgr.vbs /rearm aufgerufen.
Beim nächsten Aufruf des Startscripts wird geprüft, ob die rearm.txt vorhaden ist, und in diesem Fall auf slmgr.vbs /rearm verzichtet….

5. wie schauts mit einer GUI aus?

Kein Problem! Mit dem VAMT (Volume Activation Management Tool) 2.0 (ACHTUNG: ZWEI — PUNKT — NULL // Das 1.0 war zum Vergessen!!!) hat man ein feines Tool zur Hand, das einen klaren Überblick über die Lizenzierungssituation gibt!
Aber ACHTUNG: Wenn der KMS nicht richtig funktioniert, dann wir man mit dem VAMT auch keinen Spass haben!!! Das VAMT ersetzt den KMS NICHT!!!

Vorgangsweise Installation / Verwendung von Volume Activation Management Tool:

  • VAMT 2.0 bei Microsoft downloaden (googlen ist den Menschen zumutbar)
  • am KMS installieren und starten
  • im mittleren Fenster “Search for computers in the Active Directory” auswählen
  • alle im unteren, mittleren Fenster gefunden Clients mit STRG + A makieren
  • Rechte Maustaste >> Update Status / Current Credential (sofern man als Domainadmin angemeldet ist)
  • Nun erfolgt eine Einteilung in
    Licensed
    Out-of-Box
    Out of Tolerance Grace
    (Tipp: Falls dort alle Clients landen und keine bei Licensed, dann wurde das Problem der identen CMIDs – noch – nicht gelöst!)
  • Wenn sich noch nicht alle Clients unter “Licensed” einreihen, dann hilft
    recht Maustaste auf den/die Clients >> Activate >> KMS Activate >> …

Im Idealfall sieht das ganze dann so ähnlich aus (in dieser Umgebung sind > 160 Clients vorhanden, da wäre eine Aktivierung via MAKs kein Spass gewesen…):

Da fällt mir mein Schwager ein, der bei dieser Gelegenheit sagen würde
“Hätte es immer schon SO ausgesehen, hätte man nichts machen müssen… ;-)

FAZIT:

Der KMS ist – wenn man eine große Anzahl von Windows 7 Clients administrieren darf – eine feine Sache! Wenn er erst einmal funktioniert…

WDS: Clients im Active Directory mit der GUID oder MAC anlegen (Prestaging)

$
0
0

Mit dem WDS (Windows Deployment Services) ist es möglich, den Computername bereits vor dem Ausrollen im Active Directory festzulegen – und so ein Zerotouch-Deployment zu realisieren.
Dieser Vorgang nennt sich “Prestaging” und erfolgt unter Verwendung der MAC-Adresse bzw. GUID.

[Auf die Gestaltung der GUID bzw. deren Zusammensetzung gehe ich hier nicht näher ein, Google kennt sich damit hinlänglich aus...]

Aber ACHTUNG!!!!!!!!!
Das am Startbildschirm angezeigte Format der GUID bzw. MAC darf in dieser Form NICHT 1:1 für das Prestaging verwendet werden.

Lesen Sie weiter:

Kurzanleitung, einen Client inkl. MAC oder GUID im Active Directory vorzubereiten (prestagen):

  • Am Server, auf dem Windows Deployment Services [WDS] installiert ist, Active Directory-Benutzer und -Computer aufrufen (gegebenenfalls start->ausführen->dsa.msc).
  • in der entsprechenden Organisationseinheit -> Rechte Maustaste -> Neu -> Computer
  • Name des Clients festlegen
    neuerComputer
  • GUID oder MAC eingeben
    verwalteterComputer
  • Woher nun aber die GUID bzw. MAC nehmen?
    MAC: DHCP-Server, Verpackung, Aufkleber auf Client, Start-Bildschirm
    GUID: Start-Bildschirmstartbildschirm
  • Formatierung beim Eintrag beachten!!!! (und das ist die EIGENTLICHE CHALLENGE!!!)

Fall 1: Verwendung der MAC-Adresse (hier laut Bildschirm 00 03 FF B4 E5 EC )

Eingabe beim Prestaging:
{00000000-0000-0000-0000-0003FFB4E5EC}        ACHTUNG: inkl. {}
 oder
000000000000000000000003FFB4E5EC                ACHTUNG: OHNE – und {}

Fall 2: Verwendung der GUID
(hier laut Bildschirm 59888FA8-D0E2-1A46-8191-5546FAEC2184 )

Eingabe beim Prestaging:
{A88F8859-E2D0-461A-8191-5546FAEC2184}    ACHTUNG: {}  und ”Buchstabendreher”!!
Erklärung:
Die rot angezeigten Zeichen “drehen” innerhalb der durch “-” getrennten Gruppe, dh, die letzten beiden [A8] sind die ersten beiden, die vorletzten beiden sind die zweiten beiden [8F] usw..) 
oder

59888FA8D0E21A4681915546FAEC2184                ACHTUNG: OHNE – und {}

Anlässlich der Frage, was sich Microsoft dabei gedacht hat, beim Prestaging und der Anzeige am Bildschrim kein einheitliches Format zu wählen… fällt mir ein Sinnspruch, der hier wieder einmal schriftlich festgehalten werden sollte:

Der Magen einer Sau,
die Tasche einer Frau,
das Innere der Wurscht
sind großteils unerfurscht


Reiter “Remoteinstallation” erscheint im AD nicht (WDS)

$
0
0

Infrastruktur:
1 x DomänenController
1 x WDS-Server als Memberserver ohne AD-Dienste

Problem:
x Am DomänenController erscheint unter “Active Directory Benutzer und Dienste” der Reiter
“Remoteinstallation” nicht bei den Eigenschaften der Computer;
x Prestaging ist nicht möglich

Lösung:
Folgende Dateien vom WDS auf den DomänenController kopieren (jeweils ins selbe Verzeichnis)

%systemroot%\system32\imadmui.dll
%systemroot%\system32\DE-DE\imadmui.dll.mui

-> am Domänencontroller die .dll in einer Commandshell (als Administrator ausführen) registrieren mit

regsvr32 imadmui.dll

Adminomat kann in der Version 1.3 auch installierte Software suchen

$
0
0

Seit Version 1.3 kann die von uns entwickelte Software “Adminomat” auch installierte Software auf Clients im AD anzeigen.

Anlassfall war die Frage, ob eine ausgerollte Software per GPO auch auf allen Clients angekommen ist…
(also etwas sehr häufiges)

Alle anderen wirklich lässigen Funktionen von ADMINOMAT sowie der Download unter

http://www.adminomat.at/produktvergleich/

Und da ein Bild mehr als 1000 Worte sagt:
adminomatAdminomat_DetailsAdminomat_Anzeige

praktische Software: “ADMINOMAT”, um Remote ganze Schulungsräume aufzusetzen

$
0
0

Adminomat_2.0


Ziel der Software “Adminomat”:

Main Feature:
Ganze Schulungsräume remote über WDS aufzusetzen, in dem alle gewünschten Clients remote per WOL gestartet werden.

Dies ist möglich durch die Kombination von Windows Active Directory (AD), Wake on Lan (WOL) und Windows Deployment Service (WDS) in einem einzigen Tool!

Dadurch können Rollouts von Images für ganze Organisationseinheiten eines Active Directory erfolgen, ohne dass der Administrator physikalisch zum Client gehen muss!

Zusatzfeatures:
ganze Organisationseinheiten (zb. Schulungsräume, Abteilungen, etc) können remote gestartet werden, neu gebootet werden, oder heruntergefahren werden.
Weiters kann eine Auswahl getroffen werden, nach folgenden Kriterien:

  • angemeldete User
  • OU des angemeldeten Users
  • x86/x64
  • Datum der letzten Installation
  • Gerätehersteller bzw. -typ
  • RAM
  • etc etc

Voraussetzungen (für die volle Funktionalität):

Server:
Betriebssystem: ab Windows Server 2003 R2 / 2008 / 2008 R2
WDS sollte installiert sein (optional, damit der WDS bedient werden kann)
Verwendung von Microsoft – DHCP – Server ist vorteilhaft

Clients:
Im BIOS muss Wake On Lan einmalig aktiviert werden (inkl. bei Remotesitzung von Remoteserver booten);
Unter Windows muss in der Energieverwaltung der Netzwerkkarte folgendes aktiviert werden:
“Gerät kann Computer aus dem Ruhezustand aktivieren”

Download / Installation:

Das Tool wird NICHT installiert, sondern wird lediglich von einem beliebigen Ordner (auch USB-Stick o. ä.) am Server gestartet.
Am System wird NICHTS verändert!!!
Das Tool läuft auf jedem Windows Client ab XP!!!
Um den WDS zu bedienen und so ein Zero-Touch-Rollout zu starten, muss das Tool allerdings auf einem WDS-Server gestartet werden

Download unter:

www.adminomat.at

Handhabung und Funktion:
WICHTIG: das Tool sollte mit erhöhten Rechten ausgeführt werden –>
Rechte Maustaste auf das Tool –> “als Administrator ausführen”

Bedienung:

Clients remote per WDS neu aufsetzen:

a) kontrolliere deine “UnattendedPE.xml” auf das gewünschte INSTALLATIONSabbild im Abschnitt

<InstallImage>
<ImageName>schulungsraum</ImageName>
<ImageGroup>windows7</ImageGroup>
<Filename>schulungsraum.wim</Filename>
</InstallImage>

btw: meine 100%ig funktionierende .xml gibt’s hier zum DOWNLOAD

b) Wichtig: Du solltest nur 1 STARTabbild aktiviert haben!!!

c) wenn ADMINOMAT am WDS-Server gestartet wird, gibt es den Menüpunkt “WDS” –>  ”ohne F12″
-> dadurch muss auf den Clients nicht mehr die Taste F12 gedrückt werden!!!
(es erscheint ein roter Hinweis, dass derzeit alle startenden Clients neu aufgesetzt werden…)

d) STARTE nun die gewünschten Clients oder die gesamte OU durch drücken des Buttons

e) WARTE ein paar Minuten (bis auf allen Clients PE gebootet hat)

f) drücke anschließend wieder den Button “mit F12″
(ansonsten wiederholt sich der Vorgang beim 1. Reboot und der Client wird zum 2. mal neu aufgesetzt…)

 

technischer Hintergrund
Wake on LAN wurde über das Tool wake.exe von Matthias Zirngibl (http://masterbootrecord.de/docs/wakeup.php) realisiert.)

 

in diesem Sinne

Have fun!

DELL Precision 3430 / 3431 / etc – WDS-Rollout fail

$
0
0

Problem:
Bei besagen Clients von DELL (Precision 3430 / 3431 / andere Modelle), die mit INTEL-Netzwerkkarten ausgerüstet sind, kann es zu folgender Fehlermeldung kommen, wenn man versucht, per WDS ein Image auszurollen:

“WdsClient: Fehler beim Abrufen einer IP-Adresse vom DHCP-Server. Stellen Sie sicher, dass in diesem Netzwerksegment ein funktionierender DHCP-Server in betrieb ist”

Der Versuch, die zugehörigen Treiber in WDS nachzuladen (“Treiberpaket hinzufügen”) scheitert mit der Meldung:
“Einige Pakete konnten nicht hinzugefügt werden….” bzw. x64-basierte müssen eine Signatur besitzen”)

Lösung:
Am WDS-Server NICHT die Treiber integrieren, sondern ein neues Startabbild hinzufügen, das man einem
Windows 10 1903 64bit .iso entnimmt (“boot.wim” im Ordner “sources” )
Darin sind offensichtlich die passenden Treiber für die NIC bereits enthalten

Viewing all 12 articles
Browse latest View live