Findings:
Currently, Windows 2012 R2 AD DS role and RDS With Broker services can only seem to coexist properly in a new domain not an existing domain. Any attempt to add to an existing domain causes internal database user access denied issues and any attempt to adjust rights and circumvent is dubious at best.
The escalation technician said it best. Out of 50 clients that want to do this, they end up not being able to help 5 right off the bat for whatever reason. As for the other 40 they might be able to help by running reports, adjusting rights and trying to add the roles until it works. This can end up being a 20 day process. Basically they are playing whack-a-mole with user rights and permissions until something sticks.
We tried creating an OU where any other domain policies would not be inherited to see if that was the issue, a fresh install with different sequence of adding the Roles, no effect.
Given the errors I witnessed when running procmon and then trying to add the roles, the NT System and the Windows Internal database user had access denied issues on 100+ registry keys when trying to add the roles. After that the system is not behaving normally. The errors displayed almost mirror the errors that would occur on Windows 2012 when those two roles would be added which of course is officially NOT supported on that system.
This blog needs serious revision:
http://blogs.msdn.com/b/rds/archive/2013/07/09/what-s-new-in-remote-desktop-services-for-windows-server-2012-r2.aspx
This is the excerpt from that blog: Single server RDS deployment including Active Directory. We now support running our RD Connection Broker role service on the same physical instance as an Active Directory Domain Controller. In addition, we published guidelines for how RD Session Host could be used without the RD Connection Broker.
Microsoft Support was curteous and helpful and they were the ones who advised cutting our losses, which mirrored my hunch after seeing what was transpiring in the system. They refunded my money for the support call.
For me, it was an opportunity to find out if there was any way to configure Windows 2012 R2 in the Same manner that it was setup as Windows 2008 R2 and lay that to rest. The coexistence is poorly implemented. It is as if there was a reaction from all the deprecation of bread and butter features such as shadowing in TS and the coexistence of AD DS and RDS to where those features were re-added haphazardly. (I have no complaints on shadowing on Windows 2012 R2 it works, just do not like having to go to server manager to use it).
I opted for virtualizing the Domain controller to eliminate the incompatibility issues and that is what I will be doing from now on. I found free solutions for backing up and reporting for virtual machines as well as the suggested procedures for configruing a Domain controller as a virtual machine on a Hyper-V environment and I will be sticking to those. Thus far the setup has been operational.
I am not allergic to virtualization, but for really small setups it adds additional time and considerations but if that is how it has to be done, so be it. Windows 2008 R2 days are numbered and since we can usually squeeze 5-7 years on quality server equipment, buying a Windows 2008 R2 setup now is a borderline disservice in my opinion.
Hopefully someone finds this useful and saves some time.
Currently, Windows 2012 R2 AD DS role and RDS With Broker services can only seem to coexist properly in a new domain not an existing domain. Any attempt to add to an existing domain causes internal database user access denied issues and any attempt to adjust rights and circumvent is dubious at best.
The escalation technician said it best. Out of 50 clients that want to do this, they end up not being able to help 5 right off the bat for whatever reason. As for the other 40 they might be able to help by running reports, adjusting rights and trying to add the roles until it works. This can end up being a 20 day process. Basically they are playing whack-a-mole with user rights and permissions until something sticks.
We tried creating an OU where any other domain policies would not be inherited to see if that was the issue, a fresh install with different sequence of adding the Roles, no effect.
Given the errors I witnessed when running procmon and then trying to add the roles, the NT System and the Windows Internal database user had access denied issues on 100+ registry keys when trying to add the roles. After that the system is not behaving normally. The errors displayed almost mirror the errors that would occur on Windows 2012 when those two roles would be added which of course is officially NOT supported on that system.
This blog needs serious revision:
http://blogs.msdn.com/b/rds/archive/2013/07/09/what-s-new-in-remote-desktop-services-for-windows-server-2012-r2.aspx
This is the excerpt from that blog: Single server RDS deployment including Active Directory. We now support running our RD Connection Broker role service on the same physical instance as an Active Directory Domain Controller. In addition, we published guidelines for how RD Session Host could be used without the RD Connection Broker.
Microsoft Support was curteous and helpful and they were the ones who advised cutting our losses, which mirrored my hunch after seeing what was transpiring in the system. They refunded my money for the support call.
For me, it was an opportunity to find out if there was any way to configure Windows 2012 R2 in the Same manner that it was setup as Windows 2008 R2 and lay that to rest. The coexistence is poorly implemented. It is as if there was a reaction from all the deprecation of bread and butter features such as shadowing in TS and the coexistence of AD DS and RDS to where those features were re-added haphazardly. (I have no complaints on shadowing on Windows 2012 R2 it works, just do not like having to go to server manager to use it).
I opted for virtualizing the Domain controller to eliminate the incompatibility issues and that is what I will be doing from now on. I found free solutions for backing up and reporting for virtual machines as well as the suggested procedures for configruing a Domain controller as a virtual machine on a Hyper-V environment and I will be sticking to those. Thus far the setup has been operational.
I am not allergic to virtualization, but for really small setups it adds additional time and considerations but if that is how it has to be done, so be it. Windows 2008 R2 days are numbered and since we can usually squeeze 5-7 years on quality server equipment, buying a Windows 2008 R2 setup now is a borderline disservice in my opinion.
Hopefully someone finds this useful and saves some time.