Define AVD accelerator deployment scenarios

[danycontre]

Creating this discussion to consolidate feedback, comments, ideas on the scenarios for the AVD accelerator:

Based on experiences from the field and AVD deployment options, articulate the possible customer scenarios the construction set will be addressing with architectural guidelines and reference implementation (Code).

Some early examples:

• IAM combinations: ADDS, AADDS, AAD
• Connectivity: cloud only, hybrid, customer's forced tunneling, default connection model, RDP shortpath, private endpoint
• Of users: distribution per host pool, fslogix storage recommendations
• etc

Initial diagram and scenario specs list (uploaded to enterprise architecture AVD sharepoint):
https://microsoft.sharepoint.com/:u:/t/NorthStarPlaybookWorkshop/EfqF9SxyIp5BuIscdQ-TroMBWBuVzoSbafWt3qdaYU3-0g?e=cOXu2O&isSPOFile=1

[danycontre]

MVP aka scenario A thoughts on specs list:

• AVD single region deployment.
• Platform services contained on same region hub (identity, connectivity, management and monitoring).
• Hybrid identity with connection to ADDS servers or AADDS service (no AAD joined).
• Custom DNS and AD DS servers running in Azure.
• Connectivity to on-prem (Express route and/or S2S VPN).
• Client connections from corporate and non corporate networks to AVD’s public endpoint (no AVD private endpoint).
• Client connection to AVD session hosts only through AVD gateway (no RDP short path).
• Azure Image Builder for image build.
• Azure Compute Gallery for image distribution.
• FSLogix for user profile management
• MASIX AppAttach for application delivery.
• File shares (SMB) served from storage accounts connected to vNets through private endpoints.
• Storage accounts redundancy set to ZRS.
• Storage accounts joined to the domain.
• Centralized log analytics workspace for AVD logs and metrics.
• AVD workbook and insights configured.
• AVD session hosts distributed across availability zones (AZ) 
(availability sets used if AZs are not available).
• Automation account for updates, inventory and change tracking management.
• Start VM on connect or scaling plans for AVD scaling automation.
• Azure firewall or third party NVA in the hub (lots of users enforcing all traffic to go through NVA but not sure if want to include in the first iteration)

[edm-ms]

This is a lot to take on in a single shot, and I don't know that all of it is feasible. I have marked the items we can do or currently have in the UI.

MVP aka scenario A thoughts on specs list:

• AVD single region deployment.

I don't understand this part.

• Platform services contained on same region hub (identity, connectivity, management and monitoring).

• Hybrid identity with connection to ADDS servers or AADDS service (no AAD joined).
• Custom DNS and AD DS servers running in Azure.

This is always going to be out of scope. We can't build cross-site connectivity.

• Connectivity to on-prem (Express route and/or S2S VPN).

This is the only option for AVD. You always have to connect to the public RD gateway to initiate access.

• Client connections from corporate and non corporate networks to AVD’s public endpoint (no AVD private endpoint).

We are going to provide the option to enable RDP short path in the image build.

• Client connection to AVD session hosts only through AVD gateway (no RDP short path).
• Azure Image Builder for image build.
• Azure Compute Gallery for image distribution.
• FSLogix for user profile management

This should be a follow-up module for deployment.

• MSIX AppAttach for application delivery.

• File shares (SMB) served from storage accounts connected to vNets through private endpoints.

We could add this as an option, but due to increased cost should not default. Any zone redundant options will be tricky in the deployment since not every region supports AZ's.

• Storage accounts redundancy set to ZRS.

We think we can accomplish this. We can for sure with AADDS, but are looking into AD DS.

• Storage accounts joined to the domain.

We are giving the option to create new or select existing. All diagnostic settings will be setByPolicy to match ESLZ and to not alert on policy violation.

• Centralized log analytics workspace for AVD logs and metrics.
• AVD workbook and insights configured.

Same issue with storage. We can do it, but will need to hard code regions that have support for AZ's.

• AVD session hosts distributed across availability zones (AZ) 
 (availability sets used if AZs are not available).

Probably should move this to backlog instead of MVP. There are complexities here with linking automation accounts to workspaces, and Azure Update Managed support for multi-session VM's. Beyond that if someone has deployed ESLZ monitoring is going to be centralized so the AVD VM's will automatically report to that workspace. This needs more planning.

• Automation account for updates, inventory and change tracking management.
• Start VM on connect or scaling plans for AVD scaling automation.

This will be in the self-contained POC scenario. We will need to figure out how best to add this as an option in one of the follow up scenarios.

• Azure firewall or third party NVA in the hub (lots of users enforcing all traffic to go through NVA but not sure if want to include in the first iteration)

[danycontre]

Hey Erick, thanks for the feedback, some comments:

• Automation and portal deployment are not meant to deliver all you see in the diagram and scenario specs. Diagram is just representing the common scenario that customer's deal with but there pre-existing setups required on their Azure footprint.
• What the portal UI and automation should deliver is what is contained in the AVD LZ subscription (aka AVD scale unit module) and in the AVD shared services subscription.

MVP aka scenario A thoughts on specs list:

• AVD single region deployment. : Single region deployment refers to limiting the scope to AVD resources deployed to a single region (no cross-region setup for the MVP).

I don't understand this part.

• Platform services contained on same region hub (identity, connectivity, management and monitoring). : agree with removing this one wording is odd and a long as the session hosts have line of sight to identity sources and DNS we are good to go.

• Hybrid identity with connection to ADDS servers or AADDS service (no AAD joined). : reference to pre-existing customer setup (not deployed by MVP).
• Custom DNS and AD DS servers running in Azure. : reference to pre-existing customer setup (not deployed by MVP).

This is always going to be out of scope. We can't build cross-site connectivity.

• Connectivity to on-prem (Express route and/or S2S VPN). : reference to pre-existing customer setup (not deployed by MVP).

This is the only option for AVD. You always have to connect to the public RD gateway to initiate access.

• Client connections from corporate and non corporate networks to AVD’s public endpoint (no AVD private endpoint). : agree, this one is a place holder for upcoming private endpoint feature.

We are going to provide the option to enable RDP short path in the image build.

• Client connection to AVD session hosts only through AVD gateway (no RDP short path).
• Azure Image Builder for image build.
• Azure Compute Gallery for image distribution.
• FSLogix for user profile management

This should be a follow-up module for deployment.

• MSIX AppAttach for application delivery. : agree with this one been a follow up module since it adds complexity and not all customers will use it.

• File shares (SMB) served from storage accounts connected to vNets through private endpoints.

We could add this as an option, but due to increased cost should not default. Any zone redundant options will be tricky in the deployment since not every region supports AZ's.

• Storage accounts redundancy set to ZRS. : agree with availability settings for session hosts and storage been an additional option not the default.

We think we can accomplish this. We can for sure with AADDS, but are looking into AD DS.

• Storage accounts joined to the domain.

We are giving the option to create new or select existing. All diagnostic settings will be setByPolicy to match ESLZ and to not alert on policy violation.

• Centralized log analytics workspace for AVD logs and metrics.
• AVD workbook and insights configured. : not sure if we can deliver this via policy, will need to double check, if we can't this could be an additional module to apply AVD insights/workbook.

Same issue with storage. We can do it, but will need to hard code regions that have support for AZ's.

• AVD session hosts distributed across availability zones (AZ) 
> (availability sets used if AZs are not available). : agree with availability settings for session hosts and storage been an additional option not the default.

Probably should move this to backlog instead of MVP. There are complexities here with linking automation accounts to workspaces, and Azure Update Managed support for multi-session VM's. Beyond that if someone has deployed ESLZ monitoring is going to be centralized so the AVD VM's will automatically report to that workspace. This needs more planning. : Agree with keeping this out of the MVP and maybe deliver as an addon module.

• Automation account for updates, inventory and change tracking management.
• Start VM on connect or scaling plans for AVD scaling automation.

This will be in the self-contained POC scenario. We will need to figure out how best to add this as an option in one of the follow up scenarios.

• Azure firewall or third party NVA in the hub (lots of users enforcing all traffic to go through NVA but not sure if want to include in the first iteration) : This one could be a pretty good addon module.

[xelizondo]

My feedback:

1. Should we also prompt whether customer provides DNS hence no need of Private DNS zone for user profile storage? Currently assumed it is new or existing Private DNS zone. If customer provided, link to reference of what they should be prepping/doing (creating A record, forwarder(s) etc.)?
2. Assuming there will be 2 step process, building AVD logical components then compute components, should we prompt option to store AVD Logical components (Host pools, AppGroups, Workspaces etc.) on separate RG than the AVD compute (disk, vm, NIC, etc)?
3. For the image customization, instead of having the menu of all options should be valuable to have a basic option of pre-canned scenarios (like in AVD calculator: light, medium, heavy) that has suggested preset of configurations or an advanced where they can build and choose from the a la-carte options?

[edm-ms]

The private DNS, yeah, I see what you are saying, perhaps they just manually enter the FQDN as an A record in their DNS systems, but we have no way to address that. If they want to do that and not use private DNS zones they can simply remove the DNS zone after deployment. The best practice will be to use private endpoints with private DNS zones so I think we should just stick to this.

To option 2 this is how the deployment was intended to work. We create a resource group for all AVD components, and then the session hosts are deployed (or should be) into a different resource group containing only the VM constructs.

I'm not sure what the custom image build would look like here. The OS level tuning that is in there currently would apply to any system (small/medium/large). So turning off storage sense, time zone redirection, etc. That doesn't really matter what the workload is it's just a general best practice. On the FSLogix side maybe we just prompt for usage (Y/N) and just set the more common options:

Enable FSLogix Profile Containers Y/N
Enable FSLogix Office Containers Y/N

I think we likely should just set the options in the build, and the Y/N will only determine if we pass the URL to the storage account we build and if FSLogix is enabled or not. Thoughts?

[danycontre]

The private DNS, yeah, I see what you are saying, perhaps they just manually enter the FQDN as an A record in their DNS systems, but we have no way to address that. If they want to do that and not use private DNS zones they can simply remove the DNS zone after deployment. The best practice will be to use private endpoints with private DNS zones so I think we should just stick to this.

• Agree with deploying the private DNS zone for the file share name space, it doesn't hurt if customer also adds the records on their custom DNS and remove the private DNS zone after.

To option 2 this is how the deployment was intended to work. We create a resource group for all AVD components, and then the session hosts are deployed (or should be) into a different resource group containing only the VM constructs.

• Agree, separating management plane from compute is our guidelines in the accelerator governance section.

I'm not sure what the custom image build would look like here. The OS level tuning that is in there currently would apply to any system (small/medium/large). So turning off storage sense, time zone redirection, etc. That doesn't really matter what the workload is it's just a general best practice. On the FSLogix side maybe we just prompt for usage (Y/N) and just set the more common options:

• I think we can deliver the MVP without sizing recommendations and deliver later the sizing options Xavier references to make changes on which storage to use for profiles or session host size to create depending on the expected load.