Hi,
We have three laptops, one as an Application Server and the other two as Job Servers. They are all Windows 2003 Service Pack 2.
One Job server adds fine and the other (with exactly the same setup) doesn't.
If we try to connect via HTTP then Contributor either freezes (after Remote Test Successful) or comes back with an error:
Unable to execute EAdminUI_73.frmJobServerProperties.cmdAdd_Click
Server did not respond in the time allowed.
Internet Client Error: Request Timeout.
At line 240
If i try to connect with Com i get the error message:
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
Thanks,
Steve
Try to add datastore with user\password, not with trusted signon. You should use COM, it more reliable.
And see this (http://ykud.com/blog/?p=94) for initial settings, it might help.
Thank you for this post, useful information.
My only question though is what you say about COM being more reliable. Do you know if Cognos are changing anything in 8.2 to http as COM is going?
Yep, with over 8.2 version do http(s).
"UI_73" got me puzzled as usual, I assumed you were on 7.3.
Cognos devs don't change internal procedure names, I've seen it a lot of times, but still can't get used to it.
In Cognos Planning 8.2 and higher the archirecture changed in the following parts:
- com+ package moved to the java stack
- asp pages converted to html
- upfront like portal moved into cognos connection.
- validation now fully integrated into Cognos 8.
What did not/hardly change:
- CAC same
- Analyst same
- Active-X based client same.
As for the jobserver configuration, instability is casued by:
- Communication set to com instead of http (sorry ykud)
- When on oracle, client on jobserver to to onames/ldap instead of tnsnames
- When on oracle 9i, oraoledb.dll on jobserver not patched to 9.2.0.4.1
- When jobserver uses older processor, make sure if it uses hyperthreading that this is disabled in the bios.
General configuration for multiple jobservers:
1. Use the same username and password for the PLANNING73 com+ identity on all jobservers.
2. Make sure that this account is a member of the local admin group on every jobserver.
3. Make sure that the NT service for planning is running on this same account.
4. Make sure that the MSADC virtual directory exists and that the msadcs.dll is an allowed webserver extention on every jobserver.
When even a com+ call fails with an error like in your case, i would suggest to reinstall the software.
A com+ should always work. http is better. (com traffic tunneled over http is more stable at bigger jobs. with pure com+, saturation can act up earlier, resulting in job failliure at 99%)
Database client tools are installed to all the servers (in particular native client driver for SQL2005)?
If Trusted connection, the service account has permissions into SQL Server? COM message suggests you may have database connectivity issues and not IIS setup issues.
2 dutchcogtechie:
Gee, thanks for lots of info.
Any expectations of planning job servers becoming platform-independent since it's java already? I suspect J is pretty portable.
Quote from: dutchcogtechie on 31 Jan 2008 03:39:12 AM
- Communication set to com instead of http (sorry ykud)
I've stuck with Com since Adaytum 3.0 just because http really didn't work reliable at that time. Later test on 7.1 showed the same thing. So it moved on... Call it "conservatism" ;)