This link lists connectors moving from standard to premium in Flow and Powerapps.
Will they also move to premium for logic apps which are Azure rather than Office365 based.
For your concern about the connectors moving from standard to premium in logic app, I think you can raise a support ticket on Azure portal by following this link. The azure support team can provide you a professional answer.
Related
I need to add pages (kind of static web pages) in Azure APIM Developer Portal to display documentation. Is there any tutorial to explain how to achieve it?
Is there a way I can read the text content from REST API calls and populate the pages in Dev portal?
I believe the issue is more or less similar to this where you are trying to update documentation properly at Azure Api Managment developer portal.
In that case, as mentioned in the thread, you can try with swagger but in APIM portal it might not work immediately. Microsoft product team has confirmed that they working on improvig support for OpenAPIv3. The ETA is about end of September.
However, you may also check the self-hosted gateway feature
The self-hosted gateway feature expands API Management support for hybrid and multi-cloud environments and enables organizations to efficiently and securely manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
Overview
I have an SharePoint Office 365 Developer account and initially it was created using #xyz.onmicrosoft.com account.
Now I have added #xyz.com. All the billing management happen using the admin#xyz.onmicrosoft.com and application access happen using user#xyz.com
Now I am planning to add Azure Pay-As-You-Go subscription but I am confused should I create the Azure portal account using admin#xyz.onmicrosoft.com or user#xyz.com
Is there any best practice or general recommendation available ?
this is completely up to your organization, there are no major advantages of using one or other.
Nevertheless, an "user#xyz.com" account will be friendlier than "user#xyz.onmicrosoft.com".
For Azure automation we used Management Libraries in order to provision Cloud Services & BLOB Storage along with SQL Database. This seem to be no longer maintained. Shall we stop using this in production?
Need to provision:
Azure Web APP
SQL Database
BLOB
Azure Search Index
Any authoritative information on the recommended approach now, would be much helpful. Thanks.
As you may already know Azure Management Library is a wrapper over Azure Service Management API (ASM) which provided a REST based interface to manage the underlying infrastructure. Old Azure Portal (https://management.azure.com) makes use of ASM API.
Azure Resource Manager API (ARM) is the new REST based intefface to manage underlying infrastructure. ARM is more robust, feature rich and will be used going forward. New Azure Portal (https://portal.azure.com) makes use of ARM API.
Eventually old portal will be removed and you should be able to do all the things on the new portal. When that will happen is not generally known (someone from Azure product team will be able to comment on that). Until then, both ASM and ARM will be supported and after that ASM will be removed (or not supported).
General recommendation would be to start using ARM API wherever possible. Only use ASM API for the features that have not been ported to ARM API. You mentioned that you are using Azure Web APP, SQL Database, BLOB, and Azure Search Index. To the best of my knowledge, all of these are supported in ARM so the recommendation would be to use that instead of ASM. In fact, I think Azure Search is only supported via ARM and not ASM.
I can't find any information on which the currently advised library to use is.
However, a few weeks ago Simpler Azure Management Libraries for .NET was released into preview. It might be worth checking it out and keeping an eye on it for the future.
At the moment it seems only capable of managing Azure Virtual Machines, Virtual Machine Scale Sets, Storage, Networking, Resource Manager, Key Vault and Batch. However, since this is a preview, MS is asking developers to provide feedback and what they would like to see support next.
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
I have an application running on the Azure cloud.
Currently this is deployed as an Azure web app.
Is there any way to monitor the website status and build a page like this or this?
As you can see in those examples both have:
a service global status
An historical status which is grouped in hour/day/months period
Does azure has an API that I can use to monitor my services?
Application Insights and the Azure portal will give you a rich monitoring and diagnostics experience for your web app. It is in preview at this time.
You can get very granular data points or high-level graphs and trends. The historical data can go back as far as 13 months for aggregated data points. You can read more about the data retention policy here.
The Azure portal (the new one at portal.azure.com) gives you a rich UI to interact with the telemetry data from your app. And if you want to customize a blade to view specific data for your app you can do that too.
Azure Web Apps also has built-in monitoring support that you can use. It won't give you the depth that Application Insights does but you should look at this too to see if it will give you the data you need. And of course, you can customize the monitoring blades in the Azure portal to suit your needs.
Azure does offer a robust RESTFul API for managing and monitoring your services. Essentially anything you can do through the Azure Management Portal is accessible via an API, including analytics. The portal itself often uses this same API.
https://msdn.microsoft.com/en-us/library/azure/ee460799.aspx
You can also use MSFT authored .NET assemblies to create your own monitoring applications in Visual Studio. I find the monitoring and analytics features more robust via this model. These are available on GitHub:
http://azure.microsoft.com/en-us/updates/management-libraries-for-net-release-announcement/