Navigating Multi-Factor Authentication (MFA) for Oracle Cloud Infrastructure (OCI) - A Guide for Customers

 Introduction:

As part of its ongoing commitment to enhancing security measures, Oracle Cloud Infrastructure (OCI) has announced the implementation of Multi-Factor Authentication (MFA) for all customers. This move is aimed at bolstering the protection of sensitive data and safeguarding against potential security threats.

OCI MFA Policy Overview: The MFA policy, named "Security Policy for OCI Console," will be created by Oracle for customers who do not have Single Sign-On (SSO) configured. The activation of this policy will be carried out in batches, commencing from 20th July. This includes both recently migrated customers to OCI Gen2 and existing OCI customers.

How to avoid MFA:

While MFA is highly recommended for its added layers of security, some customers may have concerns or queries about its implementation. In this blog, we will delve into the details of Oracle's MFA policy for OCI and explore the available options for customers to navigate this change effectively. We recommend following two options:

 

Option 1: 

Activate Policy and Exclude Users One approach to handle the MFA activation is to keep only essential users under the policy, leaving out others. Here's how you can execute this option:

1. Create an Identity Domain Administrator User: Start by creating a new admin user, who will have the authority to manage the MFA policy and other administrative tasks. Once the admin user is in place, exclude all other users from the MFA policy. This ensures that only authorized administrator will be affected by the MFA requirement.
2. Create a Temporary User: To effectively implement the policy, select a temporary user as the sole entity subject to MFA. This approach allows you to thoroughly test the MFA workflow while minimizing its impact on users.

Option 2: 

Deleting the MFA Policy For customers who wish to avoid MFA activation altogether, Oracle has confirmed that once the MFA policy is deleted, it will not be recreated. Here's how you can proceed with this option:

1. Identity Domain Administrator Privilege: Ensure that the user is Identity Domain Administrator to delete policies.
2. Deleting the MFA Policy: The Identity Domain Administrator can then proceed to delete the MFA policy, effectively bypassing MFA requirements for all users.

Conclusion:

Multi-Factor Authentication (MFA) is a vital aspect of modern cybersecurity, providing an extra layer of protection for cloud infrastructure and user accounts. While Oracle Cloud Infrastructure (OCI) implements MFA to enhance security, customers have the flexibility to choose from two available options to navigate this change effectively. Whether it is configuring MFA for a select group of users or opting to delete the policy altogether, customers can make informed decisions based on their unique security requirements.

Remember, while MFA may cause initial concerns, its implementation will provide peace of mind and strengthen the overall security posture of your organization's OCI infrastructure. Stay safe, secure, and ahead in the cloud journey!

 

Title: Securing Your Infrastructure: Exploring VM Snapshots on OCI

 

Introduction:

In today's digital landscape, securing your infrastructure is paramount. With the increasing reliance on cloud computing, it's essential to have robust mechanisms in place to protect your valuable data and ensure business continuity. One such mechanism offered by Oracle Cloud Infrastructure (OCI) is VM snapshots. In this blog, we will dive deep into the world of VM snapshots and explore how they play a crucial role in securing your infrastructure on OCI.

Snapshot Process

Snapshot of System drive

To take a snapshot of a Windows virtual machine (VM) image on Oracle Cloud Infrastructure (OCI), you can follow these steps:

1. Sign in to the OCI Console at https://console.oraclecloud.com/.
2. Open the navigation menu on the top left and select "Compute" under "Core Infrastructure."
3. In the Compute menu, click on "Instances" to view your VM instances.
4. Locate and select the Windows VM instance for which you want to create a snapshot.
   
5. In the instance details page, click on the "More Actions" button (three dots icon) at the top-right corner.
6. From the dropdown menu, select "Create Custom Image."
7. In the "Create Custom Image" dialog, provide a name and description for the image.
8. Select the "Create Image" button to initiate the image creation process.
   
   
9. The snapshot creation process will start, and it may take some time depending on the size of the VM and the amount of data it contains.
   

10. 1.      Once the snapshot is created, it will appear as a new image in the "Images" section of the OCI Compute service.
    

Please note that taking a snapshot creates a copy of the VM image at a specific point in time. The snapshot can be used to create new instances or restore the VM to a previous state if needed.

 

It's important to keep in mind that taking a snapshot will not capture any data stored on attached block volumes or any data stored in cloud storage services. If you have additional data that needs to be backed up, make sure to follow appropriate backup strategies for those resources as well.

 

Snapshot of Block Volume

To take a snapshot of an attached block volume on Oracle Cloud Infrastructure (OCI), you can follow these steps:

1. Log in to the Oracle Cloud Infrastructure Console: https://cloud.oracle.com/identity/sign-in/
2. Navigate to the OCI Compute service.
3. In the left-side navigation menu, click on "Block Volumes" under the "Block Storage" section.
4. Locate and select the block volume for which you want to take a snapshot.
5. In the volume details page, click on the "Block Volume Backups”
   
6. In the "Create Block Volume Backup" dialog, provide a name and description for the snapshot.
   
7. Click on the "Create" button to initiate the snapshot creation process.
   
8. The snapshot creation process will start, and it may take some time depending on the size of the block volume and the amount of data it contains.
   
9. Once the snapshot is created, it will appear in the "Snapshots" section of the OCI Block Volumes service.

Please note that taking a snapshot of a block volume captures the data at a specific point in time. Snapshots can be used to create new block volumes or restore the original volume to a previous state if needed.

It's important to regularly back up critical data and follow appropriate backup strategies to ensure data integrity and availability.

Conclusion:

In conclusion, VM snapshots on Oracle Cloud Infrastructure provide a powerful tool for securing your infrastructure and safeguarding critical data. By leveraging the capabilities and following best practices related to VM snapshots, you can significantly enhance the resilience of your infrastructure and ensure rapid recovery in the face of unexpected events. Take advantage of the power of VM snapshots on OCI to establish a comprehensive and reliable data protection strategy that will give your organization peace of mind and enable uninterrupted operations. Embrace the potential of VM snapshots on OCI today and fortify your infrastructure against any potential threats.

 

OCI Gen2 Migration for EPM cloud

2023 is the year of OCI migration emails from Oracle.
Over time, by end of 2023, Oracle plans to migrate all EPM Cloud instances in Classic commercial data centres to OCI.
All EPM cloud instances include new orders of EPM Standard Cloud Service and EPM Enterprise Cloud Service from commercial customers with existing EPM Cloud legacy subscriptions.
26% EPM cloud environments including new and migrated ones are already on OCI.
Oracle's data centres around the globe are standardizing on the OCI architecture which delivers greater performance and reliability.
Many features of EPM Cloud are available only in OCI.

 

There are two possible options for OCI migration.

1)     Oracle Managed Migration

2)     Customer Managed Migration

 

Oracle Managed Migration

Steps for Oracle Managed Migration

•        Oracle notifies all Service Administrators when the OCI migration will occur for their Classic environments – at least 1 month before the scheduled migration date. (email received on 9^th Jan)

•        On the scheduled migration date, Oracle provides new OCI environments equaling the current number of Classic environments.

–       OCI environments will have new service URLs. (with same domain name like classic cloud URLs)

–       Classic environments continue to work at the same time.

•        Customer has 2 months to finish testing.

•        At the end of 2 months, Oracle migrates application and all artifacts from classic cloud to OCI cloud (Test env on the first Friday and PROD on the third Friday of month)

 

Customer Managed Migration

Steps for Customer Managed Migration

•        Customer creates an SR for OCI migration.

•        Flexibility to choose domain name, data centre with CSV file in SR

•        Oracle provides new OCI environments equaling the current number of Classic environments.

•        Customer has 6 months to finish testing.

•        Classic environments continue to work during these 6 months.

•        Oracle will terminate the classic environments after 6 months.

•        Customer can request termination of classic environments via SR if their migration is finished before that.

Post migration steps (Customer Managed migration)

•        Service Administrator Tasks

–       Announce URLs of OCI environments to EPM cloud users.

–       Modify scripts to change URLs

–       If Navigation Flows are used, update Connections to change URLs (and possibly passwords)

–       If EPM Agent is used, update its configuration to change URLs (and possibly passwords)

–       If you have any other integrations, such as, with FDMEE or NetSuite, update them to change URLs (and possibly passwords)

•        Individual user tasks

–       Update Smart View shared and private connections to change URLs

–       Modify bookmarks to point to the new URLs

The biggest advantage with customer managed migration is 1) flexibility to perform testing over a period of 6 months and 2) choosing the logical domain name.

E.g. Instead of “a123456”, domain name can be “customer1”

 

Steps to migrate applications and artifacts (Irrespective of ownership)

•        If Single Sign On (SSO) was setup in My Services for Classic environments, re-configure it for IDCS for OCI environments

•        If IP allowlists were configured in My Services for Classic environments, use EPM Automate command setIPAllowList to re-configure them for the new OCI environments

•        Clone ONLY the application from each Classic environment to corresponding OCI environment using Clone Environment – using schedule and order of your choice

•        Complete the testing for all applications in 6 months

•        After successful testing, clone all artifacts (application, users and their roles, data management records, audit history, job console history, and stored snapshots and files) from the Classic environments to corresponding OCI environments – using schedule and order of your choice

 

We, at Brovanture, are helping our clients with both these approaches. Give us a shout if you are on EPM cloud and want to understand more about it. 

HFM Application migration and upgrade from V11.1.2.4 to V11.2.7

 Previously, we had used CopyApp utility to copy HFM Application from one environment to another environment or from one version to another.

However while migrating HFM application from V11.1.2.4 to V11.2.7 , we used Import application wizard as suggested by Oracle.

 There are 3 important steps for HFM application upgrade, migration to V11.2.7.

 

1)    Database Link between HFM V11.1.2.4 and HFM V11.2.7

HFM schema in new version V11.2.7 must have following privileges.

CREATE DATABASE LINK

SYS.DBMS_LOB

SYS.DBMS_SQL

Create Database Link

 Use following query to create database link between HFM V11.2.7 schema and HFM V11.1.2.4 schema.

CREATE DATABASE LINK DEVTONEWDEV CONNECT TO EPMXDEV1 IDENTIFIED BY PASSWORD USING HFMDEV11;

 To view the database links present, execute following query.

select * from all_db_links

 To view applications present in source HFM database, list out datasources using following query:

Select * from HSX_DATASOURCES@DEVTONEWDEV;

 

We received following error at this point:

Error:

ORA-12541: TNS:no listener

12541. 00000 -  "TNS:no listener"

*Cause:    The connection request could not be completed because the listener

           is not running.

*Action:   Ensure that the supplied destination address matches one of

           the addresses used by the listener - compare the TNSNAMES.ORA entry with

           the appropriate LISTENER.ORA file (or TNSNAV.ORA if the connection is to

           go by way of an Interchange). Start the listener on the remote machine.

            Error at Line: 3 Column: 31

 Our first step was to add TNS entry for source database (HFM V11.1.2.4 database) in destination database, however due to security at client, found that port 1521 was closed between source and destination databases and hence we had to get port opened through firewall request.

 After creating the DB link we can run below mentioned package in the target oracle DB.

 Oracle_Create_ImportApp_package.pck file

After successful execution, the new package, HFMUTIL_PKG, will show up under the HFM schema’s available packages, in SQL Developer. If you see the green dot showing on the package, right click and click Compile. If the green dot is not there, there is no need to do this step:

2)     Import Application

After successful creation of the database link, login to Workspace and go to Navigate -> Administer -> Consolidation Administration, then click on Import Application. The Database link should be available and a dropdown list of the source environment’s HFM applications should be available.

 

3)    Upgrade HFM Application from V11.1.2.4 to V11.2.7

Once HFM application is migrated, we need to upgrade it to V11.2.7 using upgrade utility. 

And this results in successful migration and upgrade of HFM application with more than 20 years data (750 GB) for our retail domain client. 

There were couple of issues during the process, I will soon blog about issues and solutions. 

What is different about OHS server in Oracle EPM V11.2.7

 “Technology is no match for human errors.”

Every phase of every project, consultant will agree on this.
 
When we had referred the EPM V11.2.7 Installation-Configuration guide, remembered this point of explicit OHS restart. When actually coming to the end of configuration, checked Workspace URL and got following error.

Well, after remembering the OHS start point from guide, checked Workspace URL on Shared Services Weblogic port 28080 and it worked fine. We were able to access workspace. 

The first thing you may be wondering is: how do you start the OHS server? Well it's a change from the previous few versions as OHS no longer uses OPMN for this task. Instead it uses Node Manager. If you followed the official installation and configuration guide you should have a service like the below:

With that service running we have some helper scripts to get OHS online. Browse to MIDDLEWARE_HOME\user_projects\FND1\httpConfig\ohs\bin\. Then run the following command to start OHS and store the epm_admin credentials so you aren't prompted later:

startComponent.cmd ohs1 storeUserConfig

To stop OHS simply run the command:

stopComponent.cmd ohs1

From now on you can start OHS with:

startComponent.cmd ohs1

Above steps started the OHS server and hence workspace becomes available on 19000 port. 

Clean Uninstall of Oracle Hyperion EPM V11.2.7

Begin with uninstall

Any Oracle Hyperion Admin will agree – we definitely need to go through clean uninstall of system while implementing it for new client. I guess we had that day of uninstalling EPM 11.2.7 from our Integration server today.  
As it was pending from a long time after we started with Hyperion v11.2.7, here are basic steps to perform clean uninstall Oracle Hyperion EPM V11.2.7
 Uninstall using same admin account with which we have installed Hyperion EPM V11.2.

2.  Stop EPM Services

Stop all Oracle Hyperion EPM services created on server. (If any)

 3.  Uninstall related software

EPM uninstaller uninstalls JRE which comes with EPM installer. It is used for installation and configuration of any Hyperion products. The same JRE is used to uninstall related non-Hyperion software components like weblogic, OHS. So, if we proceed for EPM V11.2.7 uninstall, we cannot uninstall related software components by proper procedure and so we might end up in option of deleting folders and cleaning related stuff.

 Thus, it is very important to follow following steps before uninstalling EPM V11.2.7

Uninstall Weblogic

Run WL Uninstaller separately.
Unlike previous versions and previous Windows servers, could not find shortcut for Weblogic Windows Server 2019 and for EPM V11.2.7.
Instead of spending more time on understanding options available on 2019 server, used the batch file to uninstall weblogic. 

However this file gave error. After some due diligence , found that both Weblogic and OHS uninstall files are included in FMW 12 uninstaller.

 Uninstall OHS

 Run OHS Uninstaller separately. Included in FMW 12 uninstaller. 

Uninstall Oracle FMW 12

Run Oracle FMW 12 uninstaller separately

 Once we uninstall above products, check if the respective directories is removed from MIDDLEWARE_HOME.

3.  Uninstall Oracle EPM V11.2.7

Uninstall EPM System V11.2.7
Stop all Oracle Hyperion EPM services on server.
Uninstall Hyperion EPM system by running "uninstall.bat" located at "MIDDLEWARE_HOME\EPMSystem11R1\uninstall"

4.  Post uninstallation tasks

Check shortcuts

 Shortcuts should be removed.
 
Check from Start--> All Programs, all related shortcuts should have been removed.

Windows Registry

Check under Windows registry in HKEY_LOCAL_MACHINE > Software and HKEY_CURRENT_USER > Software whether the Brio > Hyperion > Oracle keys have been removed correctly.
 
Search registry and remove all the keys with keyword "Hyperion" or "Brio" or "Oracle"
With Oracle keyword, there will be keys for Oracle client which is installed as pre-requisite of EPM System.

Environment Variables

Following environment variables are created while installing hyperion EPM system and should be removed after uninstalling EPM system.

EPM_ORACLE_HOME

HYPERION_HOME

To confirm removal of environment variable, first check if the variable is still present.

If the environment variable is still present, delete it as below.

PATH variable

Check the PATH variable and delete any portions that need to be removed.

Manual File Deletion

Manually check the file system to see if any files or folders have been left behind. If any of these are left behind, they need to be removed manually.
 
    Ensure that <system drive>\Documents and Settings\<install_user>\.oracle.instance file has been deleted.
    Ensure that .oracle.products file in Middleware_Home\EPMSystem11R1 has been deleted.
    Remove any files left in the existing HYPERION_HOME if this location is to be re-used.
    Delete any BEA folder on the file system.
    Delete or rename installer records in C:\Program Files\common files\InstallShield\* if no other programs installed by this tool remain.
    Check for Oracle EPM related entries in the inventory.xml file located in C:\Program Files\Oracle\Inventory\ContentsXML and remove these entries from the file.
 
    Clean up any remaining Hyperion-related files and directories under the user's install home. E.g. "D:\Oracle\Middleware"
Registry keys deletion
Registry keys which should be deleted:
 
    HKEY_LOCAL_MACHINE\software\wow6432node\oracle\
    Delete any additional 'dds_proxy' settings in the registry.
    Delete any additional 'arborpath' entries in the registry.
    Delete any additional 'hyperion' entries in the registry.
 

Reboot the system

Please reboot the server after all the steps in the uninstallation have been performed. 

That makes server ready for new EPM 11.2.7 installation.