hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.61k stars 4.65k forks source link

Virtual Desktop Applications - RemoteApps icons not showing properly #23910

Open majorku5anagi opened 1 year ago

majorku5anagi commented 1 year ago

Is there an existing issue for this?

Community Note

Terraform Version

1.6.3

AzureRM Provider Version

3.79.0

Affected Resource(s)/Data Source(s)

azurerm_virtual_desktop_application

Terraform Configuration Files

resource "azurerm_virtual_desktop_application" "chrome" {
  name                         = "googlechrome"
  application_group_id         = azurerm_virtual_desktop_application_group.remoteapp.id
  friendly_name                = "Google Chrome"
  description                  = "Chromium based web browser"
  path                         = "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"
  command_line_argument_policy = "DoNotAllow"
  command_line_arguments       = "--incognito"
  show_in_portal               = false
  icon_path                    = "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"
  icon_index                   = 0
}

Debug Output/Panic Output

-

Expected Behaviour

Appropriately assigned icon of the application should appear in the Remote Application panel

Actual Behaviour

Given the fact that I have ~30 apps allocated in several application groups, I've correctly defined the each one of them with path and icon path. After successful deployment of the Azure Virtual Desktop, apps appear and they work great but they don't have appropriate icons. I've tried to move the deployment of the application groups and apps on the beginning, right after host pool creation and at the very end of the deployment but it remained the same. What is weird about it is that if I go and change something like description of the application and confirm the update, icon will appear.

The example below is right after the deployment when I took Word application and just performed the update of description field. It seems that just to performing some kind of refresh/update of the app, the icon will propagate correctly. Other apps are untouched just to show how it looks but if I'll do the same with them with some kind of update, icon will appear. This actually shows that the resource block is being defined correctly per documentation.

image

Steps to Reproduce

No response

Important Factoids

No response

References

No response

majorku5anagi commented 1 year ago

Update: My current workaround for this issue is to introduce timeand azapiproviders. Time provider with time_sleepresource would make a pause ~3min and then use azapiprovider with azapi_update_resource to update the description field of all applications and cause the icon to appear correctly.

jdraion commented 10 months ago

I am running into the same issue, can you post your code to see how you did the workaround?

acch commented 6 months ago

I am hitting the very same issue here with azurerm 3.90.0.

@majorku5anagi would you be willing to share your workaround code? I'm unable to get my head aroung using azapi_update_resource to update the description field of all applications... thanks much!

acch commented 6 months ago

OK, I think I figured it out. For anyone else who runs into this (including my future self):

terraform {
  required_providers {
    azapi = {
      source  = "Azure/azapi"
      version = "1.13.1"
    }
  }
}

provider "azapi" {
}

resource "azapi_update_resource" "update_app_description" {
  for_each = { ... you'll want to iterate over all your apps ... }

  type        = "Microsoft.DesktopVirtualization/applicationGroups/applications@2023-09-05"
  resource_id = ... provide the resource ID of the current app ...

  body = {
    properties = {
      description = "Some description"
    }
  }
}

Here's the relevant documentation:

Last but not least, you'll want to ensure that the azapi_update_resource is provisioned after your session hosts. I've solved this by adding a custom depends_on argument.