We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Solved
Windows DHCP Client and Server
Posted on 2011-02-27
In windows environment, I have noticed some computers pick up DHCP address even before they get windows OS installed.
For instance if I install vmware ESX it will pick up DHCP IP address... If I install an HP server it will also pick up DHCP IP address before windows OS is installed..
I was wondering what is the usage of windows DHCP client service if a computer is able to pick and IP address before even the OS is installed.
one thing I thought about is if a computer picks an IP address before the OS is installed, when the OS is installed, windows DHCP client can reassign IP address according to windows DHCP server configuration such as pools and scope options, exclusions,etc...
any expert out there to clear this up?
Thanks
For instance if I install vmware ESX it will pick up DHCP IP address... If I install an HP server it will also pick up DHCP IP address before windows OS is installed..
I was wondering what is the usage of windows DHCP client service if a computer is able to pick and IP address before even the OS is installed.
one thing I thought about is if a computer picks an IP address before the OS is installed, when the OS is installed, windows DHCP client can reassign IP address according to windows DHCP server configuration such as pools and scope options, exclusions,etc...
any expert out there to clear this up?
Thanks
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3
3-
2
- +1
9 Comments
This is quite normal, and even Windows will do this whilst it's installing.
Once the NIC is active it's possible to request an IP, most hardware these days also has a boot to network option to do this it may need an IP
Once the NIC is active it's possible to request an IP, most hardware these days also has a boot to network option to do this it may need an IP
It's not limited to network installs. You could actually boot from a Windows Image or a VDI environment. There are lots of uses.
Active 3 days ago
- what does a computer use to get an IP address, before the OS is installed?
-what is the usage of DHCP client of windows , if a computer can get an IP address even before OS is installed which means before even DHCP client service is in service. ??
-what is the usage of DHCP client of windows , if a computer can get an IP address even before OS is installed which means before even DHCP client service is in service. ??
It can either use APIPA (Automatic Private IP Addresing) or an available DHCP service.
This is not used by the OS because Windows for example will add it's own NIC driver and control DHCP that way, the same way as most OS's.
But, if it's booting to the network and connecting to an operating system image then it will still need an IP address but the Windows OS isn't stored locally so will get a different IP.
This is not used by the OS because Windows for example will add it's own NIC driver and control DHCP that way, the same way as most OS's.
But, if it's booting to the network and connecting to an operating system image then it will still need an IP address but the Windows OS isn't stored locally so will get a different IP.
jskfan:
- There are 2 things. The "PreBoot" environment and the OS (booted) environment.
In PreBoot environment, you have the BIOS and the BIOS extensions, that's almost all of it.
In Booted environment, you have the full OS, including network stack (which comprise network drivers and protocol drivers).
In booted environment, you can use DHCP to automatically assign an IP address to a network card, but you can also use a static address.
In preboot environment, you could use static addresses, but this would be inconvenient since you have no OS to enter the IP address. It COULD be entered at the BIOS level, as a BIOS parameter, but this would be hard and not user friendly. So was designed BootP protocol in the 1980s. It was used mostly to provide a basic TCP/IP configuration to computers in the "PreBoot" environment. At that time, most computers where using static IP addresses, but in order to be able to automate some "pre-boot" tasks, or to use diskless computers, there was a need to provide, automatically, some IP configuration to computers in the "PreBoot phase".
Of course, the computer had to be "BootP-capable". This implied that they had some BootP support at the "BIOS" level. For instance in their firmware, or with option ROMs inserted in the network cards.
Then, some people thought "hey, if I can automatically assign IP configuration to computers in the pre-boot phase, why can't I do that when the OS is booting? Then I would be able to centrally manage the IP configurations of my computers, such as [Computer A gets IP address 1.2.3.4 and related configuration]". And some (other) people thought even further: "can't I define pools of IP addresses so that client computer will get some address of the pool"? Of course they could and they designed the DHCP system (which is an extension of bootp. It uses the same ports and share some of the logic).
And in the mid 90s, Intel thought that the "pre-boot" support using Bootp/DHCP was not enough and that it had to be enhanced. They designed the PXE (Preboot eXtension Environment) specifications, which is somewhat an evolution of DHCP. It relies on DHCP but adds some more logic to it. But basically, it is aimed at providing an IP configuration AND a "remote boot file" to any client using it.
PXE has been since then widely used and became a de facto standard. Now, you have PXE capable BIOSes/NICs in almost 99% of the x86/x64 computers on the market.
This is why you can "PXE boot" a client, while in the pre-boot phase. It will get a DHCP-assigned address and can also get a "network boot file" to load and run. This network boot file can be used to install an OS on the client's local HDD, to clone a disk image on local HDD, to run diagnosis or to boot an OS on a client that has no HDD.
But usually, the IP configuration that has been assigned to the client when in the PXE phase is not available to the OS booted on the client, when it booted off a local HDD. The OS then performs its own "DHCP requests", that are different from the PXE requests. The OS can't assume that the computer was PXE-capable or that PXE requests were sent before the OS was loaded.
So, assuming that your client began to boot using PXE, got an IP address then, but actually finished to boot off its local HDD, there is nothing that can assure you that the client will get the same IP address in the PXE Phase and in the "OS phase". Actually, there are even cases when you can be sure that the client will get different addresses in both phases.
If you want to know more about all this, search bootp, dhcp a,d PXE on wikipedia and other resources.
HTH
- There are 2 things. The "PreBoot" environment and the OS (booted) environment.
In PreBoot environment, you have the BIOS and the BIOS extensions, that's almost all of it.
In Booted environment, you have the full OS, including network stack (which comprise network drivers and protocol drivers).
In booted environment, you can use DHCP to automatically assign an IP address to a network card, but you can also use a static address.
In preboot environment, you could use static addresses, but this would be inconvenient since you have no OS to enter the IP address. It COULD be entered at the BIOS level, as a BIOS parameter, but this would be hard and not user friendly. So was designed BootP protocol in the 1980s. It was used mostly to provide a basic TCP/IP configuration to computers in the "PreBoot" environment. At that time, most computers where using static IP addresses, but in order to be able to automate some "pre-boot" tasks, or to use diskless computers, there was a need to provide, automatically, some IP configuration to computers in the "PreBoot phase".
Of course, the computer had to be "BootP-capable". This implied that they had some BootP support at the "BIOS" level. For instance in their firmware, or with option ROMs inserted in the network cards.
Then, some people thought "hey, if I can automatically assign IP configuration to computers in the pre-boot phase, why can't I do that when the OS is booting? Then I would be able to centrally manage the IP configurations of my computers, such as [Computer A gets IP address 1.2.3.4 and related configuration]". And some (other) people thought even further: "can't I define pools of IP addresses so that client computer will get some address of the pool"? Of course they could and they designed the DHCP system (which is an extension of bootp. It uses the same ports and share some of the logic).
And in the mid 90s, Intel thought that the "pre-boot" support using Bootp/DHCP was not enough and that it had to be enhanced. They designed the PXE (Preboot eXtension Environment) specifications, which is somewhat an evolution of DHCP. It relies on DHCP but adds some more logic to it. But basically, it is aimed at providing an IP configuration AND a "remote boot file" to any client using it.
PXE has been since then widely used and became a de facto standard. Now, you have PXE capable BIOSes/NICs in almost 99% of the x86/x64 computers on the market.
This is why you can "PXE boot" a client, while in the pre-boot phase. It will get a DHCP-assigned address and can also get a "network boot file" to load and run. This network boot file can be used to install an OS on the client's local HDD, to clone a disk image on local HDD, to run diagnosis or to boot an OS on a client that has no HDD.
But usually, the IP configuration that has been assigned to the client when in the PXE phase is not available to the OS booted on the client, when it booted off a local HDD. The OS then performs its own "DHCP requests", that are different from the PXE requests. The OS can't assume that the computer was PXE-capable or that PXE requests were sent before the OS was loaded.
So, assuming that your client began to boot using PXE, got an IP address then, but actually finished to boot off its local HDD, there is nothing that can assure you that the client will get the same IP address in the PXE Phase and in the "OS phase". Actually, there are even cases when you can be sure that the client will get different addresses in both phases.
If you want to know more about all this, search bootp, dhcp a,d PXE on wikipedia and other resources.
HTH
Featured Post
ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.
One of a set of tools we're offering as a way to say thank you for being a part of the community.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
I guess it is not common knowledge to most Wintel engineers/administrators: If you have an SNMP-based monitoring system in your environment (and it's common to have SNMP or Syslog) it's reasonably easy to enable monitoring of the Windows Event logs,…
I've always wanted to allow a user to have a printer no matter where they login. The steps below will show you how to achieve just that.
In this Article I'll show how to deploy printers automatically with group policy and then using security fil…
In this episode Don builds upon the troubleshooting techniques by demonstrating how to properly monitor a vSphere deployment to detect problems before they occur. He begins the show using tools found within the vSphere suite as ends the show demonst…
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data.
But that feeling is fleeting. Attacks these days can happen in many w…
Suggested Courses
Course of the Month6 days, 7 hours left to enroll
705 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.