Microsoft occasionally releases hotfixes that are made available to you via your Partner or customer source. Services packs or second releases (for example, R2) are also released this way, but this is beyond the scope of this book.These hotfixes are installed as a model per hotfix to the SYP layer. The update must be coordinated with your Partner, who will apply the hotfix to its system and release an updated model of the supplied code. The only conflict resolutions you should be concerned with are conflicts to the code in your layers.
A hotfix can affect the following components:
Applying a hotfix should be done in a controlled fashion, tested, and deployed as per any change to your live environment.
This would entail refreshing a test environment from live to create a sandboxed environment so that the update can be applied and tested in isolation.
Hotfixes may make changes to code that is already modified in layers above the SYP layer (for example, ISV, VAR, CUS, and so on). If this is the case you should contact the authors for an update of where they have already merged the code from the hotfix. If not, you will have to merge the code into one of your layers.
The hotfix is normally delivered as a self-extractable ZIP file, containing another compressed file. Decompress both the files into a hotfix folder specifically for this hotfix. This should be a server share, set up for storing hotfixes. The steps for performing this activity are as follows:
Securityadmin
or greaterdb_owner
Once extracted, you will be able to see the following files in the root folder of the hotfix:
AxImpactAnalysis.exe
AxUpdate.exe
The first step is to analyze the potential impact, and the second is to perform the update.
In order to perform the impact analysis, the following steps are to be performed on a computer that has the AX client installed:
AxImpactAnalysis.exe
and select Run as administrator… which opens Update Setup in Impact Analysis Mode.If a baseline database doesn't exist, one must be created prior to this process.
Assuming the hotfix does not require a code upgrade, we can apply the update and proceed with the application update element of the upgrade, if applicable.
In CU6, you must apply the binary (kernel) components before applying the database (application code) update; otherwise, the updates do not apply correctly. If binaries must be installed first, you need to run the update twice; first for the binary components and then for the database (application code) update. You are then free to apply the update to the remaining server and client computers.
In this example, we will apply this update to UAT, which is a sandboxed environment. No components for other instances are installed. We can apply the update by performing the following steps:
Axupdate.exe
file as an administrator. This is the default behavior for this file.You can't apply the update to remote servers, so this must be run locally on each server.
The final step is to start AOS and launch the client to complete the update by performing the following steps:
The Windows installer is used to apply the updates. The application update is termed as the database update, which is a misnomer; this is not your transactional database.
The processes involved here are not new, the application update to the model store is simply an AX model. The server and client components follow the same process as any other software update. These are not available via the Windows update, as we need far more control over the deployment than what is required for Windows and Office updates.
While applying the client component updates to a large organization, it isn't feasible to apply this PC by PC.
You can either use Group Policy or System Center (2007 or 2012) to deploy the client and the hotfixes.
The following link explains the process of mass deploying the client:
http://technet.microsoft.com/en-us/library/dd309709.aspx
The binaries within the hotfixes are supplied as MSP (Microsoft Installer Patch) files, which can be found within the Hotfix
folders in a folder called msi
if there are client components to be installed.
clientoba32
and clientoba64
(a 32-bit or 64-bit OS)components32
and components64
retailpos
retailposplugins
The msiexec
command for silent installation of the client is as follows:
msiexec /update clientoba32.msp /quiet /norestart
All other updates should be applied using AxUpdate
.
Once tested, you need to apply the update in live. In order to apply the database update (model store) to other environments (UAT, development, and so on). You are recommended to transfer the model store. You should use the environment refresh method for this.
After this is completed, you should run AxUpdate
on the relevant servers.
Another important method of simplifying updates to clients is Slipstreaming. This allows the installation of a new component or client to have any of the updates automatically applied.
You can apply the following types of update:
The model files are only relevant while installing the application for the first time. The same is the case for database (application) updates in the service packs and cumulative updates.
In order to use slipstreaming, you must store the AX 2012 installation files on a shared network folder and use this to install both server and client components.
Since the previous cumulative updates and service packs are replaced, only include the latest update in the Updates
folder.
To update the installation media to use slipstreaming, perform the following steps:
Updates
...\UpdatesCU6
).AxUpdate.exe
file is in the folder, copy the files and folders into a new folder.customer changes
, Internal
).Axponents
).Binary
)Models
.Models
folder.The folder structure you should have is as follows:
The preceding updates will now be installed whenever a new client, server, or component is installed.
18.225.95.245