I have been able to work in Azure APIM with no problems until yesterday. Another member on my team can edit and save with no problems; but my save to an Inbound Processing rule always fails with:
Could not save policy for "Access API 1.2" API. Please try again
later.
Thoughts?
Of Note:
Our companies security access team verifies that I am a contributor to APIM
I login in through the companies' two factor authentication system into Azure.
Same results on Edge/Chrome.
I can update individual endpoint api policies.
Our company opened a Microsoft Support ticket on this and their response was
You are running into a known issue with APIM integration with ARM. The
dev team is working on a fix for this issue now and we are told it
will get deployed by this evening.
The following day it was working for me
The APIM dev team fixed the issue late yesterday and you should now
see the ability to update policies for the API scope too.
Note to anyone running into this situation in the future the secondary advice given revolved around the browser which was
Make sure you’ll not pulling down cached files. Try loading an
in-private session or press CTRL+F5 to refresh the page and pull down
new files.
Related
Recently, something has change with the Azure resources view in the VS Code extension.
I have 3 accounts I typically sign in with:
Personal
My Company
My customer
As recently as the April timeframe, I was able to use the extension to deploy logic apps into my customer's Azure tenant. Now whenever I sign in to them, I see nothing in the extension, in fact it behaves as if I've not signed in at all. But my other two accounts work as expected.
No Resources in customer account
My Company account with resources
I have signed in/out multiple times. I have uninstalled/reinstalled the extension(s). This is happening on both my Windows 11 and Mac machines.
I'm down to beleiving that this may be some corporate restriction/policy implemented by my customer's IT, as they are trying to reorganize and restructure their Azure environments. And yes, I still have access overall, because I can log into the portal see the resources just fine.
Would anyone know of such a setting, and what it might be? Or know anything else to try?
Despite wrestling with this for over an hour yesterday, it appears to have resolved itself, or my one last try of starting with a rebooted machine, signing in to the portal first, THEN signing in with the extension seems to have got it back up and running....
I was able to sign out of Azure in VS Code using this:
https://stackoverflow.com/a/53707442/79558
Then I signed into portal.azure.com, then signed back into VS Code.
I'm wondering if it had something to do with my org requiring multi factor authn more often for access to portal.azure.com.
I am trying to deploy an on-prem instance of Azure DevOps Server to a VM in an Azure Government subscription (which by nature, seems it does not support standard DevOps).
This template is referenced within support material directly from Microsoft:
https://github.com/usri/deploy_DevOps_Server_AzureSQL
All the referenced resources were created from scratch for the purpose of getting this server running.
This requires an AAD account with the associated password stored in a Key Vault. However, every attempt I make to run the template returns the following error on the 'Write VirtualMachines' step (when all other components pass):
The client has permission to perform action 'Microsoft.Compute/images/read' on scope '(MY_SUBSCRIPTION)\(MY_RESOURCEGROUP)\(VM)', however the current tenant '(MY_KEYVAULT)' is not authorized to access linked subscription '(ID in the template with the deployment files)'
This seems to me like the password cannot be retrieved from Key Vault- is it a formatting issue with the Secret? An access control issue somewhere? I've tried many various combinations of both. Hopefully this is just a trivial issue..
I am the original author of the code in that repo. I went ahead and merged a pull request into that repo which should address your issue. I did the following:
Updated the ReadMe file to include information on creating the image
Updated the azuredeploy.json with parameters for Key Vault & image references
Updated the ps1 file to eliminate hard links for KV (a particularly bad oversight on my part, my apologies).
Updated and tested everything for the latest version of Azure DevOps Server 2020
This should fix your issue and several other related ones. I retested the entire deployment from scratch and it worked as designed. A couple of other quick notes:
The USRI and all of it's repositories including the one being utilized here are not Microsoft official repositories. They represent an open-source Azure community dedicated to regulated entity customers. The members which contribute there are mostly Microsoft employees and the repos themselves just represent interesting and sometime niche templates that might be of interest.
This particular repo shows a manner in which Azure templates could be used to deploy services when no internet connection is available or permitted. I just used Azure DevOps Server because it was interesting and regulated industry customers use it.
All the best
I am trying to load the page 'https://www.customvision.ai' for training Vision Api for improving the object detection ability of Azure Cognitive Service Instance. But it does not getting me to https://www.customvision.ai/projects, fails instead. No error messages in browser console.
I have created a resource for Cognitive Service in West-US2 region in Azure Portal. Do I need to create any more resources specific to Custom-vision? Please suggest.
I am using MSDN Azure Subscription for accessing Azure Portal.
Actually no need to create specific one. Try logging out and switching the subscription. you should be able to access it without a problem if you're under valid subscription
Ashokan, the easiest way to get an answer for your question is
(1) visit https://cognitive.uservoice.com/forums/598141-custom-vision-service
(2) Click "Contact Us"
(3) Report the issue there and submit
This way we'll be able to assist you one-on-one and give you a solution faster.
It was fixed automatically after sometime without me intervening while I am still using MSDN Azure Subscription.
I maintain a family web site on Azure on my spare time. For a small fee, we have purchased a custom domain name to make it more "professional".
Unfortunately, the credit card associated with the susbscription has expired and since I was not actively monitoring the dedicated mail account I had created for this purpose, the susbscription has now been deleted (the susbscription is actually disabled in the portal, but the mail from Azure says that I need to create a new subscription if I want to change my mind).
In a matter of minutes, I registered a new subscription and thanks to continuous deployment, I could deploy the Web App from sources that I had kept on a GitHub account. However, an attempt to bring an external domain to the Web App fails with the reason being that the said domain is already in use by another Azure web site (presumably, the old Web App from the, now deleted, subscription)
A quick chat with the #AzureSupport team on Twitter, they suggested I file a support request from the Azure portal. However, since this is not a professionnal susbscription, I do not have a support plan. I see that support costs 25 $/month for at least 6 months in my situation.
This seems a bit too costly, like an order of magnitude higher than buying a new domain name for several years. At the same time, I don't understand why the deleted account is still locking the custom domain name. And it seems unfair that I need to pay to recover a domain name that I own but am unable to benefit from because it is associated with a Web App in a disabled Azure subscription!
Please, what are my options?
PS: Even though this is not a programmatic question, I post here because that's where Microsoft recommends to obtain community support. I have also posted a similar question on an appropriate MSDN Forum but the answers there are not satisfying.
Unfortunately on a technical level this will be something that can only be rectified by Azure support. Since you no longer have access to the account they will need to delete that domain association.
It is excessive that you are required to pay for a six month support contract to resolve an issue that is clearly an issue with the way Azure decommissions subscriptions.
The problem you now have is that you can't use Azure to host this domain until that association is removed. Your only options are to either have the complexity of using a VM or to move your site to AWS etc.
If you make those points to #AzureSupport team, maybe they will process it for you. Point them to this question and ask them to help you to keep using Azure.
I have an Azure WebApp and have activated the "Active Directory Authentication" in the Azure Preview Potal. Let's call it https://mysite.azurewebsites.net (not a real URL) Whis works as expected. However, when we add a deployment slot, we can't get authentication to work properly. When accessing the staged WebApp, e.g. https://mysite-staging.azurewebsites.net (not a real URL), we get redirected to
https://login.microsoftonline.com/<our-directory-guid>/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmysite-staging.azurewebsites.net/....
But the login portal gives us an error message:
AADSTS50011: The reply address 'https://mysite-staging.azurewebsites.net/<our-appliction-guid>/login' does not match the reply addresses configured for the application: .
The problem is, the WebApp does not show up as an application in our directory, so we can't set up alternate reploy URLs for it.
Is there any way to specify alternate addresses for WebApps, so that Azure AD login will work for deployment slots?
When you create the deployment slot, you need to re-setup the authentication for it, as if it's a new application. (From an app-service perspective, it is.)
The steps are roughly:
In the portal, go to your deployment slot under your app-service.
go to authentication/authorization
Go through all the steps to setup your authentication/authorization the same as for your production app. (Authenticate via AzureAD, Choose the provider, etc.)
Under "Manage App" in the staging environment, go to settings, and add new reply URL's for your staging environment. You should have your regular reply URL, and then the staging version:
https://myapp.azurewebsites.net/signin-oidc
https://myapp-staging.azurewebsites.net/signin-oidc
You should then be able to get in.
One weird thing that happened to me, is this didn't work, then I went into the staging authentication, and turned it off. That made everything work, and it correctly authenticated and didn't let me in if I wasn't signed in.
(I realize I'm posting this answer years after the original question, but after spending the better part of a week figuring it out, and this question repeatedly came up on searched, I wanted to document what I ended up doing in case someone else has a problem.)
I sure this will not fix the deployment slot is still pointing to live app but this fix this error as it is very silly.
AADSTS50011: The reply address 'https://mysite-staging.azurewebsites.net//login' does not match the reply addresses configured for the application: .
When you configure your URL under the application settings in Azure AD, you forgot… a trailing slash! That’s it! Can you believe that?
In other words, change this:
http://yoururlforyourapp
to this:
http://yoururlforyourapp/
Done! You’re welcome.
From http://www.matvelloso.com/2015/01/30/troubleshooting-common-azure-active-directory-errors/
Unfortunately it looks like you ran into some bugs in that version of the preview portal.
The Reply URL issue is likely because you created the staging slot after you configured auth on the production slot. In that version, we cloned the auth settings so your staging slot ended up pointing to the existing AAD application without adding the new Reply URL. This issue has been fixed by not auto-cloning auth settings when a new slot is created.
In any case, you should be able to find your application in the AAD management portal. If you're not able to see it, it could be because you need to change the "Show" dropdown filter from "Applications my company uses" to "Applications my company owns". Locating it and adding the staging Reply URL would have also worked around the issue mentioned above.
The error message you saw when trying to re-configure auth on your staging slot was likely another bug in the management portal if you were only seeing it on that staging slot.
The Authentication / Authorization blade has been radically updated since your question was asked, and all of these issues should be fixed now. Sorry for the inconvenience. I hope you were able to make progress in spite of these issues.