What happened to the
'Microsoft.RecoveryServices/Vaults/backupJobsExport/operationResults/read'
'Microsoft.RecoveryServices/Vaults/backupManagementMetaData/read'
operations in Azure? They exist in this documentation...
https://learn.microsoft.com/en-us/rest/api/recoveryservices/operations%20vaults/list
but not in this documentation...
https://learn.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations
and I cannot find them in the output of the Get-AzureRmProviderOperation powershell command.
Were the operations renamed or have the services they grant access to no longer support those operations?
Those 2 operations were definitely removed as part of following commit on github.
I will try to find out about 2nd part of this question ..ie. what is the replacement or change
https://github.com/MicrosoftDocs/azure-docs/commit/49a405a66cd91e29f9f07dfe0e057d9fdee7ac50?diff=split
Both these operations are not required for RBAC to run and hence they were removed from the ‘resource-provider-operations’ URL. The Microsoft engineer said that they will be removed from the other document as well to keep the documentation consistent.
Related
I have been trying to set up a snowpipe to ingest data from blob storage in Azure into snowflake, following this guide, I think I have done everything correctly although I am new to azure and snowflake so may have missed something obvious. Everything seems to have been set up correctly on both sides, but whenever I check the pipe status using SELECT SYSTEM$PIPE_STATUS('azure_pipe');, I get the following:
{"executionState":"RUNNING","pendingFileCount":0,"notificationChannelName":"https://snowflakedata.queue.core.windows.net/snowflakequeue","numOutstandingMessagesOnChannel":2,"lastReceivedMessageTimestamp":"2022-02-18T13:25:12.107Z","channelErrorMessage":"downloadAttributes error:Queue not found for channel Name=https://snowflakedata2.queue.core.windows.net/snowflakequeue, AccountId=6713, NotificationChannelID=2045, IntegrationID=1784764","lastErrorRecordTimestamp":"2022-02-18T17:32:47.854Z"}
I'm not sure what I have done wrong, the snowflake app has the queue contributor role in azure and I'm fairly sure I set everything else up correctly. If anyone could point me in the right direction as to how to troubleshoot this that would be really helpful!
I had the same issue as you did just this week when trying to create a Snowpipe for Azure. Using SELECT SYSTEM$PIPE_STATUS('azure_pipe'); gave the exact same error message as you have shown above. Thankfully, Snowflake Support has provided me with the answer and an explanation.
Answer:
Drop all of the objects relating to the Snowpipe (integrations, pipe, stage, etc). Then recreate them in the exact order and specification as shown in this documentation.
Explanation:
The issue for me was caused because I kept using create or replace on the objects when I was modifying them (eg changing the comment on a pipe). This re-created the object and broke the links between the objects in the Snowpipe and prevented the Snowpipe from working as intended. Dropping and starting again solved it for me.
I would like to list the locations available for a particular subscription, pretty much in the same way that it's done with az account list-locations from the command line, or like it's listed here for Python
However, I can't find a straighforward way to do that. The example here apparently creates a virtual machine, but is not too well documented.
I can't even get past the initial step of providing credentials to use my account (this could be it, but it's geared towards working with compute service; I don't know how it can be translated into simple management).
Is there any step-by-step tutorial I have missed?
The azure-mgmt package seems clear enough, but it seems also a bit outdated and it's not clear if it's current anymore.
Pretty sure you need this to auth: https://learn.microsoft.com/es-es/javascript/api/azure-arm-resource/subscriptionclient?view=azure-node-latest
and this call to get locations: https://learn.microsoft.com/es-es/javascript/api/azure-arm-resource/locationlistresult?view=azure-node-latest
Node SDK repo: https://github.com/Azure/azure-sdk-for-node
I have a standard Azure build -- one web role, one worker role. After the latest merge, it has decided that the roles are invalid. When I double click on the web role or worker role, or when I right click and choose "Properties", I get a grey screen saying "Invalid service definition or service configuration. Please see the Error List for more details". However, there is nothing at all in the Error List.
I have cross-compared the Settings elements and tried commenting out sections of the csdef and cscfg files, but nothing seems to bring the roles back to life. I have wasted half a day on this already. My question is not so much "What is wrong" -- more like, how on Earth are you supposed to find out what the error is when no information is given and successive blanking out of code draws a comprehensive blank?
I've run across this a couple of times (VS 2015 Enterprise). Simply closing and re-opening the solution resolved the issue.
In this case, nothing was wrong with the csdef and cscfg files. It was the way the wadcfgx files were linked to the roles.
I'm on a branch that is using Azure 2.5; the other branch is on a previous version of Azure, that uses the older version of diagnostics. By deleting the existing wadcfgx files and re-generating them, I was able to make the roles visible and editable again. Having different versions on different branches does, of course, open a very large can of worms, but we're stuck with that difficult situation for the time being.
Check if the VM Size specified in the configuration is Small or Extra Small as it doesn't support more than that on local emulator. In my case it was defaulted to Standard Size VM. I changed the size to Extra Small and it started working fine!
I just ran into this after adding a new Worker Role project to an existing cloud service with a few existing Worker Roles.
In my ServiceConfiguration.Cloud.cscfg, I had a <NetworkConfiguration> tag in between the old roles and the new role. This was the problem. I simply moved the <NetworkConfiguration> tag to the bottom as it was before (this tag is not in my ServiceConfiguration.Local.cscfg file, which might've been the problem).
Probably not the most common cause of this problem, but figured I'd post on the off chance someone has similar settings.
I would like to update the Diagnostic configuration file for the azure roles whenever I upgrade my deployment. How can I do this automatically?
From time to time, we do change our diagnostic (using code) - and upgrade the service. But whenever we upgrade the service, it is still using the old diagnostic configuration and we do not see any new logs we have configured using new code.
How can I achieve this so that whenever I upgrade my deployment, it upgrades the diagnostic configuration as well.
I wonder if you have a bug in your diagnostics updating code. If each role ran code in OnStart or Run to configure diagnostics on startup, there would be no reason that your instances wouldn't be properly configured. I tend to think that imperative code that configures diagnostics is inherently a bad idea in the long run, but it should still work. If you share the code, maybe I can spot an issue.
The best** way I have found to update and enforce configuration is to use the diagnostics.wadcfg file and update it. When you upgrade your deployment, it will use those settings if you have not overridden it in code somewhere. Contrary to Microsoft's guidance at that link, it should be the preferred method as opposed to code which must be maintained and is orthogonal to your application's purpose. Said another way - a declarative configuration file that your ops team can maintain over writing code is usually a better idea. To use this, just include it in your deployment as content and delete any existing files in wad-control-container (and remove any code that configured diagnostics). It will just configure itself from that file then when you next upgrade.
** you can also using a 3rd party SaaS monitoring to set and maintain your diagnostics config. I work on one such one, but I am guessing you want to know how to do it yourself. :)
Windows Azure Table has two distinct mechanisms for altering an existing entity: Update, which modifies properties in place, and Merge which replaces the entire entity.
Which of these is used when you call TableServiceContext.UpdateObject()? (I'm guessing Update.) And is the other one exposed at all through this API?
(Apologies if this is right under my nose in the docs and I'm not seeing it.)
Actually, it's Merge that modifies properties in place, and Update that replaces the entire entity.
I believe the storage client library does a merge by default, but I think you can use SaveChangeOptions.UpdateAsReplace to modify this behavior.
An easy way to test/verify this is to run a debugging proxy like Fiddler and just see what happens over the wire.