DHCP is not just broadcast based. It it "Request" based. There is a connection to the network, then a request for an address on that network, then a reply sent from the DHCP server that either holds an address lease or reports a failure. The request is repeated on the client internally, sending out the request every few seconds and waiting for a response.
However if that response is not recieved, if it is dropped, or if it simply isn't passed through the switching devices properly, you won't be able to get an address. Check to make sure that your subnets are properly configured. I've noticed that many like to use the x.0.x bits to hold only the static managed devices (switches and printers) while keeping computers and servers on the x.1.x or otherwise (this is just an example). If you don't include the x.0.x in your subnet masking properly, you can end up with bitmasks that drop your dhcp requests, or misroute them.
Remember to include this x.0.x as the primary starting address, and then move on to set the subnetting as wide as you need with a masking that matches your dhcp in full; note that sume will set the subnetting with respect to the actual dhcp server, this is not useful, it creates packet leaks. If you set your dhcp to not hand out the static portion, you still need to set it inside your subnet.
If you subnet your dhcp, you should reconfigure the masks, adding 1 to the bitmask alteration. If you subnet 255.255.252.0 for your mask on your dhcp, you need to subnet 255.255.251.0 on your switches, to allow the requests for x.0.x address masks (static routes entered at the client) to carry the dhcp signal the same as the rest of the network. Make sure your subnet masking allows the subnets that need to interact to see each other, even if only to pass the dhcp requests through.
You can separate network services on windows machines (and now macs) by setting workgroup or domain restrictions. Access to services should be handled by login, not by vlan. Login can control the address you receive if you know how to write the script into your servers, but that should only be done when absolutely necessary. VLAN should only function to help a network tech track, trace and fix a problem by following the address masking scheme to a physical location.
Remember, you can bridge vlans of completely different masks, but this only allows them to see each other from a networking standpoint, not an access level. If they need access to services, the vlans should all be bridged to a major interface and that interface should carry the full mask containing all vlans, while the vlan interfaces carry only primary mask 255.255.255.0 (or whatever vlan subnet you put accross it).