|
Simon Fisher
Posts: 17
Joined: 2016-07-12
|
Hi, we've developed add-ins for both MS Word and MS Project. We're currently deploying these via a Click-Twice installer, with auto-updates enabled, and it works great when individual users install it on their own machines. But we're now encountering corporate environments where things are lot more controlled and we're not sure of the best approach. I'd appreciate any advice on how best to install our plugins - ideally keeping auto-update functionality intact.
So far we've hit these types of environments:
* Terminal Server (Remote Desktop Services)
An administrator needs to install the add-in on behalf of all users.
Currently we set RegisterForAllUsers to True, disable auto-updates, go through the Click-Twice packaging process, and only send out the MSI (we had problems with the standard installer exe). This works, but it's error-prone if you (or the administrator) don't do everything exactly right. We'd love to find a solution where auto-updates/prerequisites etc are still possible.
* Individual desktops, but users lack the ability to install software
An administrator needs to install the add-in on behalf of individual users, either manually or via Group Policy.
This is a new customer coming on board for us. We're thinking that for individuals, we could just give the admin our standard installer, and accept that auto-updates may not work (or would they?). For Group Policy, we have no idea - this isn't our area of expertise. Either way we really want to keep auto-update, otherwise it becomes harder to keep the plugins up to date (it's more of a burden on the administrators).
I'm sure others must have hit these scenarios before. I'd appreciate it if someone from Add-In Express or the community could provide a bit of advice on the best way to achieve auto-update in these cases, and make the installation process as easy as possible.
Thanks,
Simon |
|
|
Andrei Smolin
Add-in Express team
Posts: 18821
Joined: 2006-05-11
|
Hello Simon,
ClickTwice support automatic updates for a per-machine add-in: it starts a service that waits for all users to close the host application(s) and then runs the installer.
In the second scenario, with users being unable to install anything (even per user, correct?), your only option is GPO: you provide an admin with the next version of your .MSI and the admin deploys it using GPO. No automatic update is possible in this scenario.
In theory, you can look into replacing existing files with new ones. This will not work if the new add-in version contains a new or discards an existing component requiring COM registration, say, a Custom Task Pane (see the TaskPanes property on the add-in module). Also, if the host is running, you won't be able to replace adxloader.dll/adxloader64.dll and this is a source of potential problems if we introduce some change in adxloader. However simple the process above is error-prone so I cannot recommend it.
Andrei Smolin
Add-in Express Team Leader |
|
|
Simon Fisher
Posts: 17
Joined: 2016-07-12
|
Hi Andrei, thanks for the response.
Do you have any documentation on the Click-Twice per-machine solution?
Thanks,
Simon |
|
|
Simon Fisher
Posts: 17
Joined: 2016-07-12
|
I thought I'd post an update - through some trial and error, I've managed to get auto-updates working in a Terminal Server environment which I'm really pleased about. I'll quickly post the key settings I chose in case it's useful to others.
However, to the Add-In-Express team, I think this is a candidate for a blog post or some extra documentation, as to what some of these settings are actually doing, and how they can combine into the behaviour I was after. I'm being asked by IT Administrators what our add-in is doing to their system and it's been tough to answer without official documentation.
- Set RegisterForAllUsers to True for the addin module
- Create a new Setup Project following the normal process
- Open up the Publish dialog
- Under Preferences -> Updates, I chose the following options
- - Enable automatic updates
- - Allow silent updates
- - Write to system event log (not required but useful to see what's going on during the update process)
- - Start updater when I start Windows
- Under Preferences -> Updater:
- - Enable auto-download (I think this is ticked by default but it's a key one to check anyway)
It's also key that when you first install this new version, you do it via an elevated command prompt (this one tripped me up previously - the addin will install but may not register with Office properly).
After installation on Terminal Server, there are a couple of services running in the background to handle the update process. From the user's point of view, the update can happen while Word is open, but when it gets closed & reopened, my add-in has been updated without intervention.
It seems pretty simple now that I've got something working, but it wasn't intuitive that I'd end up with background services managing the update process.
Regards,
Simon |
|
|
Andrei Smolin
Add-in Express team
Posts: 18821
Joined: 2006-05-11
|
Thank you, Simon.
We will look into providing more info about ways to use ClickTwice.
Andrei Smolin
Add-in Express Team Leader |
|
Forums
Topics
Search
Help
Login
Register