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.
Related
Prehistory is the following:
We use cloud SAP SuccessFactors app. We publish it for our users via Azure enterprise apps with SAML SSO configured with SAP support. And till last week everything worked good.
But this week we faced with the problem. SSO stopped working and started to redirect to old test link. We used SAML debugger add-in in chrome and we see this wrong redirection.
I struggled with Azure PowerShell and finally found that old link among others in SPN addresses list.
I used this command
(Get-MsolServicePrincipal -ObjectId "_our app objectid_").Addresses
BUT
I can not correct this list. If I try to create an array of such objects and then
Set-MsolServicePrincipal - Addresses $array
I get an invalid syntax error.
Maybe some PowerShell guru is watching and can guide or paste some idea I would be so much appreciated.
MS support in India says NO. Impossible to change Addresses for gallery apps.
SAP support say just delete this app and create from scratch.
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.
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.
We're completely upgrading our production and development environment from co-located boxes to an Azure implementation and we'll be developing using Visual Studio Online. Up until this point our dev has occurred on a Remote Desktop environment where developers were logging into Windows server and developing on that RDP box.
We want to set this up and we have some confusion about the Account types/set up types.
It appears there are two ways to set up our Azure and two ways to set up our developers. We are a MS partner w/ some MSDN licenses and Azure credits.
So for Azure we can use our existing MS accounts and just set up an Azure Pay As You Go (PAYG) subscription. This was suggested to us initially but it seems weird to have the entire companies Azure environment going through an individuals live ID. Then we saw we can sign up as an Organization now and it uses Azure AD. We have not been using Active Directory and we're not sure how much complexity this is going to add to our administration. Is there a discernible difference/benefit to going one way or the other?
Then, when we sign up our developers we can either have everyone sign up with their live ID's (we have MSDN w/ VS Premium credits for all developers) or we can set them up using Active Directory with Work Accounts. Having our credits allotted in work accounts sounds like a good way to control things at first reading, but it also seems a bit more complex. I'm wondering if there is much difference between MSDN accounts signed up w/ live IDs or AD Work Accounts. I can't find a real comparison article or pro/con type of discussion anywhere.
It sounds like you have already figured out the main differences. As an organization, I would suggest signing up for Azure as an organization. You can do that here. This is going to give you the management capabilities for resources typically needed by an organization.
Your developers can continue to use the MSDN subscriptions. As Dylan commented, these are not to be used for production environments. You should consider using these for Dev/Test environments and activating your MSDN benefits. This will save you some money. More on that here.
Visual Studio Online will work with your Work Accounts and again give you more control over managing your online resources. This link describes the sign-up process for both Microsoft Accounts and Work Accounts. And if you scroll down a bit you will find your original question specifically addressed.
Finally, you can also add your Work Account(s) to your existing MSDN subscriptions if you like. This way you (and your developers) can use the same account credentials when accessing Azure Subscriptions. Information on how to do that is available in this link.
Your Work Account subscription should be limited to personnel responsible for managing your "production" environment.
After signing up for Azure as an Organization, you can add users to the directory as described here. You can also add "external" users using their existing Microsoft Accounts. It's just a few dialogs to add a user.
I'm having a pretty strange issue with Azure tools for VS 2013 (version 2.6). Whenever I try to sign in to my Azure subscription (e.g. from Server explorer or creating a new web role project) I get the following error:
Server Explorer
An error occurred during the sign in process: User 'foo#gmail.com' returned by service does not match user 'bar#outlook.com' in the request
OK
My subscription owned by 'bar#outlook.com' and I can perfectly fine sign in either to management portal in a browser (IE, Spartan and Chrome) - as well as in the Power Shell. Tried everything - cleaning up browser caches/cookies, resetting IE settings, playing with different IE security settings - nothign works.
Any help is appreciated - this issue drives me crazy.
P.S. I'm on Windows 10...
I had the same problem. Imported the certificate manually and everything worked ok: https://social.technet.microsoft.com/Forums/en-US/9cdafeb4-f459-436d-b2b8-9bc5c01f0df1/azure-tools-for-vs-cant-sign-in-to-subscription?forum=windowsazuredevelopment
I had this issue, to resolve it I:
Added 'foo#gmail.com' as an alias in my 'bar#outlook.com' Microsoft account, via account.live.com
Made the 'foo#gmail.com' email address the primary alias for my Microsoft account
I could then log in successfully in to Azure by pressing the Connect to Microsoft Azure button in the toolbar of the Server Explorer in Visual Studio 2013 and see all of my websites under the App Service node.
(When I'd used the certificate method described in the other post and Microsoft documentation I'd been able to see all my sql databases etc. but not the websites.)
Once I'd done all that I then switched my primary alias back to 'bar#outlook.com' and server explorer carried on working.
NB: If you're experimenting with this beware that there is a limit on how many times you can switch your primary.. as I have just discovered.. and now my primary is stuck on the wrong email address for a week.
NB2: If your connecting in order to be able to remote debug the website, then this can still be done by going to Visual Studio>Main Menu>Debug>Attach To Process, and then enter the URL of the site (without the http bit, e.g. mysite.azurewebsites.net) as the Qualifier and then attach to the w3wp.exe process.
I am having the exact same issue. It seems that the Azure sign-in in Visual Studio is redirecting to our organizational Single Sign-On instead of the Microsoft one. I have managed to work around this problem by using a Microsoft account that is not tied to my organization:
Create new Microsoft account or use an existing account not associated with your organization
In https://manage.windowsazure.com select Subscriptions/Manage Administrators
Choose Add+ and add the new Microsoft account as administrator to your subscription
Log on to Azure using the new account from Visual Studio
/Morten
I changed my Microsoft account's email address and had this problem. Adding an alias did not help.
The problem is to do with the Azure Active Directory Library for DotNet. For whatever dumb reason, they throw an exception when Azure returns an ID different than the one requested (if the server isn't crying about it, why make up an error and make the client deal with it?).
Since Azures's support was no help, I had to build a custom copy of the ADAL with that moronic exception removed and an assembly version matching the one used in VS2013 (2.11). Also importantly, disable strong name verification for the custom assembly.