Opalis Automation Question

Re:Opalis Automation Question (jekri)

Thu, 26 Apr 2012 09:56:08 GMT

Hi James
I dont know if you still is need help with this issue, but if you do i will be happy to get you on the right track.
Since i dont know your application, the main question is if the stuff you need to do with the application can be scripted then yes orchestrator can automate the process.

Re:Opalis Automation Question (thompja1979)

Wed, 04 Jan 2012 19:50:31 GMT

Thank you so much for your reply. With all the various steps I wasn't sure if it could do it. No, it isn't required to auto login, I can get around that easily if I can automate the rest.

Re:Opalis Automation Question (jmattivi)

Tue, 03 Jan 2012 09:45:18 GMT

You should definitely be able to automate this through Orchestrator. SCOrch should stop/start the DB services as well if there's not any specific need for the DBA to manually interact with the services.

The only catch i can think of is the service account logging into AppServerName1. Is this required to stay logged in and locked at the console? I don't see a way of scripting this off hand, but there are other ways to specify an auto logon locally on the server rather than manually logging in.

There are plenty of blogs that show examples of using SCOrch/Opalis to automate patching clustered servers.

Re:Opalis Automation Question (thompja1979)

Mon, 02 Jan 2012 09:56:30 GMT

BUMP!

Opalis Automation Question (thompja1979)

Fri, 30 Dec 2011 14:02:23 GMT

Scenario: I have a Microsoft clustered environment that consists of a 2 server application cluster and a 2 server database cluster. Due to the way the application that resides on this server is written, I have to reboot the cluster in a certain order with multiple steps in between and after. I have pasted my steps below. My question is, can SCO automate this level of complexity? If not do you have any suggestions on making this a less manual process? Thx

Server Reboot Procedure (Production):
Log into AppServerName1 (or the active app cluster server)
            Stop workflow cluster group
            Stop AppName service
            Stop Application cluster group
Take down ABCware:
Go into Cluster Administrator
JOQCWorkflow Group/ ABCware Failover PRD1 – right click “Take Offline”
Go to Windows Task Manager/processes find EFG.exe
right click and “Kill Tree”
Contact DBA to stop DB services
Restart AppServerName1 – wait until no pings are returned
Restart DBServerName1
Wait until AppServerName1 and DBServerName1 are fully online (can log into it)
Restart AppServerName2 – wait until no pings are returned
Restart DBServerName2
Wait until AppServerName2 and DBServerName2 are fully online (can log into it)
Contact DBA to start DB services
Restart AppServerName3 and ABCServer1
Wait until ABCServer1 is fully online
Restart ABCServer2
Restart PrintServer1, PrintServer2, PrintServer3, and PrintServer4
Once those servers lose pings, start the ProdApp Workflow and Application cluster groups. This should be completed prior to those servers coming back online.
Bring up ABCware:
Start JOQCWorkflow Group/ ABCware Failover PRD1 (3-5 seconds)
Right click iProcessXYZ_prd1ProcessSentinels “Bring Online”
This could take up to 5 minutes or so.
Log into AppServerName1 as user and password xxxxxxx
Once those servers are online restart the HL7 service on each (Print Servers)
On each ProdApp server, kill the NamedProcessXYZ.EXE process
Restart the Vendor Rules Engine service on each ProdApp server
Restart any VendorName services that fail to launch on restart on all servers (Services.msc)
Particularly the OMS servers (Look at all services starting with Siemens listed as automatic)