deployment location about wvdquickstart HOT 9 CLOSED

from wvdquickstart.

@pazdedav is 100% spot on with his comment. If we want to change the location where the session host are this link (https://www.wvdquickstart.com/customize) explains how to customize the location. In short run the script once the create teh dev ops pipeline, SA, identities. Then go into dev.azure.com and modify variables.yml and appliedparameters.psd1 with new location.

from wvdquickstart.

Hi @gjongeneel - it is expected to fail without an US region as some of the metadata services are only supported in the US at this time. I have been trying to customise a version which separates the two inputs but I have not been able to perfect it. The repo is as follows and any PRs are very welcome if you wanted to take a look. My problem is the deployment with US regions fail in a number of tests. However, I have tried too many times (though I have cleaned up each time) so I might try with a clean slate on another subscription. Once I can successfully deploy with a US region, I will go back to try and modify that repo. It is an impressive piece of automation for sure.

https://github.com/Eighty20Solutions/wvdquickstart

from wvdquickstart.

Hi @Hopminonther

I do not own this repo, but I'd like to provide some clarifying information:

• We need to distinguish the location of WVD Service Metadata (location of all Microsoft.DesktopVirtualization resources like hostpools, applicationGroups, and workspaces) and the location of WVD session hosts (Azure VMs and related VNet).
• WVD is currently limited to store service metadata in the U.S. only, but more geos will come (E.U. being the first on the roadmap). In practice it means you need to pick one of the US regions as location for your hostpool, workspace, and application group (it is important to use the same location for all those three resources)! To emphasize, service metadata do not contain any customer data (user profiles, disks, etc.).
• You can however select any Azure region for your session hosts and underlying storage (images, disks, storage account for FSLogix user profile containers) and networking.

I haven't been able to study in detail, whether the templates and scripts work with a single location parameter or there are two, one for each "category" I described. If there is only one, this solution should be extended to accommodate all non-U.S. customers.

from wvdquickstart.

Hi @stgeorgi - I was trying, to do this, but after changing the AzDevOps files (which fails first time due to the issue above) - I run into a strange problem running the pipeline a second time. It is "An operation is currently performing on this storage account that requires exclusive access." which is basically "StorageAccountOperationInProgress" here https://docs.microsoft.com/en-us/rest/api/storagerp/srp_error_codes_common. I then tried to delete the storage account so the pipeline can deploy afresh but I got "ailed to delete storage account 'profiles......z'. Error: An operation is currently performing on this storage account that requires exclusive access."

Activity logs didn't point to an outstanding issue so I have raised a support case but I will be interested if this could be related to how the pipeline is set up? Curious to know if you have seen this before.

from wvdquickstart.

@sayanghosh123 I haven't see you particular error as noted in the thread the original error is due to whomever was running the pipeline trying to put the meta data outside of US which is not supported.

from wvdquickstart.

Hi @stgeorgi - appreciate that. It was a similar deployment attempt with "australiaeast" which failed at DevOps level (expected as the "microsoft.desktopvirtualization/applicationgroups" and "microsoft.desktopvirtualization/hostpools" type of resources wouldn't support "australiaeast"). After modifying the source files in DevOps (specifically setting the location for these as "eastus"), it failed at the storage account stage, so I was thinking it might be an issue with the operation not being idempotent? But if you've not seen this before it might be some specific to my subscription (I have got a support ticket open now). Thanks!

from wvdquickstart.

Same issue here. The location for the metadata seems to be taken from the same parameter as the session host location so this fails for deployments outside of US regions. We need a new parameter for this or a way to hardcode this properly for the metadata location.

from wvdquickstart.

During my tests, I encounter the exact same problem. We try to deploy to West Europe, but during the 'Deploy_WVDHostPool' job it fails:

Error: Code=LocationNotAvailableForResourceType;
| Message=The provided location 'westeurope' is not available
| for resource type 'Microsoft.DesktopVirtualization/hostpools'.
| List of available regions for the resource type is
| 'eastus,eastus2,westus,westus2,northcentralus,southcentralus,westcentralus,centralus'.

The Custom deployment only allows us to choose one location:

The only way this will succeed without modification, is choosing a US location during template deployment. But than all other components (Session Hosts etc.) will also land there. Besides this lack of testing outside the scope of the US, I really like this concept of the WVDQuickStart!!

from wvdquickstart.