Назад | Перейти на главную страницу

Рекомендации по использованию перемещаемого профиля Thunderbird

Я использую небольшую сеть Windows (AD), в которой мы используем Thunderbird для получения почты через IMAP. Однако некоторые пользователи также создали локальные папки для архивирования сообщений.

Цель состоит в том, чтобы пользователи могли получить доступ к своей электронной почте и, в идеале, также к своим локальным папкам, независимо от того, с какого компьютера они входят в домен.

Моя первоначальная идея заключалась в следующем: Поместить полный профиль каждого пользователя в его домашнюю папку (p :). Поскольку это позволяет мне давать каждому почтовому профилю одно и то же имя без риска конфликтов, я мог бы развернуть один общий файл profiles.ini, который указывает на указанную папку профиля.

Я не совсем уверен, какие именно данные и каким образом Thunderbird должны получать информацию профиля, поэтому я не знаю, какое влияние это оказывает на сеть и на производительность Thunderbird. Имейте в виду, что некоторые профили имеют размер в несколько гигабайт. Кроме того, я предполагаю, но был бы признателен, если бы кто-то подтвердил это, что это может привести к проблемам, если пользователь войдет в Thunderbird через второй компьютер, не закрывая его на первом.

Итак, мои вопросы:

  1. Можно ли запустить Thunderbird прямо из профиля в общей папке, даже с очень большими профилями (без значительного влияния на производительность приложения)?
  2. Насколько проблематично было бы, если бы один и тот же профиль был доступен с двух станций? Если это должно быть большой проблемой, есть идеи, как убедиться, что этого не произойдет?
  3. Какие есть причины отдавать предпочтение перемещаемым профилям Windows для профилей Thunderbird над решением для совместного использования файлов, если таковые имеются?

Проблемы)

Я несколько раз искал ответы на очень похожую проблему, как и у вас - многие большие вложения съедают дисковое пространство и создают нагрузку в сети каждый раз, когда используется Thunderbird. Я думаю, что эта ошибка 2009 года является центральной для наших проблем:

Ошибка 517425 - Thunderbird хранит локальную копию почты IMAP в AppData \ Roaming, а не в AppData \ Local профиля.

Идея заключается в следующем: если почта IMAP хранилась в локальной папке, пользователь мог бы войти в систему на другом новом ПК и просто получать свои письма с сервера (только текст, довольно дешево). Затем, путем настройки конфигурации, он загружал некоторые или все вложения в фоновом режиме во время работы, без задержки при входе в систему или выходе из системы.

С другой стороны, если почта находится в перемещаемом профиле, она всегда вас кусает, так или иначе:

  • Если у вас есть перемещаемый профиль на сервере, у вас будет быстрый вход в систему, но задержки при работе и вы не можете использовать почту локально.
  • Если профиль остается на клиенте, время входа в систему будет составлять минуты, а не секунды, особенно если вы используете .mbox (один большой файл, в котором изменено несколько байтов) вместо maildir (файлы .eml в каталоге).
  • Если профиль находится на сервере, но вы синхронизируете его с автономными файлами, теоретически все будет хорошо. На практике ожидаются многочисленные конфликты синхронизации, я думаю, даже Microsoft настоятельно не рекомендует этого делать.

Возможные ответы

Что касается ваших вопросов, я не могу дать полных ответов, только то, что я нашел в поисках решений:

  1. Да посмотри здесь для подробностей - Вы создаете папку профиля в общей сетевой папке и связываете ее с помощью диспетчера профилей или параметра командной строки. -p. Обратите внимание, что в этом случае профиль должен использоваться только одним клиентом одновременно, а не несколькими клиентами. Также ваше соединение должно быть стабильным, и я лично также был бы осторожен в отношении целостности данных (CIFS / SMB является асинхронным).
  2. Люди на форумах Thunderbird / Mozilla предлагают не делать этого, к сожалению, я не могу предложить прямой опыт.
  3. Если у вас нет больших вложений, время синхронизации будет низким, и вы сможете работать в автономном режиме (вне локальной сети). Конечно, работа с электронной почтой в автономном режиме в настоящее время довольно редка, но теоретически это было бы преимуществом. Примером использования может быть ноутбук в дороге, но без доступа к VPN, когда пользователю нужно что-то найти или написать длинные электронные письма в поезде и т. Д.

Альтернативы?

Подойдя к проблемам с другой стороны, я подумал о возможных обходных путях / альтернативах:

  • Только IMAP: Используйте локальный почтовый сервер в качестве ретранслятора, который хранит вашу входящую почту и получает доступ ко всей почте внутри LAN только с этого сервера - не храните копии писем или вложений на клиентах. Все делается по IMAP, профили небольшие, перемещаться можно как обычно. Это может сработать, если у вас много клиентов с относительно незначительными шаблонами доступа. Возможен дополнительный бонус дедупликации на сервере.
  • Виртуальные клиенты: Если у вас есть виртуальная инфраструктура, этой проблемы не существует, поскольку все уже хранится на сервере, и клиенты получают доступ ко всему удаленно (и их сеанс всегда следует за ними, куда бы они ни пошли)
  • Почтовый архив: Часто важны только самые новые сообщения, но иногда вы все равно хотите посмотреть старые. Если вы устанавливаете программное обеспечение для архивирования почты в локальной сети, вы можете автоматически архивировать все входящие и исходящие письма. Затем клиенты могут удалять свои локальные / IMAP-сообщения и вложения каждые п дней и остаются легкими, сохраняя при этом возможность поиска в старой почте. Имеет дополнительный бонус дедупликации на сервере.
  • Удаленное хранилище: Если у вас есть SAN, вы можете выделить (с дедупликацией, избыточное выделение) хранилище для каждой комбинации клиент / ПК. Затем ваши клиенты используют эти диски как «локальное» хранилище для профиля (вне перемещаемой папки). Это похоже на вашу идею, но вы не мешаете своим файлам, если они открыты на нескольких клиентах. Количество дисков iSCSI будет н * м для п клиенты с м пользователей, но вам не нужно дисковое пространство из-за дедупликации.
  • Просто примите это: Это может быть нормально, если у вас есть пользователи, которые всегда перемещаются на одних и тех же клиентах (предсказуемое поведение), и если локальное хранилище дешево (имеется в виду жесткий диск, а не SSD). Вы бы изменили формат сообщения с mbox на maildir (создавать новые учетные записи, не конвертировать старые профили, всегда иметь резервные копии!), Чтобы уменьшить необходимую синхронизацию при входе в систему / выходе из системы. Вложения, конечно, все еще будут там, но после первоначальной синхронизации измененное количество будет относительно небольшим (конечно, при условии, что каждый пользователь использует только одни и те же наборы клиентов).