G
Guest
I have been setting up RIS on a Windows 2003 Server for the past 3 weeks.
I have certainly learnt alot about how RIS works and what its limitations
are by reading as much documentation as I can get my hands on.
Now I do have RIS working but I do have an interesting issue I thought I
would share with people to see if anyone else has had it happen to them.
Some background first.
I work at a University where the majority of infrastructure servers are Sun
Solaris although I look after all the Windows Servers. Our Unix System Admins
manage all the Sun servers.
Our University DHCP server sits on a Sun Solaris 9 machine with an IP
address of 130.130.68.14 behind the firewall which is on a different subnet
to the RIS server.
I have my Production Ris Server setup behind the firewall on a private IP
172.20.3.50
because our security officer want all servers behind the firewall. Fair
enough.
We also have a test RIS server setup on our 130.130.69.0 subnet which is not
behind the firewall but is not being used well thats what I thought. Read
further.
The security officer has allowed all the relevant ports to be opened on the
Production RIS server so that RIS clients on our 130.130.69.0 and
130.130.70.0 subnets and DHCP can communicate to the RIS server and this all
works fine.
For those interested the ports we opened to allow RIS to wortk behind a
firewall are
object-group service ris_server_incoming_tcp tcp
description TCP ports needed for a RIS server
port-object eq 135 (RPC)
port-object eq 139 (Net Bios Session)
port-object eq 389 (LDAP)
port-object eq 445 (CIFS or SMB)
object-group service ris_server_incoming_udp udp
description UDP ports needed for a RIS server
port-object eq 69 (Tftp - used for image delivery)
port-object eq 4011 (Alternate Service Boot)
exit
I Pre-Stage all the computer accounts in AD withn a computer name and a 32
character GUID.
We use DELL Optiplex GX 270 and GX 280 Models for our desktops and use PXE
Boot tp connect to the RIS Server.
When we boot up using pXe the pXe client gets an IP address no problems then
boots into the CIW where this RIS menu appears so far so good.
We then authenticate using a valid domain username and password (people who
are a member of domain admins usually) which then takes us to the OS schooser
menu.
Now this is where I started to have some issues.
Machines on the 130.130.69.0 subnet worked fine could see the RIS Prep
Images in the OS Chooser and select and install them with the correct GUID
being displayed and install the image.
Going through exactly the same process for Machines on the 130.130.70.0
subnet but when you get to the OS Chooser menu the RISPREP Images were not
there. The Scripted XP Installation was there which is the Risetup image that
I put onto the RIS server when I built it. I selected this and pressed Enter
and the normal message would come up on the next screen saying the disk is
going to be formated and then on the next screen I saw that the computer's
pre-staged name was incorrect and the GUID was also incorrect. The GUID was
infact the MAC address padded with 20 0's
and the computer name was the username I signed on with example peter1
So the GUID wasn't being picked up correctly.
I then realised that the test RIS server on the 130.130.69.0 subnet was on
and probably servicing the local 130.130.69.0 Ris clients. So I truned of the
Test RIs server and then attempted to PXE boot a RIs client on the
130.130.69.0 subnet and still managed to get an IP address but the OS Chooser
menu had ni RIS images and the GUID was incorrect even though I had
prte-staged the computer in AD well before.
A work around to this is as follows
I copied the winnt.sif file to the \reminst root so that the RISPREP images
could be found and I used the guid format of the Mac Address padded with 20
0's.
This works the only thing that concerns me is that we aren't using the GUID
that is indicated by the PXE Network card on PXE boot. I think it doesn't
matter as long as the AD has a valid client GUID it shouldn't matter.
So if anyone has had this happen to them this is how I managed to resolve
this.
I have certainly learnt alot about how RIS works and what its limitations
are by reading as much documentation as I can get my hands on.
Now I do have RIS working but I do have an interesting issue I thought I
would share with people to see if anyone else has had it happen to them.
Some background first.
I work at a University where the majority of infrastructure servers are Sun
Solaris although I look after all the Windows Servers. Our Unix System Admins
manage all the Sun servers.
Our University DHCP server sits on a Sun Solaris 9 machine with an IP
address of 130.130.68.14 behind the firewall which is on a different subnet
to the RIS server.
I have my Production Ris Server setup behind the firewall on a private IP
172.20.3.50
because our security officer want all servers behind the firewall. Fair
enough.
We also have a test RIS server setup on our 130.130.69.0 subnet which is not
behind the firewall but is not being used well thats what I thought. Read
further.
The security officer has allowed all the relevant ports to be opened on the
Production RIS server so that RIS clients on our 130.130.69.0 and
130.130.70.0 subnets and DHCP can communicate to the RIS server and this all
works fine.
For those interested the ports we opened to allow RIS to wortk behind a
firewall are
object-group service ris_server_incoming_tcp tcp
description TCP ports needed for a RIS server
port-object eq 135 (RPC)
port-object eq 139 (Net Bios Session)
port-object eq 389 (LDAP)
port-object eq 445 (CIFS or SMB)
object-group service ris_server_incoming_udp udp
description UDP ports needed for a RIS server
port-object eq 69 (Tftp - used for image delivery)
port-object eq 4011 (Alternate Service Boot)
exit
I Pre-Stage all the computer accounts in AD withn a computer name and a 32
character GUID.
We use DELL Optiplex GX 270 and GX 280 Models for our desktops and use PXE
Boot tp connect to the RIS Server.
When we boot up using pXe the pXe client gets an IP address no problems then
boots into the CIW where this RIS menu appears so far so good.
We then authenticate using a valid domain username and password (people who
are a member of domain admins usually) which then takes us to the OS schooser
menu.
Now this is where I started to have some issues.
Machines on the 130.130.69.0 subnet worked fine could see the RIS Prep
Images in the OS Chooser and select and install them with the correct GUID
being displayed and install the image.
Going through exactly the same process for Machines on the 130.130.70.0
subnet but when you get to the OS Chooser menu the RISPREP Images were not
there. The Scripted XP Installation was there which is the Risetup image that
I put onto the RIS server when I built it. I selected this and pressed Enter
and the normal message would come up on the next screen saying the disk is
going to be formated and then on the next screen I saw that the computer's
pre-staged name was incorrect and the GUID was also incorrect. The GUID was
infact the MAC address padded with 20 0's
and the computer name was the username I signed on with example peter1
So the GUID wasn't being picked up correctly.
I then realised that the test RIS server on the 130.130.69.0 subnet was on
and probably servicing the local 130.130.69.0 Ris clients. So I truned of the
Test RIs server and then attempted to PXE boot a RIs client on the
130.130.69.0 subnet and still managed to get an IP address but the OS Chooser
menu had ni RIS images and the GUID was incorrect even though I had
prte-staged the computer in AD well before.
A work around to this is as follows
I copied the winnt.sif file to the \reminst root so that the RISPREP images
could be found and I used the guid format of the Mac Address padded with 20
0's.
This works the only thing that concerns me is that we aren't using the GUID
that is indicated by the PXE Network card on PXE boot. I think it doesn't
matter as long as the AD has a valid client GUID it shouldn't matter.
So if anyone has had this happen to them this is how I managed to resolve
this.