Large-scale VDI deployment management with Active Directory and domains

Copper Contributor



I am working for a start up and deployed RDS persitent VDI for just one enterprise which works perfectly.


Now office wants to offer Persitent VDI to multiple company. I don't have much experience and would appreciate a guidance and solution for large-scale deployment.


Do i have to create one Forest or multiple Forest?
Do i have to create a Parent Domain then multiple child domain?
Do i have to create multiple Domains?


I don't want the Enterprise to be able to see each other or access other Enterprise files or software. like Teams and others.

I intend to create multiple vlans per enteprise, my concern is Active Directory, RD broker, RD gateway and RD web.


I will appreciate feedback, insight on how to create the domains and trust relationship.


Best regards

11 Replies
So you want to be a provider for internal or external companies? If external, if you want to be a hosting provider, then separate everything network and Active Directory wise... If internal, then one Forest and preferably one domain with separated computers/groups/users in OU's. Multiple domains are old-fashioned with having the ability to delegate control and have different password policies if needed.

And you're also talking about Teams, are you providing Teams in one 365 tenant or multiple?

You mention a few things and without knowing the bigger picture, it's hard to give an answer...
Thank you so much for your response. I really appreciate your feedback.

We are a Startup data center targeting Mid-size organization from 5-50 users to mostly external companies.

1. We want to provide VDI, M365, Mail, Onedrive, Azure backup, Azure Storage, Lighthouse and all Microsoft services through our Account.

2. VDI's will be hosted at our data center as each organization have different requirement viz, accounting, designing, drafting, documenting, high graphics, etc

3. We want each organization to be separate, but controlled by our domain.

4. There can be more than 300 organization with 5-50 users under each organization.

5. Customer Billing will be done, under our company, as we are providing different services to different organizations.

6. We will have our own AD, DNS, DCHP for on premises IT infrastructure.

7. We plan to sync AD to Azure AD via AD Connect.

8. Important concern is, 'AAA' organization shouldn't be able to communicate with 'BBB' organization.
Neither, organization should be able to see / view organization under our domain. e.g shouldn't be able to communicate / view or can this be done by GPO or ?

9. Should we consider sub-domain topology or any other is suggested ?

I look forward to your feedback

Best Regards
Hi... Let me join this wonderful conversation... as I am/was responsible for the multi tenant active directory my company has.

Setting this all up is 1 thing.... but hardening it is 2, automating it is 3, and having it properly licenced is 4 and 5 (you need SPLA... SPLA --> no azure ad connect for you :) or you need to become a csp partner.... ) and having it tested for security issues is 6 :) , keeping it all backuped up (offline,online,replication) is 7...

My advice when looking back.. :p hire someone that could tell you where to begin...

If you want to be an MSP for external companies, then I would suggest putting more effort into automation so that you can:
- Deploy/configure a standard Active Directory structure for each customer with its own DNS/DHCP and Azure AD Connect for that customer with only access to the internet and their own environment (isolation)
- Automate the creation of networks
- Automate provisioning of accounts
- Automate the creation of the VDI environment (Deployment, configuration, and scaling)
- Have a good ticket system and self-service portal

The main goal should be, in my opinion, that you can service customers with standardization and automation but that they can leave you at any point keeping their own users and 365/Azure environment. Customers want an exit strategy too :) Don't try to host multiple customers in one 365/Azure environment, too complex for external customers. Sharepoint, Exchange Online, and Teams are difficult to separate, and what if they want to use Endpoint Manager for example? A lot of deployment profiles, settings, and risks of changing the wrong things for the wrong customer.
The Company intend to provision all these services on-premises and not Azure.. We are considering Azure perhaps next year but currently all deployment and configuration will be on-premises.

Currently I have deployed a persistent VDI for 10 users with a single domain.
Now we intend to offer services in large scale thereby all login for each companies will be via main domain, security still seems to be my major concern as i will like to isolate each company from one another.

The thought of using multiple OU doesn't seems feasible to me, why i want to know how should the deployment be for On-premises.

Parent Domain with Child Domain or Multiple domain. ?

Thank you
Multiple ou's can be done... :) ... but hardening them, to make sure users,groups arent visible when using ldap :p that's another piece of the pie :) ..
Yes we have it all secured but it took about 10 years to be an expert in it
This what i am currently trying to fix. Will you recommend i go with multiple OU per enterprise rather than Multiple domains?

Then will have to secure an expert for Hardening so they aren't visible.
The best thing would be to create a network separated Active Directory Forest per customer, you're making things very complex by trying to manage it in one Forest. And like I said, what if a customer wants to leave? It's a better exit strategy for your customers to have things separated IMHO

We decided to use seperate ou's.. for each customer a dedicated locked down gpo with their users/computers and groups in it.... of course the best way and most secure way is what harm proposed earlier...

Also please be careful... as listing sessions remotely from a storage server can also easily be done :)

Thank you so much. I appreciate your support and feedback.
Thank you so much. I appreciate your support and feedback