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. 

Currently there is no way to sepcify which storage replication is wanted when you create a Recovery Services Vault via ARM templates.

The default when spinning up a vault is GRS, and the only way to change it is to log into the portal and choose LRS before any backups have been applied.

The fact that the type of storage replication cannot be changed after a backup has been set does not help the situation.

This makes automating infrastrucutre builds painful as I have to login and change the setting in the portal before i am able to continue adding machines to the vault.

The documentation for the Vault is here:
https://docs.microsoft.com/en-us/azure/templates/microsoft.recoveryservices/vaults

If this is already available then please update the docs and the Quick start templates to include it!

If its not available then please add it to ARM!

Quick Start Template :
https://github.com/Azure/azure-quickstart-templates/tree/master/101-recovery-services-vault-create

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.