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:
• 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
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 220.127.116.11 but the web tier and IDM packages have to be installed at 18.104.22.168 and then upgraded to 22.214.171.124.
I also highly recommend that you do checksums on all downloaded packages before beginning the install to make sure that everything downloaded cleanly.
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:
GCC libraries for other OS systems should be tracked down in advance of onsite time.
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.
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.
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)
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
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.
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.