Sign in with
Sign up | Sign in
Your question

RIS 2003 Server and GUIDs

Last response: in Windows 2000/NT
Share
Anonymous
April 29, 2005 4:08:06 AM

Archived from groups: microsoft.public.win2000.setup_deployment (More info?)

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.

More about : ris 2003 server guids

Anonymous
April 30, 2005 12:00:28 AM

Archived from groups: microsoft.public.win2000.setup_deployment (More info?)

The GUID you see at PXE boot is usually in a different order than the GUID
you actually need to prestage. There are characters that will be reversed
(it's wacky, IMHO).

Best way to verify the GUID - boot the system(s) to WinPE 1.5 or 1.6 and use
WMI to tell you the GUID.

"pbirkle" <pbirkle@discussions.microsoft.com> wrote in message
news:F1B37B04-A989-458E-81E5-66E1CDB0AF68@microsoft.com...
>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.
>
>
>
>
>
>
>
>
>
Anonymous
May 18, 2005 5:11:14 AM

Archived from groups: microsoft.public.win2000.setup_deployment (More info?)

enable lan pxe boot, than by searching dhcp, you see the guid you needed. to
change that GUID, contact the motherboard-company. asus or else

"WM" schreef:

> The GUID you see at PXE boot is usually in a different order than the GUID
> you actually need to prestage. There are characters that will be reversed
> (it's wacky, IMHO).
>
> Best way to verify the GUID - boot the system(s) to WinPE 1.5 or 1.6 and use
> WMI to tell you the GUID.
>
> "pbirkle" <pbirkle@discussions.microsoft.com> wrote in message
> news:F1B37B04-A989-458E-81E5-66E1CDB0AF68@microsoft.com...
> >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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
!