Right now it is possible to monitor an Event Hub Namespace's incoming and outgoing messages. An Event Hub shared between project's will have a different consumer group for each project. Right now there's no way for the projects to monitor if they're keeping up with the message production rate, because Event Hub doesn't offer a metric of outgoing messages per consumer group.

What I need is a metric that tells me "There's this much messages coming into this Event Hub, and this many is how much my Consumer Group is consuming."

PS. There's also a related suggestion regarding monitoring on a Event Hub level, not Event Hub Namespace level. https://feedback.azure.com/forums/34192--general-feedback/suggestions/33834316-need-to-monitor-throughput-incoming-outcoming-mes

As a nonprofit approaches the end of a year's sponsorship we receive an email warning that the sponsorship will end and be converted to pay as you go. This is alarming for small charities as we do not have the funds to continue operating on this basis and sponsorship is an essential (and very welcome) offering by Microsoft.

However, the route to renewing sponsorship each year is tortuous, poorly documented, and left to the last minute. It would be preferable if there was a seamless path from within the Azure Billing and Subscriptions->Sponsorship page in the portal to be alerted each year that the sponsorship period is ending with an immediate button to 'renew sponsorship'.

Scenario:
We have a VMSS running our frond-end servers. The instances have custom software installed on a CIS base image. We would like to to change the base image so that new instances automatically have the software installed and when we upgrade the software we can use 1 instance to create an image and reimage all other instances.
Original plan information:
Publisher : center-for-internet-security-inc
Offer : cis-windows-server-2019-v1-0-0-l1
Sku : cis-ws2019-l1
Id :

Update process:
1.0 Create new managed disks (os and data) from VMSS instance disk snapshots
1.1 Snapshot VMSS instance disks
1.2 Create managed disk from OS disk snapshot
1.3 Create managed disk from data disk snapshot
2.0 Create a temporary VM to image
2.1 Create a VNet
2.2 Create a NSG
2.3 Create a Nic
2.4 Create a VM
2.4.1 Add CIS azVMPlan to VM
3.0 Prep VM for imaging
3.1 Sysprep vm
3.2 Generalize VM
4.0 Create Image
5.0 Delete everything but the images
De steps above all work great, I tested the temporary VM and all software and configuration where as expected.
6.0 Update base image of VMSS
Error:
But when we run step 6 to update the base image of the VMSS
($VMSS.virtualmachineprofile.storageprofile.imagereference.id).

We get the following error: The image type for a virtual machine scale set may not be changed. statusCode: 409

Please make it possible to update the id!

We are using Azure Artifacts as an npm feed to store a npm package that we produce, along with cached upstream packages from npmjs.org. Public upstream has been configured per your documentation, and we have enabled retention policies on the feed with the default values.

The problem we are facing is that public upstream packages are treated the same way as package we produce - if a package/version has not been consumed for a while it will be removed in accordance with the retention policies and later also removed from the Recycle Bin. After they have been removed, either to Recycle Bin or purged completely, any build requesting this package/version will fail.

If the package/version is still available in the Recycle Bin we can manually restore it to get the build working again - not good enough (might be production critical), if the package/version has been purged completely we should be able to get it restored by contacting Microsoft - definitely not good enough, regardless of criticality.

This is a flawed approach, the expectation must be that any packages in a public upstream will always be available (if still available in the upstream and not actively removed from our feed, e.g. due to compatibility issues or security). In the case that the cached version has been removed in accordance with the retention policies they should be seamlessly put back.

With the current implementation we are therefore forced to either;

1. Use the public upstreams directly, defeating some of the purpose of the Azure Artifact feeds

2. Keep running builds to ensure that no needed packages are ever removed

3. Disable, or use less restrictive, retention policies for feeds with public upstreams - no OK when you are soon about to charge for feed storage...

How packages/versions from public upstreams should work;

1. If a package that has been removed from the feed by the retention policies, regardless if it has been moved to the Recycle Bin or purged completely, it should seamlessly be put back when requested - build should not fail

2. If a package that has been removed manually (possibly for good reasons) it should not be put back when requested - build should fail

3. There should be a way to get manually removed packages back in case of packages being wrongly removed