This Blog at the beginning will be a quick series of notes while I learn about Response Groups
Let’s say you have two central sites in your environment that are resilient. We’ll call them PoolA and PoolB.All of your response groups are created in PoolA but a user of that response group is homed in PoolB. The user in PoolB will still be able to fully participate in that response group as long as the services are running in PoolA.
If you change the right hand side of a user’s SIPURI, you will need to go into response groups and update the user’s info. The Response Groups are not smart enough to know about a SIPURI change.
In my environment i have 2 2013 sites that are paired. All of my response groups are in PoolA. If PoolA were to fail, Response Groups homed on PoolA will not failover if you simply failover to PoolB. NextHop does a great job describing what needs to be done. The short is you need to run
Export-CsRgsConfiguration -Source “service:ApplicationServer:PoolA.domain.com” -Filename C:\RGSEXport”.
Once you have this file, on poolB you need to run the reverse
Import-CsRgsConfiguration -Destination “service:ApplicationServer:PoolB.domain.com” -Filename C:\RGSEXport
Once Imported you can now failover to PoolB
Imagine you have a mail enabled security group that you use for securing NTFS shares and you choose to use this group as who is to receive response group phone calls. You lose all flexibility if you go down this route. Suppose you have an intern that you want to answer calls but not have the ability reach to secure files. Also imagine you want to separate who can answer phone calls and e-mails….you have to make a separate distribution list. What the technect articles doesn’t state is that you can create a distribution list, assign it an e-mail address but NOT mail enable the group.
This setup works perfect. Now you may want to make a naming convention. My organization is looking to name all Response Groups and Response Group Distribution lists that end in TeamLine@domain.com, TeamNumber@domain, GroupNumber@domain.com, GroupLine@domain.com. Or something along those lines just so we can keep actual e-mail distribution lists and response group (fake) distribution lists separated.
Doing it this way also separates the roles. I no longer need to delegate the help desk the ability to add users to response groups. In the description field of the distribution list i will put in the phone number so when a user calls in and says “please add me to the response group…..”, all the technician has to do is ask what is the phone number of your team line and then go to the OU where all response groups are created and add the user to the group.
If you are using a Distribution Group to populate your Lync Response groups, be ready to wait 8 hours before Lync will pull in the updated group memberships.
You can adjust the frequency of the response group AD Sync by updating the ocsappserver.exe.config file located in C:\Program Files\Microsoft Lync Server 2013\Application Host
As you can see in the above, I set our to 15 minutes (note if you have multiple Front Ends, you will need to do this on each). Once the config file is updated, you will need to recycle the Lync Response Group Service.
More to come……