Fortunately, when a client submits a DHCP request, and the Cisco ACI Fabric is configured for DHCP Relay, the Cisco ACI fabric automatically inserts the DHCP Option 82 information into the proxied request on behalf of the client. This means you really do not have to do anything other than make sure Cisco ACI is configured for DHCP relay. Also keep in mind that the 1st IP Subnet assigned to the Bridge Domain will become the proxy agent. If you have multiple subnets defined on the bridge domain, make one of them “Primary” by checking “Make this IP Address Primary” under the respective Bridge Domain Subnet.
With Windows Server 2003 and 2008, these do not support Option 82. As a result, for these operating systems, you must have these servers connected to the same bridge domain as the client in order to dish out DHCP IP Addresses.
With Server 2012, this operating system supports Option 82 but not all options. It does not support the “link selection” sub-option which is needed for inter-VRF use cases. If you have a tenant VRF with clients and the DHCP server in the same VRF, then Server 2012 will support your use case with a tenant DHCP policy. On the other-hand, if you have a Multi-tenant or multi-VRF use case where the Windows 2012 DHCP Server issues IP Addresses to client in various VRFs, well then you are stuck. I suggest you upgrade to Windows Server 2016 or 2019 or use a real DHCP server like Infoblox.
Another caveat with Server 2016 and 2019 is in order to get DHCP relay to work properly with inter-VRF implementations, you must define a local scope for the DHCP server subnet itself. If you have clients on this subnet then create a local scope in addition to a client scope. If you don’t need a server subnet scope, then create the IP Address Range for the DHCP Server subnet and exclude them. If you do not do this, your Windows 2016/2019 DHCP server will get NACK DHCP responses.