Add filtering options for Get-CsCallQueue , Get-CsAutoAttendant and Get-MgUser to reduce runtimes

[zaaj]

Awesome visualization tool, thank you so much!

In large global organizations, there can be hundreds of call flows and tens of thousands of users. Get-CsAutoAttendant and Get-CscallQueue have -NameFilter options - adding a regional naming convention prefix (if the organization had the foresight to require such a convention) can drastically reduce the time to search for all flows to present in the out-gridview and to scan all flows for which ones a specified user is linked to.

I was able to add a static -NameFilter in the code, which brought Find-CallQueueAndAutoAttendantUserLinks for a UserID from over 20 minutes down to under a minute. Might be good to have a Get-MgUser search filter for that option when it's not fed a UserID as well - we have over 100,000 users, but any one region has many fewer users to have to manage. I never had the patience to find out how long that Out-GridView would take to fully populate. A config file to set such filters would be fine for our use-case, since we are not likely to need to review call flows or users in other regions of the world.

[mozziemozz]

Hi, thanks for the comment.

On auto attendants and call queues, linked AAs and CQs are referenced by the resource account object Id. In order to find the AA/CQ which has a particular RA object Id linked to it, I need to first get all AAs/CQs and then locally filter for the one which has the RA object Id in it's $_.ApplicationInstances. In earlier versions of the script, I used Get-CsAutoAttendant/CallQueue for each of these steps within the script which basically got all AAs/CQs multiple times/every time a nested AA/CQ was discovered which was bad for 2 reasons. 1: it was slow/inefficient and 2: Multiple people reported errors because they had more than 300 AAs/CQs.

Because of that, I changed the script logic and created the external function Get-AllVoiceAppsAndResourceAccounts. With this, all AAs, CQs and RAs are fetched at the beginning of the script and then stored in the respective variables, so they only need to be fetched once. I totally understand your thinking as I use regional naming conventions too. However, even if you have regional prefixes or suffixes which could be used in name filters, you can't with 100% certantiy say that all nested AAs/CQs use the same prefix. There could be global follow the sun call flows which use many/all prefixes or you could have a "global" AA which is linked to multiple regional call flows. (E.g. a final step/AA in which uses the same AA for all call flows). In that case, you would get errors because that particular AA is not present in $allAutoAttendants or $allCallQueues.

Let me think about this, maybe I can include a Name filter and only really fetch all AAs/CQs if there's a need for it/linked AAs/CQs are not present in the results of name filter.

Are you aware of the -CacheResults parameter? It's False by default but if you set it to True, it will only fetch all AAs,CQs,RAs once and keep them in global variables for the current PowerShell session.

I haven't really touched Find-CallQueueAndAutoAttendantUserLinks in a long time. I guess a name filter does make sense for large organizations but then again, you could also just use a UserId to avoid fetching all users. I'll also think about that and see what I can do.

I don't really have capacity to do anything right now so it might take me a couple of weeks/months.

[zaaj]

Thanks for the reply. I'm not in any hurry for any modifications, since I was able to put in the static name filter I need. As for a user filter, we have many different AD domains syncing to the same tenant, each with its own UPN suffix - that is followed since it takes an Enterprise admin to add additional suffixes to the on-premises forests, and we're apparently lucky none of those rare folks have added cross-region suffixes.

On our case, global Hq also requires the regional prefixes for object names to avoid cross-region conflicts.