Unity 4.2(1) Upgrade to 7.0(2) Setup failed to Configure default settings

[brown.george]

Unity 4.2(1) UM with Exchange 2003 / 2007

Upgrade Unity 4.2(1)tp 7.0(2). Phase 1 of Unity Install seems to be running OK, end of installation I get the following errors;

Setup was unable to configure default settings on your system. To resolve, do the following.

1. Gather the following file from the server, where <account> is the account name of the user logged on to the server running the installation:

-\Document and Setting\<account>\Local Settings\Temp\tempu*.*

-\Document and Setting\<account>\Local Settings\Temp\SysCheck*.*

-\Document and Setting\<account>\Local Settings\Temp\AV*.*

-\Document and Setting\<account>\Local Settings\Temp\tempu*.*

-\Document and Setting\<account>\Local Settings\Temp\CommServer_*_*.*, including all subdirectories

-\CommServer\Logs\OsqlDump_*_*.txt

-\CommServer\Logs\Diag_Install_*_*.txt

-\CommServer\Logs\CfgCUApp_*_*.txt

2. Contact the Cisco Technical Assistance Center (TAC).

3. Wait for instructions from TAC before proceeding.

I have reloaded the server from scratch, and restored DiRT. I have attempted the u/g twice - same error.

I am using lastet version of DiRT, and DBWalker (runs clean).

SQL Server and Agent services use the system account.

Nothing appears bad in the tempu.log or the OSQLDump logs..

Suggestions please

[Jason Nash]

Perfect! My problem was the same cause! I can actually see the error in the OSQL logs regarding the collation issue now. I don't recall anything in the notes on this (unless I missed it), it would have been good if the original install had checked on this as it can be easily avoided.

As this is a small install it is using MSDE which does not give any options when installing, it just selected the collation based on the locale of the OS.

As I did not want to completely rebuild I found a workaround. I changed the locale of the OS to English (US) and then uninstalled and reinstalled MSDE, this then picked up the correct collation (SQL_Latin1_General_CP1_CI_AS). I then just restored the UnityDB (as the collation was Ok on this as it came from a DIRT backup of an old server), recreated the ReportDB and imported all of the users, jobs etc back in. Ran the install and all is working perfectly now.

Thanks for your assistance on this one.

[allan.fitzwater]

I have this same problem. Upgrading from 4.2 to 7.0 failed and the osql dumps show the collation problem. However my box has been built with english and english US. All dbases except the unitydb have the correct collation. Any ideas how I can overcome this? I can't see how rebuilding the box and then restoring the same Dirt backup will fix this, as the dirt restore will surely set the unitydb back to the "wrong" collation, causing the subsequant upgrade to fail again. Any ideas, much appreciated.

[brown.george]

Allan, it does!

A rebuild selecting the correct collation, then restore will fix the issue,

gmb

[allan.fitzwater]

Thanks George - can i confirm these steps.

uninstall unity and sql, then reinstall sql selecting a custom build using the parameters you have specified. Then restore my 4.2 dirt restore, then run the upgrade. If i already have the os built correctly, there seems no point in doing that again? Thanks again very much for the reply!

[brown.george]

Perfect

[allan.fitzwater]

HI George, this isn't going to work for me. My box is built correctly and up to the point of restoring the db via dirt, the collation is correct. After running the dirt restore, the collation changes. I'm possibly going to have to recreate the unitydb with the correct collation - but im not a sql person. Thanks for the replies, will let you know how it goes with support - case is open now.

[allan.fitzwater]

Just for completeness, I'd like to clarify some issues surrounding this problem. There seem to be several conditions that cause the same error message. My particular problem it seemed was a mismatch between the unitydb collation and the sql server default collation. NB you do not have to have sql_latin1_general for the upgrade to work. Think about it - unity is used in many countries and they would build sql server to their own requirements not US standard! Rather it seems you need to have matching collations, which makes sense. Seems obvious in hindsight. My original 4.0 server built in 2005 had been built with latin1_general_ci_as as the server / sql default and likewise the unitydb was the same when created. My 4.0 server was upgrade to 4.2 with no drama. Last year during a hardware refresh I built a server from scratch but left the US local on the server. When you then install sql on a box with the us local enabled (but not necessarily the default), sql server defaults to the sql_latin1_general_XX_XX_XX already mentioned in this conversation. Restoring the unitydb using DiRT threw up no problems and I've had a good working 4.2 unity server since last year. After trying to add some languages to our server at the end of last year I had the same error message as shown at the start of this thread caused by the schema version being in the sql server tables. HP support very kindly advised me to change the major and minor version to 3 and 17 respectively which then allowed the upgrade (installation of language packs) to succeed (thanks HP). I don't know how this problem came about, but their fix worked. Now if you see in your osql dumps, a message about schema versions being null or missing you can manually edit the server table and insert the correct major and minor version, then be confident your upgrade attempt will complete. If you see a message about collation mismatch / problems check your unitydb and sql server default are the same. If you need to change something, it really has to be the sql server default to match the unitydb as it is not so easy to change a db collation properly. Hope this helps others with similar probs - thanks George for putting me on the right track with your fix.