I have never seen DHCP options delivered via GPO as that would be literally putting the cart before the horse. You can employ scripts via GPO that make changes to network card settings on machines after the fact, but DHCP is your driving factor here.

You posted this in the HP Procurve thread, so it might be best to attack the issue from the switch standpoint further. If you find after further investigation that its not a switch config issue, then I would suggest posting this question in the forum for your server OS version or in the DNS/BIND/DHCP/WINS Issues section of this website.

Now, to attack it further from this forum, please include some additional info about your setup, ie... OS version you are using for your network. Location of this/these DHCP servers as you mention you have sites, but it's not 100% clear if you have just the one at the main site, or some at the remote you are talking about. Lastly, give us a little snippit of your config on your switches with the VLAN settings. You can change the IP addresses if you feel the need for some privacy.

Did you add the new subnets into Site & Services in AD?

this is the switch config, it's very basic. The DHCP server is connected to a port that is Untagged for the server Vlan and tagged for the other vlans.

hostname "HP-E3500yl-24G-PoE+"
module 1 type J93xxA
ip routing
vlan 1
name "Servers"
untagged 1-8,12,19-20
ip address 192.168.0.1 255.255.255.0
tagged 9-11,13-18,21-24
exit
vlan 10
name "Users"
untagged 9-11,14-18,21-24
ip helper-address 192.168.0.12
ip address 192.168.100.1 255.255.255.0
tagged 1-8,12-13,19-20
exit
vlan 30
name "Voice"
untagged 13
qos priority 6
ip address 172.40.0.1 255.255.255.0
tagged 1-12,14-24
voice
exit
ip route 0.0.0.0 0.0.0.0 192.168.0.254
snmp-server community "public" unrestricted

Hi VinceWhirlwind

I will confirm with the server administrator if he added the new subnet into AD sites & services

So are you saying that users directly connected to the VLAN10 's untagged ports are encountering this issue or on the tagged ports going to other switches up the link?

Some users are directly connected to the switch on an Untagged port for Vlan10 and still not getting IP's.

This is definately not a tagging issue, it must be on the Domain controller

As Vince mentioned, have you checked then on the subnets created under AD Sites and Services? Also, it's actually best practice to not have DHCP running on a domain controller due to security issues. http://social.technet.microsoft.com/Forums/eu/wins...
If you have another server (non DC) you can run this from, I would just keep it there as that's best practice anyway.
Regardless, let us know about the sites and services config to proceed further just for courisity sake since it still should work from the DC. Also, what version is your server O.S.?

The other thing is your spanning-tree config.

By default, spanning-tree isn't enabled on E-series switches (as far as I can remember). Obviously, you should have enabled it. Make sure the Access ports are "fast-starting". Can't remember what it's called. "Admin-edge" or something maybe, "fast port-span". Get the config guide for your software version and ensure the Access ports are being fast-started.

A slow start could lose your DHCP requests.

I will inform you once all has been checked.

Spanning tree is not needed in such a small environment and is disabled. I'm only running loop protect.

Just remembered another cause of DHCP not working: server NICs are dot1q-capable. If your server is patched into a "Trunk" port, ie a switchport that has the other VLAN on it as "tagged", even though the server has no interface (and no IP address) in this other network, it will see the tagged broadcast frames regardless, and act on them. Only problem is that it is seeing the broadcast before it is DHCP-forwarded so it has no idea what subnet the request relates to (because it has no leg in that subnet), and it replies with a duff offer. The client then rejects it and the server meanwhile gets the same request again, but from the router interface, sees it is the same request and ignores it.

At least, that's my vague memory of what happens, haven't had to deal with it again since coming across it about 4 years ago.

Just another example of how crappy servers can muck up your network for inexplicable reasons.

Hi Vince

Thanks for the reply.

You basically have it correct. The server is connected to 2 lacp trunked ports. I have had this issue again recently. The dhcp does work but takes long. Still no exact solution.

Make sure the Server switchports do not have multiple VLANs on them, but just have the appropriate Server VLAN untagged.

Make sure your switchports are fast-starting. To test them, put an IP address on a device, do a continuous ping to it, then disconnect its switchport and reconnect. The ping should succeed within a few seconds of reconnecting it.