Scenario


You are in the process of migrating from Exchange 2010 to Exchange 2013 and want to keep your email signatures during this process. 

Moreover you want to make sure that the mobile signatures work as well until all users have been migrated to the new Exchange server.


Solution


We assume that you have already a working Enterprise Setup with OWA signatures, mobile module and everything connecting to the settings database in a SQL box.


To achieve a parallel setup you need to have a second instance of your settings database. The settings database contains information about Exchange server version for OWA and mobile, which is unique for your setup.


To do so you need to prepare a new database and replicate the data from the existing up into this database. This is a common DBA task and we do not provide further information on how to do that.


Setting up the Admin to handle two settings databases


Important notice is that you need to maintain both databases in parallel during this phase. To do so you need to set up your administration interface to handle two databases. You do that by adding profiles. You can add up to 5 profiles.


Click the question mark in the upper right corner and select 'profiles' Now let's assume that you are connected with database #1 and you want to set up a profile to handle database #2. Just add a new profile and then add the connection string and write "database #2" or whatever you want to call it.

 


Now you can switch between the two databases. Please make sure you have populated the information from database #1 into database #2 otherwise it cannot connect.


Adding OWA information for database #2


For database #2 you need to change the OWA information. Make sure that you have created the necessary user on the new Exchange server so the setup is comparable You just need to add the authentication method if it has changed and also change the URL to the new OWA. Then save.


Set up a task to replicate the 'ldaUsers' table from database #1 to #2


When users run sign.exe they run against one of the databases. Therefore you need to replicate the content of the table 'lgdaUsers' from database #1 to database #2. Users who run sign.exe against database #1 will not appear in database #2 and hence we need to replicate them over. You can do this by creating a SQL job on your SQL server, which should be a common DBA task.


At this stage we make sure that the users who run sign.exe appear in database #2 as well. We now need to apply OWA and Mobile module for Exchange 2013.


Scheduling OWA to run on Exchange 2013 and install Mobile Module on Exchange 2013


You will now need to add the OWA schedule to your Exchange 2013. You cannot run signOWA on the same server as you do for writing the signatures to OWA 2010 so you need to schedule this to run on another server.


Export the whole registry entry for OWA including connection strings and usernames. Add it to another server where you want to run this from, and then change the settings database entry to the new database #2. It will then run against this database and now against the old database #2 where only information about Exchange 2010 sits.


Copy the signOWA files to the new server as well and run the file to make sure that it works. It will try to write the signatures to users who do not exist yet in this database, but just ignore the errors coming up. It will only update users who exist and use OWA 2013.


Now install the Mobile Module as instructed in another article. When you are instructed to copy in the connection string, please copy in the connection string to database #2. Then it will work just out of the box.


A few extra notes


Please be ware that this setup is very special and is likely to cause support issues and questions like "it does not work". It is very difficult for us to troubleshoot this setup as it is basically out of our control, so if you have support issues please include as much information as possible which makes the support process go smoother.


Also note that is a new signatures doesn't go through straight away, then remember your schedule by which you copy over users from lgdaUsers in database #1 to #2.