Windows 365 deployment from the trenches



We’re super excited to present a live webinar on August 26 covering the basics of Windows 365, and even more excited that none of it will be a PowerPoint presentation. That’s right: we’re gonna live and die by the live demo! So that means we have it up and running, and I have some initial impressions.

First of all, you likely don’t need a massively powerful machine for day-to-day work. You probably won’t want to go with the absolute lowest SKU out there if you’re doing anything more than web browsing, but that’s no different from buying real PC’s: there are real differences at every cost level. Don’t set your expectations by what you see in the entry-level or top-tier models.

Second, deployment wasn’t as complicated as I’d expected. Having a background in on-prem AD made it a lot easier, especially since my environment didn’t actually have an Active Directory before this deployment. There were a few gaps in the documentation, particularly around some of the automated checks in the OPSC, but the biggest error I encountered was completely self-inflicted: I tried for hours and hours to deploy a Hybrid AADJ machine to a cloud-only user.


Don’t do that: you’ll get an undocumented “orchestration error.” If you need a cloud-only user to have a Windows 365 Enterprise machine, you’re gonna need to add that user to AD. Not complicated, not unreasonable, but maybe not 100% obvious when you’re administering at 100 mph.

Your checklist for getting up and running isn’t particularly long, either, but it isn’t as easy as “just add licensing.” First you’ll need the proper qualifying licensing for Windows. That’s a loaded statement, so check with your licensing specialist. Then you’ll need licensing for every VM SKU you intend to deploy. I’m a big fan of applying licensing to groups, and that will save you time later on when defining provisioning policies. In my instance, I created an overall Windows 365 dynamic device group, and user groups with assigned licensing for each SKU that I own. I have 2 SKU’s, so I have 2 groups. I assign those same groups to my provisioning policies. Easy peasy, but that’s for later.

Now you’re gonna need an Active Directory. If you have one, that’s great! If you have one that’s already joined to Azure AD with AAD Connect, that’s even better! If you’ve gone so far as to enable device write-back AND configure Hybrid AADJ machines for Intune management, well then you’re pretty much ahead of the game and ready to start provisioning.

If you don’t have one, you can go my route and build it all in Azure. I mean, why not? It’s there, and I love a self-solving problem. In fact, all the early demos of Windows 365 are shown from AD’s hosted in Azure IaaS. I wanted to be like the cool kids and went that route. Just don’t forget to make sure your vNet resolves DNS to your IaaS DC. Don’t forget that. Double-check it. Measure twice: cut once.

Once that’s ready you just build the on-prem service connector and create provisioning policies, and the rest handles itself.

And I mean that very truly. My demo users picked up their relevant configuration profiles, security baselines, application assignments, universal printers, compliance policies, everything!


Want to learn more, contact us today for a Windows 365 Quickstart Engagement.



By: Adrian Amos

Comments