05-18-2001 04:51 AM - edited 03-12-2019 11:33 AM
While I was upgrading from 2.4.5 to 2.4.6, I received the following warning: "Setup was unable to configure default settings on your system. You may continue the setup process and configure the system manually. Do you want to continue?" Is there a procedure for the manual configuration? Also, any ideas on why the automated configuration could not take place?<br><br>
05-18-2001 09:50 AM
Please contact the Cisco TAC on this issue. They will provide you with the information for running the default scripts by hand.
05-20-2001 11:21 AM
Anils right, the thing to do is to call TAC and get some help. But since I get asked about this type of thing a lot, Ill outline the procedure for running the configuration manually below and try to give you an idea of whats going on. This is going to be kinda long and rambling
There are a number of reasons why it would bail out on you, the configuration scripts are pretty fragile and if anything returns an error it pulls the rip cord entirely instead of logging the error and pressing ahead. This can be annoying but in some cases later scripts are relying on objects created/modified by earlier scripts and if you just put your head down and barrel ahead you can easily get a snowball effect and get your system in a really funky state that would be hard to recover from. As such, when an error (any error) is encountered with any of the basic scripts, youll get that error. Ive seen this happen due to previous aborted installs, someone removing an object that should not have been removed (i.e. the Operator call handler or the Unaddressed messaged distribution list for instance) and then the upgrade scripts will choke looking for them etc
lots of things can go wrong.
In your case, however, there should be no DCS scripts run during a 2.4.5 to 2.4.6 upgrade since no new objects/properties were added or changed between those two versions. Ill have to check with the install folks in the morning to see what might be going on there. Was your system functional after a reboot or not?
Unfortunately the TEMPU.LOG file created by setup isnt going to tell you a whole lot about WHY the scripts failed, just that there was an error and it aborted and that the user chose to continue or not (you should always choose to continue since in most cases its an easy problem to correct/work around). Running the configuration scripts manually with traces turned on (which is done for you automatically) will kick out diagnostic information which should point you at exactly which step in the configuration process is failing.
To run the configuration scripts manually, you need to use the ConfigMgr.EXE tool found under the Commserver directory. When you run it, itll pop up a dialog with 4 radio buttons on it and a browse button to go select the scripts to run. The trick to running ConfigMgr is to know which scripts need to be run in your situation (which is why we normally fall back and punt to TAC on this), but in your case its easy. Ill lay out the 4 basic scenarios here:
Doing a new install
You need to run 3 configuration scripts if you get this message during a brand new install. In most cases Ive seen these have failed because it wasnt a real band new install, it was a case of someone trying to clean the system out (improperly) and do a new install over it. The new install scripts dont deal well with objects/properties left around it doesnt expect.
First, choose the Run DOH configuration script radio button, browse to \Commserver\Localize\DefaultConfiguration\ENU and choose the ENU_ENU_DefaultDatabase.DCS script file (assuming youre installing a US English Unity onto a US English NT system). Leave the checkbox on for diagnostics (the 10, 11, 12 thing in the lower left) and hit the run button. The snappy little armadillo will hop around for a while as it runs. If it fails you can select the view diagnostic log button at the bottom
Just sort the resulting file search box by date and choose the most recent diag_xxxx file. It should show you what went wrong (but in some cases it may not
the logging isnt always very robust).
If that goes through, run the Rules Configuration Script and choose ENU_ENU_DefaultRules.DCS
If that goes through, run the Schedule Configuration Script and choose ENU_ENU_DefaultSchedules.dcs
Upgrading from 2.4.5 to 2.4.6
This isnt running any of the DCS scripts since theres nothing that needs to be added/changed here. No new properties or objects were added between those two versions. If youre getting that installation error, the only reason I can think of is the setup is thinking its a new install instead of an upgrade for some reason. Getting a look at the TEMPU.LOG might help give us a clue as to whats happening here.
Upgrading from 2.4.0 to 2.4.6
You need to run two DOH configuration scripts here:
UpgradeDatabase_002.dcs this adds the systemEventMessages public DL (which isnt used by anything at this point since GAEN is disabled by default).
UpgradeDatabase_003.dcs this adds a unique string onto the ends of the aliases for the UnaddressedMessages and UnaddressedFaxes public distribution lists. This was done to resolve a problem with multiple Unity serves in the same site sharing these DLs which was undesirable. In some cases these DLs will be missing or may have been modified by another Unity server in the site etc
and the script doesnt find them based on the aliases it wants to. Thus it fails. This isnt a big deal, actually, and your system should still have come up OK after a reboot.
Upgrading from 2.3.x to 2.4.6
You need to run all 3 DOH upgrade scripts for this one:
UpgradeDatabase_001.dcs this does a bunch of things including adding new properties on every mail user in the directory (i.e. the new notification devices added between 2.3.6 and 2.4.0 among other things) and it can take quite a while to run if you have a lot of users.
UpgradeDatabase_002.dcs mentioned above
UpgradeDatabase_003.dcs also mentioned above.
As I mentioned, I'll look into what configuration errors might come up during a 2.4.5 to 2.4.6 upgrade in the morning and I'll post a follow up to this here.
Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
09-20-2001 02:17 AM
I am getting this same error during a new install. Is there some recent info or should I still contact TAC?
09-20-2001 02:17 AM
new installs throwing these error usually come from objects left in the directory that the installation scripts are not expecting to find. For instance the default distribution lists (AllSubscirbers, UnaddressedMessages etc...) or the default mail users. If you make sure your directory is completely clean of these you shouldn't see these messages. This is the problem 90% of the time on new installs... upgrades are a different matter.
Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
09-24-2001 12:05 AM
TAC sent me a procedure on how to run the upgrade scripts manually so they would probably do the same with you. I don't remember if I experienced any problems running them. Good luck.
09-24-2001 12:05 AM
Going on 3 days now and TAC NO HELP. Anybody here capable of some help?
09-24-2001 12:05 AM
Here's a post with some details on how to run the ConfigMgr application stand alone... just follow the instructions for a new install in there:
http://avforums.isomedia.com/cgi-bin/showthreaded.pl?Cat=&Board=unityent&Number=2657&Search=true&Forum=All_Forums&Words=ConfigMgr&Match=Entire Phrase&Searchpage=0&Limit=100&Old=1year&Main=2634
By far and away the most common issue I see here is folks doing an install into a site where they previously had a Unity server installed and they left one or more objects in the directory (i.e. a distribution list) and the new install balks and overwriting it (we error on the side of caution here).
If running the configuration manager manually still fails out, there should be some information in the diagnostic file (there's a button there to view the diagnostic output on the ConfigMgr application itself). Near the bottom of the log it should kick out the script failure that caused it to bail out and that might gives us some clues as to what's going on.
Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
09-24-2001 12:05 AM
Jeff - I did this already and gave the information to TAC. I will post it again here and maybe you can look it over and give some clues.
2001-09-24 13:09:49 (AvLogMgrSvr_MC,10007,diag file opened,) LOGMGR OPENDIAGFILE
13:09:49:147 (AvLogMgrSvr_MC,10001,-1,-1) LOGMGR INITIALIZE
13:09:49:148 (AvLogMgrSvr_MC,10002,-1,-1) LOGMGR RUN
13:10:06:569 (AvSystemConfig_MC,1098,SystemConfig,10) Failed to log onto the Doh.
09-24-2001 12:05 AM
Hmmm... not a lot to go on there... lots of reasons why the DOH login would fail. Presumably you're permissions are setup correctly for the account you're logged in as or the initial installation wouldn't have gotten that far. You can double check by running SysCheckPreinstall off the installation CDs, but I'm doubting this is your problem.
Here's a couple of things to try:
1. delete the "Unity Messaging System -
2. If that doesn't work, turn on some DOH traces using MaestroTools and run the ConfigMgr again. This will kick out more detailed information on the DOH login process and where it might have bombed out. You'll find MaestroTools.exe under the \commserver directory, fire it up and go to the "Diagnostic Grid RegEdit" tab. On there select the following traces to enable:
AlCommon #10 (error)
DalEx #10
DOH #10
MalEX #10
once you've done this, fire up the ConfigMgr again and grab the diagnostic file. This time there should be more details on the DOH login process (more specifically, where it failed and why).
Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
09-24-2001 12:05 AM
Here is the latest traces using the Maestro tools -
2001-09-24 14:58:20 (AvLogMgrSvr_MC,10007,diag file opened,) LOGMGR OPENDIAGFILE
14:58:20:630 (AvLogMgrSvr_MC,10001,-1,-1) LOGMGR INITIALIZE
14:58:20:631 (AvLogMgrSvr_MC,10002,-1,-1) LOGMGR RUN
14:58:37:989 (AlCommon_MC,30000,AlCommon,10) Error in CAvMALExSession::Logon - Create Failed - File: h:\CommSvr\Sources\mal\MALEx\AvMALExSession.cpp Line: 1394 Error: Class does not support aggregation (or class object is remote) Thread: 000008C0H Instance: 0132EE68H
14:58:37:990 **NOT FORMATTED**,AlCommon_MC,32013,-1,-1,AlCommon,10,CAvDohSession,LogonMal, ,h:\CommSvr\Sources\doh\SrcCache\AvDohSession.cpp,1337,800404B5H,000008C0H,01325BD0H
14:58:37:989 (AvSystemConfig_MC,1098,SystemConfig,10) Failed to log onto the Doh.
14:58:37:990 (AlCommon_MC,30000,AlCommon,10) Error in CAvDohSession::Logoff - Not Logged in Failed - File: h:\CommSvr\Sources\doh\SrcCache\AvDohSession.cpp Line: 1586 Error: 80043000H Thread: 000005E8H Instance: 01325BD0H
09-24-2001 12:16 AM
A DOH engineer will need to lookup those specific lines of code but it's definitely failing logging into the messaging access layer (the MAL... as oppsed to the Directory Access Layer... the DAL) which is where the message profile I mentioned in the previous post comes into play.
Did you remove the account and message profile I mentioned and reboot before attempting this? Did you run SysCheckPreinstall on the account you're logged in as? If not, you definitely want to try that. I know the instinct is to assume that can't be it but I've worked on a number of tickets where a permission was removed upstream without the installer knowing it. With Win2K this is a frequent issue.
If it's not related to either of those you have something uglier down further in your Exchange configuration that's tripping us up while trying to gain access to it...
Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
09-24-2001 12:18 AM
So do I go through TAC for a DOH engineer? And where can I find the syscheckpreinstall? on the Unity disk?
09-24-2001 12:53 AM
SysCheckPreinstall is on CD #1 of your installation set. I believe it's in a directory called "SysCheckPreinstall" but it's moved around between versions... look around, it's on there. You need to run this, not SysCheck since SysCheck will attempt to bind to the DOH which will fail in this case. The PreInstall version simply checks all the permissions/rights of the logged in account.
Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
09-27-2001 07:03 AM
PROBLEM SOLVED!!!
As it turns out outlook was not creating the profile for Unity. Engineer did this manually and everything is working now. Were still going to wait another week for 3.0 to be released and upgrade to it, saving us from having to do it later.
Also the original problem of some not showing up when importing into Unity...Rich Text needs to be added to these accounts and then they will appear in Unity. I think this problem needs to address or aleast a document about this on CCO. I we would have know this little "trick" we would have never had to re-install everything to begin with.
Thanks everyone for the help!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: