48 votes12 comments · Azure Active Directory » Role-based Access Control · Flag idea as inappropriate… · Admin →
Just wanted to leave a quick update, we’re continuing to work on this feature and will share details in the near future.
/Stuart and Balaji
Support will be delivered for migration scenarios. In DR scenarios customer bandwidth requirement for delta replication and initial replication are similar. Hence not planned for DR scenarios
This feature is critically needed. My customer has one SQL Server VM with 17+ TB of disk and another with 8.5 TB with only a 1 Gbps uplink. We tried ASR protection but found that the storage array would run out of space, crashing the server. We would like to use ASR as the single solution for their entire DR, but large VMs like this make that impossible. Being able to seed huge VMs like this using offline replication could enable these scenarios.
We’ll do this
Customer-managed keys for Azure Storage is being deployed to Azure Government and is planned to be available in by the end of CY18Q2.
Thanks for your feedback.
This is currently under review.
We have delivered DR from Azure Stack to Azure. Please refer to this link https://docs.microsoft.com/en-us/azure/site-recovery/azure-stack-site-recovery.
DR from one Azure Stack to another Azure Stack will be delivered in future milestone
This feature is under review.
We are investigating adding Managed Disks to Azure Stack.
Azure AD B2B support is in progress and expected to be available in CY19Q2
This initial iteration of B2B is scoped to support only adding guests from other Azure Government tenants and not Azure commercial
This will be incredibly useful, too, when agencies share a single AD for identities. Say Department X owns the identities for itself and its sub-agencies. The sub agencies join their machines to Dept. X's domain and uses the identities from Dept. X's AD for access. Dept. X then synchronizes identities to their AAD tenant (such as for O365). If a sub-agency stands up their own Azure subscription and thus has their own AAD tenant, they would be unable to use their own identities in their own tenant without AAD B2B (because the identities live in another tenant). If they could add identities from Dept. X to their sub-agency AAD, then they could use SSO the same as they do on-premises. Otherwise, they'd have to use cloud-only accounts (and thus remember another login and password) or deploy a new AD that they sync. I'm currently trying to design a solution around this and am hitting a dead-end.
7 votesBrian “B” Laws shared this idea ·
Thanks. This is something we are likely to do in the future.
We have shipped a public preview of integration with AAD DS: https://azure.microsoft.com/blog/azure-active-directory-integration-for-smb-access-now-in-public-preview/
What we have in preview is a first step along a much larger roadmap for integration with AAD/AD for authentication and authorization. As the blog post says, this initial preview is really about Windows cloud VM access to the Azure file share with an AAD identity. Future refreshes to this feature will add non-Windows (Linux, macOS, etc) support, and the ability to mount the Azure file shares on-premises with your AAD identity. You can learn more about this in our Ignite session as well (at around 22:00): https://www.youtube.com/watch?v=GMzh2M66E9o
We’ll keep you updated on our progress. In the meantime, don’t hesitate to continue posting feedback on this feature below.
Program Manager, Azure Files
Being able to access Azure Files via a UNC would make the service vastly more useful. We could at that point use it like a traditional NAS for accessing common files and for automated processes. Like Eric said, non-interactive services are unable to access the Azure Files shares since they are unable to map the drive (that is, without a lot of complicated configuration). This would enable us to use it as a backup target for SQL Server, SharePoint, etc. Yes, SQL Server backups can write to an Azure Storage account, but this option is not available in Maintenance Plans (at least as of SQL 2012). We could abandon Maintenance Plans but that would require a higher level of complexity and management.