(English) Lync 2010 RegistrarDB and the mysterious 1603 error

I recently experienced a strange phenomenon during the installation of a Lync 2010 SBA.

First of all we don’t use the standard SBA installation wizard, we delete the existing SQL/Lync instances and start the installation from scratch.

So, we use the standard Lync Deployment wizard.
During step 2 of the Wizard, the script generated a 1603 exit code. The problem with this error, this can be anything 🙁

So I checked the “Add-Server.msi-RegistrarStore-[date/time].log”
As it turned out, it failed on the following line (click for readability):


I then checked the DbSetup.Wsf script. As it turns out, a lot is happening during the execution of this script. So on what function is the script failing?

I decided to run the following command in a cmd box in the ‘c:Program FilesCommon FilesMicrosoft Lync Server 2010DBSetup’:


The script (re)created the rtcdyn db and failed on the rtc db with the message that the schema version was incorrect and the current rtc should be removed first.

So I started SQL Management Studio, and deleted both rtc and rtcdyn (note, the Restrict Access setting on both db’s was ‘Restricted User’)

I then executed the dbsetup.wsf script again. It created rtcdyn and rtc and then failed on the DbReindex function. If you look at the DbReindex function in the script, this is executed:


I went back to SQL Management Studio and executed a DBCC CHECKDB on the rtc db, it failed with several errors. So corruption of the db?. That’s a bit strange if you consider that the same db is newly created.

I deleted both rtc and rtcdyn database, modified the DbSetup.wsf script; Global.Reindex = false, and executed the DbSetup.wsf script again. It passed this time, all other setting were successfully applied (rights on the db’s ect).

So, the DbSetup.wsf script creates the db’s, and somehow get corrupted.

I then realized that I shrunk the C partition and created 2 new partitions (Lync is on the 2nd part, SQL db’s on the first), the disk is a SSD…
I had the system perform a CheckDisk on all parts (errors were found!), started the Deployment Wizard, and voila it worked, the 1603 error was gone, the script completed without any errors.

Good old CheckDisk…..

Free subscription

You may also like...

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.