Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

is there a way to tell the Windows DHCP-Client not to send along this useless UID parameter with its DHCP requests?

Thing is: We have dual boot machines (Windows and Linux). When Windows gets started first it gets the lease based on a UID that it sends along. Subsequent Linux DHCP requests get a new lease because the DHCP client there - as the rest of the world excluding Windows - doesn't send a UID. The DHCP protocol allows this and if there's a lease with UID, it's preferred and the MAC address isn't even considered.

Our DHCP server has a configuration option to ignore the UID and handle requests only based on the mac address. This however is a violation of the DHCP protocol and therefor I would really be painfull to change this, even though it would most probably not do any harm.

A quick google search held nothing but one mailing list / forum conversation in which some Microsoft guy actually told the topic starter to fiddle with the DHCP server or to reconfigure the DCHP clients to send the same UID as Windows does.

share|improve this question
I understand your question but I'm not understanding the actual problem that you're trying to solve. Is it that the Windows DHCP client obtains the same ip address on startup that it previously had, due to the client identifier? – joeqwerty Jun 7 '11 at 12:29
@Joe, he thinks that both Windows and Linux should get the same IP on the same hardware. He's apparently under the impression that a "Client" is the hardware itself, instead of the DHCP Client Software. – Chris S Jun 7 '11 at 12:52
@Chris: that's not true. again: All I want is to stop windows from sending the UID with a dhcp request. it has to send chaddr - which should be unique - anyway. a client MAY send a UID value so this should clearly be at the discretion of the person who manages the client. – luxifer Jun 7 '11 at 13:25
"this should clearly be at the discretion of the person who manages the client" -- I don't think this is "clearly" the case at all. If we're going to talk about what the RFC means, then "MAY" doesn't mean "It must be an end user option", it means "it's up to you, person using this spec to code your utility. go nuts" – RobM Jun 7 '11 at 13:29
right... the RFC's talking about "vendors". still in every other os on the planet that comes with a dhcp client the admin can configure this... what's so hard in telling if it's possible with windows and if yes, how, anyway? – luxifer Jun 7 '11 at 13:46
up vote 1 down vote accepted

This is possible for Windows 8.1 with the November 2014 update rollup and Windows 10:

share|improve this answer

I don't understand the "painful" part (mostly where exactly its going to cause pain). I am assuming that UID stands for "unique identifier". The MAC address IS a unique identifier and a duplicate is something you will rarely if ever see. There is no harm in doing this.

share|improve this answer
@luxifer, you have two different OSes, just because they're on the same physical hardware does not make them the same DHCP Client or DNS Host (they should be different, though nobody's forcing you to not have conflicting settings). Windows will issue the same UID every time (until something changes), I don't see how that violates RFC2131. Your two OSes are not the same, see my comment above. Again, this behavior is by design. – Chris S Jun 7 '11 at 12:48
@Luxifer, There's nothing wrong here. Windows and Linux are two different OSes and have two different clients. The DHCP Server should respond to each client independently. This is the correct behavior. You are trying to convince the DHCP Server that two different clients are the same (which they are not). – Chris S Jun 7 '11 at 12:57
It appears what you're after is called Static IP's. It resolves your issue entirely. – ITHedgeHog Jun 7 '11 at 13:07
You still haven't said what will happen if you're not RFC compliant, or why this is actually a problem? I don't engineer my networks to be RFC compliant, I engineer them to WORK. – SpacemanSpiff Jun 7 '11 at 13:28
@Luxifer, the RFC clearly states that the implementation MAY send a UID; it clear does not state if this will be a configurable option. Therefor an implementation may or may not implement it, and if it is implemented the implementation may or may not make it user configurable. All of this conforms to the RFC so far. You may not like it, but it is the way it was designed (and purposely so at that). – Chris S Jun 7 '11 at 13:40

This behavior of windows is by design and in accordance with the spec. Until the linux DHCP clients come up to 2131 spec (it's only been 15 years which is nothing in *nix time) your best bet is to set your DHCP server to ignore the client identifier and instead rely on the chaddr field (essentially reverting it to rfc 1541 behavior). You cannot remove the UID field from the windows client.

share|improve this answer
the spec says it MAY be used so I don't see where linux DHCP clients violate the spec by not using it by default... and again: I don't know if there are hosts in our network, which rely on compliance to this very part of the spec... you also don't say whether it's possible to configure under windows or not – luxifer Jun 7 '11 at 13:51
they are not out of compliance with the spec, they have simply not implemented an essential piece. UIDs were introduced to solve problems with mac addresses and DHCP ( I believe it was a uniqeness issue in large networks IIRC that was primary). UIDs were left optional because of legacy clients and since once you start using one, you should be using it every time, there isn't really an issue. Leases for the UID using systems should get reassigned to the UID using systems and non UID using systems use mac addresses. – Jim B Jun 7 '11 at 14:00
i know... that's what i already said... all i want is to prevent windows from using a uid at all... btw: pxe doesn't use uids either (even if you'd like to) and pxe is younger than rfc 2131 – luxifer Jun 7 '11 at 14:34
correct PXE doesn't use UIDs and currently has no plans to get the spec updated - since for pxe it doesn't matter – Jim B Jun 7 '11 at 15:22
To be fair on Unix and Linux: After almost a year of pushing from Philip A. Prindeville, the default in RedHat's RawHide is for dhclient to be configured with send dhcp-client-identifier = hardware; as the default in /etc/dhcp/dhclient.conf. See RedHat Bug #560361. M. Prindeville also debunks the nonsense that luxifer is propounding here, saying "actually most DHCP clients (HP printers, iPhones, Windows, Symbian phones, etc) all use a client-id ...". – JdeBP Jun 7 '11 at 16:18

is there a way to tell the Windows DHCP-Client not to send along this useless UID parameter with its DHCP requests?


share|improve this answer
having waded through this I think you're right – Iain Jun 7 '11 at 14:10
i also found this but it's 5 years old information... there may have been the remote chance that this situation had changed in the meantime... – luxifer Jun 7 '11 at 14:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.