Avaya One-X Portal, it’s a fantastic application, but it’s a nightmare for large deployments. If you have 200 users all wanting to use the client integration features, you’re going to have a problem when you install a new service pack on your IP Office. You will of course recognise the message:

The first thing you would normally do is jump onto the one-x web portal, and download the new client bundle, whilst this is fine for small deployments and a mild inconvenience, it becomes a big problem, because the IP Office no longer sits in the sub 500 seat space, and can now be used as a centralised phone system, with all the benefits that that brings, it has some down sides, such as this.

So, what do you do then? You need to remotely deploy the client to your enterprise workstations. How? Enter in your favourite management agent – System Centre (Other solutions are available, such as Meraki MDM, and I hope to cover that in another post).

First, go ahead and download the new client from the One-X web portal as you normally would, you’ll find it under Desktop Integration on the Configure tab. Download the unnecessarily long filename executable and save it somewhere.

Anyways, once you’ve got the file in a safe place (I should add – not on a network folder, unless you have a drive mapping set up) drop to command line in that folder you need to run the executable with the /a parameter. Select a Network location to deploy the image, I had real issues actually selecting a network location so just use a local path. Note, this will not update the client on your machine if you have it installed, it just creates the msi files and two folders (program files and Win).

Next, we need to customise the .msi file and inject your company data so that the one-x server, ports, and ssl settings are already in the client when it launches for the first time. This is important, just deploying the client isn’t enough, the goal here is to have as little end user disruption as possible.

Avaya recommend the ORCA tool for this, it’s available from here. Avaya’s implementation manual has the following to say on the matter:

After downloading and installing ORCA, right-click on the MSI file and select Edit with Orca.

From the left-hand Table item select Property Table.

From the list of tables select Property. Scroll to the bottom of the table, right-click and select Add Row.

Add the following Properties with corresponding values to specify one-X Portal server address, port and secure communication mode.

ONEX_PORTAL_SERVER = IP or FQDN, this must be FQDN if using secure mode.
PORT_NUMBER = server port number – 9443 if using secure mode
SECUREMODE = 1 for enabled or 0 for disabled

After adding all the properties, save the MSI file and close the ORCA tool

You can download the full document here, it gives quite clear guidance on doing this simply using group policy objects. However if you’ve invested in System Centre you want to use it, so lets crack on..

Your Orca-edited file should look like this when you’ve finished:Create a Share for this deployment package on your SCCM server, copy the files to it.

Now we need to create a new application in SCCM, so goto Software Library -> Application Management -> Applications, right click in the main window and Select Create Application. Brose to your network share containing the client and hit next, accepting the warning about not being able to verify the publisher.. Proceed to General Information and put in some information like version number. I also set an administrative category of Productivity. I also chose to install for system to accommodate multi user systems. Click next through the rest of the process.

Now that we’ve told SCCM about our package we need to deploy it. Right click on it and select Deploy. You will need to have a collection of devices defined to deploy your software to, select this under collection, if this doesn’t exist you will need to create it. Exchange servers don’t need this client installing on them, and you’re likely to piss somebody off if you try. Click next and select a distribution point.

On the next screen select action of install and purpose required. This is a mandatory install of software for this device collection, although I don’t think a deadline is necessary – so just click next on the next page.

For user experience, I’m going to leave these on for my environment, although you can turn them off if you wish. I’m also not going to configure alerts but of course you can if you want. Press next some more till you come to the end.

After the client machines run their cycle to detect new software, they will automatically and silently if selected download and install the client. This is great for machines that did not have the software before, but not so great for machines that have the out dated software on, as system centre’s default detection rules will identify it as already installed, so won’t do anything. Go back to Software Library -> Application Management -> Applications, and right click on the Avaya Clients App, go to Properties and Select the Deployment Types Tab, Select the entry that is there and click Edit. You then need to go to the Detection method tab and edit the default rule, click browse and find your msi file again, then select the bottom radio button and select Version from the MSI Property drop menu, the Value should be automatically populated, like this:

Existing machines will now get a message instructing them that the IT Department needs to make software changes to their PC, and attempt to deploy the new client on top of the existing one, unfortunately this will fail. We must first remove the existing client from the system, and what we’re about to do is a bit of a bodge because I didn’t have the old install msi kicking around, so I created a new folder on the distribution share and copied the files there, then I added a new application to SCCM as we did with the latest client, and ran through the settings again. Then I went into the detect the detection settings to match the old client that was installed unmanaged. After doing this I deployed the application however this time selected uninstall from action dialog of wizard.

After the client ran its Machine Policy and Application deployment cycles, Configuration Manager removed the old client, which in turn allowed the new client to be deployed. This was successful but despite the old client being removed it remained running, closing it prompted a notification from CM that the installation was successful, implying that the installer was pending the application being closed, or a shutdown/logoff event.

Thankfully updating the application this way requires zero user interaction, unless the application is running, but even then its a simpler process for then end user than manually downloading and installing, and allows you to leverage SCCM to ensure compliance with applications your business runs on.

I recently updates System Center and noticed one of the new features seemed to relate to force closing a running application during deployment, however I have no idea where I put the screenshot. Avaya are due to release a new version of their IP Office platform very soon so, I will optimize my time and investigate this new and exciting feature then. I’ll also post an update about how to manage the life-cycle of the One-X application more thoroughly.

Update: April 2018

Avaya have now moved the goalposts with this, and after upgrading your system to IP Office 10.1 SP2, clients are offered the software update within the application, however installation will require local admin access, so if you don’t allow this to your users, you may still be best deploying by SCCM.