NOTE: What is suggested in this post is not supported by Microsoft.  I am typically leery of posting these types of solutions but it fixes a specific problem.  Use at your own risk!

So over the past seven days I have been ask either directly by customers, through e-mail, on the Microsoft forums or other avenues of how to reset a users default conference ID automatically. Typically when this request is happening it’s part of a larger issue.  Maybe you changed default SIP domains and removed the old domain.  Maybe you lost your file share and don’t have a backup to restore conferencing.  Whatever the case is, there may come a time you need to reset everyone’s ID’s because you lost conferencing.  I always find people willing to take a little more risk when something is broken beyond repair.

There is no out of the box solution for this.  Users can visit the dial-in page and manually reset the ID’s.  This works if you have a small problem but if you have lots of people it will become tiresome of support calls walking people through the process.

So what other option do you have? Before we get there, let’s look at where conferences are stored in database.  In Lync 2013 that is in the front-end server RTCLocal.  For 2010, that is in the back-end database instance.  For the remainder of this conversation we are looking at Lync 2013.

Going to your Lync 2013 RTCLocal SQL instance you will find three databases.  The one we are interested in is the RTC database.  Inside of that are two tables that are helpful – Resource and Conference. The resource table contains every user who has logged into that server.  Be it internal, external, partners, etc.  I’m starting here because I want to limit my testing.

So the first thing I need to do is find my resource ID.

SELECT * FROM resource WHERE userAtHost = ‘rbrynteson@avtex.com’

Here we can see 293 is my resource ID.

So now if I got to the conference table I can get back all of the conferences that are assigned to me:

Here we can see I have one static (or default conference) and two that are not.  So when I create a new conference I automatically get assigned the conference ID of CDBJ2FMZ.

So when the Outlook client requests a meeting (assuming you are using the default conference ID for meetings), that request is sent to Lync which sends it up to the server.  The server than looks into this table.  If the user has a static (default) conference assigned to them, then it will return that ID to the user.  If there is no static (default) conference, the system will generate a new conference ID, mark it as static and return that to the user.

So if I manually change static from True to False.  We see generating a new meeting request the table changes like the following:

My user has now been assigned a new static (default) conference because of this change.

So what is the end user experience for this?  The answer is it depends.  If the user has already requested a meeting the Outlook client will cache that information.  That is why the first time you request a new meeting each morning (assuming you close Outlook at night) it can take a few seconds but all other Lync meetings happen nearly instantly.  So here are the different scenarios I’ve tested:

Outlook Client Open (User has not yet requested a meeting today)
The outlook client will reach into the database, find there is no static ID and returns a new static ID to the user by generating a new record.

Outlook Client Open (User has requested a meeting today)
The outlook client will use the cached information and schedule the meeting using the old ID.

What happens when a person tries to join an existing (old) meeting?
Since you have not deleted the old conference, the system will behave like normal and allow you into the conference.  However, if you are doing this type of solution, most likely that old conference was broken and that is why you are doing this.

What happens if you modify the meeting with the old static ID in Outlook?
Outlook when opening the meeting will go and verify the state of the meeting.  Since Outlook believes it’s the “default” meeting it will prompt you that things have changed:

After clicking OK, the meeting will automatically update to the new static (default) conference and instruct the user to send an update to all participants.

Once you have tested this, you could make the change using a simple SQL Update Query.

Remember, this would never be considered the supported solution but occasionally you have to go outside the box to fix a very broken system.