Wednesday, February 16, 2011

What preferred OS for Opalis?

Because that was a question in a PoC a couple of days ago…

Since version 6.3 Microsoft also supports Opalis running on Windows Server 2008 (32 and 64bit) and R2. So far so good…

However, I don’t recommend to install Opalis on these OS because of restrictions with some Foundation Objects and all (!) pre-6.3 Integration Packs.

You can check that in the list of requirements here:

http://technet.microsoft.com/en-us/library/gg440750.aspx

So I strongly recommend to use Windows Server 2003 R2 for any of your Opalis server roles. Of course you should be able to install the Management Server on W2k8 and the Action Servers on W2k3 and design your workflows on an additional machine instead of your MS but that does not make things easier.

All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

4 comments:

  1. Hey Patrick,

    I'd actually suggest running most all of your environment on win 2k8 r2 x64. The biggest bottleneck for Opalis environments pre 6.3 was the desktop heap size. Running in a 64 bit environment this alleviates this problem. Obviously we still have some legacy objects that will not work on a 64 bit os. To work around this we just spin up two action servers (2 for failover) and set all portions of the workflows that use the legacy objects to run on that pair of action servers. This is one reason why segmenting your workflows into smaller parts is very important.

    Furthermore, while the IPs written by MS / Opalis for pre 6.3 are not 'supported' on 64 bit OSes a number of them do work correctly (All QIK made IPs should for instance). As always you should test in your own environment and ymmv.

    As for the testing problem you probably should work towards testing by turning on logging on all policy (master and child) in a workflow and then triggering the master workflow from a trigger policy. This allievates a number of issues (the issue you pointed out as well as the fact that the testing console does not support running 'trigger' policies). Have a good one!

    ReplyDelete
  2. Hey Ryan (I guess)!

    Thanks for your valueable and welcome comment! Well, my blog was targeting to small environments without several action servers and distributed clients (that's because I wrote "does not make things easier"). Fair enough, ex post I did not explain that enough.
    However, I had some problems with pre-6.3 IPs that are solved in my lab since an installation based on W2k3. I do have my 2k8 environment too, so maybe I find time to test the major IPs and post a blog with the outcome.
    Thanks again, Patrick

    ReplyDelete
  3. Hey Patrick,
    Have you encountered any issues with the Junction object when using Windows 2k8 R2 SP1? In our environment when the junction object is used to bring two or more branches together, the junction object executes but does not wait for all branches to complete first. Testing the same workflow on a win2k3 SP2 32 bit box yields the desired results as the Junction object waits for all objects to complete prior to proceeding to the next object. Thanks for any thoughts that you may have.
    Regards,
    Russell Gomez
    Denver Health Hospital
    russell.gomez@dhha.org

    ReplyDelete
  4. Hello Russel!
    Honestly I haven't seen that issue because I'm not running on W2k8 any more. All of my installations are on W2k3 at the moment and so I do not have problems with the junction object.
    I'm going to set up a new machine because I'm in the Orchestrator TAP and therefore I need it anyway. If I find anything that is not under NDA I will share it with you.
    Cheers,
    Patrick

    ReplyDelete