Changing the SIP URI of an RGS Workflow

I had an issue the other day where we needed to change the SIP domain associated with most of the RGS Workflows within a deployment.

I assumed this would be pretty straightforward with Powershell (even though working with anything RGS related in Powershell sucks) but quickly discovered that you cannot.

If you open an existing Workflow in the editor you will notice that the URI field is grayed out.

This ended up being a fairly big deal as I had to change a large number of Workfows and some of them were rather complicated. Technically it would be possible to export the Workflows to a CSV or XML, delete the Workflows, and then re-import them with Powershell. But if you have ever tried to work with anything RGS-related in Powershell you know what a nightmare that would be.

I first found this post where he shows you how to do it by way of changing the entry in the SQL database directly and then updating the AD contact. I’m always terrified to modify anything within any of the Lync/SfB databases so I avoided that technique.

Instead I found a simpler solution that involves modifying an export of the RGS configuration and re-importing the modified one.

Step 1: Export All RGS Information

Open up Powershell from a server with admin tools and run the command

Export-CsRgsConfiguration -Source "" -FileName "C:\SomePath\"

Make sure to use the appropriate pool which hosts the Workflows which you want to modify.

Do not modify anything within the new;y created archive — keep it pristine in case you mess something up horribly and need to re-import it. Just copy and paste it again to make a copy. I renamed the copy I also renamed the original archive in order to keep everything straight.

Step 2: Find/Replace

I wanted to change to If I look in the RGS Configuration Tool I can see the SIP address


All of the properties of these Workflows are stored within an XML file in the export we got in the last step. Extract unzip the archive and go into the RgsImportExport folder


‘Workflows.xml’ is the file we will be changing. Open up that XML file in whichever text editor you prefer. The URI of the Workflow, or SIP address of it, has the tag of ‘PrimaryURI’. This is what we need to change.

I just did a ctrl+f and modified the value of the PrimaryURI


After making the edit, save the XML file and zip up the ‘RgsImportExport’ folder by just right-clicking it and doing a Send To ‘Compressed (zipped) folder. While the name of the .zip file you create does’t matter, the RgsImportExport folder MUST be in the level immediately underneath the .zip.


This will create a new .zip file which you will use in Step 4.

Step 3: Delete

Any of the Workflows which you edited must be deleted first. Do this when your Response Groups are not in use because this will briefly stop them.

You can either remove the Workflows by using the Workflow editor or by using Powershell. If for instance, I was had changed all workflows with the SIP domain to, I could use Powershell to delete all of those workflows like so

Get-CsRgsWorkflow | ? {$_.PrimaryURI -like "*"} | Remove-CsRgsWorkflow

Note: If you do not use the -Force switch with that command, it will ask you to confirm for any Workflows which are ‘Active’.

Step 4: Import

The final step is to import the  recently created zip (with the modified XML) into Skype for Business. Do this with the following command (again, keep in mind which pool this should live on):

Import-CsRgsConfiguration -Destination -FileName .\

After running this command, it will give you a summary of what you are importing and ask you to confirm. Keep in mind that this is importing the entire RGS configuration, not just importing your newly edited Workflow.


Now if I reload the RGS Configuration Tool I will see that the SIP address has indeed changed



This process is annoying and most of the time you will just want to re-create the Workflows when you need to change the URI. However, in some cases (like mine) that might be incredibly difficult to do.

When modifying Workflows in bulk it makes much more sense to just change them with Powershell. But since the URIs cannot be changed via Powershell, this seems to be a tolerable way to do just that.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s