Planning an IDM Build Out for Fusion Apps Part 2 – Pre Build Out Checklist

In my last post I listed all of the architectural decisions that you’ll want to work through before diving into an IDM build out for Fusion Apps.

In this post, I’d like to take things one step further and put forth a checklist of tasks that you’ll want to accomplish before beginning the actual (onsite) build out.

Failure to complete these items before the build out will turn what is already a fairly long and intensive process into a longer and frustrating process. You want to make sure going into the actual build out that you have all the necessary hardware, software, and skill pre-requisites to ensure success.

The IDM build out for Fusion Apps and the Fusion Apps install in general is really a project where advance planning with pay off in spades.

So with that being said, I give you my list:

Machine Provisioning

• You should have all machines built out and patched to current OS patch levels before onsite install begins. Make sure that appropriate amounts of RAM, SWAP, and disk capacity has been allocated to each node in the install.

• You should also have all required system accounts created and available before onsite install begins.

• You should make sure there is graphical access to the machines being used in addition to command line. VNC (virtual terminal) is recommended over X-Windows forwarding as we’ve seen screen rendering issues with our install GUIs and X-Windows forwarding.

• Be sure that shared storage is mounted and reliable. The shared drive (NFS or CIFS) must support file locking. For NFS Version 3, the advisory locking must be configured for the NFS mount. This applies to all UNIX platforms. Please, make sure that your shared storage is really up to the task. I’ve seen a surprising number of FA install projects go bad over the last few months due to sub-standard shared storage.

Download all packages and patches

The Packages

Identity Management for Fusion Applications involves installation of the following:

• Oracle Database 11g R2

• JDK (JRockit 64-bit)

• Oracle WebLogic Server

• Oracle Fusion Middleware Web Tier (Oracle HTTP Server)

• Oracle Fusion Middleware SOA Suite

• Oracle Identity Management (OID and OVD)

• Oracle Identity and Access Management (OIM and OAM)

• Oracle Access Manager WebGate

The packages for the IDM build out are included in the eDelivery media kit for Fusion Apps. Search for Product Pack: Oracle Fusion Applications. You can also download each package indivivdually from OTN (Oracle Technical Network). Just make sure that whatever you do you are using the appropriate version of each package. For FA V1 RUP1, all IDM software should be 11.1.1.5 but the web tier and IDM packages have to be installed at 11.1.1.2 and then upgraded to 11.1.1.5.

I also highly recommend that you do checksums on all downloaded packages before beginning the install to make sure that everything downloaded cleanly.

GCC Libraries for OAM 10g WebGate

The WebGate requires you to provide GCC runtime libraries during installation.

64 bit libraries for LINUX can be found in support article 840870.1

32 bit libraries can be gotten using the GCC Libraries for Oracle Identity Federation line on:

http://www.oracle.com/technetwork/middleware/ias/downloads/101401-099957.html

GCC libraries for other OS systems should be tracked down in advance of onsite time.

The Patches

As of right now, there are a fair number (8+) patches required for the IDM build out of Fusion Apps. It is important that you are applying the latest required list of patches. To obtain the current list of patches for the IDM build out, refer to the most recent version of the Fusion Apps release notes and IDM EDG for Fusion Apps. Once you have the list you can get the patches off of support.oracle.com or through eDelivery.

Documentation

Be sure you have downloaded and review the current version of the Enterprise Deployment Guide for Identity Management (Fusion Apps Edition) and the Fusion Applications Release Notes. For the release notes, this should include both the base release (V1) release notes and the patch set (RUP1) release notes. The release notes are very long but it is important that you review them for the following items:

1) The latest list of required patches for IDM.

2) Any additional configuration steps listed in the release notes that are not in the IDM EDG for FA.

3) Known issues that you should know about.

Database Build Out

Two Oracle Database instances should be created before the onsite install begins. One is for OID and the other is for the rest of the IDM components. You should verify up front that the database is the correct version, configured with the correct parameters, and the correct character set (ALT32UTF8).

It is also advisable that customers complete chapter 3 of the IDM EDG –Configuring Database Repositories: http://download.oracle.com/docs/cd/E15586_01/fusionapps.1111/e21032/db_repos.htm#BABHBICE

There are several reasons to do this in advance:

1) This is the first actual step of the install.

2) In many organizations this will be performed by DBAs whose availability can be scarce.

3) Successfully running the RCU tool to configure the repositories validates that the there is a working DB that can be used for the install and that the necessary information to use it has been collected.

Network Prerequisites

DNS Aliases

DNS aliases for the following virtual hosts should be created before the onsite install begins. The usage of these virtual hostnames is discussed in detail in the IDM EDG for FA.

admin.mycompany.com – Resolves to load balancer or web server fronting WLS admin server for the IDM domain running on IDMHOST1.

sso.mycompany.com – Resolves to load balancer or web server fronting the OAM and OIM managed servers running on IDMHOST1 (and IDMHOST2 if HA) and OIMHOST1 (and OIMHOST2 if HA).

oiminternal.mycompany.com – Resolves to load balancer or web server fronting WLS admin server for the OIM managed servers running on OIMHOST1 (and OIMHOST2 if HA).

idstore.mycompany.com – Resolves to the load balancer fronting the LDAP identity store or the LDAP server itself.

policystore.mycompany.com – Resolves to the load balancer fronting the LDAP policy store or the LDAP policy store itself.

Load Balancer Configuration

If one or more load balancers will be used in the environment, it is advisable to configure it in advance of the install. The following is a sample mapping of what will need to be provided to the network administrator responsible for configuring the load balancer.

Front End HTTP(S)

HTTP

admin.mycompany.com:80 --> webhost1.mycompany.com:7777 webhost2.mycompany.com:7777

sso.mycompany.com:80 --> webhost1.mycompany.com:7777 webhost2.mycompany.com:7777

oiminternal.mycompany.com:80 --> webhost1.mycompany.com:7777 webhost2.mycompany.com:7777

HTTPS (SSL terminating at load balancer)

admin.mycompany.com:443 --> webhost1.mycompany.com: 7777 webhost2.mycompany.com: 7777

sso.mycompany.com:443 --> webhost1.mycompany.com: 7777 webhost2.mycompany.com: 7777

oiminternal.mycompany.com:443 --> webhost1.mycompany.com: 7777 webhost2.myco.com: 7777

LDAP Load Balancer

policystore.mycompany.com:389 --> oidhost.mycompany.com:389 oidhost2.mycompany.com:389

idstore.mycompany.com:389 --> oidhost.mycompany.com:389 oidhost2.mycompany.com:389

LDAPS

policystore.mycompany.com:636 --> oidhost.mycompany.com:636 oidhost2.mycompany.com:636

idstore.mycompany.com:636 --> oidhost.mycompany.com:636 oidhost2.mycompany.com:636

Virtual IP Addresses

If customers are building an HA environment and wish to be able to bring up the WLS/OAM admin server on a secondary box (IDMHOST2) in the event that the first box becomes unavailable, then they will have to provision a virtual IP address to the subnet of IDMHOST1 and IDMHOST2 and initial configure the IP address for IDMHOST1.

Additionally, virtual IPs are recommended for each SOA and OIM managed server. This enables these servers to participate in server migration.

For more about virtual hostnames, see the IDM EDG for FA.

Certificate Creation

Customers should try to create any certificates needed for any of the SSL connections made to already existing infrastructure like the load balancer and should make arangments to generate certificates for any infrastructure that will be installed during the build out (like OHS or OID) where a "legitimate" certificate is desired.
In particular, it is advisable that the front end certificates being used for the browser to load balancer or browser to web server connections be “legitimate” certificates where the hostname in the certificate is correct and where the CA of the server cert is or can be imported into the trust store on browsers that will be using the environment.

Beyond the front end SSL connection, all other connections can function OK with self signed certificates produced in the install. It is up to each customer to decide as to whether or not this is sufficient.