Please add Secure http for application gateway cookie based session affinity in azure. The websites are showing not secure for "ApplicationGatewayAffinity".

We use okta for synchronizing accounts to Azure AD.

We plan to use AAD Join for our windows10 devices, it works well with AAD Connect(As AAD Connect synchronizes attributes DomainDNSName, NetBIOS name & Onpremisesamaccoutnanme)

Okta could not update these attributes, I want to find a way to update the attributes(by using PowerShell or GraphAPI?).

And also would like to know if there is any possibility to sync MSDS-Keycredentiallink attribute to on-premise without using AAD Connect so that I can use windows hello.

we need an easy way to lift and Mainframes/ AS400 to lift and to Azure. instead of replatforming if Microsoft can build a layer which AS 400 or Mainframe apps can run on, can help drive consumption of Azure. Hopefully Microsoft can do it before AWS

Allow Password Policies to be set at the Group Level instead of only at the domain level.

Example: Our default password expiration is 90 days, but we have a group that requires their passwords to be reset every 60 days.

This is not currently possible.

Create another Admin Role that allows the view of MFA users that are blocked/unblocked so in the case of the issue users getting themselves blocked for various issues, and only Global Admins can unblock (or wait out the 90 day period), other Admins (aside from Global Admins) can do so.

From: https://docs.microsoft.com/en-us/azure/application-gateway/migrate-v1-v2

" v2 gateways currently don't support only private IP addresses."

We need to be able to create fully private App Gateway V2, without public IP.

At the moment V2 Gateways will be public facing so we need to stick with V1. We cannot rely on NSG/Firewall to restrict traffic: we need to be able to provision a private load balancer.

Currently AzureRM tagging only supports one value for one key. This means if i want to tag multiple departments to one resource it is incapable of handling it.

Currently the "Premium" tier on App Service offers this three options:

P1: 1VCore DSV2
P2: 2VCores DSv2
P3: 4VCores DSv2

I wouldn't call this a premium tier now that we are getting into 2020...

App service is one of the most useful services offered in Azure and it really needs an upgrade.

Amazon's Beanstalk does not have such limitations.

I would suggest that to upgrade the hardware/resources of the Premium tier to at least:

P1: 2 VCores
P2: 4 VCores
P3: 8 VCores

The processors model should be upgraded as well to use DSv3 or even better the F series.

There needs to be a way to apply service tags to Azure CDN. When applying NSGs or firewall rules it would be beneficial to be able to use Service Tags to target the CDNs.

Marc

In application gateway HTTP settings when we use "override back-end path" option, it is stripping out the query parameter and retains only the resource path.

Eg: https://<<HostName>>:443/resurcepath/invoke?api-version=2016-10-01&number=5

It retains only "https://<<HostName>>:443/resurcepath/invoke" and ignoring "?api-version=2016-10-01&number=5"

It will be good to retain the query parameters without doing any URL redirection etc

For example, I created a custom policy definition that audits if a tag exists. It is set mode=indexed, so only taggable and location based resources should be evaluated.

Here are some things that are coming back as non-compliant:
/microsoft.insights/alertrules
/microsoft.insights/actiongroups
/Microsoft.Compute/virtualMachines/extensions
/microsoft.insights/activitylogalerts
/microsoft.operationsmanagement/solutions
/microsoft.portal/dashboards

The EA portal needs auditing capabilities.

Hi Team,

Currently Azure is not supporting AAS as a datasource. Suppose i created the Datamodel in AAS and i want to use same in another AAS model, it is not working. Can we have any idea when it will support AAS as a datasource

Provisioning a QnA Maker Service provisions a Public App Service App <yourAppsName>.azurewebsites.net, but you are not given any control over the App Service Plan for which the App Service resides. My first choice would actually be an App Service Plan in our ASE environment, but if that isn’t doable at least let us select one of our existing public App Service plans to host this in.

A 1-1 ratio of App Service Plan to App Service is extremely inefficient.

When creating a 'secret' in Azure Key Vault you mainly got Name, Value and Content type fields to populate. It would be great to have a Description field as well to provide some verbose description/notes about the particular secret.