14 Mar Which is the most appropriate method for managing your users in MailStore?
One of the things I like about MailStore is the simplicity with which local users can be managed, so I wanted to take a moment to provide you with an overview of the various options available to you in this area.
Before I start, I should point out, that for each member of staff having their email archived, an account must be created in MailStore and a user licence allocated.
One option is to create accounts manually within MailStore, entering the relevant information for each, which will typically include passwords, email addresses and access rights. This works perfectly well for smaller installations, but when dealing with more than a handful of user accounts it does start to make more sense to consider synchronising your MailStore user list with an external user directory service.
Active Directory
Active Directory configuration settings
Active Directory is the most commonly used directory service in MailStore and out of the box is easily configured using the auto-detect feature to query your settings. If you need to link into a specific Active Directory object container this can be entered manually for more control, but in most installations I’ve found the automatic option works just fine.
I also tend to recommend you set up an Active Directory group named ‘archived’ and choose the option to only synchronise the members of this group, this allows you to easily add new users in the future. Once the synchronisation has been set up, you can either choose to test the settings or run the synchronisation once to pull in a list of users.
A nice point to note here is that passwords aren’t stored within MailStore, but instead are looked up live against the Active Directory, which means it copes well with any changes to them and provides some added degree of security.
If using Active Directory synchronisation, you’ve also got the ability to use the Windows user sign-on mode within the MailStore Client and Outlook Client. Here no details need to be entered and instead MailStore will use those details entered at log-on by the current Windows user.
To keep the user synchronisation up to date we recommend you tick the option in your archive jobs to run a new directory service synchronisation before every job is run. This will make sure any new users are added before email for those users attempts to be archived.
MDaemon Userlist.DAT
MDaemon configuration settings
For MDaemon users, there is a specific user synchronisation option. In this mode, MailStore reads the user information directly from the MDaemon ‘Userlist.DAT’ file in the MDaemon ‘APP’ folder.
This text file is what MDaemon uses to manage all of the user information, and as long as MailStore has read access to this file it can synchronise the users directly.
If MailStore is installed on the same server as MDaemon, you should enter the local path to the ‘app’ folder (e.g. c:\MDaemon\APP), or if you wish to run MailStore on a different server you can choose to use a UNC path to that folder instead (e.g. \\mdserver\app). It’s important to make sure if you use the latter, that the user running the MailStore service has rights to view that share.
Just as with the Active Directory synchronisation, if you don’t want to archive all users, it’s possible to synchronise only those belonging to a particular MDaemon group. You do this by simply choosing that group from a pull down list.
Password lookups are performed live against the MDaemon server by using the IMAP protocol, so you must enter the MDaemon server details again for this lookup to work. You must also make sure all users that you need to authenticate have IMAP access enabled.
So what happens when staff leave?
The first step would be to delete the user in either ActiveSync or MDaemon as they no longer exist on the system. Doing this doesn’t automatically get rid of that user from MailStore, and this is something you’d need to do manually. Even at this stage, the mail of that user remains intact, and by design, it’s available then for reallocation to one or more other users who can continue to access it if required. Importantly in this scenario, once you’ve deleted the MailStore user, you will free up one user license which you can use again for a new starter if required.