I’ve spent as much time as I can this past week responding to reader questions. Still more to research though!
Today I wanted to blog about a curious problem one reader (I’ll call him “Tim”) ran into while managing his Lync Server 2013 server. When Tim removed a user from Lync, the user account lingered in their Response Groups.
Didn’t matter what method he used to remove the user account – through the GUI or PowerShell. Even if the user no longer existed in Active Directory, they still appeared in the Response Group member list. Like a ghost. (oooOOOoooo…)
What could cause this? Was Tim missing something when removing the user? Did he have to perform an additional step to remove a user from Lync AND from their Response Groups?
How to Remove a User Account in Lync Server 2013
Let’s back up a step. Here’s the official method for removing a user account from Lync Server 2013:
Remove a User Account from Lync Server 2013 – TechNet
(The process is the same in Skype for Business Server 2015.)
It does stand to reason that removing a user would automatically remove them from Response Groups. At the very least, it should deactivate them from the workflow.
I tested account removal on our own server, after adding a dummy account to one of our Response Groups. But the account vanished from the Response Group after I removed it. (It’s possible that the error didn’t occur because we use Skype for Business Server.)
I’ve no doubt Tim performed a correct user account removal. He’s just getting an unusual result. Why?
Why a User Account Lingers in Lync Response Groups
Asking the rest of our Lync/Skype4B team yielded no other encounters with this “ghost” error. So, to Google I went.
It took a while, but the research did bear some fruit. I came across the following TechNet Blogs post: Lync Server: Event 31137,31138 LS Response Group Service – UC Lobby @ TechNet
From what I can tell, the problem originates from the Lync user’s SIP address getting “stuck” in the Response Group Service. That’s how users are associated with a Response Group – through SIP addresses.
It appears that disabling or removing a user sometimes leaves a “ghost” of its SIP behind. If you see Warnings 31137 & 31138 in the Lync Server Front End logs, you have ghosts. This is a noted error in Lync 2013 – an inconsistent one, but it does happen.
How to Clean Out the Response Group “Ghosts”
Fortunately, there is a solution! The TechNet post references a script which should remove the “ghosts” from a Response Group. It’s located at the Greg in Sydney Blog:
Get-InvalidRgsAgents.ps1 – GreginSydney.com
From the script description:
“This script searches the Event Logs on the local Front-End server for the most recent instance of each error. It then extracts the SIP addresses, tests their current state and reports this information to screen. If you add one of the “-restore” or “-remove” switches, the script will take action to correct the situation.”
Greg has even provided the PowerShell script in a handy ZIP file for download.
Thanks to Greg and the TechNet team, we have a solution for these Response Group “ghosts”. Another reader question answered!
Have you encountered Response Group “ghosts?” Did you remove them, and if so, how? Please comment or email your thoughts.
I’d like to close this post asking for one thing more. Readers on Skype for Business Server: Do you use (or are planning to use) Video Interop Server, or VIS? If so, I’d like to talk with you about your VIS interest and/or experience. Please email me directly.
Have a fun Labor Day Weekend! And join us back here next week.