Recently I was involved in doing a Proof of Concept (PoC) for Windows Virtual Desktop (WVD) for one of my customers. My goal was to use as many Azure Platform as a Service (PaaS) components as possible resulting in a simple environment using the following services:
- Azure AD Domain Services (AAD DS)
- Azure Files
- Bastion to access a Jumpbox
- WVD Host Pools
I used a simple Azure Reference Architecture to deploy the Virtual Network infrastructure, which is available at https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/shared-services but without the ‘hybrid’ components like VPN/ExpressRoute and replaced the AD DS VMs with AAD DS. This is a requirement to use Azure Files to store the FSLogix profile containers. See https://docs.microsoft.com/en-us/azure/virtual-desktop/create-profile-container-adds for more information. Based on the PoC I must admit it works remarkably well.
This has become possible since Azure Files supports identity-based authentication over Server Message Block (SMB) through Azure Active Directory Domain Services (Azure AD DS). See https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-domain-service-enable for more information.
I am talking about this setting:
To me, this may become a huge game changer regarding File services, especially when authentication through AD DS becomes generally available. This makes a lot of File Servers become replaced by Azure Files. But it also caught my attention to use it for a different scenario.
A while ago I wrote this post to install Windows 10 over the Internet. I still believe that installing Windows over the Internet should be possible, especially when having a lot of bandwidth. My thoughts were to determine if it’s possible to use Microsoft Deployment Toolkit (MDT) to deploy an Operating System over the Internet with Azure Files.
NOTE: This scenario works only when your ISP allows SMB traffic (TCP port 445). Some ISP’s don’t.
To prepare the environment I did the following:
- Setup Azure AD DS in a small vNET
- Install Azure Files
- Deploy a small VM to install MDT and manage the Deployment Share
The first thing that needed to be done was to create a share, I use a quota 1TB which is more than enough. I didn’t use a Premium share
I created two identities in Azure AD I used for not only for joining the domain but who need access to the Azure File Share and provided the required permission. The accounts used are also part of the AAD DS Administrators Group to keep the scenario simple.
I use one of these accounts to log on to the VM used to create and manage the Deployment Share. The VM is joined to the AAD DS domain and has MDT installed.
Eventually you can create your deployment share using the UNC path of the Azure Files Share and do your typical MDT stuff like adding apps or your Windows 10 installation media. It may look like this:
In the Azure Portal, you see the same directory structure as well:
The trick is to provide access from any location outside AAD DS so we can access the Deployment Share from anywhere. We need to specify the user name and password in the Bootstrap.ini file. The credentials are the same as the one script available by the Azure Portal (the same thing when doing a typical use command MDT uses as well):
Once everything is created, you can extract the bootable .iso from the share itself, you can even download it directly from the Azure Portal:
Eventually, all you need to do is boot from the .iso and you can start your deployment.
Here’s a screenshot of a machine running Hyper-V from a different location, choosing a normal deployment:
NOTE: You can choose to capture an image if you want to…
For the rest I didn’t bother to do anything specific from an MDT perspective, just a simple Windows 10 deployment with Office365. What you’d like to put into MDT is up to you. The end result is you can deploy a machine from any location over the Internet.
Happy deployments and hope this helps!