AudioCodes when deploying XUM give you a script that can create and manage the users.csv file. This script works great if you are not using Sfb for Enterprise Voice. So I had to do a work around for this. I guess you could also setup a different Hosted Voicemail Policy if in a mixed environment and filter off that, but I think that would get ugly down the road. Though in a large environment hitting AD and SfB in large bunches isn’t propbably the best. And I though about hitting Exchange Online as well, but that could be painful. I also tried doing one that just looked at the lastChanged attribute in SfB or in AD, but that isn’t reliable since it changes often as well. It would be so much better if they used some AD Attribute to do this. Though not LineURI unless they support an additional option, like ;XUM, or something like that.
The other issue with the default AudioCodes script is that it writes out to log files, and you have no history of anything. So my script writes what is going on to a an event log where it can be monitored and reported, and keeps a certain amount of hours or days of users.csv file in case you have to roll back.
At the end the best way to do this is just re-create the file on using a scheduled task (TBD). But here is the script, for those who like PowerShell. So there is a couple things on why the AudioCodes one will not work for us. It works great if you don’t have mixed users SfB and CUCM. However, we are mixed, so I had to find a way to filter out the users who are not using SfB Enterprise Voice. So they have to be enabled for SfB, their IPPhone field has to be greater than the number 20000 (our IPPhone range), and their lineURI contains ms-skip-rnl. Unfortunately to the other attributes the hostedvoicemailpolicy and hostedvoicemail are not contained in a LDAP lookup so I still have to get a csuser. Because if all those things are not right, then their voicemail will not work, so why bother adding it. Ideally I would go up to Office 365 as well and get their extensions attribute. But to do all those queries I think MS would see it as a threat and it would take much longer. I could also download the UMEnabled users and do a comparison, but at that point it is getting overly complicated. And yes, I had to do this via an LDAP Search because some of the attributes are not searchable in regular AD Filter.
To use this script in a test environment, you will need to add the following registry key (mind you that without installing XUM, you will see some errors in the event log message, but in production it will be clean. You need to run PowerShell with elevated permmisions
New-Item -Path HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Application\ -Name XUMConnector -force
Here is the file : XUM-users