Register RP using Bicep

[stan-sz]

Is your feature request related to a problem? Please describe. Have the ability to register an RP in a subscription using Bicep. The documentation at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types does not mention this functionality.

Describe the solution you'd like Microsoft.Resources could provide a type to (un)register another RP.

[matsest]

Not saying that this shouldn't be supported but the docs does mention

Other resource providers are registered automatically when you take certain actions. When you deploy an Azure Resource Manager template, all required resource providers are automatically registered. When you create a resource through the portal, the resource provider is typically registered for you. For other scenarios, you may need to manually register a resource provider.

If that goes for ARM, it should as well for Bicep? Perhaps the docs should be clearer on this, as well as what "other scenarios" might be.

[stan-sz]

If this can be solved automatically (ARM after receiving a template to deploy among first steps auto-registers the required RPs) that would be a perfect, seamless solution.

[alex-frankel]

Mats is right - @stan-sz let us know if this is not working as expected.

I'm going to leave the issue open since we do sometimes get the ask to register RPs as part of a subscription setup process, especially if you don't want to give dev teams the ability to register RPs and can't rely on this auto-registration capability.

[slavizh]

A few scenarios I am aware where registering is needed:

• When you add activity logs to Log Analytics workspace (via legacy way) you add the subscription ID. For that subscription the Microsoft.Insights RP needs to be registered. This of course legacy way is to be deprecated and people should use diagnostic settings. May be there were are few more scenarios like these where you reference something and in order to work you will need to register the RP. The resource where you reference this does not do any checking so it will not throw error if the RP is not registered. Overall these are I think rare cases with some not so good architecture that in most cases is being deprecated.
• Running what-if when you deploy Lighthouse if the RP is not registered returns error. This somehow behaves differently from other resource deployments. I have already flagged this issue long time ago.

[azMantas]

another scenario where registering needed:

• if subscription is not configured for automation account provider to update azure vm, update will fail

[VHamar]

Another scenario where (pre) registration is required is:

• users only have contributor on resource group, not subscription, so even adding resources through portal (or arm/bicep) will fail

This then creates a need to preregister providers, can be done through CLI/PS but would be nice to have the ability through bicep too

[alex-frankel]

@vhamar -- i'm not following this one. If you don't have contributor rights on the subscription, you wouldn't be able to register an RP w/ bicep and you shouldn't be able to do it with CLI or PS. Are you using a different identity with PS/CLI?

[VHamar]

@alex-frankel -- I guess that could be misunderstood when looking at it now in hindsight. Yes, I as an admin through automation, today using the CLI register the providers, but the developers provides me with a list of providers that are required for the sub(s).

It's still in the context of pre registering allowed providers, as users/devs do not have permissions on the sub, just on rg's. So being able to do that automation through bicep would be nice :)

[JulienFloris]

i have a issue when deploying NetworkWatcher FlowLog with bicep:

Status Message: Subscription ****-9fdc-4417-a4be-******* is not registered with Microsoft.Insights provider which is required to emit flow logs to storage account. You can register it, for example, by running Register-AzureRmResourceProvider PowerShell commandlet. (Code: SubscriptionNotRegisteredToUseMicrosoftInsights)

[vcantrell]

i have a issue when deploying NetworkWatcher FlowLog with bicep:

Status Message: Subscription ****-9fdc-4417-a4be-******* is not registered with Microsoft.Insights provider which is required to emit flow logs to storage account. You can register it, for example, by running Register-AzureRmResourceProvider PowerShell commandlet. (Code: SubscriptionNotRegisteredToUseMicrosoftInsights)

@JulienFloris Did you ever figure this out? I'm running into this when trying to setup flow logs on single-deployment bicep deployments where both the subscription is deployed, then the resources. I'm unable to setup flow logs automatically because there seems to be no way to register the Microsoft.Insights resource provider via BICEP...

Do we know if RP registration is in the pipeline at all for BICEP/ARM?

[JulienFloris]

Resource providers should automatically register when deploying with ARM (or bicep). Posted the issue here because in this case it was not working. And worked around it for now by 'manually' registering the resource provider in the devops pipeline with a AzurePowerShell Task.

[vincecantrell-tn]

That's my problem as well. Trying to setup flow logs on brand new subscriptions via BICEP and they're failing due to the Microsoft.Insights RP not being registered. So this bug still exists then.

[slavizh]

To generalize the problem: When certain features for one resource type are enabled they require that another RP is registered. It is quite often for the monitoring scenarios. For many of those scenarios your monitoring resources can be in one subscriptions so there the Microsoft.Insights RP Is registered but the monitored resources are in another subscription where Microsoft.Insights RP may not be registered.

[bartvermeersch]

Creating a subnet with delegation is also not registering the necessary delegation RP, no error is shown, the delegation is visible in the GUI but is not functional.

[drmmr763]

For the record I'm currently experiencing issues where RPs are not auto-registering using bicep deployments. The service connection has owner rights to the subscription, but I get errors:

##[error]DeploymentScriptOperationFailed: The client '4d862f92-b6be-4f23-8cfc-7ea716b33fd0' with object id '4d862f92-b6be-4f23-8cfc-7ea716b33fd0' does not have authorization to perform action 'Microsoft.ContainerInstance/register/action' over scope '/subscriptions/496a5cf9-079f-4e66-aee0-dc4f900c65ad' or the scope is invalid. If access was recently granted, please refresh your credentials.

Going to the subscription and manually registering the RP resolves. I've had this occur with 3 different resources. Granted these are resources that I have created after the RS is already stood up.

[pemontto]

We provide customers an ARM template to run which creates RGs that we access via Lighthouse with the contributor role. At deployment time we have no requirement for e.g. Microsoft.Compute or Microsoft.Logic, however we need to be able to deploy these resources later via Lighthouse. Because we can't register RPs at the subscription level, these deployments will fail with messages like Resource provider(s): Microsoft.Compute are not registered for subscription X and you don’t have permissions to register a resource provider for subscription X. Currently the only way we can make this work is by creating hacky dummy resources at deploy time.

[miiic]

Is there any update on this? Is automatic registration of resource provider's supposed to work when deploying bicep templates?

I'm new to bicep deployments and I'm trying to build a full suite of templates that will cover all aspects of deployment with no manual intervention. For now I have been registering manually, but this defeats the purpose of my project...

[alex-frankel]

@miic - Bicep does auto-register resource providers prior to a deployment starting. If this fails to happen, it is usually evidence of some issue with that workflow and we would want to look into it.

[deggja]

@Miic - Bicep does auto-register resource providers prior to a deployment starting. If this fails to happen, it is usually evidence of some issue with that workflow and we would want to look into it.

Does it? if so, I might have another example of this not working as intended on my hands. I am trying to deploy a managed application using bicep - and it is failing due to missing resource providers for Microsoft.App and Microsoft.ContainerService.

Considering I am deploying these particular resources in my Bicep file - should they not have been automatically registered in the subscription?

[alex-frankel]

My guess would be that because it is Managed App deploying that may be causing an issue. In this case, bicep is not aware what the app is deploying. It will only try to register that managed app RP. Can you share the code you are deploying that we can use as a repro?

[deggja]

My guess would be that because it is Managed App deploying that may be causing an issue. In this case, bicep is not aware what the app is deploying. It will only try to register that managed app RP. Can you share the code you are deploying that we can use as a repro?

Yeah, I think you're absolutely right. Actually, its not Bicep deploying the application at all. Bicep is simply building the ARM template that deploys the managed application. So in this case, I suppose this would be an ARM issue..

I think I jumped the gun a little with my comment. Sorry :-)

[AndriiKutsenko]

any updates on this? we are deploying resources via Azure pipelines and Bicep, however still must to pre-register providers via powershell task, otherwise deployment fails

[Dronec]

Getting the same when trying to deploy Log Analytics using bicep: "InvalidAuthenticationToken\",\r\n \"message\": \"Please register the subscription '***' with Microsoft.Insights.

Certainly that stuff should not be "semi-automatic"

[segraef]

Is it planned to have the capability to enable RPs via Bicep in future like TF already does?

[jarredm-demo]

Reading through this thread, I am somewhat confused. Are we saying that Bicep is failing to register RPs in very specific circumstances (i.e. there may be bugs or specific times where it cannot be implemented by design), or that we think registering any RPs automatically during Bicep deployment is not a current feature?

Because according to the Learn documentation, auto-registration upon deployment is a current GA feature: "Resource providers have to be registered for your subscription before you can use the resource types they expose. Registration is usually a one-time process. When you submit a Bicep deployment, Resource Manager automatically registers the resource providers used in the file." (https://learn.microsoft.com/en-us/training/modules/child-extension-bicep-templates/2-understand-azure-resources)

If auto-registration is not a feature at this time, then the appropriate documentation team and product group need to be notified so that the documentation and learning path can be fixed.

[Dronec]

Actually, please disregard my comment. I can't remember what exactly I did wrong, but it was my fault.

[VHamar]

@jarredm-demo Bicep is not doing the registering, that is, as the documentation you refer to a GA feature...

That works as long as the identity running the deployment have contributor access on the subscription. If the identity running the deployment only have access on the RG and tries to deploy a resource type that have not been deployed in the subscription before, then there is a need for someone with at least contributor on the subscription to register that RP in the subscription (if they approve the use of it).

There are many reasons why I will not grant identities contributor access on the subscription. One example is a subscription where we create "sandbox" RGs for users where they can run tests and experiments. In this scenario I do not want the users to have access to each other's sandboxes but the nature of deployments in an environment like this is that users' wants to try to deploy the latest and greatest, and the RPs for those are not always in the subscription.

Today I have to either use the portal or az cli to register the RP. Or run a bicep deployment of the resource and then clean up again just to register the RP.

[arealmaas]

That works as long as the identity running the deployment have contributor access on the subscription. That doesn't seem to be the case for me. It has contributor access, but getting the samme error messages..

Is this really supposed to work? In that case, I am not sure what we're doing wrong..

[vRune4]

I have a consultant working on a new project and I've created a separate resource group for him to work with. He has his own little bicep project so he can deploy stuff he needs. This is deployed by a github workflow using federated credentials. The managed identity has owner access to the resource group and little else.

Meanwhile, I have my "main" bicep project that, among other things, sets up his resource group. My thought was that I would register any resource providers in my main bicep project. My deployment runs in the context of a user that has Owner access to our subscription.

What specific access is required to be able to autoregister a resource provider?

[marshalexander99]

I've just encountered this issue. We're performing a multi-region deployment via DevOps with BICEP. We have a loop to deploy a vnet in each region. The first deployment triggers the auto-registration however the other 2 fail because the RP isn't registered (I guess due to the RP registration being in progress and not unregistered).