Quick update: We reduced the entry point to partitioned collections by 75% to make it more cost effective for applications that need high storage but low throughput.
Please see https://azure.microsoft.com/en-us/blog/azure-documentdb-entry-point-for-partitioned-collections-now-75-cheaper/ for details, and email us at firstname.lastname@example.org for any questions.
We’re excited to announce that we are making this a lot easier with our preview of Autopilot. With Autopilot, Azure Cosmos DB will automatically manage and scale the RU/s of your containers based on the usage. This eliminates the need for custom scripting to change RU/s and makes it easier to handle bursty, unpredictable workloads.
You can try out Autopilot in your Cosmos accounts by going to the Azure Portal and enabling the feature in the “Preview Features” blade.
We are currently have on our road map this feature for Point-in-Time Restore (PITR) with continuous and on-demand backups. We will update the status here as this feature progresses.
Reopening this user voice item as our support for Skip/Take (Offset/Limit) was only limited to single partition queries.
The newly released .NET SDK v3 now includes support for x-partition queries using Offset/Limit. You can learn more about v3 SDK and try it and provide feedback on our github repo here.
We will also be back-porting this functionality to our .NET v2 SDK. This work will begin shortly and we anticipate it to be released in September.
Once that is released we will mark this feature as complete.
Thank you for your patience and votes.
11 votesJon shared this idea ·
Currently, you can use “App Registration” blade in the Azure Portal (outside of the Azure AD B2C blades) to register an apps that define application permission and the register apps that use client credentials to request these. The caveat is that this is done using the same mechanism that you’d use in regular Azure AD.
Ideally we’d have a first class experience for this in the Azure AD B2C blades or at least have an Azure doc that walks you through the experience I just summarized, so I’m leaving this feature ask open.
It would be great if you guys can add comments with your feedback. What scenarios areyou trying to achieve? Does the approach above help you achieve what you want to achieve? Does the experience to do so work for you guys and if not, what would you like to see?
Hey folks, thanks for the interest in this, and we have some good news to share. Configurable lockout is in development now (mostly done, actually) and we’re aiming for June or July public preview.
For configurable password complexity, length, etc, we hear you. Longer passwords are in planning now, and we’re thinking about our approach to how we want to enable the other configurability features. I don’t have any more details to share on this for now, but we do have interest in building features.
We are interested in enabling this scenario and are looking for more data.
- Would you want to be able to use this in conjunction with email or would you only be interested in one way to sign up accounts at a time?
- Would you like to be able to create the account without needing an email at all?
181 votes23 comments · Azure Active Directory » Self-Service Password Reset · Flag idea as inappropriate… · Admin →
Hi folks – apologies for the lack of updates here. This work is still in progress but unfortunately we don’t have an ETA that we can share yet. We will update as soon as we do. Thanks!
We have a sample for this use case here: https://github.com/azure-ad-b2c/samples/tree/master/policies/invite
Let us know what you think and if this fits your use case.
We have released the public preview for this feature! Learn more about how to use it here: https://docs.microsoft.com/azure/active-directory-b2c/active-directory-b2c-setup-oidc-azure-active-directory
We’ve put out a new version of the sign in policy called sign in v2. This is available through the new portal experience and we have rebranded policies as user flows. Please give this a try and give us feedback through this link: https://microsoft.qualtrics.com/jfe/form/SV_0Gu45RkBy2YR1kh
We have started the planning for this feature and hope to have a preview by the end of the calendar year. In the meantime, could you respond to email@example.com with the answers to the following questions:
- In which scenarios do you plan to force the user to change his/her password?
- What kind of information (if any) would you like to get back if the user goes through the reset flow?
- Do you currently or plan to track which users have reset their password?
Really need this, its a weird experience to have to use the sign in policy just for password resets.
Just a quick update. This is still on the roadmap, but not work that has started. The comments here are useful as we start the design. Thanks
Due to various technical limitations, the first iteration of the customer-owned domains functionality will not be available for a few more months. We will provide an update as soon as we can get a more specific ETA.
We continue evaluating several alternatives to provide full email customization. We are actively working on an alternative.
Unfortunately we do no yet have an ETA.
Thank you. We will examine the experience of duplicate sign ups across Identity providers. Would performing this check by using the email address be sufficient?
BTW, Linking multiple provider accounts to one user is in our roadmap and we’ve already achieved it in preview…
We look forward to your feedback
Can we get some more information from microsoft about this? Seems pretty standard to check based on email.
this feature is in public preview now. https://docs.microsoft.com/en-us/graph/api/resources/trustframeworkpolicy?view=graph-rest-beta.
We are working on managing policy keys programmatically.