Windows Server 2008 RC2 DHCP Server Option 119
If you’ve scoured through Windows Server configurations for the DHCP server looking to set the Search Domains and have come up empty, there’s good reason: Most, if not all, versions of Windows do not support setting Search Domains via DHCP (option 119), thus Microsoft does not include a visible option to set this on their DHCP servers.
99% of the computers used at my company are Windows based, so we use GPO to push down the search domains and it works pretty well. We do, however, have iPads used by upper management, as well as Android users connecting to the corporate wifi and a few of us using Linux based operating systems which won’t accept Microsoft’s GPO. We were essentially out in the cold unless we manually configured our networking options to add all of the search domains used by our company.
Someone in Executive Management requested that the “GPO only” push of search domains be changed to be included in the DHCP server for any non-Windows users. After 3 hours of troubleshooting, searching the web, and scouring RFC’s, we finally implemented it. Here are some notes about our journey: Technet is wrong when it explains how to add this functionality; everyone who says just use GPO simply didn’t get that non-Windows couldn’t use GPO; Stephen was close in his explanation, but that still didn’t work (chankster even pointed him to the RFC that helped me, but he brushed it off).
The size does indeed have to be per domain component (excluding the ‘.’); but the size also comes BEFORE the domain component, not after. The domain in it’s entirety also needs to be null terminated. So here’s an example: apple.com (we’ll use Stephen’s example as a base).
We have two domain components: apple and com
Translated to hex, we get the following:
a - 0x61 p - 0x70 p - 0x70 l - 0x6c e - 0x65 c - 0x63 o - 0x6f m - 0x6d
The size of apple is 5, or 0×05 and the size of com is 3, or 0×03, so our complete string is
0x05 0x61 0x70 0x70 0x6c 0x65 0x03 0x63 0x6f 0x6d 0x00
Each one of these needs to be individually added as a separate byte in the array for the 119 option in the DHCP server configuration (Remember to null terminate the entries with 0×00). Once we made this change and saved it, our non-Windows based clients were then able to get the Search Domains via DHCP (note: it appears Android does not support option 119 as well, at least from my testing with packets from Wireshark).
Hope this helps someone out.
| Print article | This entry was posted by Matt on March 16, 2011 at 3:54 pm, and is filed under Linux. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
about 2 years ago
Thanks for this article, made my life easier. I noticed a small mistake: You interchanged the hex codes for o and m
about 2 years ago
Thanks Derek, I’ve corrected the hex codes. Glad this helped you.
about 2 years ago
Works perfectly! Thanks so much for this.
about 2 years ago
Great article Matt, it really helped me out! Just one question – I have this working for multiple domains but it doesn’t seem to work for sub domains.
For example, below are the domains and how they show up on the client:
Converted to HEX and entered in DHCP 119:
domain1.local
domain1.net
sub.domain1.net
DNS Search List on Client:
domain1.local
.domain1.net
Any pointers would be greatly appreciated.
Thanks.
about 2 years ago
Don’t worry, simple typo was the issue! Easily done with all those HEX bytes!
Thanks again for the great article.
about 2 years ago
Glad you got it sorted… I was a bit perplexed at first, because all but one of our domains at work are sub-domains, so it should have worked.
about 1 year ago
Thanks! Brilliant lifesaver. We’re slowly moving all our DHCP to Windows across hundreds of schools and we have various intranet sites with different domain endings. This helps the Macs get there where the content has many unqualified links. Don’t approve of unqualified links myself but you can’t stop everyone in such a large disparate organisation.
about 1 year ago
Sorry to ask dummie questions (hope this help other dummies), so let’s say, i.e. I set 119 as a default dhcp option on a DHCP Windows Server, type string. Then configuring a scope options for a search list in foo.com and tenletters.com, according to Microsoft http://technet.microsoft.com/en-us/library/dd572752(office.13).aspx I should write in the ‘String’ field foo.com;tenletters.com, but this shouldn’t work on all OSes.
Instead you suggest to set option 119 type as Byte and flag ‘Array’, then add for each (?) suffix an 119 option like 0×03 0×66 0x6f 0x6f 0×03 0×63 0x6f 0x6d 0×00 (corresponding to foo.com) and 0x0a 0×74 0×65 0x6e 0x6c 0×65 0×74 0×74 0×65 0×72 0x7a 0×03 0×63 0x6f 0x6d 0×00 (corresponding to tenletterz.com)? Does this work on Windows XP to 7?
In any case, readers take care to convert string length, which is a number, following the link Decimal to Hex
about 1 year ago
Sorry, forgot to change all tenletterz.com. No offense and no reference to letters.com (existing)
about 1 year ago
Yes, I’m basically saying don’t listen to Microsoft. This will not work on any Windows machine as Windows does not support option 119. If you want to push down search domains to Windows machines you’ll need to either manually configure it on your machines or use Group Policy.
about 1 year ago
Thanks Matt for the information. However, I have followed your instructions but my mac clients are still not receiving the domain search list. Is there an order in which you enter the bytes into the Data Byte Entry?
In your example: 0×05 0×61 0×70 0×70 0x6c 0×65 0×03 0×63 0x6f 0x6d 0×00, do you enter 0×05 first, or 0×00?
Many thanks in advanced!
about 1 year ago
We typed them in, in the exact order shown. I’d suggest using a tool like Wireshark to capture the packets on the Mac (or over the wire in promiscuous mode) and see if a) the Mac is requesting option 119 from the server, and b) if so, what the response from the server is.
about 1 year ago
Matt,
What the other person was trying to ask was the order in which the DHCP server reads the hex information. If you type it in the order in which you did, it shows up backwards in the scope options. Assuming the first hex address it read was 0×0 instead of 0×05, it would expect no letters after the first hex. If the first hex was 0×05, it would expect 5 letters.
I will assume since the other scope options are in the correct order, you would need to put these in reverse order.
about 1 year ago
Is there a maximum length? I can get apple.com to work fine, like your example above… but I can’t get my company domain to work. 12(criticalmass) + 3(com) characters.
about 1 year ago
Nice blog and good content, thank you for putting in the effort
about 1 year ago
Thansk for this article Matt. Other than the RFC notes, this was the most helpful page I have come across on this topic so I thought I would share here.
Configuring by hand using the GUI is tedious and error prone. Fortunately NETSH can be used to configure option 119. Using the apple.com example, the following netsh command will configure option 119 for scope x.x.x.x on server ‘servername’:
netsh dhcp server \\servername scope x.x.x.x set optionvalue 119 BYTE 05 61 70 70 6c 65 03 63 6f 6d 00
about 7 months ago
Here are the netsh commands to perform all of the steps, and a perl one liner to print the appropriate hex strings (CYGWIN):
1)
echo " " | perl -ne '@words=split;foreach $word ( @words ){ @chars=split(//,$word); $len=scalar(@chars); printf("%02X ", $len); foreach $char (@chars){ $ord = ord($char) ; printf("%02X ",$ord) }} printf("%02X\n","")'Example:
echo "google com" | perl -ne '@words=split;foreach $word ( @words ){ @chars=split(//,$word); $len=scalar(@chars); printf("%02X ", $len); foreach $char (@chars){ $ord = ord($char) ; printf("%02X ",$ord) }} printf("%02X\n","")'06 67 6F 6F 67 6C 65 03 63 6F 6D 00
2) Delete previous definitiion:
netsh dhcp server V4 delete optiondef 1193) Add the option to the DNS Server (run from server itself)
netsh dhcp server V4 add optiondef 119 "DNS Search Path" BYTE 1 comment="DNS Search Domains"4)Set the value for the scope:
netsh dhcp server V4 scope 10.10.10.0 set optionvalue 119 ARRAY 05 6E 78 73 79 73 03 6C 74 64 00about 7 months ago
Here is a PowerShell version, it returns each element on a separate line… so you’ll have to concatenate them manually.
"google com" | %{ $words= -split $_ ; $words | %{ $len=$_.length ; $len=([String]::Format("{0:x}", $len)).PadLeft(3,"0") ; $hex=[int[]][char[]]$_ ; ($len+" "+$hex) } | %{ Write-Host "$_ " } }
006 103 111 111 103 108 101
003 99 111 109
about 1 year ago
Thanks for this. I just used it on a Windows 2003 R2 DHCP server and it worked a treat.
about 1 year ago
I am trying this on Windows 2003 DHCP, but it not working for me…Not sure, if I am doing correctly….So, when I create the Byte array and enter the value like: 0×3 0×72 0×74 0×70 0×4 0×63 0x6f 0×72…..It picks up 0×3 only and truncates the complete string…please assist….
about 1 year ago
0×3 would indicate a string that is over 40 characters long… do you have a domain that is really that long? If it’s only 3 characters, you need 0×03.
about 11 months ago
I have problem on windows 2008 r2, when i entering 0×03 it saved as 0×3 . Please help
about 11 months ago
Enter the hex, line by line, don’t enter all the values on a single line otherwise all value except for the first will be truncated.
about 1 year ago
With DHCP Windows Server 2003 I had to enter binary values instead of hex when using netsh
about 10 months ago
Which character do I use to separate domains? I tried to simply end in 0×00 and then have 0×09 as the next character to indicate 9 letters in the first part of the next domain, but my client only picks up the first search domain. Do I use some other character to separate domains?
about 10 months ago
Figured it out, I simply had to follow point 4.1.4 of RFC 1035, available here: http://www.faqs.org/rfcs/rfc1035.html
about 3 months ago
Hi
I have a windows server 2008 and win 7 clients. Does the mentioned scope option support my scenario