RIS, same GUID, duplicates, Dell GX60's

[Guest]

Hi All,

Hope someone can help me with this baffling problem. I've been searching
for three days for a fix. Apologies for the following novel - hope it's
thorough enough! ;-)

I'm deploying Windows XP by RIS from Windows 2000 SP4 servers. The RIS is
on a server with no DHCP, while DHCP is been serviced by another two servers.

Most of the client computers are Dell Optiplex GX60's. These have the Intel
100+ pro onboard. The Dell's do not support PXE boot, so I'm using the boot
disk made with RBFG.EXE.

The major problem is that of the 25 odd GX60's, about 20 of them display the
same GUID when booting from the floppy disk, and hence all get the same
workstation name from the RIS server as it thinks that it is the same machine.

I'm not using a shared NIC with the machines. The PXE boot process is
obviously not finding a GUID on the computers and is attempting to generate a
unique ID based on the MAC address.

However, although these GX60's were purchased at the same time and are all
part of the same batch with similar MAC addresses, obviously they are not the
same.
EG. (GX60's MAC addresses):
000BDB741826
000BDB741866
000BDB741867
000BDB741882

Now as soon as the floppy disk boots, it states:
NODE: C082FFBF0080
DHCP....

Finds the RIS server, asks for username and password, then displays:
GUID: 00000000000000000000C082FFBF0080
COMPUTER NAME: Workstation-1

This same Node ## and GUID appears for all of these GX60's. So hence the
computer name is the same.

If I start the build process of one of these computers, then move on to
another, it will start the build process on the second machine, say it's the
same name as the first computer name, get as far as loading windows files
from the RIS server (after giving username password etc.), state "Starting
Windows" then bluescreen with "IP address conflict".

From either of the DHCP servers I can see that the DHCP servers receive the
MAC address of C082FFBF0080 from these clients when booting from the floppy.
But if I boot from Windows on these computers their proper MAC adddress is
registered with the DHCP servers.

Now, to add to the puzzle, other Dell optiplex GX60's which are only about 3
months old (the batch of approx. 18 GX60's with the problems are approx. 2
years old, while another two or three ordered over the last year display the
same problem) do not have this problem. Almost anyway....

When using the boot disk on the newer GX60's, they show the Node address to
be SLIGHTLY different than the above node address that is displayed for the
large amount of the GX60's.
Each of the newer GX60's display Node addresses very similar but not quite -
eg.
C083FFBF0080
C0F2FFBF0080

So these computers build ok with individual computer names, however you can
still see that the Node addresses which are supposed to be the MAC addresses
of their NIC's are still not correct (their MAC addresses are vastly
different).

So far I have tried:
- Re-installing RIS on the same server
- Removing RIS from server and installing on another server
- shutting down other DCHP servers and having DHCP run from just the RIS
server
- Checking that BINLSVC has been updated and is running correctly.
- Rebuilding the floppy boot disk a number of times
- Formatting some of the GX60's so they contain no software apart from their
BIOS.
- Updated BIOS's on older GX60's - they now all have A09.

I'm thinking that this must be some problem between the boot disk and the
hardware of the GX60. It seems to get or generate the Node number (which
should be the MAC address) before talking to the servers, and it seems that
this Node address which later becomes the GUID is the heart of the problem.

I have run 3rd party programs on the GX60's to check their UUID's and found
although again they are extremely similar, they differ slightly between each
other.

I don't know if this is helpful in anyway, but previous to this attempt to
RIS all these desktops, their builds were managed by Norton Ghost so in
effect each HD was an exact replica of each other.

The only thing I can think of now is that the PXE sequence on the floppy is
using some weird third method of generating the GUID's based on MAC + UUID +
HD ID and mixed all together or something????????

Any help greatly appreciated! I love RIS but am frustrated that if I can't
resolve I'm going to have to go back to Ghost which is a pain in the
proverbial...

Thanks.

 

[NIC Student]

Hi Martin,

My first thought is the boot agent on the nic needs to be updated. Are
these nics part of the motherboard or pci devices? If onboard, I would have
guessed that a system BIOS update would have fixed it... If not onboard,
then you go to Intel's site, you'll need the latest ProBoot. I found the
pxe20-pdk.exe file from Intel's site, when extracted, has some flash updates
for your nic bios. It has to be run from a server and a floppy is created
to flash the nic bios. It's up to you if you want to try that... maybe if
you have a machine set up in a test lab.

I found this blurb on Intel's site:

Some BIOS do not properly communicate GUID, or properly recognize boot
agent. You will need to contact your motherboard or computer vendor to find
the latest system BIOS.

If the nic is onboard and you have updated the latest bios, then I suspect
the nic drivers are not entirely correct, update the drivers in your RIS
image:

http://support.intel.com/support/network/sb/CS-000023.htm

If you go this route, you can try the Intel Pro100 drivers from my site:

http://www.mvps.org/serverstuff/RIS/Intel/Intel100VM.htm

 

[Guest]

Scott,

Thanks for your reply.

The NIC is unfortunately onboard - so cannot flash it or re-configure it to
enable the bootrom. Hence the requirement of the RIS boot disk.
I attempted some Intel NIC configuration programs but they didn't help me
progress. However, they and the SM_INFO.EXE program I have confirm that they
at least are reading the correct GUID and MAC address from the Dell BIOS.

It appears that the MS RIS boot disk is booting, then attempting to find the
GUID on the Dell. At this stage, it can't find it, so decides to get the MAC
address and slap 20 zeros in front of it for the new GUID.

Unfortunately it looks like the RIS boot disk looks in the wrong place for
the MAC address and comes back with some Dell ROM code that is static and the
same on each GX60 (of the old batch), and just slightly different on the
newer lot of GX60's I have. I've just found that even the newer GX60's have
problems because of the latest two, although their "MAC" addresses according
to the RIS disk are different from the older batch, they are the same as each
other.
Their true MAC addresses however are obviously not the same.

I'd love to be able to either run a hex editor over the GX60 ROM and see if
I can match up the "MAC" address that the RIS disk finds with some other
location in the ROM, or disassemble the RIS boot disk file which probes the
ROM and find out at which address it's looking. Because it's definately NOT
the same location where Dell stores the MAC address of the on-board NIC.

Anyone know of newer type RIS build disk file?
Or how about a different boot disk that allows the Intel NIC to boot just as
a normal remote-boot enabled NIC with PXE enabled? (ie. F12 network boot?)

That wouldn't fix the problem but would bypass it me thinks.

I'm in contact with Dell support but so far they are looking for ways to
hand the ball back to me and say it's a Microsoft problem.

Thanks Scott, and thanks to anyone else who has got any suggestions they can
send me.

Martin.

 

[Guest]

As an update for all, this is now "sort of" resolved. Dell have provided
BIOS updates and settings for these GX60's so they can boot straight from
their NIC without the requirement of the MS RIS boot disk.

This has fixed my problems for now. The chances of finding other machines
that (a) can't boot from the network, and (b) don't work with the RIS disk I
think are minimal.

 

[NIC Student]

Thanks for the update, Martin. Maybe your notes will help someone in the
future.

--
Scott Baldridge
Windows Server MVP, MCSE


"Martin"