Thunderbird roaming profile best practice

Question

I'm running a small windows network (AD) where we use Thunderbird to retrieve mails via IMAP. However, some users have also created local folders in order to archive messages.

The goal is that users can access their emails and, ideally, also their local folders no matter from which PC they log onto the domain.

My initial idea was to do the following: Put each user's full profile into their home folder (p:). Since this allows me to give each mail profile the same name without the risk of collisions, I could roll out one generic profiles.ini that points to said profile folder.

I am not exactly sure which data exactly and in what way Thunderbird needs to retrieve the profile information so I don't know what kind of impact this has on the net, and on the Thunderbird performance. Mind you, some of the profiles are several Gigabytes large. Also, I assume, but would appreciate if someone confirmed it, that it could lead to issues if a user logged on to Thunderbird through a second computer without having closed it on the first.

Thus, my questions:

1. Can Thunderbird be run straight from a profile on a file share, even with very large profiles (without a considerable impact on application performance)?
2. How problematic would it be if the same profile was accessed from two stations? If this should be a big issues, any ideas how to make sure this can't happen?
3. What reasons are there to favor windows roaming profiles for Thunderbird profiles over the file share solution, if any?

Answer 1

The problem(s)

I have searched several times for answers to a very similar problem like you have - many large attachments eat away disk space and put strain on the network each time Thunderbird is used. I think this bug from 2009 is central to our problems:

Bug 517425 - Thunderbird does store local IMAP mail copy in AppData\Roaming not AppData\Local of profile

The idea behind it is: if IMAP mail was stored in the local folder, a user would log on onto another new PC and just get his mails from the server (only text, pretty cheap). Then, by configuration setting, he would download some or all attachments in the background while working, without delay on login or logoff.

If the mail is in the roaming profile, on the other hand, it always bites you, one way or another:

• If you have the roaming profile on the server, you have fast logins, but delays while working and cannot use the mails locally.
• If the profile stays on the client, your login times will be minutes instead of seconds, especially if you use .mbox (one large file where a few bytes are changed) instead of maildir (.eml files in a directory).
• If the profile is on the server, but you sync it with Offline Files, in theory everything would be fine. In practice, expect numerous sync conflicts, I think even Microsoft strongly recommends not doing this.

---

Possible answers

Regarding your questions I cannot offer complete answers, only things I've found out in search for solutions:

1. Yes, see here for details - You create the profile folder on the network share and link it with the help of Profile Manager or command line option -p. Note that in this case the profile should only be used by one client at the same time, not multiple clients. Also your connection needs to be stable and I personally would also be cautious regarding data integrity (CIFS/SMB is asynchronous).
2. People in the Thunderbird/Mozilla forums suggest not to do it, I cannot offer direct experience unfortunately.
3. If you don't have large attachments, the sync times will be low and you would be able to work offline (outside of the LAN). Of course, working offline with emails is pretty uncommon nowadays, but in theory that would be the advantage. A use case might be a laptop on the road, but without VPN access, where the user needs to look something up or write long emails on the train etc.

---

Alternatives?

Approaching the problems from another side, I have thought about possible workarounds/alternatives:

• IMAP only: Use a local mail server as a relay that stores your incoming mail and access all mail inside the LAN from this server only - do not store copies of mails or attachment on clients. Everything is done over IMAP, profiles are small and can be roamed as usual. This might work if you have many clients with relatively minor access patterns. Added bonus of deduplication on the server is possible.
• Virtual clients: If you have a virtual infrastructure, this problem does not exist, as everything is already stored on the server and the clients access anything remotely (and their session always follows them wherever they go)
• Mail archive: Many times, only the newest mails are important, but you still want to look up old ones sometimes. If you install a mail archive software on the LAN, you can archive all incoming and outgoing mails automatically. The clients can then delete their local/IMAP mails and attachments every n days and remain lightweight, while still being able to search through old mails. Has the added bonus of deduplication on the server.
• Remote storage: If you have a SAN, you can provision (deduplicated, over-provisioned) storage for each client/PC combination. Your clients then use these disks as "local" storage for the profile (outside the roaming folder). This is similar to your idea, but you do not interfere with your own files if open on multiple clients. The amount of iSCSI disks would be n * m for n clients with m users, but you don't need the disk space because of deduplication.
• Just accept it: This might be ok, if you have users that always roam on the same clients (predictable behavior) and if local storage is cheap (meaning HDD, not SSD). You would change the message format from from mbox to maildir (create new accounts, don't convert old profiles, always have backups!) to reduce needed syncing on login/logoff. Attachments would of course still be there, but after initial syncing the changed amount would be relatively small (assuming each user only uses the same sets of clients of course).