Operations Console Deployment Options

about the neurons for itsm operations console deployment options docid 3hv3oblc u4pkqxpp5vmloption oc1 separate configuration databases and application servers for production and development (best practice) docid 3hv3oblc u4pkqxpp5vmloption oc2 two configuration databases and separate application servers for each landscape (best practice) docid 3hv3oblc u4pkqxpp5vmloption oc3 separate configuration databases for each landscape (best practice) docid 3hv3oblc u4pkqxpp5vmloption oc4 one configuration database and one application server docid 3hv3oblc u4pkqxpp5vmloption oc5 one configuration database and separate application servers for each landscape docid 3hv3oblc u4pkqxpp5vml about the neurons for itsm operations console deployment options determine your database deployment options first in all of the operations console deployment options below, you can substitute any of the database deployments described in database deployment options docid\ ftnlmendkoje7cj72dzmt for the database deployments in the figure so for the database engine instance shown in option oc1 below, you could substitute option d1, option d2a, option d2b, option d3, and so on for that database engine instance to use the operations console, the production, staging, and uat application servers must all use the same version of when you test new versions of , either install the new version in a separate environment or plan the operations console pushes before testing the new version we recommend using a deployment that has either two or three configuration databases, such as option oc1, option oc2, or option oc3 option oc1 separate configuration databases and application servers for production and development (best practice) you only install the operations console on the staging/uat server do not install it on any other servers example of separate configuration databases and application servers for production and development option oc2 two configuration databases and separate application servers for each landscape (best practice) you only install the operations console on the staging server do not install it on any other servers example of two configuration databases and separate application servers for each landscape option oc3 separate configuration databases for each landscape (best practice) the only use case for this option is to upgrade the staging or uat landscape at different times you only install the operations console on the staging server do not install it on any other servers example of separate configuration databases for each landscape option oc4 one configuration database and one application server we do not recommend using this or any similar deployment that has only one configuration database that is used for ivantism, ivantism stg, and ivantism uat, unless you are setting up a demo environment the reason for this only being viable for demo environments is that this deployment prevents you from being able to test future upgrades on development tenants without forcing production to upgrade at the same time example of one configuration database and one application server option oc5 one configuration database and separate application servers for each landscape we do not recommend using this or any similar deployment that has only one configuration database that is used for ivantism, ivantism stg, and ivantism uat, unless you are setting up a demo environment the reason for this only being viable for demo environments is that this deployment prevents you from being able to test future upgrades on development tenants without forcing production to upgrade at the same time you only install the operations console on the staging server do not install it on any other servers example of one configuration database and separate application servers for each landscape