IPCONFIG /RENEW fails when 2012 DHCP server in a failover relationship is in communication interrupted or partner down state. This behavior is by design and is the only instance Microsoft has not followed the IETF DHCP Failover draft standard.
DHCP RENEW behavior of Microsoft Server 2012 DHCP Servers when failover relationship in communication interrupted or partner down state
“RENEW requests from the client will not be responded to. This will cause the client to move into REBIND state. If the server which owns the hash bucket assignment for this client is operational by the time the client moves into REBIND state, the REBIND request will be responded to by this server. This ensures that the client is now in transaction with the server which owns the hash bucket assignment for this client (fail back of the client).” — http://blogs.technet.com/b/teamdhcp/
The command IPCONFIG /RENEW reports a failure in this situation as the command only sends out a DHCP RENEW request.
DHCP RENEW V’s DHCP REBIND some background information
When a client gets to half way through its IP address lease it performs a DHCP RENEW. To do this it sends a unicast packet to the issuing DHCP server and attempts to renew the lease on the currently allocated address.
If a client does not get a response to its DHCP RENEW request it will continue to use the IP address it has been allocated until it gets to 87.5% of the way though its lease, at this point it will perform a DHCP REBIND. To do this the client sends a broadcast DHCP REQUEST out its network interface, as this is a broadcast packet all servers on the network will receive it.