RIS en GUID probleem

[Verwijderd]

Situatie:
- AD domein bestaande uit 2003 servers en XP;
- 1 RIS Server, tevens DHCP server;
- meerdere DC's, DNS en DHCP servers (over verschillende locaties).

Wens:
- op hoofdlocatie 1 RIS server erbij in verband met uitrol clients met XP SP2.

Uitvoering:
- server ingericht als dedicated RIS server (zonder DHCP), OS is Server 2003 STD (geen SP), ging allemaal probleemloos. Server bestand dezelfde 'riprep-images' als de eerste server.

Probleem:
- Riprep uitvoeren vanaf de nieuwe RIS server levert voor de client een nieuwe computernaam op, dit is ongewenst. De telling gaat wel keurig door, dat wel.
Het verschijnsel is als volgt: hij laat in het blauwe setup scherm (laatste blauwe scherm) de GUID zien, deze klopt niet met die van de bestaande computeraccount in AD! Hij gebruikt nu het MAC-adres aangevuld met een aantal 0-en. Aangemaakte account weggegooid, met oude RIS-server gaat het wel goed, de 'oude' computernaam wordt weer gebruikt.

Volgens mij zou het principe als volgt moeten werken: controle in AD of GUID/ UUID voorkomt, zo ja, weer gebruiken (reset account), zo nee, maak nieuw account aan. Alleen omdat de nieuwe RIS-server een andere GUID/UUID 'ziet' / 'maakt', vindt hij deze natuurlijk niet in AD en maakt een nieuw account aan. Alleen hoe voorkom ik dat er een nieuw GUID/UUID gemaakt wordt (aan de hand van het MAC-adres)?? Heb al lang gezocht (technet, forums etc.) maar nog niks kunnen vinden. Wie o wie??

[sanfranjake]

Je kan in de properties van de machine in AD opgeven door welke RIS0server deze geserviced wordt. Dat al aangepast?

[Verwijderd]

Ja dat weet ik, maar dat is het probleem niet. Probleem is dat er (alleen door de nieuwe RIS-server) een nieuwe GUID aangemaakt wordt (aan de hand van het MAC-adres) en dat het normale GUID (door de fabrikant van de machine aangemaakt en door de 1e RIS-server gebruikt) dus niet door de 2e RIS-server herkend / gebruikt wordt, en er dus een nieuwe computernaam wordt aangemaakt. En dat wil nou juist niet...

[Verwijderd]

Nog wat info bij Microsoft gevonden:

"When a RIS client computer on the network starts up it initiates a network service request. The RIS server (using the Boot Information Negotiation Layer [BINL] service) must check Active Directory for the existence of a prestaged client computer account that matches the client computer. BINL checks for the existence of a client computer by querying Active Directory for a computer object whose netbootGUID matches the GUID sent during the request."

Kennelijk gaat er in het hierboven beschreven proces iets niet goed op de nieuwe RIS-server. Kan het toch ergens een setting zijn (zo ja, wat / waar dan)?

[Verwijderd]

Ik kon zo even niet uitmaken welke client machines je hebt, maar let hier even op:

Wat ik nog van RIS weet is dat het GUID besloten ligt in je moederbord (ergens in de SMBIOS waarden). Het komt dus NIET van je NIC zoals velen denken.

A-Merk PC's zoals Compaq, Dell, HP, IBM en noem maar op kennen dit correct toe. Zijn je PC's echter van het caliber zelfbouw of een eigen merk van bijvoorbeeld alternate of iets dergelijks, dan hebben deze 9 van de 10 keer een ongeldige GUID waarde, of ze hebben allemaal dezelfde waarde. Ik heb dit bijvoorbeeld op mijn ASUS moederbord.

Ik hoop dat je hier wat aan hebt, want ik ken het probleem wel. Maar dan gekoppeld aan het gebruik van RIS met "klonen". Ik heb dit gehad bij een klant met dergelijke apparaten, gebruik je de eerder genoemde A-merken, dan is het probleem weg.

Het geschetste probleem met een tweede RIS server heb ik nog niet eerder gehad, ze kijken immers beide naar dezelfde Active Directory. Ik neem aan dat er geen replicatieproblemen oid zijn, maar dan nog volgens mij wordt zoiets netjes afgevangen middels timestamps etc.

[ Voor 22% gewijzigd door Verwijderd op 18-10-2006 13:18 ]

[Verwijderd]

Okee, ik ben er uit... domdomdom , 2e RIS-server moet in DHCP als Authorized DHCP server worden toegevoegd (ook als heeft de server niet de rol als DHCP server, maar wel als een soort doorgeef-luik). Wist het eigenlijk wel maar had er niet aan gedacht. Probleem opgelost!