virtual_desktop_application_group - optional argument `default_desktop_display_name` can be required

[patters-match]

Community Note

• Please vote on this PR by adding a :thumbsup: reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

This is a small tweak to the documentation to mention that, although described as an optional parameter (presumably by the azurerm API) default_desktop_display_name is in fact required when connecting to a virtual desktop via the Windows App / Windows 365 portal, even though a connection using the older Windows Virtual Desktop portal works just fine without it.

Failure to specify a value for default_desktop_display_name results in the Windows 365 connection stalling at Loading Client with no indication of the cause. If you create a Desktop Application Group via the Azure Portal you will notice that default_desktop_display_name has the value "SessionDesktop" which is the same default name you would see advertised without setting default_desktop_display_name at all.

There are three potential ways forward:

1. The note in this PR is merged into the documentation, or...
2. Microsoft fixes this apparent inconsistency with the Windows 365 portal, or...
3. terraform-provider-azurerm aligns with the Azure Portal behaviour and defaults the value of default_desktop_display_name to "SessionDesktop" if not specified - ensuring the Windows App / Windows 365 portal will always work.

Since the older portal has a banner advert describing the Windows App / Windows 365 portal as the "the new way to connect all of your cloud and remote resources", it will become the most popular front end. Consequently I think option 3 above may be best - but it's outside my programming experience. Could convert this to an Issue ticket if preferred.

PR Checklist

• [x] I have followed the guidelines in our Contributing Documentation.
• [x] I have checked to ensure there aren't other open Pull Requests for the same update/change.
• [x] I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• [x] I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• [x] I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work. For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

This is a (please select all that apply):

• [x] Bug Fix
• [ ] New Feature (ie adding a service, resource, or data source)
• [ ] Enhancement
• [ ] Breaking Change

[!NOTE] If this PR changes meaningfully during the course of review please update the title and description as required.