Automatisch gegenereerde Computer Accounts in AD werken niet

[Koffie]

Ola,

Op dit moment ben ik bezig met een migratie van Windows 2000 clients op een NT4 domain, naar Windows 2000 clients op een AD (ik beheer de DC's niet, maar onze lokale File server is iig Windows 2003).

Enfin, tijdens de voorbereidingen begonnen met scripten, en zo ook een scriptje geschreven welke op basis van een CSV file de Computer Accounts in de juiste OU aanmaakt en enabled.

Het script heeft zijn werk goed gedaan, en de Computer Accounts zijn netjes aangemaakt.

Toen we vanochtend begonnen met de migratie, liepen we meteen tegen een probleem aan.
De gebruiker was geen local admin, ondanks dat een Global Group met een Policy dit wel zou bewerkstelligen.

Na enig contact met de technische beheerders in Engeland, kwamen we erachter dat er een nieuw Computer Account aangemaakt was in de OU genaamd 'Computers' (rechtstreeks in de root van de tree).

Volgens mij is het redelijk technisch onmogelijk om binnen eenzelfde AD tree 2 objecten van hetzelfde type te hebben met exact dezelfde benaming ?

Verdere tests wezen uit dat het mis ging bij computers welke een Computer Account automatisch in de tree hebben gekregen.
Een test computer welke 'met de hand' in dezelfde OU werd aangemaakt, werkte wel in 1 keer perfect.

Nu is de oplossing voor dit probleem relatief simpel; alle Computer Accounts verwijderen en met het handje opnieuw aanmaken.
Dit is dan ook wat we gedaan hebben.

Waar het mij meer om ging, hoe kan het dit deze automatisch aangemaakte Computer Accounts 'onwerkbaar' waren

Het belangrijkste gedeelte van het script voor de Computers Accounts ziet er zo uit :

code:

NewName = "xxx" & SVTag & "D"
NewCNName = "CN=yy" & SVTag & "D"
NewString = "LDAP://CN=" & NewName & ",OU=Desktops," & OU & "," & DC

set oContainer = GetObject("LDAP://OU=Desktops,OU=Workstations,OU=Computers,OU=xx,OU=yy,DC=zz,,DC=com")
set oComputer = oContainer.Create("Computer",NewCNNAme)
oComputer.Put "description", NetBios
oComputer.Put "sAMAccountName", NewName
oComputer.SetInfo

oComputer.AccountDisabled = False
oComputer.SetInfo

De variables die in dit script gebruikt worden kloppen allemaal, daar is niets mis mee.

De computers krijgen bij deze migratie namelijk een nieuwe naam, als 'desciption' heb ik de huidige/oude 'netbions' naam opgegeven.

Het joinen aan de AD alsmede het renamen gaat als volgt :

- Inloggen als Domain Admin
- Computer hernoemen, niet rebooten
- Computer disjoinen en joinen aan fictieve workgroup
- Reboot
- Inloggen als Local Admin
- Computer disjoinen van fictieve workgroup en joinen aan AD
- Reboot

Deze procedure is bij de 'handmatige test' als bij computers met gescripte Computer Accounts exacte hetzelfde geweest.

Iemand enig idee wat er mis kan zijn geweest met de automatiche Computer Accounts ?

[zomertje]

Die procedure die jij beschrijft moet ik hier altijd uitvoeren (win2k) domein als ik een pc wil hernoemen. Direct hernoemen in het domein werkt gewoon niet, ik moet hem eerst in een werkgroep zetten, rebooten, dan opnieuw in het domein zetten. Rare meuq...

[reddog33hummer]

Soms werkt het door de computers accounts te resetten.

[Hmzaniac]

zomertje schreef op 11 november 2004 @ 21:49:
Die procedure die jij beschrijft moet ik hier altijd uitvoeren (win2k) domein als ik een pc wil hernoemen. Direct hernoemen in het domein werkt gewoon niet, ik moet hem eerst in een werkgroep zetten, rebooten, dan opnieuw in het domein zetten. Rare meuq...

klopt, dit is een known issue die microsoft niet gaat/wil oplossen de eerste tijd. Hier heb ik een jaar of wat geleden mijn hoofd nog heel erg over gebroken toen op een gegeven moment een computer onder de verkeerde naam het domein was gejoined. Maar ik vind het niet zo heel vreemd dat het lastig te vinden was, het is maar op erg weinig plekken bekend (en nog minder waar een correcte uitleg en oplossing staat)