Looks like I'm running into (a variant of?) this issue: the promotion completes successfully if I use "long" logon credentials, i.e. A0.lab\AdmA0 instead of A0\AdmA0.
However, based on the article, this issue should only happen if NetBIOS over TCP/IP is disabled, but it's actually enabled, and this can be verified in the ipconfig output. I also tried configuring the VMs with static network settings instead of using DHCP (which is required by Azure), and forcing NetBIOS over TCP/IP to "Enabled", but the error always happens; the only way for the promotion process to work is by using "long" credentials.
However, this definitely seems to be an Azure-specific quirk: I have created an identical test environment on a local Hyper-V server, and everything works as it should.
Looks like either Azure is doing something strange at the network level which block NetBIOS, or the Azure Windows Server 2012 R2 VM templates have some strange NetBIOS-related behavior which makes DC promotion fail in this peculiar way.
Update:
Culprit found: https://msdn.microsoft.com/en-us/library/azure/dn133803.aspx.
Does Virtual Network support multicast or broadcast?
No. We do not support multicast or broadcast.
Azure virtual networks don't support broadcast; thus, even if NetBIOS is enabled, it just doesn't work. And it looks like Windows Server 2012 R2 really needs it for a DC promotion to work.
Workaround: use "long" logon credentials during DC promotion (full.domain.fqdn\username instead of NetBIOSDomain\username).
As for why Azure virtual networks don't support broadcast, and how can they manage to do that while still relying so heavily on DHCP... that's beyond my ability to understand. And I'm not quite sure I really want to understand; Azure networking is well known to be rather peculiar.
Best Answer
I'd comment on the original question so I can gather more info before posting my answer, but I don't have enough reputation yet as I'm new; go figure right :)
Anyway, I've ran into this twice for two different clients, one that was running SBS 2003 and another running 2008 R2 like you are. Both times had a few different tweaks but ultimately the solution turned out to be this:
Remove the Active Directory Domain Services role from the 2012R2 server if you have already installed it.
Reboot.
I know you already said you had Enterprise and Schema rights, but make sure you're using an account with Enterprise, Schema, and Domain admin creds.
Reboot the 2008 R2 DCs; yes all of them.
Go to the 2012 R2 server and add the Active Directory Domain Services role and reboot after it successfully adds.
Once logged back into the 2012 R2 server open Server Manager and on your post installation tasks you should see something similar to this screenshot:
picture source: http://blogs.interfacett.com/wp-content/uploads/2013/02/015-promote-domain-controller-server-2012-add-a-child-domain-ad-ds.png
click on the link "Promote this server to a domain controller" (ADPrep (both forest and domain) will run automatically without manually needing to have you run it from a command prompt)
If you are still having trouble please look for the value in ADSI Edit for your server entitled "ClaimIsValueSpaceRestricted"; it will either be true or false. Let me know if it's true or false and if it's greyed out or not. We can troubleshoot further should we need to, but steps 1-7 should resolve your issue.