What is the difference between these two portals and why? And when should I use which of them?
For example:
When I want to configure if/which Java version I want to use in a WebApp, in the "manage"-portal I only can choose between off and v1.7.0_51. In the "portal"-portal I can choose between off, v7 and v8.
Or, if I want to create a new Ubuntu-VM, in the "manage"-portal I can choose between v12.04, v14.04 and v15.04. In the "portal"-portal there is only v14.04.
As commented by Mike, manage.windowsazure.com is the current production Azure Portal while portal.azure.com is the preview portal which will eventually replace the production portal.
From an underlying technology perspective, there's one big difference between the production and preview portal. Production portal makes use of Azure Service Management API while the Preview portal makes use of Azure Resource Manager (ARM). Along with ARM API, you get Role-based access control (RBAC) that enables you to grant granular permissions on your Azure resources to your team members. In the production portal, there's only a concept of Subscription Administrator and Subscription Co-Administrator.
Not all services in Azure has been ported to make use of ARM API as of today and that's why you see only few services in the preview portal. Services that make use of ARM API (all the new services) will only show up the preview portal.
As to when to use what portal, just see the Azure services you need to manage. Based on how they can be managed, you will choose between production and preview portal. Also please note that functionality for a service may differ between portals even though it is present in both portals. That may be another criteria between choosing the portal.
More information Can be find from microsoft site
Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources
Related
I want to migrate all the content/data of 1 azure API management instance to a different instance.
While checking for options, came across backups, however the MSFT clearly informs that Developer Portal Content( i.e applications,products,subscriptions) are not included in the backup.
https://github.com/MicrosoftDocs/azure-docs/issues/28199
In this case, How can I migrate apim instance with also the contents of developer portal.
I have also looked at REST API's but there are no API's exposed for Applications in developer portal. Does that mean in case of disaster recovery , all the data of developer could very well be gone? Any better options here?
It is possible. We can take backup of applications, products and subscriptions of API management and restore it to another APIM. Only constraint is that both APIM should be of same tier.
Please follow following [blog] https://blogs.msdn.microsoft.com/stuartleeks/2015/04/29/azure-api-management-backing-up-and-restoring-configuration/
Other solution of instant DR is using 2 APIMs in different regions behind a traffic manager and maintain both APIMs.
I have an asmx webservice that is hosted in azure cloud and it has been active for the past 2 years and recently I have received an email from Microsoft stating that
"Azure App Service resource management will now be supported only
through Azure Resource Manager. Support through Azure Service
Management will be retired on June 30, 2018. Transition to Resource
Manager to keep programmatically managing your resources."
Dear Azure customer, You’re receiving this email because you’re a
current Azure App Service customer, and you use an Azure Service
Management–based client to programmatically manage your App Service
resources.
The Resource Manager portal and APIs have replaced the legacy Service
Management portal and APIs for managing App Service resources.
Beginning June 30, 2018, App Service resources will be supported only
by Resource Manager. You’ll no longer be able to manage App Service
resources using Service Management.
Resource Manager offers a number of advantages over legacy Service
Management, including: • A robust resource deployment model.
• Built-in role-based access control. • Fully supported REST API and
clients for existing and new features.
Recommended action
We recommend you transition any automation that programmatically
manages App Service resources using Service Management APIs to
Resource Manager APIs by June 30, 2018. The specific steps you’ll
take depend on what client(s) your automation is coded against. Read
our blog post to learn more about the transition and any action you
might need to take.
I am not sure whether this is a kind of question to be posted here but i thought someone familiar with azure will be able to shed some light on this. Thanks in advance.
Azure App Services were removed from the "old" portal, https://manage.windowsazure.com and can only anymore be accessed from the "new" portal, https://portal.azure.com.
If you got some web app created using the old portal, then you need to managed it using the new portal.
The above email is regarding any customization that rely on the old portal, and its APIs to function. You need to update them to use the new portal, and its API for them to continue functioning after June 30, 2018.
We are developing applications in .Net and deploying them to Azure app services. We currently have a multi-tier environment (QA/STG/PROD). In order to replicate the same environments we are using slots. However, the issue with slots is all developers who has access to QA slot are able to view/modify STG / PROD slot settings. We want to segregate this with authorization where-in users should only be able to publish apps on QA. Should we still use slots or we go with separate web apps?
As suggested in one of the comments you can use RBAC (Role Based Access Control) to control the user permissions on the web app/slots.
Azure RBAC has three basic roles that apply to all resource types:
Owner has full access to all resources including the right to delegate access to others.
Contributor can create and manage all types of Azure resources but can’t grant access to others.
Reader can view existing Azure resources.
So, you could add the developers as a READER to the webapp and as a CONTRIBUTOR to one of the slots. This will prevent the web app changes
Further, you can customize the RBAC to suit your requirements.
You can create a role with custom
Refer this article:
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
You can go with slots. Each slot creates a separate URL and you could control access to the slots by Authenticating using AD.
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/
I am having an issue while deploying an Azure web role to a cloud service. It shows me the error
Cloud services are not available in this subscription.
I am using a pay as you go subscription on Azure. I don't know if there is any limitation with this subscription for cloud service deployment or not.
.
Updated version of JerryGoyal's solution.
Cloud Service Management will have to be done using the new Azure Portal, because Cloud Service Management in the old portal will be disabled as of 11/15/2017.
Log into the new Azure Portal.
Go to the Subscriptions View.
Set your account as a Co-Admin. Microsoft Documentation.
I think the issue you're running into is that the Cloud Service Publish Wizard in VS only supports subscriptions in which you are an admin or co-admin granted via via the old portal (manage.windowsazure.com). If you've been given access via RBAC or the new portal, then VS will not see the resources under those subscriptions.
To work around it, you can build the package using msbuild.exe and then upload it via the portal.
That help?
Cloud services are not available in this subscription
The error is caused because the Cloud Services still use the old deployment model that is based on Azure Service Management (ASM).
To deploy an ASM based component to Azure you need to be ‘co-admin’ for the subscription.
Right now you are ‘Owner’ on the new portal but this role only has impact on the new ARM based resources.
So, just ask your subscription admin to login to the old portal (https://manage.windowsazure.com) and make you co-administrator:
Login to the old portal
Click on Settings –> Administrators
Click on the Add button at the bottom
Enter the co-admin email address and click on the OK button.
After this reload your Visual Studio and the problem will be solved.
I need to assign publish permission to one of my developers so that he should be able to publish to only one cloud service & do not affect others.
Azure websites have these concepts called download publishing profile.
I could not find anything similar for cloud service. Can it be
achieved?
As you know Azure Management Portal does not have any role defined where we could map a user account login to manage a set of resources (say cloud service 1 & 2)
It is not possible as of today. It seems that it should be possible with Resource Groups and Role Based Access Control (RBAC) however currently cloud services can't be added in resource groups and assigned RBAC.
One way you could achieve this is have a custom application consuming Service Management API and implement your own RBAC in that application. However it is still a "hack" and not proper solution.
Why don't you try using "publish from source control"? When the developer checks in it will auto publish the code.
I believe the new portal will allow the creation of roles for publishing profiles; it already allows adding additional users to your organization; but to get what you want for now; publishing from source code should do the trick.