Installing MAPI Connector in a distributed business

MailEnable's Connector for Microsoft Outlook provides a rich messaging and collaborative interface to MailEnable.
Post Reply
RNEUSCHUL
Posts: 92
Joined: Wed Jan 27, 2010 11:16 pm

Installing MAPI Connector in a distributed business

Post by RNEUSCHUL »

It's likely that my searches have failed to find the right docs but so far I cannot see any way of automating the distribution and installation of the Outlook Mapi connector in a business environment.

Any business with more than a few dozen users needs to be able to take their exported list of ME accounts/passwords and use that to automate the attachment of the MESetup.exe file to an email to each user such that when the attachment is executed [run] by the recipient it carries out a full installation and configuration of MAPI with full Server data and UID/PW to connect them to their Mail Enable account. In other words no user involvement other than "running" the attachment in the first place.

Having to manually install and configure the MAPI Connector on each desktop or laptop - or talk users through this process - is going to be an unmanageable support burden: before anyone suggests using GPOs and application installation policy processes - yup, that works fine on an integrated local network. It isn't a process that works well or reliably in a nationally distributed environment with several hundred users and locations, very few of whom are participants in an Active Directory. Yes, we know GPOs work locally too, but they can be fragile beasts at the best of times.

Does anyone have any thoughts on this? Or have I simply missed the documentation that tells me how to do all this?

Robert

Marcusg
Posts: 50
Joined: Wed Nov 04, 2009 8:18 pm

Re: Installing MAPI Connector in a distributed business

Post by Marcusg »

I think it would be nice to have a msi file that could be put into a ris image. Or an additional utility to configure/reconfigure the account settings once the connector is installed.

RNEUSCHUL
Posts: 92
Joined: Wed Jan 27, 2010 11:16 pm

Re: Installing MAPI Connector in a distributed business

Post by RNEUSCHUL »

I agree: especially if it could be used with script variables and a data source list so one can create individual mails to users and have each item preconfigured with the correct mail server address, UID and PW.

We have one client who is just testing Enterprise version, they're planning on rolling out to some 150 sites of theirs across the UK; logging in to each machine via RDP in order to configure Outlook with the MAPI connector would be hell on earth, as well as taking far too long to be economic.

MailEnable
Site Admin
Posts: 4441
Joined: Tue Jun 25, 2002 3:03 am
Location: Melbourne, Victoria Australia

Re: Installing MAPI Connector in a distributed business

Post by MailEnable »

The mesetup installer itself can create an Outlook Profile on installation (although the ability to do so has not been documented and is presumably largely untested).

It currently occurs if you set this registry key prior to installing the client:

HKCU::SOFTWARE\Mail Enable\Mail Enable\Clients\MAPI
Value Name: REG_SZ: Profile Name

In terms of the information used to provision the profile, there are currently 2 options:

1. Gather and Best Guess:
-------------------------------
Currently gathers the windows domain name, logged in user, dns settings and attempts to best guess the profile construction.

2. Pre-Set HKCU reg keys
------------------------------
You can also override the detection process by pre-configuring the registry keys under HKCU::SOFTWARE\Mail Enable\Mail Enable\Clients\MAPI
If they exist then the installer will use those pre-sets rather than attempting to query them from the client workstation.


From whats discussed here, it seems that it may be desirable to extend this capability and have the installer contact a web service passing all this information and have that webpage/script return actuals via parsing and logic processing.

The end result would be that the installer would be passed a switch (or check for a pre-set registry key) which would then pass its detected user settings to. That receiving web page could then query a database (and/or use the mailenable API to query user details) to which it would return to the client for the ongoing setup.

I think that it would not be difficult for us to implement the client side functionality (assuming it is something that might be useful as a deployment option).
Regards, Andrew

RNEUSCHUL
Posts: 92
Joined: Wed Jan 27, 2010 11:16 pm

Re: Installing MAPI Connector in a distributed business

Post by RNEUSCHUL »

Andrew

Adding a web-based feedback/validation and user data confirmation/installation capability would be absolutely perfect - at least for our clients - especially if it's over an SSL connection: as far as our client is concerned, any requirement for users to install and configure anything manually would be a deal-breaker - it just will not fly - either at board policy level where there are compliance issues to address, or at the practical operational support level. Similarly, the notion that the support team might have to RDP/VNC to each remote system in turn to install and configure the connector is - quite simply - a non-starter - it's far too time consuming [and therefore costly] and in many cases also impractical.

It's cheeky to ask, but do you have any idea how quickly you might be able to implement such a service?

On a wider note, is there any chance that the "hidden" MAPI Connector documentation could be published?

MailEnable
Site Admin
Posts: 4441
Joined: Tue Jun 25, 2002 3:03 am
Location: Melbourne, Victoria Australia

Re: Installing MAPI Connector in a distributed business

Post by MailEnable »

Robert, I have some additional ideas and considerations (before we start picking up the shovel and making it happen - which in any case seems straight forward and should take less than a week for us to implement).
Adding a web-based feedback/validation and user data confirmation/installation capability would be absolutely perfect - at least for our clients - especially if it's over an SSL connection: as far as our client is concerned, any requirement for users to install and configure anything manually would be a deal-breaker - it just will not fly - either at board policy level where there are compliance issues to address, or at the practical operational support level. Similarly, the notion that the support team might have to RDP/VNC to each remote system in turn to install and configure the connector is - quite simply - a non-starter - it's far too time consuming [and therefore costly] and in many cases also impractical.
Firstly, MailEnable does require some software to be installed on the on end user machines. In any case, this installation will either need to happen by automated deployment (Policy or Script) or as a last resort... mailout instruction to download and run the exe.
The reason is that the client outlook installation will need the necessary libraries to contact the MailEnable server. Unfortunately, there is little that can be done about this step. I should point out that if you were to move ahead with MS Exchange, these libraries are distributed with Outlook - so this is a Non-Exchange constraint.

Secondly, assuming the above is in some way achievable, we could make the installation of the MailEnable DLLs silent/non-GUI and simply ask the user for their e-mail and password when the launch the Outlook profile created by the silent installer. ie: When the user launches outlook, they are prompted for their e-mail address and password (and the rest of the information is derived form that). It would (optionally) submit over SSL to a web page to verify and return exact match.

Also, if the users are not under the same security realm or directory (ie: they are in different locations/network environments), then there will be problems hooking them up to a server based mailbox irrespective as to the backend system. (Even if you attempted to deploy Outlook Exchange users, you still would have issues fully automating the profile creation under a distributed scenario, because the users are possibly on unknown networks/directories).

The difference in this revised approach is that while you still *somehow* need to get the executable run on the users machine, the configuring of their profile would happen when they first launch outlook based on simply asking them for their e-mail address.

Do you think this would work in your scenario?
Regards, Andrew

Marcusg
Posts: 50
Joined: Wed Nov 04, 2009 8:18 pm

Re: Installing MAPI Connector in a distributed business

Post by Marcusg »

@Andrew

It may just be me but I read Robert's statement to mean that inside of webmail there might be some kind of link that pushes the user to an executable that's been given the proper variables. IE. uid, server address, e-mail address, etc. Then with very minimal input (password, share connections etc) it would do all the hard work and voila, open outlook and there's your whole world.

On that note, you could really help out client IT groups wanting to push this automatically by adding an option in the MEsetup to link an old pst to the install and import from that pst into the new mail-enable. This would completely bypass outlook's pst import tool and allow ME more granular control of what gets mirrored over to the mail-enable server. Finer character control, the ability to merge folders, the ability to give an end user the choice of how to handle problems, better error reporting, and the ability to pre-apply quotas would all be things you could do that currently are impossible to do via a typical outlook import. I'd say that about 80% of the issues we've had so far involve importing an old pst through the MAPI connector after it's installed in outlook and any additional functionality there would be greatly appreciated.

I'd venture to bet most of us chose Mail Enable because we hate MS and Exchange but we're stuck with Outlook. Kudos for the one server for all licensing btw, that's definitely got us hooked.

I might add that in a larger organization this, (in any case) is still going to be a monstrous task, with exchange, Mail Enable, or any other server. Particularly if your users ALREADY use outlook with calendaring or contacts because you'd have to find a way to export/save/import that information correctly and there are still some (if not very many) hiccups there as I understand. If this functionality is every added you might want to add a way in ME server to enable/disable this webmail link for particular users or sets of users as this would never be something you want to do in mass, but in smaller bite-sized chunks. I guess it would be a bit easier for those that use the outlook sync tool, but there's still the question of getting the e-mails put into the folders the way the users saw them in outlook. At least if you used POP.

Anyhow it's good to see some attention here. We have one more minor issue before we'll be ready to do a roll out, but then again, we're much smaller than you're typical customer.

RNEUSCHUL
Posts: 92
Joined: Wed Jan 27, 2010 11:16 pm

Re: Installing MAPI Connector in a distributed business

Post by RNEUSCHUL »

Andrew

Let me lay out the scenario for you in /this/ specific client case, it may help to illustrate the problems:

Broadly speaking we have a distributed business with several regional admin offices, plus lots of mobile users and a number of fixed sites. Currently each of the admin offices has its own AD domain, some with Exchange, some without. As a part of a long term continuity and resilience strategy we're gradually moving the client into a single integrated forest, where most of the core services will be delivered from the cloud. Mail Enable will - we hope - form a key part of that strategy - delivered from a high availability cluster in the cloud: we'll be using different post offices [and sub-domains] for each of the admin offices, plus additional post offices for mobile and site-based staff.
Sites and mobile users are currently not in an AD. Sites rarely have more than 2 computers.

All in all we therefore have a mix of about 4 AD domains, plus lots of solo machines/users in various different local Workgroups. Currently we have a not very efficient mail server which delivers all relevant mail to the 2 Exchange servers, whilst the remaining users collect their mail via IMAP.

With Server 2008 and its enhanced HTTP/RPC and Remote Desktop/Remote Application services delivery - plus the cloud - we finally have the opportunity and capability to integrate everyone into a single coherent structure without further reliance on local Exchange Servers - and Mail Enable Enterprise with Outlook/Mapi & Webmail and Mobile Mail fits into that architecture very nicely.

As far as our remote users and sites are concerned we have no issues with allowing/permitting the installation of anything that's required: my significant concern is to keep labour time and labour costs to a minimum - especially since almost all users a] don't have admin/install rights and b] are distinctly non-tech and generally not to be trusted with managing installations anyway. We know the admin and user passwords for all machines, we have RDP capability for 99% of the machines [and will have it for the remaining 1% by the time it matters].

That rather messy problem domain would be resolved very nicely by a web service of the kind you describe.

My ideal here - and I suspect it would be the ideal for many SYstems Administrators - would be the ability to customise delivery at the Mail Enable web service on a per user basis - to 'read' the Post Office user/password databases [or to accept a CSV input file] and generate a unique pre-packaged one-time URL and email for every user we wish to 'activate' in this way - that way when the user clicks on the URL it will be unique to their machine and will have the correct run_as administrator UID/Password embedded to permit it to close any open instance of Outlook, install any required libraries, install the connector and/or ME Synchroniser, add the required mail server and user account data, and then restart Outlook with the new mapi service as the default account. Once the URL has been "run" once it should be deleted/deactivated and no longer be valid: if the install fails for any reason then the ME sysadmin needs to regenerate the URL and associated email and download access.

I'm not entirely sure how well or easily what I'm describing fits with what you think you can achieve. If it helps, perhaps we should continue this discussion by direct email.

Robert

RNEUSCHUL
Posts: 92
Joined: Wed Jan 27, 2010 11:16 pm

Re: Installing MAPI Connector in a distributed business

Post by RNEUSCHUL »

Marcus

Your analysis of what I want - and what others are likely to need or want - are spot on: ME Enterprise with Mapi and Outlook Synchroniser has the potential to cut or significantly reduce the SysAdmin burden - especially if we can deliver easy import/export functions - not just for pst but also old mbox/mdir files from other mail clients. Similar issues exist across the OS divide with Entourage and Apple Mail.

If we reduce the admin burden and enhance the functionality and ease of use for end users then we're [probably] improving productivity and reducing costs: all of which give sysadmins and CTOs even more reasons to recommend and implement ME.

This whole Outlook thing is going to get /very/ interesting and complex when Office 2010 starts to ship and companies start delivering Remote Applications from 2008 servers. The ability to "prepackage" their users' accounts directly from the same server or portal gateway that's delivering ME services will become essential to customers.

Robert

RNEUSCHUL
Posts: 92
Joined: Wed Jan 27, 2010 11:16 pm

Re: Installing MAPI Connector in a distributed business

Post by RNEUSCHUL »

Andrew

Sorry to push, but do you have any further news on progress towards a web-enabled installation service?

Robert

Post Reply