This article describes how updates should be deployed in a standard iCM installation in a Windows environment. Of course, if you host with us, we'll take care of all of this for you.
Updates are tested and released by our core platform team. Due to their integral nature, it's generally not necessary or possible to "roll back" individual files. If you are concerned about deploying files yourself, we recommend taking a full backup of all iCM directories and the database before proceeding, allowing you to restore iCM to a known state.
What is an "Update"
A platform update is a collection of files, deployed into the root iCM directory. Some updates are created following support calls, others add new functionality.
Unless they relate to security, updates are released on a fortnightly schedule, and can be downloaded from the support area of the main GOSS Interactive website, where you'll also find a copy of this article.
Updates are supplied as a single zip file. When we release a new update, a new zip file is issued containing all previous updates, so you'll only ever need the latest to get all previous updates for your version of iCM.
The update zip file includes a readme.txt file. This lists details for every fix and update, the files included, what is being fixed or changed, the date of release, and our version control revision number.
The first section of the readme file describes the installation steps. You should always follow those steps because there may be special instructions relevant to a particular update not covered in this article.
1. Stop the iCM Server Service
While you're deploying updates, iCM needs to be stopped. This means your users won't be able to log in for a few minutes while the files are being deployed.
2. Copy Update into the ROOT Directory
Unzip the update directory. It will contain an "icm" folder and might also have a "WEB-INF" folder, depending on what is being updated. Paste both into the ROOT directory of your iCM installation, typically E:\iCM10\tomcat\webapps\ROOT. If prompted, choose to replace any files already in the directory.
3. Start the iCM Server Service
You can now restart the iCM service from the same Windows Services Manager you used to stop it. iCM will now be back online, but there are a few more steps to perform before letting your users log back in.
4. Run iCM's Autoconfig Tool
Autoconfig holds background configuration settings for iCM. It's generally only ever used when iCM is first installed - and after deploying updates. It's normally available at http://[normal-iCM-URL]/autoconfig. Autoconfig is not usually available over the internet, you'll probably need to use a browser on the iCM server to access it.
Run autoconfig, pressing "Next" and "Finish" to navigate through all of the pages. You don't need to make any changes, it just needs to run all the way through.
5. Update any Worker Services
Log into iCM. Using the iCM/API Servers section of the System Configuration menu, edit each of your API Servers and check if any workers have updates available. You can use the "Update all running services" option in the action panel. There won't be any updates to install if the fixes don't include any. See iCM/API Servers for more information about managing API Servers.
6. Import New Form Families
If the update includes any changes to the form family (new or improved field types) you'll need to import the latest family and republish your forms. Before you can import a new form family you will need to disable the restricted content lock in iCM's autoconfig (and re-enable it immediately after the import).
Import the form family from the File Manager. You can republish all of your forms in one go from the menu in the Forms Library.
7. All Done
That's it! It's often best for users to clear their browser caches before logging back in.