Joel

My feedback

  1. 192 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Data Factory  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  2. 67 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Networking » Application Gateway  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  3. 718 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    40 comments  ·  Data Factory  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  4. 65 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  SQL Managed Instance  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for the feedback.

    We assume that you are talking about ability to restore native backup (.bak files) taken from SQL MI to SQL Server 2017/2019.

    It’s a tough one unfortunately. Native backup contains binary data, and never been backwards compatible. E.g. you can’t restore backup from SQL 2012 on SQL 2008. Same logic applies here.

    SQL MI gets updates faster SQL Server, as soon we check-in code, it gets deployed with the next wave of updates on Azure. Same as SQL DB.
    Theoretically if you take backup of SQL MI now, and wait until SQL Server version release catch up, then you will be able to restore it.

    Can you please let us know what kind of issues with BACPAC you are encountering?

    Also, you can consider making transaction replication from SQL MI on on-prem as a way to move data around.

    Joel commented  · 

    While it is true that the DB Engine of SMI may be changing frequently...the Internal Database Version number should not be changing frequently. It would be extremely helpful if the Internal Database Version number used in SMI was coordinated with the latest Internal Database Version number used on the latest version of SQL Server On-Premise (or IaaS). This of tremendous value for folks that want to push forward into hybrid cloud, but are fearful of an inability to return back fully in tack. BACPAC and Replication are not solutions, they are half-baked work arounds. If they were solutions then there would be no need for backup to exist in SQL Server at all.

    Joel supported this idea  · 
  5. 40 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  (General Feedback) » azure.microsoft.com  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  6. 22 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Managed Instance  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  7. 27 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Managed Instance  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  8. 27 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  5 comments  ·  SQL Managed Instance  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  9. 66 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  SQL Managed Instance  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  10. 21 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Azure Analysis Services  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  11. 8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  API Management » Security  ·  Flag idea as inappropriate…  ·  Admin →
    Joel supported this idea  · 
  12. 14 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel supported this idea  · 
    Joel commented  · 

    This option is absolutely critical. The role level setting can be a default, but when the assignment occurs (i.e. when the role is paired with the user/group) you should be able to override the role default and allow some users to require approval (like a user that has the need say like once a quarter) vs a user that may have the need several times a day every day.

  13. 3 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel supported this idea  · 
  14. 2 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel supported this idea  · 
  15. 11 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel supported this idea  · 
  16. 61 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel commented  · 

    This is absolutely essential for large organizations. We manage the concept of group membership centrally via AD and shouldn't have to provide AAD User Access Administrator rights and training to individuals that are very comfortable living only in AD land. We also have existing Manager Access review procedures on top of AD and should not have to re-invent these for Azure AD. If Microsoft is thinking properly...any time a user can be assigned to anything, there should always be the option to assign a group of users to the same thing.

    Joel supported this idea  · 
  17. 3 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel commented  · 

    Making MFA a requirement vs a choice is not a good idea. For example, many organization federate their Azure AD authentication to a 3rd party provider like Okta for example. In such, cases, the organization may have already addressed MFA via their 3rd party authentication provider (perhaps even universally as a requirement for all users). Requiring a separate Azure MFA on top of the 3rd party MFA is just silly double MFA noise.

  18. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Service Bus  ·  Flag idea as inappropriate…  ·  Admin →
  19. 325 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    16 comments  ·  Networking » Network Security Groups  ·  Flag idea as inappropriate…  ·  Admin →
    Joel commented  · 

    Rody you said this was planned over 2 years ago. How is the progress coming?

    Joel supported this idea  · 
  20. 5 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Joel commented  · 

    An interesting caveat to this is when you have federated your AAD auth with another vendor such as Okta, for example. In this case, the MFA available from that 3rd party is ignored and AAD MFA becomes required. This creates an inconsistent and undesireable MFA experience require 2 separate MFAs to gain access. So while I can see that some would like a secondary MFA on PIM access, others of us would not. We should be able to fully turn off MFA in PIM if we so choose. Under current configuration, certain PIM roles are excluded from being able to not have MFA. Since we already have MFA, you are requiring us to have MFA twice.

← Previous 1

Feedback and Knowledge Base