[Feature request] Stop AAD Query in GUI?

[JRRW]

Is there a way to stop the 'add objects' from populating a list (I assume it's querying Azure Active Directory and waiting for the responses) until you've put a user into the query field?

For organizations of a certain size, it's tedious waiting for it to load 2,000+ objects, instead of letting us type the name or part of a name and letting it then return only those results.

We automate most of this with PS, and are working on automating more, but for testing and trial/manual adjustments it's a huge waste of time waiting 40s for the list to populate. This is on solid hardware, and a synchronous 1Gb ISP, so the bottleneck is either Azure or just the GUI handling the population of that many objects.

Same on doing a restore, waiting for the entire GUI to populate takes a fair amount of time.


If not, it'd be a feature request I'd certainly make.

[Mike Resseler]

Hey Ryan,

FR is noted. But we are also thinking on caching this after the first query. Because even if you would type in a name, the 40s will still remain there I'm afraid. We still need to query everything

[JRRW]

Morning/Afternoon Mike,

So the GUI load is not the slow down, but the actual query against AAD - that does pose an inherent delay.

Though there's something to be said about UX - if it let me put in a user/upn (partial or otherwise) and had to wait for that query, I probably would get less impatient knowing that I'm waiting for that specific query, vs waiting for (the same query) to populate the UI with every person and 'filter' by the user/text I specify.

The word 'search' in the display field lead me to believe it was doing an additional search against AAD AFTER it searched/queried the entire list - when it sounds like it's actually not 'searching' but filtering out the results it already pulled.

Of course, if you use a cache that means the UI would need a 'refresh' option, as if you're adding a new user that hasn't been queried since VBO last updated the cache.


The joys of coding around the needs and pitfalls of UX =) - fix one thing and cause another issue, all while juggling workflow 'feels' vs actual actions. Filtering the AAD query likely takes only 1-2 seconds longer than if it searched for exactly what I wanted, but impatient me makes that feel like hours



Thanks for the insight; I might just write a script to handle one off adds, as I'll already know their UPN - then it's just feeding the UPN to the job and associating the same backed up or excluded objects as the other users in the job.

Though this is mostly for testing/one offs, as really we'd rather just let O365 Dynamic Groups populate/feed 99% of VBO eventually.

[Polina]

Hi Ryan,

You are right, search now simply filters the results. And since objects are populated one by one, it can help to speed up a bit and get the needed object immediately when it's received from AAD. However, as Mike said, looking at the larger tenants we clearly understand the need to optimize the enumeration.

And, btw, you already can 'refresh' the list with a green button in the upper right corner.

Thanks!

[JRRW]

May I still blame Mike for not foreseeing every possible UX request in advance?

Thank you both for the information! Completely logical, I look forward to future enhancements =)