TruTek is a national leader in technical and functional Oracle training and consulting. We also offer permanent placement services for part-time and full-time employees. We offer Oracle database and E-Business Suite consulting, training and remote services. We have a state of the art training facility in Salt Lake City, Utah.

If you have 5 or more people interested in a class, we can also bring classes to your company if you would like onsite training. And if you've wanted to take a training class, but were intimidated by the crowds, we also offer "Personal Training" for certain classes, as well as online training. 

These are all the patches that I've found so far for patching Patch Wizard. If you come across any others, please let me know!

Check to make sure you are running the latest version of Patch Wizard:

Additional Release 11i Patch Wizard Patches: 

• 10405353 and 9803629 - Adds a filter to show Minimum, Mandatory Release 11i Extended Support patches
• Pre-requisite patches for 9803629/10405353
• 10351691 - makes Patch Information Bundle (Infobundle11i.zip) download correctly
• 9690361 - makes custom filter code level patches display correctly
• 4527622 - resolves an issue with missing Critical Patches

• 10364330 - makes Patch Information Bundle (InfoBundle.zip) download correctly for Release 12.0.x
• 10364346 - makes Patch Information Bundle (InfoBundle.zip) download correctly for Release 12.1.x
• 10318223 - Makes Patch Information Bundle (InfoBundle.zip) download correctly for Application Change Management Pack
• 9643141 - makes custom filter code level patches display correctly for Release 12.1 (not available for 12.0.x)
• 4527622 - resolves an issue with missing Critical Patches

Extended Support Patching: Read the Fine Print by John Stouffer, Just a DBA

Here are some more Extended Support patching rules: You must apply patches for all Installed, Shared and Pseudo modules. If you run patchsets.sh, you can see the list of products at the top that Oracle thinks you have licensed. In all likelihood, if you've been running the E-Business Suite for several years, then the list has more products that your company is actually using.

To understand why there are so many patches, particularly in Section 2 of MOS Doc. ID: 883202.1, let's start with a little history lesson about the origins of the Oracle Applications. In the early days of the Oracle Applications, customers only installed the modules they used. As more modules were released, supporting unique configurations where every customer could have a different set of software installed became too cumbersome for Oracle. There were places where data needed to be shared, and it didn't make sense to have the same tables associated with each module, so Oracle introduced Shared Modules. Shared Modules may have data, like customer information, that many other modules need to access. This issue is not unique to Oracle - any vendor who offers a suite of functionality will have to deal with this problem.

Nowadays, customers install every module, whether used or not. You install everything, but you license only the modules that you have purchased from Oracle. Unfortunately, in the early days of the Oracle Applications, the License Manager often had groupings of modules, in addition to individual modules that could be selected. The groupings were likely bundles that reflected some aspect of Oracle's sales process. The License Manager interface was confusing, and it was very easy for a customer to inadvertently over-install modules. And, at the time, there weren't that many modules, so over-installing didn't seem like a big deal.

Years later, many of Oracle's customers have a long list of over-installed modules. And since the database sees them as Installed, Shared or Pseudo modules, those modules have to be patched.  You might ask, "Can I just patch the ones we use?" That's where risk is introduced - how can you tell for sure that there isn't some code or data that is part of what you consider an over-installed module that is necessary for you to run the Applications? It would be nice if Oracle could help you out here, and we've noticed that users are logging SRs asking if they need to patch specific modules. It can't hurt to ask, but if you have dozens of modules, it may take Oracle a while to come up with an answer, and you may not be satisfied with what they tell you. The standard response is, if you installed it, you must patch it.

John Stouffer, from Just a DBA, has a terrific paper with more details about the nuances of Patch Wizard: Oracle E-Business Suite Patch Wizard Path to Less Errors.

• Database Health Checks

• The TruTek Oracle Database health check is designed to spot performance issues and make certain that your database is fully optimized.  

• Upgrade Readiness
• The Upgrade Readiness Assessment has three components:
• Functional Upgrade Assessment
• Technical Upgrade Assessment
• Customization Assessment
• Functional Gap Analysis
• The Gap Analysis evaluates current business practices against best practices and determines how an upgrade can help close the functional gap.

What is an Assessment?
Trutek's Assessments consist of an audit, analysis, and recommendations in three key areas:

• Strategy
• Process
• Technology

Additionally, at the client's option, the Assessment can also include the following two areas:

• People
• Governance

Read more about all of TruTek's available upgrade services.

Really, it shouldn't be possible. But Mike Swing has figured out how to do a Release 12 First Pass Upgrade using your own data, and here's how he does it. First, we perform a Release 12 Upgrade Assessment of your environment. We need to know from that Assessment, if you're ready to go to Release 12, and if you're not, what you need to do to get ready. For the most part, you're ready if you've applied the Release 11i Extended Support Mandatory Patches, you have your operating system and hardware changes in place, and you have a highly motivated technical team.

If you have all that, then we think we can do a Release 12 First Pass Upgrade. We offer two choices - if you want to learn how to do this, then you do the upgrade, and we walk you through the steps. We don't even need to touch your environment, because you'll do all the work, but we'll sit with you and guide you, and we'll chase after My Oracle Support notes and additional patches. On the other hand, if you'd like to have a test environment, but don't want to create it yourself, we can do the First Pass Upgrade remotely, and hand it off to you when we're done. Now, you just have to ask, "How can you get through all that in two weeks?" The answer, my friends, is hard work and perspiration. Here's what we tell our customers: 

1. We will start work on Monday morning, and finish on Thursday afternoon each week.
2. We will provide a list of patches that need to be downloaded ahead of time. You'll need the patches downloaded before we arrive. Your server configuration needs to be the one you'll use for all your Release 12 testing - don't start testing on one configuration and then expect to switch to something else partway through. Oh, and make sure your test environment is beefy - we don't want to waste any time trying to move things around and make space during this upgrade. Assume you'll need at least 20% more disk space than you are currently using for your production environment, and think hard about adding more CPU and memory, and take a look at your I/O subsystems.
3. You'll need to have your environment ready to go before we start on Monday - so you'll need to have a Release 11i clone of your current production environment up and running and ready to start applying patches to.
4. You'll likely need to babysit programs running at night, and you'll likely have assignments for over the weekend. We will provide extensive instructions when we determine the processing that would best run over the weekend, depending on where we are in the steps. We can advise you on Thursday afternoon as to what we would like to have run over the weekend and agree to some reasonable amount of monitoring to fit everyone's schedule. But the bottom line is, you don't get an upgrade in place in two weeks without working up a pretty big sweat.
5. Our goal is not to touch your environment, just to advise you step by step through the process.
6. We'll use TruTek's the little R12 upgrade guide as our guide, and we'll add anything new that we learn along the way. We always learn new things, because the applications are a moving target.
7. We assume that we'll hit problems and will have to log tars, search My Oracle Support, or call colleagues. We've never had a First Pass Upgrade come to a halt due to issues, but since we're dealing with your unknown data, there's always a risk.  

If you're ready to take your first run at Release 12, give us a call.  

"Hey! I'm a big burly DBA and I know how to RTSM (Read the Stinking Manual). I've got a PhD in tracking down My Oracle Support Notes. I can spout architecture changes, Oracle versions, one-off patches, high priority patches, Extended Support Mandatory Patches, RUPs and CPUs with the best of them. So leave your consultants at home and give me the bare essentials to what I need to do to get my company to Release 12."

Here at TruTek, we like smart people who can take care of themselves. So here are the list of resources that we have. Go ahead, pick and choose what you need:

1. Release 11i to Release 12 Upgrade Training - in this grueling one week class, you'll upgrade a Release 11i Vision instance to Release 12, complete with a database upgrade to 11gR2 and a plethora of additonal patches to get your instance to Patched Current status. Come in early and stay late, though, because it isn't easy to get an instance upgraded in one week.
2. Release 12 Upgrade Assessment - we evaluate your environment from head to toe and give you a detailed report of issues that we find that ought to be fixed before you upgrade, as you upgrade, or after you upgrade.
3. The Release 12 First Pass Upgrade - in two long weeks, you do the upgrade, we provide the guidance. At no point do our hands touch your hardware. Any mistakes are yours to make.
4. Worried about reimplementing? We've got the answer with our colleagues at eprentise.
5. Worried about security? Check out our friends at Integrigy.
6. Wondering how you'll track down 10 years' worth of customizations? We've figured out how to do that too. Just give us a call, we've got the answers to your R12 upgrade issues.
7. Don't want to hear our lilting voices? Check out our books:  

the little r12.1.2 upgrade guide,

the little r12.1.2 upgrade essentials for managers and team members, and

the little r12.1.2 project plan.

  We'll be coming out with new versions for Release 12.1.3 before Collaborate.

I probably shouldn't admit this, but it's true. Lately, I've taken to watching Integrigy's security webinars. I always walk away with a pearl of wisdom. I told you a couple of months ago about my first revelation: if you upgrade your RDBMS version, chances are, you'll finish the upgrade and be behind on your Critical Patch Update (CPU), even if you had been current on the CPU before you applied the RDBMS upgrade. Take a look at this chart, and you'll see why:

I confess, I had to squint my eyes for a little while at this chart, because I have a customer who has tested and applied all the Release 11i Extended Support Mandatory Patches and is running on RDBMS 11gR2, which was released prior to the January 2011 CPU, so it didn't make sense to me that they would be patched current on the CPU. Several more emails sent off to Stephen Kost, of Integrigy, and I finally understand that in the case of Release 11gR2, it really is patched to the January 2011 CPU, so you don't need to reapply anything. Of course, when the April 2011 CPU comes out, this customer will need to test and apply that patch. Now take a look at RDBMS Version 11.2.0.1 - if you patched to that version today, which you might do in preparation for upgrading to R12, you'd be running the January 2010 CPU. There have been four CPUs since then, so you'd need to apply the January 2011 CPU.

You might wonder why you might consider patching to RDBMS Version 11.2.0.1 instead of 11.2.0.2. We think it's easier to patch to the version of the RDBMS that is installed with Release 12 and then upgrade to 11.2.0.2 than it is to patch first to Version 11.2.0.2. The RDBMS version that is laid down with Release 12 has been tested against that version of R12. But it's up to you; some customers go with the absolute latest, and that works too.

Another tidbit that I learned from an Integrigy webinar - when you apply patches, you'll sometimes install a new E-Business Suite module. If it's a module you don't plan to use, you may not think much about it. But remember that when you install a new module, the password for that module is extremely easy to guess, which means there's an opportunity for a hacker to break into your database via that module. So you should be sure to check to make sure that you have changed passwords on all modules after patching. 

If you'd like to increase your security savvy, check out these upcoming webinars by Integrigy:

Oracle January 2011 Critical Patch Update Oracle Database Impact - Thursday, February 3, 2011 - 2pm EST

OAUG eLearning: Update Security in Your Oracle R12 Upgrade - Thursday, March 1, 2011 - 2pm EST

We've added an optional Security Audit to our Release 12 Upgrade Assessments, courtesy of Integrigy, so if you'd like to know how you're doing, sign up for an Assessment. 

One of several Oracle E-Business Suite (EBS) auditing challenges relates to Segregation Of Duties (SOD).  Here are some of the SOD questions auditors ask.  How do you set up policies to control which duties and related EBS functions must be segregated so no individual can use EBS to steal from the enterprise or commit fraud?  Having defined the SOD policies, how do you determine if the users are in compliance?  If they are in violation, because they have theoretical access to conflicting functions, how can you detect if they have actually stolen anything or committed fraud?  If a user is in violation, how do you correct that?  How do you handle exceptions, where a remote office is so small, there is only one EBS user who has to perform all the business functions?

In EBS, users get access to business functions via Responsibilities, Menus, an arbitrary string of Sub-Menus, and ultimately to Functions that control database access and transactions.  It isn't sufficient to know which Responsibilities are assigned to a user.  You have to follow the complex navigation access paths through these layers and then compare each pair of Functions to see if there is a conflict; a violation of an SOD policy.  There are complexities due to the EBS multiple organization model, where data access is controlled by the user's Business Group, Set Of Books, and Operating Unit.  Once you determine which Responsibilities have inherent SOD function access violations, and which users have violations due to multiple Responsibilities, you use EBS standard functionality to adjust Responsibilities and Menus, and to change a user's Responsibilities. 

In recent years, public audit firms have asked EBS customers to monitor and report SOD violations quarterly or twice a year.  Many companies have the IT department run a number of Responsibility or Function access reports, send these to business process owners, and these process owners say everything's OK, or not.  The results are not necessarily theoretically accurate.  There are false negatives and false positives.  There is a huge amount of data to review.  The audit firms may get different results than the IT department's reports.  When the audit firm is comfortable with the customer's controls and software tools, that can reduce the amount of work and resulting audit fees, without increasing business risk.

A useful framework for EBS customers is to follow these steps:

1. Define EBS Function Conflicts
2. Run Baseline Violation Reports
3. Remediate the SOD Violations (change User and Responsibility access to Functions, and exempt certain users from violations)
4. Institute Continuous SOD Violation Detection
5. Continue Cycles of Reporting and Remediation
6. Monitor and Track Progress to Zero Violations and Total SOD Compliance

Absolute Technologies' Application Auditor products provide a set of software tools for EBS customers that address the key technical questions and are easy to fit into a customer's internal audit processes.  They also make it easy for the outside audit firm to review the processes and internal controls.  The functionality includes:

• Seeded SOD policies that are easy to tailor to each customer's business and risks.
• The ability to detect when you assign new Responsibilities that create an SOD conflict violation for a user.
• Periodic capture of all SOD violations, with standard and ad hoc analysis reporting.
• Creation of exceptions for specific users, where there might be other mitigating controls.
• Screens and reports to document and analyze a User's or a Responsibility's Function access paths.  You can also examine where or to whom a Function is assigned.
• Transaction audit to detect, report, and optionally prevent transactions that violate SOD policies or otherwise create business risk.
• User watch lists, so you can closely monitor a group of users to see what transactions they perform. 

Absolute's customers have successfully automated their manual SOD review processes while reducing the workload on IT and business process owners.  They are able to deploy Application Auditor products in a few weeks.  They have eliminated false-positive and false-negative reporting, which reduces the business risk.  Rather than having to mine huge volumes of SOD reporting data, they focus on exceptions. 

 

 

 

Oh, go on. Maybe you've written a great presentation or paper and want to tell people about it? Here's your chance. Drop us a line, and if we publish your article, we'll send you a $50 Gift Certificate from Amazon!

Don't be shy! Send your submission to editor@trutek.com by February 25th. We'll include the winning article in our next newsletter.