Using Office 365 in Workflow Notification mailer in Test environments Configuration steps

Using Office 365 in Workflow Notification mailer in Test environments

Steps1- Configure the mail server and email sender

    1.      Login using ‘SYSADMIN user and go to responsibility 'System Administration' > Oracle     Applications Manager > Click on Workflow

   2.      Screen displayed as Notification mailer Down

 

   3.      Click on 'Service Components'

  

 4.      Select Workflow Notification Mailer and click on Edit.

   

Set the following parameters

   a)    Outbound EMail Account (SMTP)

Server Name: 'smtp.office365.com'

Username: 'mailer@Company.com'

Password: 'password'

Connection Security: 'STARTTLS'

        b)    Inbound EMail Account (IMAP)

Server Name: 'outlook.office365.com'

Username:'mailer@Company.com'

Password:'password'

Reply-To Address: 'mailer@Company.com'

Connection Security:'SSL/TLS'

         5.      Click on button 'Advanced'

          

         

          6.      Press 'Next'

   

    7.      Press 'Next'

               

      

          8.      Press 'Next'

             

      9.       Update from field to ‘Workflow Mailer Test Environment’ and click on finish.

         

      

          

           10.  Click on finish

       Steps2 - Configure the override address 

          Override email address is very imported in test environment. all the emails will be redirected to  this email. Following are the steps to set it up from back end.

      

          1.      Run the below sql statement

       SELECT fscv.parameter_value

       FROM fnd_svc_comp_params_tl fscp, fnd_svc_comp_param_vals fscv

       WHERE     fscp.display_name = 'Test Address'

       AND fscp.parameter_id = fscv.parameter_id; 

           

             Query will result with value     ‘NONE’ if override is not set earlier.

         2.      Now run the below sql update statement and commit

    UPDATE fnd_svc_comp_param_vals fscpv

    SET fscpv.PARAMETER_VALUE = 'erp.test02@company.com' --(Email        address to which all emails will be redirected)

    WHERE fscpv.parameter_id IN (SELECT fscp.parameter_id

    FROM fnd_svc_comp_params_tl fscp

    WHERE fscp.display_name = 'Test Address');

         3.      Now run the below SQL again to verify that the override email address has been set as required.

      SELECT fscv.parameter_value

      FROM fnd_svc_comp_params_tl fscp, fnd_svc_comp_param_vals fscv

      WHERE     fscp.display_name = 'Test Address'

    AND fscp.parameter_id = fscv.parameter_id;

           Query will result with value 'erp.test02@company.com'.

   4.      Start the workflow mailer from 'System Administration' > Oracle Applications Manager >  Click on Workflow

 Select Workflow Notification mailer and Click on   Select ‘Start’ from drop down list and Press on Go button. 

  



   5.      Workflow notification mailer should start and the status should be 'Running'.

      Steps3 - Test the setup

        

       1.      Click on 'Workflow Notification Mailer'.

       

  

  2.      Click on ‘Test Mailer’

        

       3.      Select user with email address set and click 'Accept' button.
Email address which has been set to  override will receive two email. 

      The emails should not be sent to the actual email address that is set for the user which selected above.

Now test environment has been configured to test workflow mailer server.

Read More

Veritas NetBackup OpsCenter upgrade

Veritas NetBackup OpsCenter upgrade

Pre-Checks:

1. OpsCenter should run on same version as Netbackup is running or should run on higher version. OpsCenter/OpsCenter Analytics must always be running the same or higher version.

2. Make sure that OpsCenter is compatible with Operating System and Netbackup.

3. OpsCenter should always run on a dedicated server and not on a NBU master

4. Ensure that all required ports are open on OpsCenter Server.

OpsCenter Port requirement:

Technote: https://www.veritas.com/support/en_US/article.100002391

Steps to Upgrade OpsCenter Analytics

1.    Backup OpsCenter Database

OpsCenter is shipped with a database backup script that performs backup of the database , the corresponding database password file, and the encryption key file without interrupting its operations, which is referred to as hot backup. On UNIX as well as Windows platforms, the script overwrites the existing database files before backing up or restoring them.

Note:

Regular file system backups are not sufficient for backing up the OpsCenter database. You must schedule periodic hot backups for the OpsCenter database to avoid losing any important data.

To back up the OpsCenter database

1. Log on to the OpsCenter database server host in one of the following ways:

Windows	As an administrator or user in the Administrator group
UNIX	root

2. Open the Windows command prompt or the UNIX console.
3. Run the backup script that is appropriate for your platform. Specify one of the following backup directories depending on your platform:

LINUX	/opt/SYMCOpsCenterServer/bin/dbbackup.sh /u01/backup/OpsCenter/

4. The backup script backs up the database files, database password files, and encryption key file in the backup directory that you specified.
5. Ensure the compatibility of the OpsCenter with the OS Version ad Bit.
6. Download OpsCenter installation file to the OS.
7. Run the installation and follow the process.

Note: OpsCenter should always run on a dedicated server and not on a NBU master

Documentation:

Backing up the OpsCenter database

Technote: https://www.veritas.com/support/en_US/doc/27537447-127427700-0/v28842080-127427700

Download OpsCenter:

Link: https://www.veritas.com/content/support/en_US/article.100019594.html 

How to Backup OpsCenter Database:

Link: https://www.veritas.com/support/en_US/doc/27537447-127427700-0/v28842080-127427700

Upgrading OpsCenter on UNIX

Use the following procedure to upgrade to OpsCenter software on UNIX hosts.
Note:

Veritas recommends that you do not cancel or interrupt the installation process once it is started.

To upgrade OpsCenter Server on UNIX

1. If you plan to upgrade your backup product and OpsCenter, ensure that you upgrade OpsCenter first. When upgrading OpsCenter, always upgrade the OpsCenter Server first followed by the Agent and then the View Builder.
2. Open a UNIX console and log on as root on the target host.
3. Mount the OpsCenter product DVD on the OpsCenter Server that you want to upgrade.
4. Untar OpsCenter_7.7_Unix.tar.gz
5. Cd /u01/share/soft/OpsCenter_7.7_Unix
6. Type the following command: ./install. Press Enter.
7. [root@em01 OpsCenter_7.7_Unix]# ./install

8. The Welcome message is displayed. Press Enter to continue.

9. The installer then checks if OpsCenter Server is installed on the system or not. It prompts you in case OpsCenter Server is already installed. The installer also examines the system for existing packages. 

10. The following prompt is displayed:

Where should the existing OpsCenter database and configuration files be backed up? 

An 'OpsCenterServer_backup' directory will be created within the directory that you specify to store these 

files. (/var/symantec/)

Type the directory name in which the existing OpsCenter database and configuration files can be saved and then press Enter.

To accept the default directory path (/var/symantec), press Enter.

11. The installer displays a list of components that will be installed or upgraded like PBX, OpsCenter Server, OpsCenter user interface and so on. Review this list and press Enter to continue.

12. The installer prompts you with the following question:

installOpsCenterServer is now ready to upgrade OPSCENTERSERVER.

Are you sure you want to upgrade OPSCENTERSERVER? [y,n,q] (y)

Press Enter to continue OpsCenter upgrade.

13. The installer prompts you with the following question:

Participate in the NetBackup Product Improvement program? [y,n,q] (y)

Press Enter if you want to participate in the NetBackup Product Improvement program or press n if you do not want to participate.

14. The installer prompts you with the following question:

Do you want to import users from <remote AT host name> to OpsCenter AT?

Press Enterto import users from the earlier OpsCenter versions.

For more details, refer to the About Importing Authentication Settings section.

If the import fails, you need to reset password of all OpsCenter(vx) users.

15. By default, in OpsCenter, the database is upgraded in the beginning. However, you can choose to first upgrade the OpsCenter software.

The database upgrade process starts. In this process, the OpsCenter data is migrated to the new OpsCenter database version. The database process may take time depending on your database size.

The following message is displayed:

The database upgrade is in progress. This may take some time based on the database size. You can see the progress and current status in /var/tmp/(directory)/db/log/dbManager_<timestamp>_.log file.

After complete installation, the logs are copied to the following location:/var/VRTS/install/logs/LogDirectory/db/log

LogDirectory is generated during the upgrade progress.

16. The installer displays the OpsCenter packages that are installed. Depending on the installed packages, the following message may be displayed:

The following packages were found on the system. However the package

versions are older than the ones required by OpsCenter.

VRTSOpsCenterServer existing version was found on the system, 

but OpsCenter requires VRTSOpsCenterServer new version

VRTSOpsCenterGUI existing version was found on the system, 

but OpsCenter requires VRTSOpsCenterGUI new version

VRTSOpsCenterLegacyServer existing version was found on the system, 

but OpsCenter requires VRTSOpsCenterLegacyServer new version

The installer then uninstalls the older packages and installs new version of OpsCenter Server.

17. OpsCenter Server is installed. Configuration changes are made to the system.
18. All the OpsCenter processes are started. The following information is also displayed:

o    Web URL to access OpsCenter console

o    Location of install log and summary files.

Note:

After successful upgrade, OpsCenter database password is set to an auto-generated string, if the earlier password is still the default one, that is 'SQL'. Veritas recommends that you change the database password after the installation.

If you had changed the default password in the earlier version, you do not need to change it again. The installer retains the old password that you can use in the current version.

Read More

Decommissioning a media server

Decommissioning Netbackup Media Server

Following information about is decommissioning a NetBackup media server.

Your path through the nbdecommission wizard depends on how you respond to the wizard prompts. Depending on your environment and how you respond to prompts, the wizard may advise you to perform an action and then exit. To continue in the wizard, you must run the wizard again after you perform the advised action. You may have to exit and rerun the wizard several times.

If active jobs exist on the media server, you must cancel them before the command can begin to decommission the media server. Alternatively, you can wait until they finish.

The OldServer does not have to be up and responsive.
Veritas recommends that you preview the media server references before you decommission a media server.

The nbdecommission command logs to the standard NetBackup administrator commands log directory.
Two procedures exist, as follows:
1. Replace an old media server with a new media server
2. Decommission a media server.

To replace an old media server with a new media server
1. Run the nbdecommission command on the master server or on a media server that is not the object of this operation. The following is the command syntax:

On Windows:
install_path\NetBackup\bin\admincmd\nbdecommission -oldserver OldServer [-newserver NewServer] [-file decom_ops.txt]

On UNIX:
/usr/openv/netbackup/bin/admincmd/nbdecommission -oldserver OldServer [-newserver NewServer] [-file decom_ops.txt]
Replace OldServer with the name of the host to be decommissioned.

-newserver is optional. If you specify a new server, the new server becomes the default media server for the replacement operations. If you do not specify a new server, the wizard prompts you for the new server for each storage type that contains valid backup images. This method is useful if you want to move backup images to different media servers. For example, you can move backup images from tape storage to one media server and backup images from disk storage to another media server.
-file is optional. It writes the command operations to the specified file. Replace decom_ops.txt with a name that denotes its purpose or contents. Veritas recommends that you use the -file option to maintain a record of the command operations.

2. Follow the prompts and perform the requested actions.
For example, the command may make changes on the master server and on multiple media servers. You may be required to restart the NetBackup services on those servers so that the changes take effect.

To decommission a media server
a) Run the following command on the master server or on a media server that is not the object of this operation. The OldServer does not have to be up and responsive.

On Windows:
install_path\NetBackup\bin\admincmd\nbdecommission -oldserver OldServer

On UNIX:
/usr/openv/netbackup/bin/admincmd/nbdecommission -oldserver OldServer
Replace OldServer with the name of the host to be decommissioned.

b) Follow the prompts and perform the requested actions.

Read More

bphdb exit status = 5449: The script is not approved for execution

Registering authorized locations used by a NetBackup database script-based policy

To add an authorized location

    Open a command prompt on the client.
    Use nbsetconfig to enter values for an authorized location. The client privileged user must run these commands.

On UNIX:
root@erpddb01:/usr/openv/netbackup/bin/nbsetconfig
nbsetconfig>DB_SCRIPT_PATH = /export/home/oraprod/scripts
nbsetconfig>DB_SCRIPT_PATH = /export/home/oraprod/scripts/rmanfull.daily
nbsetconfig>
<ctrl-D>

Reference: NetBackup Support Knowledge base

Read More

Oracle Home inventory is corrupted LsInventorySession failed: OracleHomeInventory

Oracle Home inventory is corrupted LsInventorySession failed: OracleHome Inventory

[oratest@slctest01 OPatch]$ opatch lsinventory

Oracle Interim Patch Installer version 11.2.0.3.3

Copyright (c) 2012, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/oracle/testdb/11.2.0

Central Inventory : /u01/oraInventory

   from           : /u01/oracle/testdb/11.2.0/oraInst.loc

OPatch version    : 11.2.0.3.3

OUI version       : 11.2.0.3.0

Log file location : /u01/oracle/testdb/11.2.0/cfgtoollogs/opatch/opatch2013-05-15_10-27-12AM_1.log

List of Homes on this system:

Inventory load failed... OPatch cannot load inventory for the given Oracle Home.

Possible causes are:

   Oracle Home dir. path does not exist in Central Inventory

   Oracle Home is a symbolic link

   Oracle Home inventory is corrupted

LsInventorySession failed: OracleHomeInventory gets null oracleHomeInfo

OPatch failed with error code 73

Solution

I was able to solve this issue; Follow the steps below:

 1. Login to the server.

 2. cd $ORACLE_HOME/oui/bin

 $ ./attachHome.sh

 Starting Oracle Universal Installer...

 Checking swap space: must be greater than 500 MB. Actual 196608 MB Passed

 Preparing to launch Oracle Universal Installer from /tmp/OraInstall2012-06-27_03-07-48AM. Please wait ...

 3. Re-run the same command and it is going to work.

 [oratest@slctest01 ~]$ opatch lsinventory

Read More

Issue with Robots Missing Path

  è To Check Robots with missing path

o   Java GUI

n  Under Media and Device Mgmt àUnder Devices àSelect Robots

o   Command

n  /usr/openv/volmgr/bin/tpconfig –d

80  Drive161   hcart3 TLD(6)  DRIVE=7             /dev/nst27                                                       UP

81  Drive162             hcart3 TLD(6)  DRIVE=8   /dev/nst28                                                       UP

82  Drive108             hcart3 TLD(6)  DRIVE=9   /dev/nst29                                                       UP

Currently defined robotics are:

  TLD(1)     robotic path = /dev/sg291

  TLD(3)     robotic path = /dev/sg76

  TLD(4)     robotic path = /dev/sg52

  TLD(5)     robotic path = /dev/sg98

  TLD(6)     robotic path = /dev/sg87

  TLD(7)     robotic path = /dev/sg74

EMM Server = usvhvoilms001

 or

/usr/openv/volmgr/bin/tpconfig -l

  èDelete the robot with missing path either java GUI or Command

o   Java GUI (Recommended)

n  Under Media and Device Mgmt àUnder Devices àSelect Robots àSelect the robot with missing path  àRight Click and Select Delete

o   Command

n  /usr/openv/volmgr/bin/tpconfig –delete  -robot <robot number>

  èRestart Media Manager processes.

  èIf received any error while deleting robot, please follow this steps

o   Please check any resource holding this robot using this command

n  /usr/openv/netbackup/bin/admincmd/nbrbutil –dump

n  If you see any resource holding this robot please use this command to release it nbrbutil -resetMediaServer <media server name>

or

nbrbutil -releaseMDS

nbrbutil -releaseMedia

  èCheck the robot at Operating System Level

o   /usr/openv/volmgr/bin/scan

o   /usr/openv/volmgr/bin/tpautoconf –r

o   cat /proc/scsi/scsi

If found robot at OS level, please run Device Config Wizard on Master server and rescan the devices on master server and follow the on screen steps to add the robot.

èRestart Media Manager processes.

  èTo Confirm Robot is added

o   Java GUI

n  Under Media and Device Mgmt àUnder Devices àSelect Robots

o   Command

n  /usr/openv/volmgr/bin/tpconfig –d or

/usr/openv/volmgr/bin/tpconfig -l

  èTo Test the robot

o   Use /usr/openv/volmgr/bin/robtest.

Read More