The following knowledgebase article provides some recommended group policy settings when configuring an Azure VM with a graphics card in it:
https://docs.microsoft.com/en-us/azure/virtual-desktop/configure-vm-gpu
Following the recommended GPO settings on an NVv4 VM yields an incompatible result, whereby accessing the RemoteApps through the standalone installation of the Remote Desktop agent prevents the graphics card from being properly utilised. Resulting in black boxes and lagging cursor.
This has been raised with Microsoft under a ticket and the final resolution of the ticket was to Disable "Use Hardware Graphics Adapters for all Remote Desktop Services Sessions" and Disable "Configure H.264/AVC hardware encoding for Remote Desktop connections".
This is a contradiction of the knowledgebase article recommended configuration.
The support agent associated with this ticket is unable to advise how these settings should be configured going forward for other sizes of Graphics VMs and has advised raising this issue here.

We use AAD token encryption for authenticating to our application, requiring that our application has the private portion of the certificate to decrypt the token and that AAD has the public portion. We are currently using the Keyvault VM extension for Windows to install the private certificate on our VMs.

This works fine until we need to rotate certificates. When we're in the middle of a rotation there's a period of time where the extension only installs the new version of the certificate on new VM instances, since the new version has been generated, but AAD has not yet been updated to encrypt with the new version, since not every VM has the new version of the certificate deployed yet. During this period of time, any new instances of the VM would be unable to decrypt the tokens.

We need this extension to be able to download all non-expired versions of the certificate so that during the certificate roll new VM instances are able to decrypt the tokens using the old certificate.

With the lack of support for Internet Explorer in the majority of web products these days which are commonly hosted on Windows Server it makes sense to Install the Edge browser to allow use of this rather than IE.

There are two options as I see it.

The first being that an option is included during the provisioning of a VM in Azure that is a Yes or No (default) to having Edge install on the server as part of the provisioning.

The other being that Edge is added as part of the base image for all Microsoft owned Windows Server images.

Preference would be for the optional installation to give users the option of automating rather than having to manage it via a custom script extension or post-deployment activity.

Hi,
when I try to get list of supported API according your documentation here:

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service?tabs=linux#versions

then I get following list

[root@azure-machine ~]# curl -H Metadata:true --noproxy "*" http://169.254.169.254/metadata/versions
{"apiVersions":["2017-03-01","2017-04-02","2017-08-01","2017-10-01","2017-12-01","2018-02-01","2018-04-02","2018-10-01","2019-02-01","2019-03-11","2019-04-30","2019-06-01","2019-06-04","2019-08-01","2019-08-15","2019-11-01","2020-06-01"]}

You provide different list in the documentation:

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service?tabs=linux#versioning

The list returned by REST API should be current.

When I try to use unsupported version or I don't use version at all, then every REST API endpoint return different error message. Example:

[root@azure-machine ~]# curl -H Metadata:true --noproxy "*" http://169.254.169.254/metadata/instance?api-version=2011-01-01
{ "error": "Bad request. api-version is invalid or was not specified in the request." }

[root@azure-machine ~]# curl -H Metadata:true --noproxy "*" http://169.254.169.254/metadata/instance
{"error":"Bad request. api-version is invalid or was not specified in the request. For more information refer to aka.ms/azureimds","newest-versions":["2021-01-01","2020-12-01","2020-10-01"]}

[root@azure-machine ~]# curl -H Metadata:true --noproxy "*" http://169.254.169.254/metadata/attested/document?api-version=2011-01-01
{"error":"Bad request. api-version is invalid or was not specified in the request. For more information refer to aka.ms/azureimds","newest-versions":["2021-01-01","2020-12-01","2020-10-01"]}

[root@azure-machine ~]# curl -H Metadata:true --noproxy "*" http://169.254.169.254/metadata/attested/document
{ "error": "Bad request. api-version is invalid or was not specified in the request.
For more information refer to aka.ms/azureimds" }

I believe that error messages should be consistent and returned JSON document should include some unique error_code that could be used in applications for decision what to do next. Imagine that some application is very old and it tries to use obsolete API. Returned JSON document could be useful for debugging, but it could not be used in application to switch to some fallback mode (e.g. try to get list of supported APIs and try to use the newest API version).

Best Regards,

Jiri