Moving around from client to client, I have one recurring job – installing Siebel Tools and the Siebel Web Client. I’ve done this dozens of times, with dozens of different Windows builds, and it always takes way longer than it should.
Siebel 6 Client and Tools were delivered using InstallShield, which just worked – and why wouldn’t it, those components have always been Windows only. OUI does try hard, bless it, but it always seems to be on the lookout for ways to make things difficult.
If the Siebel installation software is on a network drive, and you don’t have access to your local “Administrator” user, you may be used to the OUI “setup.bat” running for 30 seconds, unpacking a load of crap to your hidden AppData\Temp folder and then falling silent. I certainly am. It would seem that OUI likes to run elevated and hates running from a UNC path. Mapping a drive then running a CMD prompt as administrator doesn’t help, as Windows will not give Administrator access to your personally mapped drives.
Thanks to Winability.com, there’s a way around this. Add a simple DWORD registry key:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System/EnableLinkedConnections = 1
Reboot, map a drive to your Siebel installation folder. Run CMD as administrator, CD to your required installation folder and run setup.bat
I have, of course, downloaded the Siebel 15 distribution from Oracle Delivery Cloud – how could I resist? I’ve completed the installation on 64-bit Windows Server 2012 (note that R2 is also fully supported) and I thought I’d share with you my thoughts.
Siebel 15 Login Screen
Download and Installation
Very little, if anything, has changed with respect to download and install in Siebel 15, compared with IP2014. Expect the usual downloads, running of snic.bat and creation of installers. Running the installers themselves present no new features or issues – I did notice that both the Tools and Web Client installers ran quite slowly and the progress bars were completely wonky. I can live with that, though!
Having installed all of the base software without issue, I installed Oracle XE and set up a test database with data and index table spaces.
Setup and Configuration
As this was a new installation, I got back to basics and started with “grantusr.sql”. This hasn’t changed since 188.8.131.52 and it still does not GRANT QUOTA UNLIMITED on your index table space. A minor inconvenience, but I wish it were a standard part of the set up.
I still can’t get used to having to run the Gateway and Enterprise configuration tools first, before running the database setup. However, without the ODBC settings created by running those two steps, I was unable to connect to my XE instance within the database setup wizard. Having created a Gateway and Enterprise, I was then able to use the ODBC source (SBA_82_DSN) to kick off the database installation.
Database creation was very quick but there is still an issue with duplicate seed data. This has been an issue in previous releases and means that the creation process takes much longer than it should. It also makes reconciliation and genuine error identification and resolution almost impossible. However, once complete, all is well and I proceed to set up the Siebel Server.
Nothing new here to report – the option to “Enable OpenUI” is present, as it was in 184.108.40.206. I don’t see any specific Component Group for CRM composer, which is interesting; the new Composer bookshelf guide points you to the installation guide which contains nothing related to Composer. Hopefully that will change shortly and anyway, the SWSE CFG shows a new entry for “WebTools_enu” so I’m guessing it’s quite straightforward to get going.
It IS easy to get up and running!
Setting up the SWSE was as simple as it has ever been and, having created the profile, I quickly applied this to my Windows Server 2012 IIS instance and I’m ready to go. Don’t forget to explicitly enable ISAPI and 32-bit App Compatibility in IIS, or you’ll just see HTTP 500 errors the moment you try to access the SWE.
With all services started, I attempt to log into Sales and Public Sector OpenUI thin client with great success.
Stay tuned and thre’s a lot more to come on the new Synergy theme, enhancements in OpenUI and, of course, CRM Composer!
So, you’ll know by now that Oracle have ended their support for Siebel running on a 32-bit Windows platform. As of 220.127.116.11 (IP2014), Siebel Server components must be running on 64-bit Windows servers. The reasons for this are pretty clear, and the formal “End of Life” of Windows Server 2008 this January really was the final nail in the coffin.
However, that leaves customers running earlier releases on 32-bit Windows platforms with a bit of a quandary: if we upgrade to 18.104.22.168 (even from 22.214.171.124), we’ll need to upgrade our OS to 64-bit Windows.
This can be a big deal. I’ve worked on a programme which had 8 Production Siebel Servers, running a clustered Gateway and FS service, two load balanced OM servers, two workflow servers and two load balanced web servers. Add in dev, test, fix, pre production and we’re talking nearly 22 servers, all on Windows Server 2008. Microsoft do not support in place upgrading of 32-bit to 64-bit OS’s, so the clients only option to move to 126.96.36.199 is to build 22 new servers, re-install Siebel, and switch it all out. It’s complex, costly and time consuming – though virtualisation, and Oracle’s support of it in a Production Siebel site, helps matters no end. All this just to upgrade from 188.8.131.52 to 184.108.40.206.
So, I was wondering – are you in the process of working through this problem yourself? What are your thoughts on the matter? Is this preventing you from upgrading altogether?
I’ve put together a simple poll to tally responses, but please feel free to add comments to the post to explain what you’re doing in more detail.
UPDATE: As @lex points out, this is hinted at in the Installation Guide and referred to in the Siebel Security Guide:
NOTE: When you upgrade to the current release, the Siebel Server system service password, which is required to connect the Siebel Server to the Gateway Name Server, is automatically reencrypted using AES encryption. The Gateway Name Server Password parameter, which is set at the Siebel Enterprise level, is also automatically reencrypted. You do not have to reencrypt these passwords manually.
Shame the installation doesn’t seem to do either! 🙂
I reported last week that I had significant issues with the upgrade to IP2014: I ended up with an “un-startable” Siebel Server and yet another open Service Request (still unanswered, I might add).
One of my readers and valuable contributors, Lance, has done some investigation and has found the solution to this problem: a new encoding mechanism (AES instead of RC4) for the password component of the Windows Service / Linux daemon command line and SIEBNS.DAT has been implemented and is not updated correctly by the installation process.
I’m not even going to begin to rant about how disappointing this is in terms of Oracle’s failure to test their software – it’s a story I’m really quite tired of repeating. So, on with the solution.
Recreate the Siebel Server Service
Execute the following on the command line:
siebctl -S <Siebel Service Name> -d
siebctl -h <SiebelServerHome> -S <SiebelServiceName> -i <ServiceInstanceName> -a -g "-g <GatewayHost:GatewayPort> -e <Enterprise> -s <SiebelServer> -u <Username>" -e <Password>
This should update the ImagePath with the newly encoded password, allowing the Siebel Service to start.
Open a copy of your SIEBNS.DAT file in Notepad. Note down the encoded enterprise level Password parameter.
Run the following command line:
gpu -g <GatewayHost>:<GatewayPort> -e <Enterprise> -u <User> -p <EncodedPassword>
This should fix SIEBNS.DAT and allow all of your components to start.
Well, after my miserable attempt at upgrading 220.127.116.11 to 18.104.22.168 (which has left me with a completely unusable Siebel Server – more on that in a future post), I’ve downloaded and applied 22.214.171.124.1 – aka 126.96.36.199 PS1.
Download and creation of the installer is much the same as always, no dramas. SNIC seemed to take a bit longer than usual but I still ended up with the usual installation folders.
PS1 is an “opatch” installation and, though I used to hate opatch, it has grown on me. It’s actually really straight forward to apply after setting ORACLE_HOME and JAVA_HOME. Something deep inside me yearns for a UI front end to this though – too many years of being spoilt with InstallSheild.
Installation took a while and it looks like every file and binary has been shipped, not just those updated, which means pretty much everything is replaced. Hopefully that will cure my earlier SBL error but I have a gowning fear that this is because I’m still running 32-bit Windows. Oracle have always stated that 32-bit OS’s would soon be removed from support and it looks like the time has come. As I understand it, the Siebel dev team’s build environment has also moved to a 64-bit platform from 188.8.131.52 and onwards, so it would all make sense.
There’s a new version of the ActiveX control, which is a real pain for us. We just want rid of it altogether and it’s a real bind to deploy to our locked down client estate. Hopefully we will have fully deployed to OpenUI on 184.108.40.206 before we get to applying 220.127.116.11PS1.
As others have noticed, PS1 completely buggers up your CFG files – nice bit of testing there! This is easily remedied by copying the files back from the backup folder created by the original 18.104.22.168 installation process.
Having applied my PS1 updates, I’m still unable to start up the Siebel Server Service – same error as before. 🙁
Back to the drawing board and a Windows 2012 64-bit server, methinks! 🙂
UPDATE 28-Nov-14: Word from Oracle is that the “Merge Report” issues have been addressed in PS1. I’ll update further once that’s released and I’ve had a chance to test it.
I’ve finally had time to download the IP 2014 / 22.214.171.124 installation media and have a crack at applying it to my 126.96.36.199 Proof Of Concept (POC) environment.
Installation of the binaries was really straight forward and the new OUI installers really have improved since the old days of 188.8.131.52 and below. I had no problems whatsoever patching client and server components and the process was quick. I think Oracle may have tweaked the “backup” process that plagued 184.108.40.206 to 220.127.116.11, so all went well with this stage.
Executing IRM is once again as straight forward as running the Database Configuration wizard and selecting “Upgrade Database”. Don’t forget to download and install the Ancestor Repositories first though. I still encountered the same issue as 18.104.22.168 in that Siebel Tools prompted me to select a Repository when IRM had finished importing the 3 new Repositories. Oracle need to fix this as it makes an unsupervised installation impossible.
The merge itself took less than two hours, which was most unexpected. Oracle have stated that the volume of repository changes between 22.214.171.124 and 126.96.36.199 was far lower than with previous IRM’s but I was pleased with the performance of the merge.
However, I’ve been unable to continue the process past the new “Merge Report” step. This is failing for a number of (cryptic) reasons that required me to look into the MergeReport.jar file shipped in the Database Server “COMMON” folder:
- The process does some checks against your Windows OBDC settings and it does this using a hard coded repository path: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\
- If you are running Siebel on a 32-bit Windows Operating system, this will fail. I got around this by exporting my ODBC.INI registry settings, modifying the file and re importing. This is not supported, though, so don’t go trying this at home!
- The process creates some tables (S_MERGE_ALLDATA, for example) in the SIEBEL schema, but hard codes the tablespace name
- The process is hard coded to attempt to create these in the “DATA” tablespace of the Siebel user schema. In my environment, I call my table space SIEBEL_TAB so the process fails. The wizard accepts data and index table spaces as input so there’s no excuse for these to be hard coded. I’m currently looking for where I need to hack the correct values to get the process to complete but worked around this for now by doing a temporary “ALTER TABLESPACE RENAME TO”
- The process now fails with an error: “Error in SplitFile function1”
- I have no idea what this means or how to resolve it and I’m giving up! This new piece of functionality clearly hasn’t been tested properly and I’m not wasting another minute on it! 😉
So, another unfortunate experience with the process. I might just skip the Merge Report for now and let the upgrade finish so I can get on with the conflict resolution and compilation, but it’s frustrating to have to “bypass” one of the touted new features. If and when I find a solution, I’ll be sure to post.
Stay tuned for a first look at the new functionality and look and feel of the new UI and responsive theme – coming soon!