Some DHCP clients do not reliably disclose the OS information at boot. As was mentioned above, there is some intellectual property associated with these techniques; for instance, Infoblox and Cisco ISE can build client OS profiles based on the dhcp packets they see. Actually Cisco ISE includes some fairly sophisticated OS classification algorithms, if you can send more than dhcp to it.
Alternatively, you could use a heuristic like the Windows endian bug in the "seconds elapsed" field, but relying on an OS bug is a poor way to handle OS detection.
If you really must detect the OS without a dedicated vendor appliance, just issue an IP address, and scan the host with NMAP after sending the DHCP Ack. Using HTTP headers is not as reliable as nmap, because anyone can change the UserAgent string if they want. nmap is not 100% reliable at OS detection, but it is about as good as you will find if you must choose a single method for everything.
I would make this a configurable option on the server since some folks may not like a default nmap scan on every DHCP host.
Example nmap OS scan against Windows7:
[mpenning@myhost ~]$ sudo nmap -O 10.1.1.1
Starting Nmap 5.51 ( http://nmap.org ) at 2013-08-24 16:20 CDT
Nmap scan report for 10.1.1.1
Host is up (0.00078s latency).
Not shown: 985 closed ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Device type: general purpose
Running: Microsoft Windows Vista|2008|7
OS details: Microsoft Windows Vista SP0 - SP2, Server 2008, or Windows 7 Ultimate
Network Distance: 5 hops
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.25 seconds