How to manage and identify disabled csaduser and csuser objects to prevent UserPoolInuse and other Topology failures

I wanted to spend some time on a subject I once wrote about, but I didn’t make the article general enough to apply to other situations that may be useful. The following commands are guaranteed to benefit you, at some point. Below I have compiled a simple list of get commands that loosely describe user or device objects that are likely to be referenced by other Objects. What Is the value of this? Let me explain

Actually first lets introduce our lovely objects:

Get-Csuser

Get-CsExUmContact

Get-CsCommonAreaPhone

Get-CsAnalogDevice

Get-CsRGSWorkFlow

Get-CsDialInConferencingAccessNumber

Get-CsAudioTestServiceApplication

Get-CSTrustedApplicationEndpoint

Get-CsPersistentChatEndPoint

Don’t forget you can add > c:\myfile.txt to the end of any of these. The value of these commands is for Migrations and pre-migrations, General maintenance and housekeeping.

I presume if you are doing a migration, you will just run the disable form of the above cmdlets, and just move along. However if you have done that, and any one object in the 9 categories of user/device is disabled, you will find that your command succeeds, because the script returns no error, but later, topology wont publish when you try to delete a pool or any object. The error will be innocuous or vague to what you’re are doing. You may get a userpoolinfo error at best.

This alone is a great reason to keep these commands in a one note. But there are other reasons. Any time you are having to audit or move or deal with user objects, this list comes with some switches you can use to script down to exactly what you want to find. My purpose for keeping this list is to know how many disabled objects I have across my whole deployment. I can do this by just adding the following:

Get-Csuser | ft SipAddress,Registrarpool,enabled

Get-CsExUmContact | ft SipAddress,Registrarpool,enabled

Get-CsCommonAreaPhone | ft SipAddress,Registrarpool,enabled

Get-CsAnalogDevice | ft SipAddress,Registrarpool,enabled

Get-CsRGSWorkFlow | ft SipAddress,Registrarpool,enabled

Get-CsDialInConferencingAccessNumber | ft SipAddress,Registrarpool,enabled

Get-CsAudioTestServiceApplication| ft SipAddress,Registrarpool,enabled

Get-CSTrustedApplicationEndpoint | ft SipAddress,Registrarpool,enabled

Get-CsPersistentChatEndPoint | ft SipAddress,Registrarpool,enabled

Now I really get a decent report of how many total User/Device Objects, along with how many are enabled and disabled. This will be important information, if users are moving around a-lot, or If the pace of the company is fast. In addition, I just like to keep track of things. A PS script and a little elbow work, and this whole piece can be automated.

Get-CsUser | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsExUmContact | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsCommonAreaPhone | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsAnalogDevice | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsRGSWorkFlow | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsDialInConferencingAccessNumber | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsAudioTestServiceApplication | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CSTrustedApplicationEndpoint | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

Get-CsPersistentChatEndPoint | ?{ $_.Enabled -eq $false} | ft Name,Enabled,SipAddress -auto

To add more complexity to this mess, what if some of the AD accounts are disabled? Well guess what? The Lync objects are oblivious to that. If you disable-CsUser in bulk, you will likely get an error, but if you are busy and don’t pay attention, those errors are gone with the close of a window. There is no appearance of a show stopper until you go to publish that topology, when you are removing the pool. Then you get an error, unrelated to your actual action in real time. This is where I come into the picture. You call me and tell me you were publishing the topology, and all you were doing was removing the pool object. This case took 2 days before we finally go onto the idea, that the users were possibly at fault. So my recommendation is to just spend a few minutes and make sure your users have been maintained properly.

Now the AD problem. First Find out if you have any issues by running this command

Get-CsAdUser | ?{$_.UserAccountControl -match “AccountDisabled” -and $_.Enabled -eq $true} | ft Name,Enabled,SipAddress -auto

Then Run this command to disable those Lync\SFB users who don’t work because their AD Account is disabled. These users don’t show up in problem logs and will cause your larger deployment commands to fail. It is good to see these users get disabled.

Get-CsAdUser | ?{$_.UserAccountControl -match “AccountDisabled” -and $_.Enabled -eq$true} | Disable-CsUser

The beauty of these last commands is you can use them for the other user\device objects with some possible tweaking. I can’t say you can substitute the exact same Syntax, but with a little mental thought into what you are doing, you can make the logic work for any user/device object.

You can disable or set to false, any Lync object. Remember that when you run into issues with users stopping you from changing larger logical objects like gateways, pools, trunks, policies, etc.. The same kind of logic will always apply. You can’t delete a trunk from topology builder if you are using that trunk in Lync Control panel. You can’t delete a dial plan if that dial plan is used by a usage or a policy.

I may document these other situations in the future, but for now you have the user situation figured out. This pertains to OCS to Lync and Lync to Skype for Business.

For those who are looking for more on CsAdUser here is a very nice detail blog on those specific command types.

I hope this helps with your management, maintenance and daily work on Lync and Skype for Business.

Thanks,

Louis

Advertisement