09-12-2008 08:06 AM - edited 03-18-2019 09:37 PM
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
02-19-2009 09:21 AM
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.
07-11-2009 08:54 AM
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.
07-11-2009 09:03 AM
Allan, it does!
A rebuild selecting the correct collation, then restore will fix the issue,
gmb
07-11-2009 09:08 AM
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!
07-11-2009 09:48 AM
Perfect
07-13-2009 01:45 AM
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.
07-17-2009 10:10 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide