I would like to inquire about an issue in the CSP portal.
For an end customer with the Self Service and Password Write Back feature enabled in Azure AD, the correct helathy status is being showed up as working,, this is only being displayed when the tenant is accessed directly through the Azure Portal (portal.azure.com), form the end user perspective.
If the customer environment is accessed from the partner portal, the same features are being showed as "not working".

This will undoubtedly cause issues for engineers that are trying to essentially fix an issue that is not really broken.
And the CSP are going to notice their customers on a false alarm.

Is there any feature for the CSP portal that can be created in order to track the healthy of these products? Or can this be fixed?

Thanks.

Our position is that having MFA satisfied by claim via PRT and TPM creates CA Policy loophole.
When a device is hybrid joined to Azure AD and the TPM sensor has been enabled, the PRT is able to satisfy the MFA request from a Conditional Access rule. This creates a vulnerability as it bypasses the CA rules that are configured to intentionally and explicitly require MFA. An example of this is where a user has a laptop and has previously signed in successfully. If the valid user’s session were to become compromised, an attacker could operate within the trusted profile session. An approach we would like to take to thwart this scenario is to choose explicitly require an active MFA prompt that involves a human action (like approving via the Authenticator application) as an access condition when employees access a particularly sensitive application. When a Conditional Access policy is set to require MFA, we would like the option to require MFA regardless of the TPM/PRT token status for satisfying the MFA claim.

I tried the new Azure Static Web Apps preview for a Gatsby project of mine. I was really amazed by the simplicity of the deployment process and the speed of the web site. There was a deal breaker, though.

What really kept us from switching from Netlify to Azure Static Web Apps was the lack of control over HTTP headers. I need to be able to for example set the cache-control header on a per-file as well as per-directory basis. The same thing goes for the link header, although that would not break the website. There also needs to be an option to set other headers arbitrarily, for example security headers.

I do know, that most of those things could be done with a CDN and we have tried that. The problem with that option is, the limitation of the maximum number of rules and the number of actions per rule. It is impossible to set all appropriate security headers, while still keeping the fine grained control of caching that we need.

If or when Azure Static Web Apps gains the ability to set headers on the same level of detail as Netlify does, it will become a serious competitor to the market leader on the JAM-stack.

Here is a reference to the Netlify way of doing things. I think it is excellent in it's simplicity and could be used as an inspiration for Azure Static Web Apps.
https://docs.netlify.com/routing/headers/

The new Rules Engine for Azure CDN Standard is definitely a long awaited improvement to Azure's offering for hosting single page applications / static websites.

After trying it out in a real project though it has currently one limitation which is a showstopper at the moment:

https://docs.microsoft.com/en-us/azure/cdn/cdn-standard-rules-engine-reference#terminology

"Each Azure CDN endpoint can have up to five rules."

Let's say you have a multilangual front end app (SPA) which serves the different language versions as relative paths from under the same subdomain (CDN endpoint). And you naturally want to enforce all those lang specific sites to rewrite to their corresponding index.html files. This requires lang specific rules for each language version and you end up with quite a lot of them (1 per language).

Please remove this limit for 5 rules per CDN endpoint, or raise it up to 50 or 100. It makes absolutely no sense to restrict the number of rules down to 5, making the feature useless for many real life scenarios.

Administrative Units allow for users and groups to be added to the AU, and then RBAC roles to be assigned to users for that AU specifically. We tested this recently only to learn that in order for a Helpdesk Admin to reset a user's password, that user has to be added independently of the groups. For example, if John Doe is a member of group Sales, and the Sales group is added to the AU, a Helpdesk Admin for that group would not be able to reset John Doe's password. Only if John Doe is also added as a user would this work. In environments where groups are often updated automatically and outside of the AU, the AU would quickly fall out of sync with the group membership and have gaps of users for whom the Helpdesk Admin could assist. It is also redundant to have to add a user to the AU when their group is already a member. My understanding from Support is that the group aspect is to allow RBAC roles to manage the group, which is great, but it is not clear during setup that group members cannot be managed, and does not make much sense given the strides to automate more processes in IT.