Showing posts with label OCI. Show all posts
Showing posts with label OCI. Show all posts

Saturday, 30 May 2026

Oracle Fusion Is Upgrading to OCI IAM

If you manage Oracle Fusion Applications — whether that's ERP, HCM, CX, or SCM — your identity and access management layer is getting a significant upgrade. Oracle is migrating all Fusion environments from the legacy identity service to Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), and this change requires your attention before the scheduled downtime window.

1. What Is Actually Changing?

The identity service that handles authentication, sign-on policy, single sign-on (SSO), multifactor authentication (MFA), and user lifecycle management for your Fusion Applications environments is being replaced with OCI IAM — Oracle's modern, cloud-native identity platform.

This is not a minor configuration tweak. It is a one-time mandatory upgrade with downtime. Once complete, your Fusion environments will gain the latest capabilities for enterprise identity management, including improved MFA controls, federated SSO policies managed directly from the OCI Console, and fine-grained identity domain administration.

Important

If your Fusion Applications environment family was provisioned after April 6, 2025, you are already running on OCI IAM. This upgrade does not apply to you.

2. Who Needs to Act — and When?

The urgency of your required actions depends on whether your Fusion environments are configured with federated SSO. Here is a quick overview:

No Federated SSO

No pre-upgrade actions required. Oracle handles everything. Monitor the schedule from the OCI Console and verify user sign-in after the upgrade.

Federated SSO Enabled

Action required at least 72 hours before each environment's downtime. Missing this deadline breaks SSO for all users after upgrade.

Fusion as Identity Provider

Apps like Taleo, CPQ, or SelectMinds using Fusion as IdP require post-upgrade tasks to restore their sign-in flow.

3. How You Will Be Notified — Timeline

90 days before

Email notification sent if any of your environments have federated SSO configured.

30 days before

Email notification sent if none of your environments have federated SSO.

10+ days before

Recommended window to begin and complete pre-upgrade tasks, leaving time to troubleshoot.

72 hrs before

Hard deadline. Pre-upgrade tasks must be acknowledged for each scheduled environment, including production.

During upgrade

Environments are unavailable. Expected downtime is up to 3 hours or longer, depending on user count.

Post-upgrade

Email confirmation sent. Post-upgrade tasks required for environments with downstream SSO dependencies.

4. Pre-Upgrade Steps for Federated SSO Environments

Oracle automatically creates the required identity providers in your environment's associated identity domain once it is scheduled. You do not need to create them manually — but you must complete and test the configuration.

Warning

Do not delete the Oracle-created identity providers from the identity domain. Doing so prevents you from completing the pre-upgrade tasks.


Step 1: Download the SAML metadata file — In the OCI Console, navigate to your Fusion environment family → Maintenance → Identity upgrade. Select your federated SSO environment, then choose Pre-upgrade actions and download the Metadata.xml file. Each file is unique to each environment — label them carefully if you have multiple.

Step 2: Configure a new service provider in your corporate IdP — Open the SAML metadata file and use its contents to create a new service provider in your corporate identity system (Azure AD, Okta, ADFS, etc.). This does not affect the existing service provider — your current SSO continues to work during this step. Download the SAML metadata from the new service provider once configured.

Step 3: Update and test identity providers in OCI IAM — Back in the OCI Console, import the SAML metadata from your corporate IdP into the OCI IAM identity provider. Then run the test sign-in flow — sign in to the identity domain first using a local administrator account (not the SSO button), then authenticate to your corporate IdP. A successful result shows "Your connection is successful."

Step 4: Acknowledge identity provider readiness — Only after all test sign-ins succeed, check the acknowledgment box in the Pre-upgrade actions panel and submit. The status changes to Completed. Do not add new identity providers in the Security Console after acknowledging — doing so resets your acknowledgment.

Tip

Oracle estimates about one hour to complete and test pre-upgrade tasks per federated SSO environment, assuming administrator permissions are in place. Budget time to obtain Domain Administrator access to each Fusion identity domain before you start.

5. What Happens After the Upgrade?

Once Oracle completes the upgrade and notifies you by email, verify that your users can sign in to each Fusion environment. Then complete the following:

     Verify user sign-in works for both SSO and non-SSO flows.

     For OIC integrations using OAuth Authorization Code Credentials with a non-Fusion identity domain, reconfigure the OAuth security policy to use a Fusion identity domain instead.

     For Taleo, CPQ, or SelectMinds using Fusion as SSO IdP, download new SAML metadata and update identity provider configuration in those apps.

     Test SSO sign-in for all dependent applications before acknowledging post-upgrade task completion in the OCI Console.

     Replace Sign In/Sign Out Audit REST API usage with OCI Audit reports — the Fusion audit API is not available post-upgrade.

     Review and reapply any custom default password policies. Changes may not survive the upgrade — this is a known issue.

6. Key Things That Are Not Changing

Amid all the change, the following remain exactly the same:

        Your Fusion Applications sign-in URL remains unchanged.

        Existing federated SSO configuration is preserved — same identity providers continue to be used.

        Password policies managed via the Fusion Security Console remain intact.

        The Security Console is not removed — user management, password resets, and role assignments continue there.

        Non-SSO (username/password) access for supplier portals and similar use cases continues to work.

        There is no cost change or subscription change associated with the upgrade.

7. Scheduling, Cancellations, and Opt-Outs

The identity upgrade is scheduled separately from quarterly Fusion updates — it will not appear in the same month as your quarterly patch. Non-production environments are upgraded in the second week of the scheduled month; production environments go in the fourth week.

You cannot opt out of the upgrade. If your scheduled window conflicts with a critical business event, you can submit an Oracle Support Request to request rescheduling, but approval is not guaranteed. Act early if you foresee a conflict.

If Oracle cancels a scheduled upgrade for any reason, the acknowledgment of pre-upgrade tasks is reset. You will need to redo and re-acknowledge those tasks once a new date is confirmed.

8. Practical Recommendations

Check your schedule now

Log into the OCI Console → Environment families → Maintenance → Identity upgrade to see your current upgrade status and scheduled timeline for each environment.

Get admin access early

Ensure you have Domain Administrator access to each Fusion identity domain before starting pre-upgrade tasks. Password resets and role assignments can take time and may require coordination with other teams.

Map your dependencies

Identify all apps using Fusion as their SSO identity provider. Check the Integrated Applications section in the identity domain once your upgrade is scheduled in the Console.

Start 10 days early

Oracle recommends completing pre-upgrade tasks at least 10 days before the first environment's scheduled downtime — not just 72 hours — to allow adequate time for troubleshooting.

Don't touch SSO config after acknowledging

Once you've acknowledged pre-upgrade readiness for a Fusion environment, do not add or modify identity providers in the Security Console. Any such changes reset the acknowledgment and require you to complete and re-acknowledge all pre-upgrade tasks.

 

Summary

This upgrade is mandatory for all Fusion Applications environments provisioned before April 6, 2025. Federated SSO customers must complete pre-upgrade tasks at least 72 hours (ideally 10 days) before each scheduled environment's downtime. The upgrade window is up to 3 hours. There is no cost impact, and most existing configurations are preserved.

 Resources

        Oracle Docs: Identity Upgrade Overview — docs.oracle.com/en-us/iaas/Content/fusion-applications/identity-migration-overview.htm

        Oracle Docs: IAM with Identity Domains — docs.oracle.com/iaas/Content/Identity/home.htm

        Oracle Docs: Federating with Identity Providers —docs.oracle.com/iaas/Content/Identity/federating/federating_section.htm

        Oracle Docs: Identity Upgrade Checklist — docs.oracle.com/en-us/iaas/Content/fusion-applications/identity-migration-checklist.htm

        Oracle Support: Submit a Support Request for rescheduling — docs.oracle.com/iaas/Content/GSG/Tasks/contactingsupport.htm

 

Friday, 27 March 2026

OCI Basics: Building Your Cloud Network with Virtual Cloud Networks (VCNs)

You've got your cloud computers (Compute Instances) and your storage (Boot and Block Volumes) sorted out. But how do these pieces talk to each other? How do they connect to the internet or stay securely isolated? That's where networking comes in, and in Oracle Cloud Infrastructure (OCI), the foundation of your network is the Virtual Cloud Network.

Think of a VCN like your own private, customizable network that you build inside OCI. Just as your physical home or office network has routers, switches, and security rules, your VCN provides all these capabilities in a virtual environment. It's an isolated network space where all your OCI resources—like your Compute Instances and databases—can securely operate and communicate.

What is a Virtual Cloud Network (VCN)? Your Private Network in the Cloud

A VCN is essentially a software-defined network that you create in OCI. It provides a secure and isolated environment for your cloud resources. Within your VCN, you define your own IP address ranges (like 10.0.0.0/16 or 192.168.1.0/24), subnets, routing rules, and security configurations.

Imagine you're setting up a new office building. You wouldn't just plug all your computers into each other randomly; you'd design a network with different departments having their own sections, and specific rules about who can access what. A VCN is exactly that, but for your cloud "office."

In simple terms: A VCN is your custom, private network in OCI, where all your cloud resources live.

Why is a VCN Important? The Foundation of Connectivity and Security

The VCN isn't just about connecting things; it's also crucial for security and organization.

Isolation and Security: Your VCN is logically isolated from other customer VCNs in OCI. This means your network traffic and resources are private and secure. You control exactly what traffic goes in and out using security rules.

Organization: You can divide your VCN into smaller sections called subnets. This allows you to group resources based on their function (e.g. a "web server subnet" for public-facing servers, and a "database subnet" for backend databases).

Connectivity: Resources within the same VCN can communicate with each other. You can also configure your VCN to connect to the internet, to your on-premises data center, or even to other VCNs.

Flexibility: You have complete control over IP addressing, routing tables, and security lists, allowing you to design a network that perfectly fits your application's requirements.

Analogy: Think of a VCN as your own private plot of land in a massive cloud city. You get to build your roads (routing), divide your land into districts (subnets), and put up fences and security checkpoints (security lists) to control who comes and goes.

Key Fact: Every resource you deploy in OCI, whether it's a Compute Instance, a database, or a load balancer, must be placed within a VCN and a specific subnet.

In simple terms: The VCN is the secure and organized network space where all your OCI cloud components connect and operate.

Understanding VCNs is your next big step in mastering OCI. It’s the invisible backbone that ensures all your cloud components work together efficiently and securely. With a solid grasp of VCNs, you can confidently design and deploy robust applications in the cloud.

Wednesday, 25 March 2026

OCI Basics: Your First Guide to Cloud Servers and Storage

                         OCI Basics: Your First Guide to Cloud Servers and Storage

So, Let's start our journey with Oracle Cloud Infrastructure (OCI)? Welcome! It can seem like there are a lot of new terms to learn, but it's all quite logical once you break it down.

Today, we're going to talk about the three fundamental building blocks of any cloud setup:                             Compute Instances, Boot Volumes, and Block Volumes.

Think of it like building a new computer. You need the computer itself (the brains), a main hard drive for the operating system, and maybe an extra hard drive for your files. Let's see how this works in OCI.

What is a Compute Instance? The "Computer" in the Cloud

An OCI Compute Instance is basically your own private computer or server living in Oracle's secure data center. It's the "brains" of the operation. This is where you'll run your website, your application, or any other software. It has processing power (CPU) and memory (RAM), just like the PC or Mac you're using right now.

You can choose how powerful you want this cloud computer to be—from something small for a personal blog to a massive server for a busy e-commerce site.

In simple terms: A Compute Instance is your virtual server in the cloud.

What is a Boot Volume? The Main Hard Drive (C: Drive)

Every computer needs a main hard drive where the operating system (like Windows or Linux) is installed. In OCI, this is called a Boot Volume.

When you create a new Compute Instance, OCI automatically creates and attaches a Boot Volume to it. It's the startup disk. Without it, your cloud server wouldn't know how to turn on.

Its Job: To hold the operating system and essential system files.

Analogy: It’s the C: Drive on a Windows PC. It's essential for the computer to start and run.

Key Fact: The Boot Volume is directly tied to its Compute Instance. When the instance starts, the boot volume starts.

In simple terms: The Boot Volume is the startup disk for your cloud server.

What is a Block Volume? The Extra, Portable Hard Drive

Now, what if your main C: Drive is full, or you want to keep your personal files separate from your system files? You’d plug in an external USB hard drive, right? In OCI, that's a Block Volume.

A Block Volume is an extra storage drive that you can attach to your Compute Instance. It’s perfect for storing things like:

Website files and images

Databases

User data

Log files

The best part about Block Volumes is that they are independent. You can unplug it from one Compute Instance and attach it to a different one, and all your files will travel with it, safe and sound. If you decide you don't need your cloud server anymore, you can delete the server but keep the Block Volume with all your important data.

Its Job: To provide extra, flexible storage for your data.

Analogy: It’s like an external USB hard drive. You can attach it, detach it, and move it between computers without losing your files.

Key Fact: Block Volumes live on even if your Compute Instance is deleted. Your data is safe.

In simple terms: A Block Volume is an extra hard drive for your data that you can move around.

Why Does This Matter?

Understanding this separation is key to managing your cloud resources effectively.

Safety: By keeping your important data on a separate Block Volume, you can experiment with, upgrade, or even delete your Compute Instance without worrying about losing your files.

Flexibility: Need to upgrade your server to a more powerful one? Just detach your Block Volume from the old instance and reattach it to the new one. All your data is instantly available.

Cost: You can add exactly as much extra storage as you need, when you need it.

Congratulations! You now understand the core components of running a server in OCI. By thinking of Compute Instances as the computer, Boot Volumes as the main C: drive, and Block Volumes as your trusty external hard drives, you're well on your way to building amazing things in the cloud.

Sunday, 9 February 2025

Step-by-Step Guide to Create an Autonomous Database in Oracle OCI

 Log in to Oracle Cloud Console

Navigate to Autonomous Database Section



Click on Create Autonomous Database

    Click on Create Autonomous Database and select correct Compartment


Fill Out the Create Autonomous Database Form

  • Compartment
  • Display Name
  • Database Type
  • Deployment Type
  • Database Version
  • License Type


Configure Database Options

  • Admin Password
  • Storage
  • Auto Scaling
  • Network
  • Backup & Restore



Click on Create Autonomous Database 



Wait for the Database to be Provisioned

    OCI will now provision your Autonomous Database. This can take a few minutes.



    Once the database is ready, you'll see its status as Running on the console.