Thursday Mar 11, 2010

A Primer on Migrating Oracle Applications to a New Platform

In Support we field a lot of questions about the migration of Oracle Applications to different platforms.  This article describes the techniques available for migrating an Oracle Applications environment to a new platform and discusses some of the common questions that arise during migration.  This subject has been frequently discussed in previous blog articles but there still seems to be a gap regarding the type of questions we are frequently asked in Service Requests.

Some of the questions we see are quite abstract. Customers simply want to get a grip on understanding how they approach a migration. Others want to know if a particular architecture is viable. Other customers ask about mixing different platforms within a single Oracle Applications environment.   

Just to clarify, throughout this article, the term 'platform' refers specifically to operating systems and not to the underlying hardware. For a clear definition of 'platform' in the context of Oracle Applications Support then Terri's very timely article:
The migration process is very similar for both 11i and R12 so this article only mentions specific differences where relevant.

1. Why Have a Migration Process at All?

Some customers have asked why there is a migration process at all. Surely they say it would be easier just to perform a fresh install of the E-Business Suite on the target environment and then perform an export/import of the database.

The above process is reliant on the fresh install you perform exactly matching the patching levels and technology stack levels of the environment you are migrating from. The database contains tables with information regarding files in your APPL_TOP. If you mix a fresh application tier install with an already established database, there will be a mismatch between these tables and the objects they describe. This will cause problems during later patching. The same issue applies regarding Java objects in the database and the files contained in the JAVA_TOP. For these reasons, you should never consider mixing an application tier with an unmatched database tier.

Although the migration process may appear quite time consuming and linear, much of it can be done in advance. With careful planning, your production environment downtime can be limited to little more than the time it takes to export and import the database and the time taken to apply several key patches. The majority of the application tier migration can be done in advance whilst your production environment is still up and available for updating by users.

2. Migrating the Database Tier to a New Platform

If you plan to migrate both the application and database tier to a new platform, the flow of the documentation will follow more logically if you migrate the database tier before the application tier however there's no particular reason why you should not migrate the application tier first.
Tip:  If migrating the database tier first, make sure the source application tier is updated to connect to the migrated database tier before migrating the application tier. This is because the application tier migration process is only updating the application tier configuration, and assumes the database connection values are the same as source. 
There are several different ways to migrate the database tier. Using the basic export/import tool was the only way up until the release of 10g. With 10gR1 came the introduction of the datapump utility which looks similar to export/import but with useful enhancements and improved performance.

With 10gR2 came the introduction of cross-platform transportable tablespaces and transportable databases. At time of writing, transportable database functionality is certified for use with Oracle Applications for Release 11i and for Release 12Cross-platform transportable tablespace (XTTS) is still currently part of an Early Adopter Program (EAP). Version 11g of the database supports both datapump and transportable database migrations.

Using transportable database as a means to migrate your database is dependent on both platforms having the same "endian" format. The following SQL query run on your source database will tell you if your target platform is compatible.
SQL> select platform_name from v$db_transportable_platform;
Transportable database uses the Recovery Manager (RMAN) Convert Database functionality to migrate the database to the new platform. It's not supported to use RMAN outside documentation written specifically for Oracle Applications to perform your database migration.

One rule that applies to all the above migration methods is that only complete database migrations are supported. It is not supported to perform partial database migrations or complete migrations by using a "schema by schema" approach.

If using export/import, there are some parameters that are not used in the default parameter file supplied such as named pipes and direct=y. This generally means they are untested in the Oracle Applications environment and, although they may work, you should generally be wary of using parameters that are not specifically documented as being Oracle Applications friendly.

If migrating from a 32-bit platform/database to-64 bit, then assuming you install a 64 bit Oracle home on your target environment, the conversion to a 64 bit database is done automatically. No additional conversion is required to enable 64 bit functionality. Similarly, if you are migrating a 64 bit database to a 32 bit platform the downward conversion is performed implicitly.

You should also remember that it is generally only possible to migrate Oracle Applications databases of the same versions. There are only very limited circumstances where you can upgrade the database as part of the migration. Version compatibilities are discussed at the start of each database migration Note. 

It's inevitable with Applications databases that export files are going to be large. Datapump supports the ESTIMATE_ONLY parameter that can be used at the command line to estimate the size of the datapump export files that will be generated.

3. Migrating the Application Tier to a New Platform

The main notes to follow are:
These notes explain how to migrate the Apps application tier to a new platform. The 11i note can be used to migrate to all supported Unix and Linux platforms, not just Linux. However, these Notes cannot be used to migrate the application tier to a Windows platform.

The first section of the Notes covers the prerequisite requirements of the migration. This migration method requires AutoConfig and Rapid Clone.

The final step in Section 1 requires you to run Maintain Snapshot in adadmin. This must be run, and it must run successfully. Snapshot information is stored in the following tables:
The migration requires you to create a manifest of your application tier file system based on the Snapshot taken in the preceding step. This manifest is then uploaded to My Oracle Support and is used to generate a custom migration patch. The custom migration patch created is specific to your upgrade only and contains all the files contained in the APPL_TOP that are binary specific to your new target platform. This patch is therefore applied in your new environment.

When performing the application tier migration, you are required to install a new application tier technology stack. These are the Developer and Application Server Oracle homes. This is a good opportunity to install the latest version. For example, if you are migrating an 11.5.9 environment, you can still install an application tier technology stack.

The same rule applies with the R12.0 and the R12.1 technology stack. There is no requirement to upgrade to 12.1 if you wish to use a 12.0 technology stack. Remember, even if you are maintaining your existing technology stack versions you will still need to download and build a new installation staging area for your new target platform.

Remember to check all the patches you have applied to the source technology stack previously as it is conceivable you have applied patches on your old technology stack that have not been applied to the newly built technology stack. 

4. Partial Migration to a New Platform

There's no particular reason not to migrate the database or application tier in isolation to a new platform. It may be, for example, that you are currently running the E Business Suite on a single node and you're encountering resource or performance problems. You therefore decide to migrate Forms and web application tier processing to a new node which is running on a different platform to your current environment. This is generally described as a split configuration. You should be able to just follow the same Notes to perform this migration.
Tip:  Remember, if you only migrate Forms and Web services to the new platform, in your new environment you will now have to download and apply each E-Business Suite patch twice (once for each platform) as you will  still have concurrent processing being handled on the database tier.
For the above reason, if you're planning to run a split configuration, I would always tend to advise running all application tier services (including admin and concurrent processing) on one platform and using the other platform exclusively as a database tier. This means E-Business Suite patches only need to be applied once at the new application tier level.
In the early days of 11i there was a perceived performance advantage to having the database and concurrent processing on the same node. This is no longer an architectural requirement, given the vast improvements in network bandwidth.  You are free to locate your batch processing services on a different physical server than your database tier.

There is an additional maintenance overhead of running multiple application tiers on different platforms, so you should take that incremental cost into consideration when planning your architecture. In all cases, you should always locate all nodes in the same data centre and ensure the fastest available network connection between nodes. This configuration should also be more scalable allowing easier introduction of additional nodes at both application and database tier levels.

The above conditions regarding concurrent processing and the database tier apply equally to Apps 11i and 12.

5. Sharing the Application Tier

If you're contemplating a migration and are using multiple application tiers then this is often a good opportunity to implement a shared application tier architecture. A shared application tier means storing a single application tier filesystem on a shared disk accessible to all application  tier nodes. Each application tier node continues to run all or a subset of application tier services however all application tiers access the same single disk subsystem. This reduces maintenance as application tier patches only need to be applied once and therefore may reduce future upgrade or patching downtime.

If you are running multiple application tiers in your source environment (on the same platform) and plan to use a shared application tier on your target environment then you should merge your application tiers on the source environment before migrating. This means only having to migrate a single application tier. The merge process is described in Note 233428.1 for 11i.

In R12 all applications tiers have a full application tier file system installed, even if the application tier is only configured to run a subset of application tier services. This means there is no need to merge application tiers in the same way as was required with 11i.   

A shared application tier can be configured in conjunction with third party software and hardware load balancers.

Top Five Migration Tips

So to conclude, here's a top five list of things to consider when migration Oracle Applications to a new platform:
  • Perform as much of the migration as possible outside of the production system downtime
  • Consider a shared application tier configuration if you plan to use multiple application tiers
  • Place all nodes in your E-Business Suite environment in the same data centre regardless of the location of your users
  • If using a split configuration, do not feel compelled to retain concurrent processing on the database tier
  • Use transportable database functionality to migrate the database tier if your source and target platforms have the same endian format

Related Articles

Wednesday Sep 23, 2009

Field-Tested Advice for Smooth EBS Upgrades

Premier Support for Oracle E-Business Suite Release 11.5.9 ended in June, 2008.  If you are currently running 11.5.9 or earlier and your immediate plans do not involve an upgrade to Release 12, then it's a good idea to move up to the terminal release of Apps 11i: This will ensure you remain supported and can make the most of any technology stack and functional upgrades. 

A lot of what you do as part of an upgrade to will also ease your transition to Release 12, so this upgrade can be considered as a Release 12 prerequisite exercise, too. Critical patch updates, roll-up patchsets (RUPs) and new technology stack certifications are still being released for Apps, and the more up-to-date your system is, the easier it will be to apply these when they come along.  This article takes you through some of the best tips from Oracle Support to ensure a successful upgrade to EBS

Screenshot patch 3480000.png
Tip #1: Give Yourself Enough Time

The first and most important piece of advice is to give yourself enough time. If you have not done an upgrade like this, then don't create a project plan with fixed dates and times until you have a good feel for what the upgrade will involve and how long it will actually take. Your current E-Business Suite release and database version will dictate how much work you have to do. Not surprisingly, if you are running Apps 11.5.2 on the Database, you will have your work cut out for you.  If you are on 11.5.9 and, then your job will be much easier.

We talk to a few customers who have decided how long they have to complete the entire project before even contemplating what work is required. Don't fall into this trap. Nobody likes working with a gun to their head, least of all, one that they're holding themselves.

Remember this is not just a technical upgrade. The Maintenance Pack has functional and technical implications.  Even if the upgrade is not motivated by functional requirements, it will certainly require User Acceptance Testing.

Tip #2: Read the Documentation Beforehand

Engineers in Oracle Support would be the first to admit that navigating through a combination of Oracle manuals, Notes from My Oracle Support and adpatch readme files and then corralling all that information into a coherent upgrade strategy can be an intimidating task. The temptation to use documentation that is not specifically written for the E-Business Suite or to devise an upgrade strategy of your own can sometimes look very appealing.

It's not difficult to find a document that appears to apply to your circumstances but then have Oracle Support tell you that you need to be following a different document.  Documentation that is specific to Oracle Applications exists for upgrading just about every component of the technology stack. If, for example, you can't find the Note that talks about upgrading or patching Developer 6i (Note 125767.1) then raise a Service Request (SR) with Oracle Support.

Tip #3: Don't Take Any Undocumented Shortcuts

We're sometimes asked, "What if I ignore Step X of my upgrade? Will it still work?" This is an almost-impossible question to answer.  In Oracle Support, we're not insensitive to questions such as this, but the reality is that we will probably not be able to give you a clear and unambiguous answer.

Our published documentation is designed to achieve a successful upgrade. It is not tested by trying to perform the upgrade steps in a different order or by deliberately omitting steps to see how the upgrade will turn out.  You should perform all steps in the upgrade documentation unless you have a clear reason not to, or clear guidance from Oracle Support that a step can be omitted.

Given the above, it's also no surprise that a common question we get from customers is "Here is my upgrade plan. Can you go through it and tell me if it's OK?"  This is a perfectly understandable question to ask but sometimes a tough one to answer, especially if the upgrade includes platform migrations, technology stack updates, and Oracle Applications upgrades. 

We'll try to do out best, but it's difficult for us to give an unconditional endorsement of an upgrade plan that greatly varies from our documentation. Circumstances may sometimes force you to perform upgrade steps in a non-standard order. We're always happy to discuss variations, but it is unlikely we will be able to give you a carte blanche endorsement of an entirely bespoke upgrade, since we are unlikely to have ever attempted an upgrade in the way you might describe.

Tip #4: Get the Latest Patches and Maintenance Tools

Start by reading Note 316365.1: the Maintenance Pack documentation. This has all the major steps you may or may not need.  The Upgrade Manual Script for the Maintenance Pack (TUMS-MP) will also create a report listing the steps which are required -- specific to your system -- therefore telling you what steps can be omitted.

Apply the latest AD patchset as early as possible in the upgrade.

Whenever you see a patch specified in documentation do not assume this is the latest incarnation of this patch. Check on My Oracle Support to see if it has been superseded. If it has, apply the latest version whenever possible.

Implement AutoConfig if you have not done so already.  If AutoConfig is only implemented on the application tier, then implement it on the database tier without delay.

Install and run the Technology Stack Validation Utility. If this reports any errors then, instead of trying to address each issue individually, I'd encourage you to just go to Note 146468.1 and build new 8.0.6 and iAS ORACLE_HOMEs using the install media. This will save you time.

Tip #5: Switch to the Oracle Applications Tablespace Model (OATM)

OATM is the latest Oracle Applications tablespace model. Instead of having separate tablespaces for each product, it converts your system to use a greatly reduced number of tablespaces. This is installed by default in fresh installations from 11.5.10 onwards. It will almost certainly reduce the overall footprint of the database, will simplify administration, may improve performance, and is mandatory for Release 12.

It will take some time to migrate all your database objects to the new tablespaces, but the benefits are worthwhile. The opportunity to optimise a database that may have been running for several years should not be underestimated.

Tip #6: Configure database for new products and new tablespace requirements

With each Maintenance Pack release there tend to be some new products introduced.  These products have to be "spliced" into your existing database and APPL_TOP.  Pay particular attention to the patch readme and complete all steps.  You cannot avoid adding these new products simply because you do not anticipate licensing or using these products.  This is a mandatory step. 

Tip #7: Upgrade the database (conditional) 

Releases 10gR2 and 11gR1 are currently supported for the E-Business Suite.  If you're running an earlier database release, you need to upgrade to at least 10gR2, and preferably 11gR1.  You can currently upgrade to E-Business Suite Release 12 only if you are already running Database Version 10gR2 or 11gR1.

There are specific Notes for Oracle Applications users when upgrading the database:
The default method is to use the Database Upgrade Assistant (DBUA) to upgrade Oracle Applications databases.  The upgrade will invalidate a large number of objects in the database.  You need to decide whether you want DBUA to compile these automatically or whether you want to compile them manually later.  You can configure DBUA accordingly before starting the upgrade.  If you're currently on 10gR1 or an early release of 10gR2 then take the opportunity to upgrade to or 11gR1.

Install the Data Mining and OLAP options as instructed. This is a mandatory step, even if you're not using products that require those options.

Tip #9:  Monitor the Upgrade Driver

The main part of the upgrade to EBS is performed by the upgrade driver supplied in patch 3480000. This should complete without error -- no jobs should be skipped or ignored. If you find yourself having to skip jobs without a very good reason, this suggests something that should have been performed earlier has been omitted or has failed.  Skipping a job may have consequences for subsequent jobs as data or objects may be accessed by several workers during the upgrade driver.

Accept the default number of workers unless you have a good reason not to. Substantially increasing or decreasing the number of workers you use may affect the performance of the upgrade driver.  While it may be a worthwhile exercise to experiment with the number of workers you use, you should always use the default number as your benchmark for performance.

Tip #10: Rehearse Your Upgrade Process Thoroughly

As Support engineers, we generally advise performing a minimum of three test upgrades prior to performing a production upgrade. This means three complete upgrades from start to a successful conclusion. This iterative process allows you to find possible pitfalls during the production upgrade and have workarounds ready.  If you encounter issues during your production upgrade that were not encountered in testing then -- and I apologise for being blunt here -- you probably have not done enough testing. The production upgrade should mostly be a formality, not the most stressful phase of the whole project. 

We often talk to customers who encounter a series of errors during one of their test upgrades. For each error, a workaround is found and the test upgrade proceeds. The workaround may involve applying a patch that should have been applied earlier in the upgrade, perhaps resizing a tablespace during a patch, or changing a value in an initialisation file or something similar. These errors should be noted and then another test upgrade performed with these workarounds in place so the error no longer appears. There can come a point during a test upgrade where an error is encountered and several things are tried before the successful workaround is found.  If you find yourself in this position at several times within the same test upgrade, it is often advisable to start a new test upgrade and not continue with this test upgrade. This is because this particular test upgrade (usually very early in the project) is no longer representative of what you would actually do in your production upgrade, therefore invalidating your initial testing conditions.  As Oracle Support engineers, we don't advise this lightly. Sometimes the best advice is to give up and start again.

Because of the above, it's advisable that during each test upgrade, you backup the system at each major step in the upgrade.  If you then encounter a problem during an upgrade that results in your abandoning that particular step, you only need to revert back to the latest backup rather than rewinding to the start of the upgrade.

Rehearsing your upgrade also allows you to fine tune the process. Testing should give you the chance to record the whole upgrade with each step documented and timed. With this upgrade documentation you may see stages where, for example, you can merge patches into a single step. You can use adpatch command line parameters to avoid generating forms or reports in the middle of an upgrade that are perhaps going to be updated and compiled again further along in the same upgrade by another patch. Refinements like this will reduce the time of the overall upgrade. This refinement process is how you manage to turn your first test upgrade that might take two weeks into a production upgrade that you have to complete in 36 hours for example.   

All test upgrades should be performed on a very recent clone of your production environment.

Tip #11: Be Aware of Database Tuning Opportunities

We're sometimes asked whether fine tuning of database parameters or other components of the technology stack can enhance the performance of the upgrade. There are some pointers within the documentation suggesting when you can do this. I personally find that careful refinement and optimising of all the steps that you perform during the upgrade as a whole will reveal more opportunities to reduce the time the upgrade takes than specific database tuning. That said, it never hurts to look out for opportunities to optimise database performance.

Wrapping Up:  Upgrade Myths

So finally, here are the top 5 myths (from an Oracle Support perspective) about upgrading to E-Business Suite
Myth #1:  Shortcuts are safe

There are no safe shortcuts.  This upgrade can't be done by performing a fresh install of, linking this installation to your 11.5.x database and then applying the database portion of the Maintenance Pack. It's a nice idea, but it is a flawed strategy

Myth #2:  You can safely ignore adpatch worker failures

No, this is very dangerous.  It is not acceptable to skip worker failures in adpatch because the errors are in products you do not intend to use.

Myth #3:  You can export from an old database version to a higher one

It is (generally) not supported to upgrade an Applications database by exporting from one database version (8i for example) and importing into a fresh empty database of a later version.

Myth #4:  You can ignore unused products

It is not acceptable to ignore the installation of new products just because you do not intend to use those products. 

Myth #5: You can live without AutoConfig

AutoConfig must be implemented on the database tier -- this is mandatory and will improve your quality of life
Good luck with your upgrade!

Related Articles

Friday Aug 07, 2009

Oracle Universal Installer Inventory Essentials for Apps Sysadmins

We see quite a few Service Requests (SRs) where E-Business Suite customers have gotten into difficulty with the Oracle Universal Installer (OUI) Inventory.  It's important to note the Oracle Universal Installer Inventory has nothing to do with the Oracle E-Business Suite Inventory product (product code INV).

Screenshot of generic Oracle Universal Installer dialog box

The Oracle Universal Installer Inventory is a component of the OUI and creates a record of the Oracle homes, products and patches you have installed on a node. Whilst it's not part of the E-Business Suite, as an Applications DBA it's inevitable that sooner or later you will have to look after the Inventory. This article will focus on issues relating to the OUI Inventory specifically within the context of Oracle Applications.

An Overview of the OUI Inventory

The Oracle Universal Installer Inventory comprises three main components:

  • The Pointer File
  • The Central (Global) Inventory
  • The Home (Local) Inventory

Central Inventory and Home Inventory are the official names, however, almost everybody talks about the Global and Local Inventory so it's useful to mention this now as the terms are often used interchangeably.

The Pointer File, created or referenced when running the OUI or rapidwiz, is called oraInst.loc and is used to either locate an existing Central Inventory or tell OUI where to create a new Central Inventory. It's a simple text file, stored, by default, in a system directory. In the Microsoft Windows environment it is stored in the registry key \\HKLM\Software\Oracle\INST_LOC.

The Central Inventory records details of Oracle homes installed on a node. A single node might contain one Central Inventory with details of all Oracle homes on that node, or a single node might contain multiple Central Inventories each one containing details of a single Oracle home.

The Home Inventory is specific to, and contained within each Oracle home, and contains details of patches or updates applied to that specific Oracle home.

This article will concentrate on the Central Inventory as, generally speaking, the Home Inventory looks after itself.

Central Inventory Differences Between Apps 11i and R12

In Apps 11i, the default action was to use a single Central Inventory -- that is, one Central Inventory per node -- which recorded all Oracle homes installed on that node. The Central Inventory Pointer File was stored in a system directory to which you had to have write access. This was why during an EBS 11i installation, or when cloning to a new node, you would be prompted to run scripts as the root user before you could complete your installation or clone. If you had multiple 11i installations on a node, these would generally all be recorded in the same Central Inventory.

In Apps R12, things have changed. If rapidwiz is not able to automatically create a Pointer File in the default system directory, it will create multiple Central Inventories and multiple Pointer Files. Instead of prompting to run a script as the root user, a separate Central Inventory and Pointer File will be created in each Oracle home created on the node.

Things have the potential to get complicated when you have multiple Oracle Applications installations on a single node, or where 11i and R12 installations are both installed on the same node. Start cloning to and from this same node and soon you may be forced to pay attention to the Inventory.

How EBS Creates and Updates the OUI Inventory

Here are a couple of typical examples of how the OUI Inventory is configured during an Oracle Applications installation.

Scenario 1: Upgrading Apps 11i to 12 creates multiple Pointer Files and Central Inventories

A typical scenario might be that you have an 11i test environment installed on your node. You plan to upgrade sometime soon and wish to install a simple R12 test environment on the same node.

By default, the operating system user installing R12 will probably not have permission to update the Central Inventory created by the previous 11i installation. In this case, multiple additional Pointer Files and Central Inventories are created within the new R12 Oracle homes. This in itself is not a problem but it is important that you understand that this may be what is happening.

Scenario 2: Upgrading Apps 11i to 12 updates the Global Inventory

Using the same starting scenario as above, if your R12 operating system user has write access to the Global Inventory created by 11i, then rapidwiz will update that Global Inventory with details of the new Oracle homes installed. Again, this is not a problem, but it is important that you are aware of what is happening.

When multiple Central Inventories exist, you must to be aware of this, as the correct Pointer File will need to be specified when maintaining the Oracle homes to maintain the correct Central Inventory.

Updating the Inventory When Removing an 11i or R12 environment

With the potential for single or multiple Global Inventories being created or updated, it’s important that when you delete an Oracle Applications environment from a machine, you make sure its corresponding Global Inventory entry is also updated correctly.

If your node is using a single Global Inventory and you wish to delete an Oracle Applications environment, it is not enough to just shut down the database and all the services and delete the software. This will leave a record of the installation in the Global Inventory.

To completely remove an installation, you must run OUI and use the graphical interface or the OUI command line to update the Global Inventory to record that the installation has been removed. If this is not done, then the Global Inventory retains a record of an environment that no longer exists on the node.

If you were to then perform a new installation or clone to that node at the same location as the previously removed installation, there would be a failure to correctly register the new installation. This could easily create an Oracle Applications installation which does not work correctly, or has links to non-existent locations. You might also have problems upgrading the technology stack or applying patches to this environment at a later date.

Tools for Managing the Inventory

Fortunately, there are various tools that allow you to check the condition of the Global Inventory on a node:

  • The Opatch utility has some useful command line parameters which allow you to interrogate and report on the condition of the inventory.
  • OUI and OPatch also support the “invPtrLoc” parameter which allows you to specify the inventory Pointer File you wish to use when you install or patch a product.

If you encounter a situation where your Oracle home is not correctly recorded in a Global Inventory, it is also possible to create or update the Central Inventory. There are several notes (see links in the Reference section below), which explain how to create or update the Central Inventory. There is also a note on how to consolidate multiple Central Inventories on a node into a single Central Inventory.

There is sometimes the temptation to manually edit the XML files that make up the Central or Home Inventory. Don't give in to temptation. The OUI Inventory should only be updated via Oracle tools such as the Oracle Universal Installer itself, the Rapid Install (rapidwiz), Opatch, and RapidClone.

Checking the OUI Inventory Log Files

During an installation or clone of Oracle Applications, the inventory creation or updating process is recorded in the log file called ohclone.log. The ohclone.log file will tell you if any aspect of the registration process has failed. You should always check this (and other log files) as part of your installation or cloning process.

Four Tips for Maintaining a Healthy Inventory

If you spend a lot of time installing and removing Oracle Applications environments and and have not really thought about the inventory in the past, you should keep the following in mind:

  1. Always deinstall the Oracle Applications technology stack using the OUI before deleting the software.
  2. Always check the ohclone.log after an installation or clone.
  3. If you know how your OUI Inventory is currently arranged, you should be fine. If you don’t, you should take a little time to familiarise yourself with the setup.
  4. Do not try to manually edit files that make up the Global or Local Inventory.




« April 2014