Forum Discussion
Domain Controllers in Azure
Can I build a domain controller in Azure and sync it to OnPrem? Is this the best way if we slowly want to move out of On-Prem or should there be a migration strategy of moving On-Prem DC to Azure?
As, I want to get Windows 365 PC setup and want to be 100% Azure AD joined and not Hybrid Azure AD of the Windows PCs.
Thoughts and suggestions and documentation?
The answer can be yes or no depending on exactly what you're asking, but reading between the lines - and given you have posted a second question asking about an on-premise application - I feel like you're in the "no" camp.
Explaining "yes"
Technically, you can host a domain controller in Azure as a virtual machine (i.e. an IaaS deployment.) However, apart from being located in a Microsoft datacentre, there's no architectural change and does not specifically benefit your desire to go cloud-only.
Independent of whether you host your domain controllers on on-premise hardware or on Azure IaaS, you'll still have to have the usual things like Azure AD Connect synchronising account and groups from your on-premise domain controllers over to your Azure tenant - Azure IaaS does not change this model.
Which leads us to the "no" explanation.
Explaining "no"
The primary driver underpinning the "no" answer isn't actually which "joining" model you wish to pursue, since it is possible (with caveats, naturally) to operate a hybrid environment (i.e. both AD and AAD) while only using Azure AD joining. Rather, the primary driver are the on-premise applications you run.
I've already provided a generic overview in your other question but to summarise here:
- If your applications have some kind of direct or indirect dependency on Windows-integrated authentication at the device level, then you cannot do either of the following:
- Go purely with Azure AD device joining;
- Go cloud-only (i.e. you'll still need your AD forest + AAD Connect);
- If your applications only target user accounts for Windows-integrated authentication, then:
- You may be able to avoid hybrid-joining devices and go straight to a pure Azure AD joining model (with caveats mentioned in the other article);
- You still need the on-premise AD + AAD Connect, meaning for as long as those applications are around, you cannot go cloud-only.
Although I linked this article in the other post, for completeness, here it is again - bookmarked at the best section for the application discussion.
Circling back to domain controller placement
Where the domain controller is placed (Azure IaaS or on-premise) does not change anything for you. You can move them to Azure IaaS if you want to avoid managing your own on-premise hardware but the fundamental architecture isn't profoundly different and won't help you reach a cloud-only implementation.
Similarly, domain controller placement has nothing to do with choosing between hybrid- or Azure AD-joining.
Potential alternative to domain controllers (and therefore on-premise AD)
You may want to look into Azure Active Directory Domain Services. Like anything halfway useful in Azure, you have to pay extra for it, but it may allow your remaining on-premise applications to operate successfully while providing you with a pathway to decommissioning your on-premise AD earlier than you otherwise would be able to.
Cheers,
Lain
- If your applications have some kind of direct or indirect dependency on Windows-integrated authentication at the device level, then you cannot do either of the following:
The answer can be yes or no depending on exactly what you're asking, but reading between the lines - and given you have posted a second question asking about an on-premise application - I feel like you're in the "no" camp.
Explaining "yes"
Technically, you can host a domain controller in Azure as a virtual machine (i.e. an IaaS deployment.) However, apart from being located in a Microsoft datacentre, there's no architectural change and does not specifically benefit your desire to go cloud-only.
Independent of whether you host your domain controllers on on-premise hardware or on Azure IaaS, you'll still have to have the usual things like Azure AD Connect synchronising account and groups from your on-premise domain controllers over to your Azure tenant - Azure IaaS does not change this model.
Which leads us to the "no" explanation.
Explaining "no"
The primary driver underpinning the "no" answer isn't actually which "joining" model you wish to pursue, since it is possible (with caveats, naturally) to operate a hybrid environment (i.e. both AD and AAD) while only using Azure AD joining. Rather, the primary driver are the on-premise applications you run.
I've already provided a generic overview in your other question but to summarise here:
- If your applications have some kind of direct or indirect dependency on Windows-integrated authentication at the device level, then you cannot do either of the following:
- Go purely with Azure AD device joining;
- Go cloud-only (i.e. you'll still need your AD forest + AAD Connect);
- If your applications only target user accounts for Windows-integrated authentication, then:
- You may be able to avoid hybrid-joining devices and go straight to a pure Azure AD joining model (with caveats mentioned in the other article);
- You still need the on-premise AD + AAD Connect, meaning for as long as those applications are around, you cannot go cloud-only.
Although I linked this article in the other post, for completeness, here it is again - bookmarked at the best section for the application discussion.
Circling back to domain controller placement
Where the domain controller is placed (Azure IaaS or on-premise) does not change anything for you. You can move them to Azure IaaS if you want to avoid managing your own on-premise hardware but the fundamental architecture isn't profoundly different and won't help you reach a cloud-only implementation.
Similarly, domain controller placement has nothing to do with choosing between hybrid- or Azure AD-joining.
Potential alternative to domain controllers (and therefore on-premise AD)
You may want to look into Azure Active Directory Domain Services. Like anything halfway useful in Azure, you have to pay extra for it, but it may allow your remaining on-premise applications to operate successfully while providing you with a pathway to decommissioning your on-premise AD earlier than you otherwise would be able to.
Cheers,
Lain
- Lain,
Thanks for the detailed explanation. I am not an architect who has architected a On-Prem move to Azure Cloud. But, trying to learn more towards that area. Now having read your comments. We already have AD Connector and synching between On-Prem and Azure AD. Do you think that Option 3 would be the best option based on this document. I thought of going with Option 2 and having an Express route should make it work with Cloud PCs accessing On-Prem apps through Express routes.
https://techcommunity.microsoft.com/t5/healthcare-and-life-sciences/deploy-cm-client-to-windows-365-cloud-pc-azure-ad-joined-no-cmg/ba-p/3257126I couldn't see an option 3 in the slide you linked, but I did find an option 3 in the slide below. Is this perhaps the one you meant?
I'll assume it is and make some quick observations.
First, Windows 365 is a very different beast to what organisations have traditionally been used to with domain-joined corporate devices, or even BYOD for that matter.
Second, your on-premise applications will determine whether option 2 or 3 is the best. But if I were in your shoes, I would still be trying to pursue option 2 as it represents the best current starting point and the least amount of change if and when you get the change to move to option 1.
I'm not sure if I've understood the following bullet point from the article correctly (since I've only heard of hybrid devices, not hybrid users), but if I have, then a "problem" with option 3 is that only users synchronised from AD to AAD can log on, which to me doesn't make a lot of sense, and would be a big reason to avoid this option completely.
The sixth bullet point in option 3.
It's very hard to give you authoritative advice given I don't know anything about your applications, but from what you've said so far, my thinking would be:
- Choose option 2 to begin with, as it's likely you'll have things transitioning through an IaaS phase anyway, and using ExpressRoute is significantly better than VPN (almost always, in my experience);
- This is based on the assumption your on-premise applications and services (such as Wi-Fi) do not require device-specific Windows-integrated authentication;
- This has got nothing to do with domain controllers (that's more related to your on-premise applications);
- Your final objective is to be cloud-only with no AD, so I would not recommend co-management between InTune and SCCM unless you expect to be co-managing Windows 365 and traditional Windows together for years to come. You're better off managing Windows 365 purely with InTune as per option 1 and 2 from the outset, as this will save time and money in the short to medium term;
- Focus on understanding the authentication and authorisation requirements of your remaining on-premise applications and services, as they are the key to which device joining method you choose, which endpoint management design you choose and when you can potentially switch off your on-premise environment.
Cheers,
Lain
- If your applications have some kind of direct or indirect dependency on Windows-integrated authentication at the device level, then you cannot do either of the following:
