Comments 30
>который в открытом состоянии ТАК блокирует PST файл, что скопировать его нельзя никак
Можно. Достаточно использовать VSS.
Можно. Достаточно использовать VSS.
О. Я пробовал :)
Но на тот момент не нашел способа удаленно(!), т.е. запускаясь с сервера, и обходя компы по списку, использовать их, удаленные VSS. Городить запуск скриптов по расписанию у каждого на своей машине- не хотелось, т.к. громоздко получается. Ставить на машины агентов какого-нибудь бэкап-софта — дорого, и опять таки громоздко. Плюс (вернее минус) приходилось принудительно заставлять всех этих людей НЕ выключать компьютеры на ночь, ну и это все равно не решало проблемы удаленного доступа к архивам.
Но на тот момент не нашел способа удаленно(!), т.е. запускаясь с сервера, и обходя компы по списку, использовать их, удаленные VSS. Городить запуск скриптов по расписанию у каждого на своей машине- не хотелось, т.к. громоздко получается. Ставить на машины агентов какого-нибудь бэкап-софта — дорого, и опять таки громоздко. Плюс (вернее минус) приходилось принудительно заставлять всех этих людей НЕ выключать компьютеры на ночь, ну и это все равно не решало проблемы удаленного доступа к архивам.
DPM? Хотя, если денег не дают на Exch2010, то на DPM тоже вряд ли допросишься…
там дело не в том что не дают. Просто они уже купили 2007 Exchange и не видят особого смысла переезжать на 2010 (я честно говоря тоже в данной конкретной ситуации не вижу великого смысла делать это, каких то сверх преимуществ (как например 2007 относительно 2003) он не дает, так что пока ждем что выйдет дальше).
А с помощью DPM бэкапить рабочие станции, причем исключительно ради несчастных PST — не… :) увольте.
А с помощью DPM бэкапить рабочие станции, причем исключительно ради несчастных PST — не… :) увольте.
DPM вообще волшебный, доложу вам. Попробовав раз, не смогли отказаться. Нафиг всякие скрипты и планы обслуживания с бекапами у SQL-серверов — всё бекапится с шагом в 15 минут, «железные» и виртуальные машины сразу под колпаком, агенты на компах пользователей не просто бекапят всё важное, но и дают юзерам возможности прямо из свойств файла откатить документ на вчера или на неделю назад. И всё это удобно управляется из удобного гуя без всяких скриптов и костылей.
DPM мне не нравится тем, что он «нестандартные» виртуалки не бэкапит нормально =(
+ если нужна почта из 2-3 ящиков из бэкапа — он настаивает на восстановлении ВСЕЙ базы.
+ если нужна почта из 2-3 ящиков из бэкапа — он настаивает на восстановлении ВСЕЙ базы.
да, об этой фиче узнал случайно, это конечно провал. Полный
а это не DPM виноват, это в Exchange так процесс восстановления сделан. Я думаю все бэкап-ПО работающее с Exchange, работает таким образом
Вроде не все, AFAIK.
Нортон + Акронис ВРОДЕ бы умеют извлекать поящиково.
Говорю вроде — потому что написано, но сам не пробовал
Нортон + Акронис ВРОДЕ бы умеют извлекать поящиково.
Говорю вроде — потому что написано, но сам не пробовал
Я тоже эти продукты не щупал, так что мы с вами говорим про кота в мешке, но по идее из бэкапа Exchange можно извлекать конкретные письма или ящики только восстановив всю базу в т.н. Recovery Group, и дальше уж вытаскивая все что душе угодно.
Вытаскивать ящики прямо из самого бэкапа можно разве что специальными утилитами какими нибудь.
Вытаскивать ящики прямо из самого бэкапа можно разве что специальными утилитами какими нибудь.
Wake-Up-On-LAN не работает?
Есть такая штука — psexec. Я её для установки VNC-сервера на компьютер пользователя использую. Про неё можно почитать тут (первое, что нашёл в яндексе) xaegr.wordpress.com/2008/12/17/remote-process-psexec/
Вас не затруднит описать вот этот пункт подробнее?
«Затем я повозился с скриптом — раз в неделю обходить компы по списку и сливать PST в папку на сервере»
Существует аналогичная ситуация, но принятое вами в конце концов решение мне к сожалению не подходит, а вариант изначального размещения ПСТ файла в сети, очень напрягает.
«Затем я повозился с скриптом — раз в неделю обходить компы по списку и сливать PST в папку на сервере»
Существует аналогичная ситуация, но принятое вами в конце концов решение мне к сожалению не подходит, а вариант изначального размещения ПСТ файла в сети, очень напрягает.
Не очень понял что именно вам рассказать, вроде уже писал про это, но попробую.
Идея была проста — есть список компов, за которыми у определенных пользователей есть PST-архивы.
Зная список компов и список пользователей — получаем точное месторасположение PST-архивов. Дальше уже вопрос чем и куда копировать. (Я пробовал стандартным батником и xcopy.exe, пробовал VBS ObjFSO.CopyFile, пробовал сторонними бесплатными утилитками типа FastCopy.)
Потом уперся в то, что Outlook блокирует PST намертво, и скопировать его при открытом Outlook не получается. Повозился с VSS, в этом мне помогла вот эта статья. Понял что не могу запустить VSS на удаленной машине, и бросил.
Пробовал настроить нечто подобное через шедулер на удаленной машине — но плюнул, как только начал — громоздко и слабо управляемо получалось.
Пробовал скриптом сначала срубать процесс Outlook.exe на удаленной машине, потом копировать файлы — довольно жесткий метод, хотя и работоспособный.
В итоге тот минус, что все эти усилия так и не дают удаленного доступа к архивам — перевесил, и я отказался от идеи «скрипта копирующего PST в сеть»
Достаточно подробно?
Идея была проста — есть список компов, за которыми у определенных пользователей есть PST-архивы.
Зная список компов и список пользователей — получаем точное месторасположение PST-архивов. Дальше уже вопрос чем и куда копировать. (Я пробовал стандартным батником и xcopy.exe, пробовал VBS ObjFSO.CopyFile, пробовал сторонними бесплатными утилитками типа FastCopy.)
Потом уперся в то, что Outlook блокирует PST намертво, и скопировать его при открытом Outlook не получается. Повозился с VSS, в этом мне помогла вот эта статья. Понял что не могу запустить VSS на удаленной машине, и бросил.
Пробовал настроить нечто подобное через шедулер на удаленной машине — но плюнул, как только начал — громоздко и слабо управляемо получалось.
Пробовал скриптом сначала срубать процесс Outlook.exe на удаленной машине, потом копировать файлы — довольно жесткий метод, хотя и работоспособный.
В итоге тот минус, что все эти усилия так и не дают удаленного доступа к архивам — перевесил, и я отказался от идеи «скрипта копирующего PST в сеть»
Достаточно подробно?
Да, и не располагайте PST в сети, все-таки не стоит. Вот здесь например довольно подробно описывают почему.
Разве что если PST небольших размеров, до гига — и то… подумайте сорок раз прежде чем сделать это.
Разве что если PST небольших размеров, до гига — и то… подумайте сорок раз прежде чем сделать это.
UFO just landed and posted this here
не буду спорить, но вы забываете про те плюсы, которые дает связка Outlook-Exchange любой версии, и о которых не написано в статье. Сомневаюсь что эта компания захочет куда либо мигрировать. на данный момент их все устраивает.
UFO just landed and posted this here
Вопрос не совсем по адресу, вам бы в блог Microsoft его задать, там бы постарались :)
Но давайте попробуем. Я, честно говоря, не видел Zimbra и уже только поэтому не вправе разводить холивары. Давайте я назову то, чем у нас пользуются, а вы уж сами смотрите есть оно в вашем варианте или нет.
— поручения в задачах,
— полноценные общие папки (в т.ч. модерируемые), общие контакты, общие календари
управляемые папки (со сроком хранения и т.п.)
— полноценная синхронизация со всякими iPAD и прочими штучками через Mobile Access или active Sync
— интеграция со всеми решениями MS, начиная от AD, sharepoint и project и заканчивая приложениями office (хоть One Note хоть Word)
— широкое управление правами на сам ящик, send as, send behaf и т.д., очень просто делаются «заместители», «отсутствую» и «я в отпуске»
— и т.д. и т.п.
кроме того есть масса вещей, которые мы используем, но полезность их от этого не уменьшается тот же IRM например, который в связке с RMS, AD и Exchange создает систему защиты данных, аналогов которой, я по крайней мере, не знаю. Ну или единая система Unified Messaging, которую все руки чешутся попробовать но никак не соберусь.
Но давайте попробуем. Я, честно говоря, не видел Zimbra и уже только поэтому не вправе разводить холивары. Давайте я назову то, чем у нас пользуются, а вы уж сами смотрите есть оно в вашем варианте или нет.
— поручения в задачах,
— полноценные общие папки (в т.ч. модерируемые), общие контакты, общие календари
управляемые папки (со сроком хранения и т.п.)
— полноценная синхронизация со всякими iPAD и прочими штучками через Mobile Access или active Sync
— интеграция со всеми решениями MS, начиная от AD, sharepoint и project и заканчивая приложениями office (хоть One Note хоть Word)
— широкое управление правами на сам ящик, send as, send behaf и т.д., очень просто делаются «заместители», «отсутствую» и «я в отпуске»
— и т.д. и т.п.
кроме того есть масса вещей, которые мы используем, но полезность их от этого не уменьшается тот же IRM например, который в связке с RMS, AD и Exchange создает систему защиты данных, аналогов которой, я по крайней мере, не знаю. Ну или единая система Unified Messaging, которую все руки чешутся попробовать но никак не соберусь.
UFO just landed and posted this here
про поручения я наверное непонятно выразился. Вот тут подробнее написано.
У данного решения вижу следующие минусы:
— нет off-line доступа к архиву
— доступ к архиву без использования Outlook 2010 реализован, насколько мне известно, не полностью
— нет механизмов экономии дискового пространства (дедупликации)
— нет поиска по разному контенту (Exhange, SharePoint, файлы)
— нет возможности хранения архива на ленте (?)
Есть более изящные, экономичные и удобные способы архивации. Для небольшой компании в принципе пойдет и так, а когда объемы почты и файлов совсем выйдут из берегов, надо будет уже думать об альтернативах
— нет off-line доступа к архиву
— доступ к архиву без использования Outlook 2010 реализован, насколько мне известно, не полностью
— нет механизмов экономии дискового пространства (дедупликации)
— нет поиска по разному контенту (Exhange, SharePoint, файлы)
— нет возможности хранения архива на ленте (?)
Есть более изящные, экономичные и удобные способы архивации. Для небольшой компании в принципе пойдет и так, а когда объемы почты и файлов совсем выйдут из берегов, надо будет уже думать об альтернативах
не очень понял возражения.
— off-line доступ вы что имели в виду? работа с архивом БЕЗ Exchange? если так — то можно ведь включить режим кеширования в Outlook, и прекрасно работать в offline.
— доступ к архиву в нашей ситуации это то же самое что доступ к еще одному почтовому ящику. Что вы имеете в виду когда говорите «не полностью»? То, что автоматически туда ничего не получится архивировать — да, согласен. Но у нас это даже плюс, т.к. много пользователей привыкли сортировать почту самостоятельно, по своим папочкам а я не уверен что архивация в 2010 отличается от «взять все старше 1 года и положить в архив». правда спорить не буду — не видел.
— место пожалуй да, не экономится. Хотя надо поизучать вопрос, ведь для Exchange это будут просто еще дополнительные ящики, а он по идее с помощью SIS механизма должен дедуплицировать одинаковые письма в пределах одной базы.
— поиск по разному контенту? не понял вопрос, вероятно вы имели в виду полноценный «архив компании»? Здесь такое не практикуется, задача была что то придумать с архивами почты, коотрые удалять было нельзя, а работать с ними так как было — не удовлетворяло. Ну а поиск по архиву писем — он есть, и это ни что иное как поиск в Outlook.
— хранение архива на лентах? почему же нет? Давайте еще раз по механизму: У нас есть допустим 200 ящиков пользователей, из них есть допустим 150 пользователей, у которых большие архивы, берем их архивы и кладем в отдельную базу в Exchange в т.н. «фантомные ящики», к которым у пользователей есть доступ (через outlook или OWA). Все. Дальше можно делать что угодно — в том числе и бэкапить эти архивы на ленту и хранить их в сейфах и банковских ячейках.
И кстати, напишите про ваш, более изящный способ решения поставленной задачи, я с удовольствием прочитаю. Думаю и другие тоже.
— off-line доступ вы что имели в виду? работа с архивом БЕЗ Exchange? если так — то можно ведь включить режим кеширования в Outlook, и прекрасно работать в offline.
— доступ к архиву в нашей ситуации это то же самое что доступ к еще одному почтовому ящику. Что вы имеете в виду когда говорите «не полностью»? То, что автоматически туда ничего не получится архивировать — да, согласен. Но у нас это даже плюс, т.к. много пользователей привыкли сортировать почту самостоятельно, по своим папочкам а я не уверен что архивация в 2010 отличается от «взять все старше 1 года и положить в архив». правда спорить не буду — не видел.
— место пожалуй да, не экономится. Хотя надо поизучать вопрос, ведь для Exchange это будут просто еще дополнительные ящики, а он по идее с помощью SIS механизма должен дедуплицировать одинаковые письма в пределах одной базы.
— поиск по разному контенту? не понял вопрос, вероятно вы имели в виду полноценный «архив компании»? Здесь такое не практикуется, задача была что то придумать с архивами почты, коотрые удалять было нельзя, а работать с ними так как было — не удовлетворяло. Ну а поиск по архиву писем — он есть, и это ни что иное как поиск в Outlook.
— хранение архива на лентах? почему же нет? Давайте еще раз по механизму: У нас есть допустим 200 ящиков пользователей, из них есть допустим 150 пользователей, у которых большие архивы, берем их архивы и кладем в отдельную базу в Exchange в т.н. «фантомные ящики», к которым у пользователей есть доступ (через outlook или OWA). Все. Дальше можно делать что угодно — в том числе и бэкапить эти архивы на ленту и хранить их в сейфах и банковских ячейках.
И кстати, напишите про ваш, более изящный способ решения поставленной задачи, я с удовольствием прочитаю. Думаю и другие тоже.
• Off-line – да имеется в виду работа с архивом без доступа к Exchange. “Продуктивный” ящик кэшируется Outlook'ом, архив – нет.
• Не доступ к архиву, а работа с архивом – так будет корректнее
• В Exchange 2010 дедупликации (SIS) нет (по сравнению с 2003,2007). Если появятся реплики почтовых серверов, то объем хранимых данных можно смело умножать на их (реплик) кол-во
• Не практикуется и ладно, однако объективно — это «нишевое» (только почта) решение
• Здесь речь не о резеврной копии, а именно о самом архиве, который хранится на ленте, и, в случае необходимости, без вмешательства администратора доступен пользователям. Это возможно через интеграцию архива с бекапом.
О более изящном способе напишу наверно даже отдельный пост. Если у вас 200 ящиков, то вам это не надо. А вот если 20 000, как у нас, то жизненно необходимо.
• Не доступ к архиву, а работа с архивом – так будет корректнее
• В Exchange 2010 дедупликации (SIS) нет (по сравнению с 2003,2007). Если появятся реплики почтовых серверов, то объем хранимых данных можно смело умножать на их (реплик) кол-во
• Не практикуется и ладно, однако объективно — это «нишевое» (только почта) решение
• Здесь речь не о резеврной копии, а именно о самом архиве, который хранится на ленте, и, в случае необходимости, без вмешательства администратора доступен пользователям. Это возможно через интеграцию архива с бекапом.
О более изящном способе напишу наверно даже отдельный пост. Если у вас 200 ящиков, то вам это не надо. А вот если 20 000, как у нас, то жизненно необходимо.
— почему это архив не кэшируется? в моем случае это ровно такой же ящик как и основной рабочий, никто не мешает включить режим кеширования и для него тоже.
— у нас 2007 Exchange. У нас пока еще есть SIS. Он правда действует в пределах одной базы, но т.к. все архивы лежат одной базе, то среди архивов дедупликация уж точно должна работать. Что касается 2010 Exchange, то у MS как всегда свое видение того, почему они перестали поддерживать SIS :)
— безусловно. Статья про архивы почтовых сообщений. Я кажется так и писал.
— ой… архив который хранится на ленте и с которым могут работать пользователи? Честно говоря не понимаю зачем и как это сделано. лента она ведь для долгосрочного хранения, м? если с архивами нужно работать — то постоянно таскать их с ленты и обратно — глупо, не находите?
— у нас 2007 Exchange. У нас пока еще есть SIS. Он правда действует в пределах одной базы, но т.к. все архивы лежат одной базе, то среди архивов дедупликация уж точно должна работать. Что касается 2010 Exchange, то у MS как всегда свое видение того, почему они перестали поддерживать SIS :)
— безусловно. Статья про архивы почтовых сообщений. Я кажется так и писал.
— ой… архив который хранится на ленте и с которым могут работать пользователи? Честно говоря не понимаю зачем и как это сделано. лента она ведь для долгосрочного хранения, м? если с архивами нужно работать — то постоянно таскать их с ленты и обратно — глупо, не находите?
А было бы интересно послушать тех, кто справлялся с такой проблемой не на Exchange, а на почте, хранимой в IMAP folders. То есть UNIX way решение этой проблемы.
Решение с Zimbra уже описано, но zimbra — коммерческий дорогой продукт, если нужно поддерживать Outlook.
Сходу приходит в голову решение на основе dbmail (и далее следить за данными средствами БД), может есть другие варианты?
Решение с Zimbra уже описано, но zimbra — коммерческий дорогой продукт, если нужно поддерживать Outlook.
Сходу приходит в голову решение на основе dbmail (и далее следить за данными средствами БД), может есть другие варианты?
ага, было бы интересно :)
кстати а чем сам принцип «вынос архивов в отдельную базу, и подключение „фантомными ящиками“ пользователям» не подходит для Unix? По большому счету-то неважно какой почтовый сервер (я рассказывал про Exchange Просто потому что делалось это все на нем), важна идея. Где-то она может уже «из коробки» есть и работает, а где-то просто руками настроить надо.
кстати а чем сам принцип «вынос архивов в отдельную базу, и подключение „фантомными ящиками“ пользователям» не подходит для Unix? По большому счету-то неважно какой почтовый сервер (я рассказывал про Exchange Просто потому что делалось это все на нем), важна идея. Где-то она может уже «из коробки» есть и работает, а где-то просто руками настроить надо.
По скольку хранение в unix почты imap пофайловое, то и решение всей задачи гораздо более простое. Можно выбирать только изменившиеся файлы (почтовые сообщения), можно выносить часть файлов (устарые) на более медленные и дешевые устройства, линкуя их в прежнее место, проще собирать инкрементальные изменения, можно использовать файловые системы с дедупликацией/архивацией. В общем задача сводится к типичной работе/архивации кучи мелких файлов и не представляет какой-то сложности, по сравнению с exhange, где используется фактически один фаил базы данных под каждый стор.
Т.е. вопрос в том, что не нужны никакие дополнительные сущности, а-ля фантомный ящик.
Пользователь просто этого не узнает, для него вся почта как лежала в ящике, так и лежит, а на самом деле может часть писем (скажем старее недели) уже перенесена в архивные медленные диски, а новые все еще находятся на быстрых.
Пользователь просто этого не узнает, для него вся почта как лежала в ящике, так и лежит, а на самом деле может часть писем (скажем старее недели) уже перенесена в архивные медленные диски, а новые все еще находятся на быстрых.
mittel, а есть ли в вашей схеме т.н. «общие ящики/емылы»?
т.е. некоторые адреса, почту которых должны получать сразу несколько сотрудников и/или иметь возможность отправлять от имени этого общего емыла.
интересно было бы узнать, по какому варианту вы пошли: почтовый ящик, группа, еще как-то.
если ящик и добавляемый как дополнительный, то как решили проблему сохранения отправляемых писем в нем?
если группа, то как ведется архив и доступ к архиву полученной/отправленной почты таких емылов?
как пример: hr@company.ru. могут как просто получать все эйчары, так и быть ящик, куда валится весь входящий спам. а сам ящик подключен у пользователей (и права full+send as).
до outlook 2010, отправляемая почта кладется в основной ящик пользователя. и на наших почтовиках сделаны хитрые правила, чтобы класть ее обратно. в 2010 ситуация гороздо лучше — аутлюк научился подключаться несколько учеток экса в один профиль. но может быть можно решить вопрос и без него?
и вопрос по конкретной системе: у вас насколько я понял, экс 2007. используется ли у вас архивирование почтовой переписки? если да, то штатным механизмом экса или транспортными правилами или как-то еще?
т.е. некоторые адреса, почту которых должны получать сразу несколько сотрудников и/или иметь возможность отправлять от имени этого общего емыла.
интересно было бы узнать, по какому варианту вы пошли: почтовый ящик, группа, еще как-то.
если ящик и добавляемый как дополнительный, то как решили проблему сохранения отправляемых писем в нем?
если группа, то как ведется архив и доступ к архиву полученной/отправленной почты таких емылов?
как пример: hr@company.ru. могут как просто получать все эйчары, так и быть ящик, куда валится весь входящий спам. а сам ящик подключен у пользователей (и права full+send as).
до outlook 2010, отправляемая почта кладется в основной ящик пользователя. и на наших почтовиках сделаны хитрые правила, чтобы класть ее обратно. в 2010 ситуация гороздо лучше — аутлюк научился подключаться несколько учеток экса в один профиль. но может быть можно решить вопрос и без него?
и вопрос по конкретной системе: у вас насколько я понял, экс 2007. используется ли у вас архивирование почтовой переписки? если да, то штатным механизмом экса или транспортными правилами или как-то еще?
Sign up to leave a comment.
Опытные мелочи-2 или «Что мне делать со всей этой почтой»?