94209
Oct 04, 2010, updated at 11:45:22 (UTC)
18528
3
0
Windows Deployment Services Benennungsrichtlinie für Clients deaktivieren bzw. umgehen?
Hallo,
mein Name ist Sebastian und ich arbeite seit einer Woche mit WDS. Ungefähr genau so lang beschäftige ich mich nun schon mit dem folgendem Problem und ich hoffe, dass mir einer von euch helfen kann.
Umgebung:
Server 2008 R2 mit Hyper V
3 virtuelle Maschinen:
Server 2008 R2 als DC, DHCP, DNS
Server 2008 R2 mit WDS
Testclient
Also, ich habe mit dem WDS ein Aufzeichnungsabbild erstellt und ein gesyspreptes W7 Enterprise im WDS aufgezeichnet. So weit so gut. Ich habe das Image nun an meinen Testclient verteilt und in der unattend.xml den Computernamen leer gelassen damit er wie gewöhnlich abgefragt wird, weil es im Unternehmen eine spezielle Namenskonvetion gibt, die mit der automatischen Benennungsrichtlinie nicht zu realisieren ist.
Nach der Installation musste ich aber leider fest stellen, dass nicht wie erwartet nach dem Computrname gefragt wurde sondern der Benutzername des von mir eingerichtetem Benutzers zur Anmeldung am WDS (WDS-Installer) auch der Computername war. Die automatische Domainaufnahme lief reibungslos.
Ich hab also angefangen zu googeln und verschiedene Lösungsansätze gefunden, die allerdings alle nicht funktioniert haben. Ich möchte Sie an dieser Stelle kurz auflisten damit ihr mir vielleicht sagen könnt ob ich irgendwo einen Fehler gemacht habe bzw. ob es bekannte Fehlerquellen bei diesen Schritten gibt.
unattend.xml:
Wie ich bereits erwähnte habe, habe ich einen ähnlichen Beitrag gefunden in dem geraten wurde den Computername in der unattend.xml frei zulassen "ComputerName" in der Komponente "Microsoft-Windows-Shell-Setup" Phase 4 "specialize" . Erfolglos.
PE manipulieren:
Ich habe nach einigen Stunden google.de einen Technetbeitrag gefunden in dem dieses Problem ebenfalls beschrieben war. Man sollte sich ein VBScript anhand eines enthaltenem Beispiels schreiben bei dem man beim Start der PE noch einmal nach dem Computernamen und der OU gefragt wird. Ich habe nach längerem rumprobieren ein funktionierendes Script gehabt welches ich über ImageX in das Startabbild kopiert und wie beschrieben in der Winpeshl.ini den Aufruf eingefügt habe. Leider wurde das Script nicht geladen. Man lässt sich ja nicht aus der Ruhe bringen also hab ich den 2ten beschriebenen Weg auch probiert und das Script über die Startnet.cmd aufgerufen, was ich vorher auch probiert habe und es funktionierte, nur eben nicht bei Installationsstart. Das Script lässt sich also einfach nicht ausführen. Wer das jetzt nicht so richtig nachvollziehen konnte hier die Quelle Tech-Net Artikel .
Um es nochmal kurz zu umschreiben, ich möchte meine Images mit WDS verteilen, aber den Computername manuell vergeben bzw. soll der Benutzer die Eingabe machen. Leider kann ich diesbezüglich keinen Kompromiss eingehen wegen der oben erwähnten Namenskonvention.
Am liebsten wäre mir es diese Benennungsrichtlinie kompeltt zu deaktivieren, aber wie es scheint ist das nicht möglich. Vielleicht hat ja einer von euch ein ähnliches oder sogar das selbe Problem und eine Lösung dafür parat. Ich bin wirklich am verzweifeln.
Vielen Dank im voraus.
MfG
Sebastian
Server 2008 R2 mit Hyper V
3 virtuelle Maschinen:
Server 2008 R2 als DC, DHCP, DNS
Server 2008 R2 mit WDS
Testclient
Also, ich habe mit dem WDS ein Aufzeichnungsabbild erstellt und ein gesyspreptes W7 Enterprise im WDS aufgezeichnet. So weit so gut. Ich habe das Image nun an meinen Testclient verteilt und in der unattend.xml den Computernamen leer gelassen damit er wie gewöhnlich abgefragt wird, weil es im Unternehmen eine spezielle Namenskonvetion gibt, die mit der automatischen Benennungsrichtlinie nicht zu realisieren ist.
Nach der Installation musste ich aber leider fest stellen, dass nicht wie erwartet nach dem Computrname gefragt wurde sondern der Benutzername des von mir eingerichtetem Benutzers zur Anmeldung am WDS (WDS-Installer) auch der Computername war. Die automatische Domainaufnahme lief reibungslos.
Ich hab also angefangen zu googeln und verschiedene Lösungsansätze gefunden, die allerdings alle nicht funktioniert haben. Ich möchte Sie an dieser Stelle kurz auflisten damit ihr mir vielleicht sagen könnt ob ich irgendwo einen Fehler gemacht habe bzw. ob es bekannte Fehlerquellen bei diesen Schritten gibt.
unattend.xml:
Wie ich bereits erwähnte habe, habe ich einen ähnlichen Beitrag gefunden in dem geraten wurde den Computername in der unattend.xml frei zulassen "ComputerName" in der Komponente "Microsoft-Windows-Shell-Setup" Phase 4 "specialize" . Erfolglos.
PE manipulieren:
Ich habe nach einigen Stunden google.de einen Technetbeitrag gefunden in dem dieses Problem ebenfalls beschrieben war. Man sollte sich ein VBScript anhand eines enthaltenem Beispiels schreiben bei dem man beim Start der PE noch einmal nach dem Computernamen und der OU gefragt wird. Ich habe nach längerem rumprobieren ein funktionierendes Script gehabt welches ich über ImageX in das Startabbild kopiert und wie beschrieben in der Winpeshl.ini den Aufruf eingefügt habe. Leider wurde das Script nicht geladen. Man lässt sich ja nicht aus der Ruhe bringen also hab ich den 2ten beschriebenen Weg auch probiert und das Script über die Startnet.cmd aufgerufen, was ich vorher auch probiert habe und es funktionierte, nur eben nicht bei Installationsstart. Das Script lässt sich also einfach nicht ausführen. Wer das jetzt nicht so richtig nachvollziehen konnte hier die Quelle Tech-Net Artikel .
Um es nochmal kurz zu umschreiben, ich möchte meine Images mit WDS verteilen, aber den Computername manuell vergeben bzw. soll der Benutzer die Eingabe machen. Leider kann ich diesbezüglich keinen Kompromiss eingehen wegen der oben erwähnten Namenskonvention.
Am liebsten wäre mir es diese Benennungsrichtlinie kompeltt zu deaktivieren, aber wie es scheint ist das nicht möglich. Vielleicht hat ja einer von euch ein ähnliches oder sogar das selbe Problem und eine Lösung dafür parat. Ich bin wirklich am verzweifeln.
Vielen Dank im voraus.
MfG
Sebastian
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 152303
Url: https://administrator.de/contentid/152303
Printed on: April 27, 2024 at 16:04 o'clock
3 Comments
Latest comment
Ich gehe mal davon aus, dass dieses Problem mehrere Leute haben, aber keinen Lösungsansatz. Ich bin gerade dabei etwas zu probieren um das Problem zu lösen. Es ist etwas umständlich aber falls es funktionieren sollte werde ich das hier noch einmal detailiert Kund tun. ;)
So, ich habe es tatsächlich zufriedenstellend hinbekommen und es war wesentlich einfacher als gedacht. Ich werde es mal schnell dokumentieren und hoffe, dass es den gequälten Seelen die dass selbe oder ein ähnliches Problem haben weiter hilft. Man kann es auch als Tutorial zur komplett unbeaufsichtigten WDS Installation benutzen.
Wichtig:
Ihr müsst dem Installationsimage und nicht dem Bootimage im WDS über die Eigenschaften des zu installierenden Image das unten links versteckte Häkchen setzen und eure für das Image erstellte ImageUnattend.xml zuweisen (hier aufpassen ihr braucht noch eine gesonderte unattend.xml für die automatisierung des PE-Bootvorgangs welche ihr beliebig bennen könnt) Die ImageUnattend.xml muss sich im Ordner %SYSTEMDRIVE%\RemoteInstall\WdsClientUnattend\ befinden und ich weiß nicht genau ob der Name der Datei hier eine Rolle spielt, aber meine heißt ImageUnattend.xml. Mit dem eben beschriebenen Schritt "deaktiviert" ihr die automatische Benennungsrichtlinie für Clients und den automatischen Domainbeitritt über WDS bzw. umgeht ihn. Deshalb auch die Scripts wie später beschrieben.
Wenn Ihr die unattend.xml für das PE fertig habt (bei Fragen dazu steh ich gern zur Verfügung) wird die nich wie bei der ImageUnattend.xml einem Image zugewiesen sondern separat in den Eigenschaften des WDS-Servers zugewiesen und zwar unter dem Reiter Client den Hacken bei Unbeaufsichtigte Installation aktiviere setzen und unten bei der benutzten Architektur (bei mir x64) die an einem bliebigen Ort gespeichte PEUnattend.xml angeben. Ich erwähne es nur so oft weil ich die beiden selbst verwechselt habe und dann alles umsonst war, weil es dann nicht funktioniert.
Da ich trotz mehrtägiger Suche keine Dokumentation von Microsoft für das Problem gefunden habe, sonder nur irreführende TechNet Beiträge hoffe ich, dass ich hiermit Abhilfe schaffen konnte. Wenn irgendwas unverständlich ist immer raus damit ich werde versuchen es dann zu erklären.
Also ihr fangt erstmal an eine für eure Bedürfnisse angepasste unattend.xml zu erstellen bis Ihr an folgender Stelle seid:
Phase4 specialize
+--amd46(natürlich architektur abhängig)_Microsoft-Widows-Deployment_neutral
+--RunSynchronus
--RunSynchronusCommand
Dort nehmt ihr folgende Einstellungen vor:
Action: AddList Item
Description:
Order: 1 (abhängig davon ob ihr vorher noch ein anderes Kommando laufen habt sonst halt 2... 3... etc.)
Path: net user Administrator /active:yes (Administrator aktivieren)
und:
Phase7 oobeSystem
+--amd46(natürlich architektur abhängig)_Microsoft-Widows-Shell-Setup_neutral``
+--AutoLogon ~1
+--Password ~2
+--FirstLogonCommands
+--SynchronousCommand ~3
+--UserAccounts
+--AdministratorPassword ~4
+--LocalAccounts
+--LocalAccount ~5
+--Password ~6
Die Tilde und die Zahl müsst ihr euch oben natürlich weg denken ;) hier die Einstellungen und die Erläuterung:
~1
Domain:
Enabled: true
LogonCount: 1 (Wie oft er sich automatisch als Administrator anmeldet)
Username: Administrator
~2
Value: Pa$$w0rd (natürlich euer selbst gewähltes Passwort ;) nach dem speichern und erneutem aufrufen der unattend.xml ist das Passwort verschlüsselt, falls ihr Angst haben solltet jemand kann in der .xml lesen)
~3
Action: AddList Item
CommandLine: cmd /c %windir%\system32\"Selbst erstellter Ordner"\"Scriptname.cmd"(Ich werde am Ende des Beitrags noch 2 Scripts mit Erläuterungen anhängen das Betrifft nur Leute die Ihre Computer automatisch in die Domain aufnehmen lassen wollen, wenn das nicht der Fall diese Punkte einfach weg lassen)
Description:
Order: 1 (abhängig davon ob ihr vorher noch ein anderes Kommando laufen habt sonst halt 2... 3... etc.)
RequiresUserInput: false
~4
Value: Pa$$w0rd (natürlich euer selbst gewähltes Passwort nach dem speichern und erneutem aufrufen der unattend.xml ist das Passwort verschlüsselt, falls ihr Angst haben solltet jemand kann in der .xml lesen)
~5
Action: AddList Item
Description:
DisplayName: Administrator
Group: Administrators
Name: Administrator
~6
`Value: Pa$$w0rd (natürlich euer selbst gewähltes Passwort nach dem speichern und erneutem aufrufen der unattend.xml ist das Passwort verschlüsselt, falls ihr Angst haben solltet jemand kann in der .xml lesen)
So zu guter letzt die 2 versprochenen Scripts. Es handels sich um ein .cmd Script und ein .ps1 Script (PowerShell) wie ihr sicher wisst, ist es ein bekannter Bug, dass man die Domainaufnahme nicht über die unattend.xml steuern kann, da die Domainaufnahme in Phase3 generalize geschieht, dass Problem dabei ist das an dieser stelle noch kein Benutzerdefinierter Computername festgelegt, aber ein zufällig generierter z.B. WIN-4FSFGH42 dieser wird in die Domain aufgenommen und in die OU COmputers gepackt.
Dann kommt ihr zur Phase7 oobeSystem in dem Ihr entweder ein Computername angebt oder es, wie in meinem Fall, diese Einstellung leer lasst und eine Benutzerabfrage aufpoppt in dem ihr den Computername festlegen könnt. Ich denke Ihr erkennt die Problematik. Der Computer heißt nach der Domainaufnahme anders als an der Stelle wo er in die Domain aufgenommen wurde, damit lässt sich ntürlich keine Vetrauenstellung aufbauen und man müsste den Computer nochmal von Hand in die Domain packen.
Hier meine Lösung:
Inhalt des .cmd Scripts welches ihr in der Unattend.xml an beschriebener Stelle aufruft. Dieses wiederum ruft dann das .ps1 Script auf. Warum das so gemacht werden muss steht im .cmd Script als Kommentar dabei. Die mit einem "::" davor sind Kommentare, könnt ihr also auch weg lassen. Was noch wichtig ist, beide Scripte müssen in einen Ordner den Ihr irgendwo in euer Image packt. Ihr müsst nur die Pfade in den Scripten richtig angeben.
@echo off
:: Signierungszwang für die Powershell deaktivieren
powershell Set-ExecutionPolicy Unrestricted
:: Skript zur Domainaufnahme ausführen
powershell %windir%\system32\"Selbst erstellter Ordner"\"Scriptname.ps1
:: Signierungszwang für die Powershell wieder aktivieren
powershell Set-ExecutionPolicy Restricted
:: Nach dem Neustart dieses Verzeichnis und alle Inhalte löschen nicht das der User das Passwort klaut.
:: WICHTIG: Funktioniert nur, wenn sich einmalig ein Administrator anmeldet --> in der unattend.xml festlegen.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v Clean_HD /t REG_SZ /d "cmd /c rd /s /q %windir%\system32\"Selbst erstellter Ordner"
:: Neustart ausführen
shutdown -r -t 0
Hier das PowerShell Script, hier sind die Rauten die Kommentare:
$account = "$domain\Domainadmin"
$password = 'Passwort'
Add-Computer -DomainName "$domain" -Credential $credential
Wie oben erwähnt, bei Fragen immer raus damit.
MfG
Sebastian
Wichtig:
Ihr müsst dem Installationsimage und nicht dem Bootimage im WDS über die Eigenschaften des zu installierenden Image das unten links versteckte Häkchen setzen und eure für das Image erstellte ImageUnattend.xml zuweisen (hier aufpassen ihr braucht noch eine gesonderte unattend.xml für die automatisierung des PE-Bootvorgangs welche ihr beliebig bennen könnt) Die ImageUnattend.xml muss sich im Ordner %SYSTEMDRIVE%\RemoteInstall\WdsClientUnattend\ befinden und ich weiß nicht genau ob der Name der Datei hier eine Rolle spielt, aber meine heißt ImageUnattend.xml. Mit dem eben beschriebenen Schritt "deaktiviert" ihr die automatische Benennungsrichtlinie für Clients und den automatischen Domainbeitritt über WDS bzw. umgeht ihn. Deshalb auch die Scripts wie später beschrieben.
Wenn Ihr die unattend.xml für das PE fertig habt (bei Fragen dazu steh ich gern zur Verfügung) wird die nich wie bei der ImageUnattend.xml einem Image zugewiesen sondern separat in den Eigenschaften des WDS-Servers zugewiesen und zwar unter dem Reiter Client den Hacken bei Unbeaufsichtigte Installation aktiviere setzen und unten bei der benutzten Architektur (bei mir x64) die an einem bliebigen Ort gespeichte PEUnattend.xml angeben. Ich erwähne es nur so oft weil ich die beiden selbst verwechselt habe und dann alles umsonst war, weil es dann nicht funktioniert.
Da ich trotz mehrtägiger Suche keine Dokumentation von Microsoft für das Problem gefunden habe, sonder nur irreführende TechNet Beiträge hoffe ich, dass ich hiermit Abhilfe schaffen konnte. Wenn irgendwas unverständlich ist immer raus damit ich werde versuchen es dann zu erklären.
Also ihr fangt erstmal an eine für eure Bedürfnisse angepasste unattend.xml zu erstellen bis Ihr an folgender Stelle seid:
Phase4 specialize
+--amd46(natürlich architektur abhängig)_Microsoft-Widows-Deployment_neutral
+--RunSynchronus
--RunSynchronusCommand
Dort nehmt ihr folgende Einstellungen vor:
Action: AddList Item
Description:
Order: 1 (abhängig davon ob ihr vorher noch ein anderes Kommando laufen habt sonst halt 2... 3... etc.)
Path: net user Administrator /active:yes (Administrator aktivieren)
und:
Phase7 oobeSystem
+--amd46(natürlich architektur abhängig)_Microsoft-Widows-Shell-Setup_neutral``
+--AutoLogon ~1
+--Password ~2
+--FirstLogonCommands
+--SynchronousCommand ~3
+--UserAccounts
+--AdministratorPassword ~4
+--LocalAccounts
+--LocalAccount ~5
+--Password ~6
Die Tilde und die Zahl müsst ihr euch oben natürlich weg denken ;) hier die Einstellungen und die Erläuterung:
~1
Domain:
Enabled: true
LogonCount: 1 (Wie oft er sich automatisch als Administrator anmeldet)
Username: Administrator
~2
Value: Pa$$w0rd (natürlich euer selbst gewähltes Passwort ;) nach dem speichern und erneutem aufrufen der unattend.xml ist das Passwort verschlüsselt, falls ihr Angst haben solltet jemand kann in der .xml lesen)
~3
Action: AddList Item
CommandLine: cmd /c %windir%\system32\"Selbst erstellter Ordner"\"Scriptname.cmd"(Ich werde am Ende des Beitrags noch 2 Scripts mit Erläuterungen anhängen das Betrifft nur Leute die Ihre Computer automatisch in die Domain aufnehmen lassen wollen, wenn das nicht der Fall diese Punkte einfach weg lassen)
Description:
Order: 1 (abhängig davon ob ihr vorher noch ein anderes Kommando laufen habt sonst halt 2... 3... etc.)
RequiresUserInput: false
~4
Value: Pa$$w0rd (natürlich euer selbst gewähltes Passwort nach dem speichern und erneutem aufrufen der unattend.xml ist das Passwort verschlüsselt, falls ihr Angst haben solltet jemand kann in der .xml lesen)
~5
Action: AddList Item
Description:
DisplayName: Administrator
Group: Administrators
Name: Administrator
~6
`Value: Pa$$w0rd (natürlich euer selbst gewähltes Passwort nach dem speichern und erneutem aufrufen der unattend.xml ist das Passwort verschlüsselt, falls ihr Angst haben solltet jemand kann in der .xml lesen)
So zu guter letzt die 2 versprochenen Scripts. Es handels sich um ein .cmd Script und ein .ps1 Script (PowerShell) wie ihr sicher wisst, ist es ein bekannter Bug, dass man die Domainaufnahme nicht über die unattend.xml steuern kann, da die Domainaufnahme in Phase3 generalize geschieht, dass Problem dabei ist das an dieser stelle noch kein Benutzerdefinierter Computername festgelegt, aber ein zufällig generierter z.B. WIN-4FSFGH42 dieser wird in die Domain aufgenommen und in die OU COmputers gepackt.
Dann kommt ihr zur Phase7 oobeSystem in dem Ihr entweder ein Computername angebt oder es, wie in meinem Fall, diese Einstellung leer lasst und eine Benutzerabfrage aufpoppt in dem ihr den Computername festlegen könnt. Ich denke Ihr erkennt die Problematik. Der Computer heißt nach der Domainaufnahme anders als an der Stelle wo er in die Domain aufgenommen wurde, damit lässt sich ntürlich keine Vetrauenstellung aufbauen und man müsste den Computer nochmal von Hand in die Domain packen.
Hier meine Lösung:
Inhalt des .cmd Scripts welches ihr in der Unattend.xml an beschriebener Stelle aufruft. Dieses wiederum ruft dann das .ps1 Script auf. Warum das so gemacht werden muss steht im .cmd Script als Kommentar dabei. Die mit einem "::" davor sind Kommentare, könnt ihr also auch weg lassen. Was noch wichtig ist, beide Scripte müssen in einen Ordner den Ihr irgendwo in euer Image packt. Ihr müsst nur die Pfade in den Scripten richtig angeben.
@echo off
:: Signierungszwang für die Powershell deaktivieren
powershell Set-ExecutionPolicy Unrestricted
:: Skript zur Domainaufnahme ausführen
powershell %windir%\system32\"Selbst erstellter Ordner"\"Scriptname.ps1
:: Signierungszwang für die Powershell wieder aktivieren
powershell Set-ExecutionPolicy Restricted
:: Nach dem Neustart dieses Verzeichnis und alle Inhalte löschen nicht das der User das Passwort klaut.
:: WICHTIG: Funktioniert nur, wenn sich einmalig ein Administrator anmeldet --> in der unattend.xml festlegen.
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v Clean_HD /t REG_SZ /d "cmd /c rd /s /q %windir%\system32\"Selbst erstellter Ordner"
:: Neustart ausführen
shutdown -r -t 0
Hier das PowerShell Script, hier sind die Rauten die Kommentare:
- Variablen zum Anpassen
$account = "$domain\Domainadmin"
$password = 'Passwort'
- =========================
- Ab hier nicht mehr ändern
Add-Computer -DomainName "$domain" -Credential $credential
Wie oben erwähnt, bei Fragen immer raus damit.
MfG
Sebastian
Hi Sebastian,
ich habe mir ebenfalls recht lange die Sachen zusammensuchen müssen um diese Anforderung, den Namen manuell zu vergeben, zu erfüllen.
Ich löse es so:
Stelle im WDS die PXE-Antwort auf
Allen Clientcomputern antworten und mache den Haken rein bei Administratorgenehmigung für unbekannte Computer erforderlich machen.
Der Prozess sieht dann so aus:
ich habe mir ebenfalls recht lange die Sachen zusammensuchen müssen um diese Anforderung, den Namen manuell zu vergeben, zu erfüllen.
Ich löse es so:
Stelle im WDS die PXE-Antwort auf
Allen Clientcomputern antworten und mache den Haken rein bei Administratorgenehmigung für unbekannte Computer erforderlich machen.
Der Prozess sieht dann so aus:
- der Client bootet per PXE und sendet dem Server im DHCP-Request seine GUID mit (die Mac ist im Paket ja sowieso enthalten)
- der WDS prüft nun, ob
- es im AD einen Computer gibt mit derselben GUID (Attribut netbootGUID) gibt - Achtung: Anzeige des Attributs im AD und am Client unterscheiden sich - Little-Endian <!=> Big-Endian!
- der Client schon in der WDS-eigenen Datenbank hinterlegt und autorisiert ist
- gibt es den Client noch nicht, hält der Startvorgang an
- man autorisiert den Client und kann ihm einen Namen geben (der Client ist immer anhand der Mac, der GUID oder einer fortlaufenden Nummer in der WDSUtil-eigenen Datenbank identifizierbar, man kann sich also auch vom Nutzer die angezeigte kurze Nummer ansagen lassen und anhand dessen den Computer zuordnen)
- Beim Benamen des Clients wird im AD ein Computerkonto angelegt, und zwar in der OU, die im WDS im Reiter "AD DS" eingestellt ist. Da der Server das Computerkonto anlegt, muss das Konto <WDSServerName>$ Computerobjekte im AD anlegen dürfen, sonst gibt es einen Fehler.
- Jetzt kann der Client per PXE durchbooten und ein Boot-Image starten
- In der Antwort-Datei, die dem Install-Image zugeordnet ist, gibt man als Computername unter [4-specialize -> Mircosoft-Windows-Shell-Setup -> Computername] den Wert %MACHINENAME% an. Unter [4-specialize -> Microsoft-Windows-UnattendedJoin -> Identification] steht [JoinDomain] auf %MACHINEDOMAIN% und [UnsecureJoin] auf true. Damit wird der Computer in die Domäne gehoben und er heißt tatsächlich so, wie er bei der Benamung ins AD geschrieben wurde.
Weiterer Vorteil dieser Methode: Man kann den Computer bereits in die OU verschieben, bevor er fertig installiert ist.
Noch zwei Worte zur PXE-Antwort:
Ist ein Rechner schon vorhanden und Du willst die Autorisierung für eine erneute Installation aufheben (der Nutzer soll also nicht einfach vom Netz booten und neu installieren dürfen), dann musst Du die Autorisierung im WDS aufheben. Das geht meines Wissens leider nicht pro Gerät, sondern nur global indem man alle autorisierten Geräte löscht.
Anzeigen aller Approved Devices:
WDSUtil /get-AutoAddDevices /DeviceType:ApprovedDevicesLöschen aller Approved Devices:
WDSUtil /Delete-AutoAddDevices /DeviceType:ApprovedDevicesGibt es Probleme, bspw. weil ein Rechner mit der selben GUID im AD steht, kann man die GUID im AD suchen:
Will man bspw. im AD den Computer mit der GUID 444555CC-4C01-1031-8036-C5C55CC554C2 finden, muss man im AD das Suchfenster aufrufen, "Benutzerdefinierte Suche" auswählen, im Feld erweitert gibst Du dann folgendes ein (die Backslashes wegen der endian-Problematik, damit braucht man nicht umrechnen):
(&(objectClass=computer)(netbootGUID=\44\45\55\CC\4C\01\10\31\80\36\C5\C5\5C\C5\54\C2))Nun das gefundene Computerobjekt löschen und Voilà - die Installation sollte klappen.
HTH!
Ciao!
Marco