Central IP Object usable for ALL Azure Resources

In this new feature (ex : Azure IP Object management) user can create IP Object (List of Ips or Subnet) this object can be added in any Azure Resources who have a Firewall (Azure SQL, Storage Account, WebApp,...)

For Exemple:
You create an Object "Company Public IPs" and you add in this object All your company Public IP.
In your Azure resources Firewall (WebApp, AzureDB, NSG,...) you specify this Object to allowing access.

If tomorrow you need to add a new public IP you just need to add this new public IP in your "Company Public IPs" Object and all resources link to this object will allow this new IP (cf: diagram)

Matthieu

We are using New-AzureRMSubscription to automatically create subscriptions. After creation we see that the Account Owner is made Service Administrator of each subscription that is created via this way.
There is a risk that, when the credentials of this account owner are confiscated, the attacker takes over control, as service administrator/ (service owner), of all the subscriptions.
This risk can be mitigated by having the possibility to assign a different identity as service administrator for each subscription created.
If we create such an subscription via the enterprise portal, we already have the possibility to assign a different identity as service administrator.
It wwould be of great importance to us when we also have the same possibility to specify a different identity as service administrator when using the API's.

Azure SQL Database is a major output resource for Data Factory(ADF) and Stream Analytics(SA), but these PaaS applications do not have a static IP address.
Therefore making it impossible to setup a robust Firewall configuration.
We understand that [Allow access to Azure services] is designed to handle this sort of situations, but it is way too loose from security point of view, since it allows access from all the resources on Azure including those are NOT owned by the users.
which is a risk and to achieve more secured environment, many customers demand for a more detailed firewall option, which will allow specific PaaS services level access to Azure SQL DB. 

We only have a execute stored procedure in ADFv2. But most of the time we don't want to create stored procedure for all of the primary ETL tasks, such as counting the no. of records from a table, Updating data into tables, creating tables, etc. There are many such activities need T-SQL Execution. It would be great if we have Execution SQL option.

ADFv2 have the option to use variety of RDBMS source and sink systems such as MySQL, Oracle, etc., . ESQL would be the powerful task to have in Azure Data Factory V2 to be used in all of the RDBMS source / sink systems, as SQL is compatible for all of them.

Some of the other points to have ESQL task is highlighted,

1. Stored procedures are not the effective object to understand, debug complex sql code written within. With E-SQL, a large complex SP could be split at many places in the ETL flow and graphically represented to easy understanding. - Graphical representation is the core feature for any ETL tool.

2. Version management - For example. A create table script could be placed on a blob storage. which can be used as a source for E-SQL task. This helps to manage the table object in terms of adding additional columns in future could be done from blob / file storage

3. When SSIS is rebuilt on Azure Data Factory (which is the ultimate goal for Azure Data Factory V2). ESQL is used quite commonly in SSIS. By having this in ADF, it helps for quicker development

Additional feature with E-SQL could be great is to use source and sink systems. For example, getting data from Oracle source system and which need to perform a lookup with SQL Sink, and load them back to SQL Sink. If we have the option on ESQL to use both source and sink. It would be more powerful.

Thanks and Regards,
Vijay

Even after performing a transfer for a subscription, though it is visible at https://account.windowsazure.com/Subscriptions, the included Resource Group, Database Server, and SQL Database that belong to it are not seen at https://portal.azure.com/#blade/HubsExtension/Resources/resourceType/Microsoft.Resources%2Fresources until you go and access the “Access control (IAM)” screen and individually add the new transfer user as both an Owner and as a Co-administrator for the Database Server (under All Resources). I suggest all this be automated! I thought these settings would have been taken care of (or inherited) automatically when we initially transferred the subscription, but I was wrong. We were down unnecessarily for a little while until we figured this out (unnecessarily because had the documentation been more clear or adamant that these steps take place we would have caught the issue earlier, and unnecessarily again because in fact I am beginning to think all this was only administrative virtual paperwork that really didn't impact the operational status of the database while we got it all sorted out--so we probably could have continued using it anyway). Immediately after making those changes, the missing resource group, database server and the database showed up in the transfer user's Azure Portal! Additionally, I had to manually change the SERVICE ADMINISTRATOR e-mail separately on the Subscriptions page. This was also not set automatically by the subscription transfer routine. These are important additional steps that are easy to miss on Microsoft’s write-up at https://docs.microsoft.com/en-us/azure/billing/billing-subscription-transfer because that page only hints at it. I don't see why these steps couldn't all be lumped into the subscription transfer process either as a wizard UI or in an automated batch process. FYI - I’ve documented my exploits at https://dba.stackexchange.com/questions/216708/azure-sql-server-database-error-18456-severity-14-state-1/216711#216711.