Отвечу картинкой
Это не рабочая среда, это просто пример. Здесь: root — корень DFS Department, Level1 — это виртуальные папки уровня 1 (т.е. они нигде не рсшарены, они есть только в структуре DFS) HR, Marketing, Level2 — это линки(ссылки) DFS, которые ссылаются на реальные сетевые папки. Это видно на примере папки marketing.
таким образом система остается
— структурированной (четко видно где что лежит. департаменты, пользовательские папки, общие папки и т.п.)
— постоянной (например путь в каталог HR всегда будет вида \\domain\root\deprtment\HR) независимо от того на каком сервере эта папка находится.
— гибкой (можно увеличить свободное пространство в папке Marketing, просто перенеся его на сервер с большими дисками и поправив линк в DFS, пользователи ничего не заметят)
— централизованной (для изменения ее достаточно изменить линк в консоли DFS, дальше все автоматически, не нужно бегать по пользователям и менять им сетевые диски и заниматься подобной ерундой)
Каждый раз начиная пост, я понимаю, что можно писать и писать. И пост тогда будет километровой длины, скучным и нудным. Поэтому пытаюсь сокращать, выбирая ограниченные темы или вопросы. Отсюда видимо и куча ваших вопросов.
По порядку:
— перечисление железной составляющей на мой взгляд излишне, т.к. цель была рассказать про систему организации файлохранилища, именно логическую, структурную его часть. По части железа — это можно еще не одну простыню наваять.
— DFS, вы правильно заметили, здесь используется только для структуризации данных. Для резервирования с репликацией, необходимо как минимум иметь еще столько же дискового места «про запас», а в данной компании с этим пока туговато. Резервирование средствами DFS я впервые попробовал уже на 2008 server, понравилось, и думаю посвятить этому отдельный пост. Там кстати ABDE интересно встроен на уровне самой DFS ну да вы наверняка и сами об этом знаете.
— Creator Owner в ACL для Users мы оставили с одной единственной целью: ради предельно простого и автоматического создания сетевой папки для конкретного пользователя. Еще раз опишу механизм: на корневую папку (и только на нее, без наследования) у доменных пользователей есть права «Обзор папок\создание папок», и стоят права Creator Owner на все нижеследующие объекты, причем права уровня Write\Modify, а не FullControl. Логин скрипт от имени пользователя проверяет наличие папки вида %username%, если ее нет — то создает ее и монтирует в сетевой диск.
В итоге пользователь на все нижележащее имеет нормальные права (не Full Control! а Write\Modify), а админы не парятся по поводу «создать папку для еще одного пользователя»
В остальных корневых папках Creator Owner убран, и оставлены только нужные группы — я об этом писал.
— по поводу бэкапа — это будет еще один пост, причем хочется коснуться именно системы, принципа бэкапа, которой я придерживаюсь, не расписывая прелести той или иной конкретной программы.
Да, и не располагайте PST в сети, все-таки не стоит. Вот здесь например довольно подробно описывают почему.
Разве что если PST небольших размеров, до гига — и то… подумайте сорок раз прежде чем сделать это.
Не очень понял что именно вам рассказать, вроде уже писал про это, но попробую.
Идея была проста — есть список компов, за которыми у определенных пользователей есть PST-архивы.
Зная список компов и список пользователей — получаем точное месторасположение PST-архивов. Дальше уже вопрос чем и куда копировать. (Я пробовал стандартным батником и xcopy.exe, пробовал VBS ObjFSO.CopyFile, пробовал сторонними бесплатными утилитками типа FastCopy.)
Потом уперся в то, что Outlook блокирует PST намертво, и скопировать его при открытом Outlook не получается. Повозился с VSS, в этом мне помогла вот эта статья. Понял что не могу запустить VSS на удаленной машине, и бросил.
Пробовал настроить нечто подобное через шедулер на удаленной машине — но плюнул, как только начал — громоздко и слабо управляемо получалось.
Пробовал скриптом сначала срубать процесс Outlook.exe на удаленной машине, потом копировать файлы — довольно жесткий метод, хотя и работоспособный.
В итоге тот минус, что все эти усилия так и не дают удаленного доступа к архивам — перевесил, и я отказался от идеи «скрипта копирующего PST в сеть»
Достаточно подробно?
О. Я пробовал :)
Но на тот момент не нашел способа удаленно(!), т.е. запускаясь с сервера, и обходя компы по списку, использовать их, удаленные VSS. Городить запуск скриптов по расписанию у каждого на своей машине- не хотелось, т.к. громоздко получается. Ставить на машины агентов какого-нибудь бэкап-софта — дорого, и опять таки громоздко. Плюс (вернее минус) приходилось принудительно заставлять всех этих людей НЕ выключать компьютеры на ночь, ну и это все равно не решало проблемы удаленного доступа к архивам.
Там на картинке достаточно длинный провод, телефон не расплавится, а вот сами жилы — вполне себе могут.
Хотя в ситуации когда сей чудо-девайс уже продается, сомневаюсь, что в Японии этот момент не предусмотрели.
можно и так, но на мой взгляд это было усложнением системы.
т.е. получается, что нужен отдельный комп, который отдельным процессом стягивает логи с контролеров, хитро их там сливает в единую базу и парсит потом по коду событий, вытаскивая описание событий, чтоб можно было понять кто откуда залогинился.
Мне показалось это громоздким, поэтому пошел путем логон-скриптов.
плюс ситуация «300 компов» это не к тому, что по компам ходить надо и логи парсить, а к тому, что объем Security лога тогда нужно увеличить довольно сильно, для более-менее адекватной глубины хранения, а не дай Бог у вас еще аудит объектов включен где-нить — застрелитесь ворочать сотни мегабайт, а то и гигайбайты логов.
не — не хочу.
скачал — посмотрел.
В принципе это просто оболочка для powerShell скриптов. Которыми все равно лезть в журнал выкачивать логи, потом парсить их чем-то и как-то и т.д.
А если компов 300 штук, как оно все будет работать?
Как мне в любой момент «нажать кнопку и посмотреть кто где сидит»?
Я вот именно эту схему не смог придумать в ситуации с «парсингом логов». Так то какая разница чем парсить, хоть powerShell хоть VBS хоть CMD.
Справедливости ради признаю, что PowerGUI довольно удобен, но вопросы озвученные выше все равно остаются.
не понял вопроса :)
имеете в виду PowerShell? — так какая разница на чем написан скрипт — лишь бы отрабатывал. VBS быстрее кажется, да и чтоб ан XP работал PowerShell его нужно туда ставить, а VBS «по умолчанию» есть
Или вопрос в другом?
у меня была оговорка в самом начале про небольшие сети (30-500 компов),
По личному опыту никаких проблем с репликацией (в т.ч. межсайтовой, была одна компания, в которой было 6 сайтов, и 7 контролеров домена ) не было.
В очень крупных сетях, думаю можно смотреть в сторону стороннего софта.
А по поводу журнала событий, я думал его парсить, но так и не смог нарисовать простую и рабочую схему системы. Расскажите, как вы это предлагаете сделать, чтобы был результат, аналогичный описанному в посте?
в данном случае это означает Personal Computer Windows :) А номер сначала был просто порядковым, а потом решили чтоб добру не пропадать, переименовали всех по номеру ближайшего телефона, благо ситуации когда есть компьютер но нет телефона у них практически не встречается.
А вообще задачу «где комп находится» конкретно в этой сети решают вручную (заполняя поля Location для объекта Компьютер в AD, например так «10 каб, 234 роз»). Мне лично этот способ не нравится — из-за обилия ручной работы при выдаче\замене\поломке компа. Чревато забывчивостью и скатыванием в хаос.
Еще — называют компьютер именами, которые однозначно его идентифицируют (Glavbuh, BigDirector, Ohrana и т.п.), при замене компа — меняют имя.
Еще — рисуют картинки сетей, с помощью всяких сторонних программ, типа FrendlyPing, hardware Administrator ну или чего помонструознее OpenView там и иже с ними.
Поля Custom Attribute непросто вытащить в оснастке ADUC (если вообще можно, я не нашел как), а хотелось чтобы стандартными средствами можно было видеть и отслеживать состояние компьютеров\пользователей.
Если писать в Custom Attribute — то как потом оттуда доставать данные? еще один скрипт писать, который будет вытаскивать их и складывать в таблицу? как то громоздко… не находите? Программу отдельную — ну тоже… излишне мне кажется.
Что касается поля Department — то оно не обязательно, можно в любое другое, главное чтоб потом было удобно его просматривать, и оно не мешало остальным задачам (например один наш клиент пишет у компьютеров в Department а у пользователей в City, т.к. у Пользователей поле Department занято названиями их отделов, в которых они работают, и отказываться от этого клиент не хотел.
по пунктам.
1. имелось в виду версии ОС а не уровни леса\домена. Поправил, для большей ясности.
2. можно также настроить Saved Queries (как на приведенном скриншоте), и тоже видеть все в одном месте. Там тоже довольно много OU, но все собрано в одном месте с помощью Saved Queries.
3. про права на атрибут — вы меня просто повергли в ад. Да! сто тысяч раз да! причем когда писал пост — еще полез было проверить себя, а потом отвлекся и так и оставил. В общем поправил.
Спасибо.
Это попытка описать мой взгляд на способы борьбы с соцсетями, т.к. последние полгода множество знакомых сисадминов этим занимаются с переменным успехом.
Повторюсь, я не сторонник запретов, не сторонник наказаний (по крайней мере за посещение соцсетей) — свою позицию я описал в посте, видимо неудачно, раз был непонят.
Если будет хоть кто-то, из бессмысленно воюющих, кто, прочитав этот пост, задумается на тему «вот человек тоже запрещал запрещал, в итоге все разрешил, и доволен. А в этом что-то есть!» — считаю что пост написан не зря.
Это не рабочая среда, это просто пример. Здесь:
root — корень DFS
Department, Level1 — это виртуальные папки уровня 1 (т.е. они нигде не рсшарены, они есть только в структуре DFS)
HR, Marketing, Level2 — это линки(ссылки) DFS, которые ссылаются на реальные сетевые папки. Это видно на примере папки marketing.
таким образом система остается
— структурированной (четко видно где что лежит. департаменты, пользовательские папки, общие папки и т.п.)
— постоянной (например путь в каталог HR всегда будет вида \\domain\root\deprtment\HR) независимо от того на каком сервере эта папка находится.
— гибкой (можно увеличить свободное пространство в папке Marketing, просто перенеся его на сервер с большими дисками и поправив линк в DFS, пользователи ничего не заметят)
— централизованной (для изменения ее достаточно изменить линк в консоли DFS, дальше все автоматически, не нужно бегать по пользователям и менять им сетевые диски и заниматься подобной ерундой)
Достаточно подробно и понятно?
По порядку:
— перечисление железной составляющей на мой взгляд излишне, т.к. цель была рассказать про систему организации файлохранилища, именно логическую, структурную его часть. По части железа — это можно еще не одну простыню наваять.
— DFS, вы правильно заметили, здесь используется только для структуризации данных. Для резервирования с репликацией, необходимо как минимум иметь еще столько же дискового места «про запас», а в данной компании с этим пока туговато. Резервирование средствами DFS я впервые попробовал уже на 2008 server, понравилось, и думаю посвятить этому отдельный пост. Там кстати ABDE интересно встроен на уровне самой DFS ну да вы наверняка и сами об этом знаете.
— Creator Owner в ACL для Users мы оставили с одной единственной целью: ради предельно простого и автоматического создания сетевой папки для конкретного пользователя. Еще раз опишу механизм: на корневую папку (и только на нее, без наследования) у доменных пользователей есть права «Обзор папок\создание папок», и стоят права Creator Owner на все нижеследующие объекты, причем права уровня Write\Modify, а не FullControl. Логин скрипт от имени пользователя проверяет наличие папки вида %username%, если ее нет — то создает ее и монтирует в сетевой диск.
В итоге пользователь на все нижележащее имеет нормальные права (не Full Control! а Write\Modify), а админы не парятся по поводу «создать папку для еще одного пользователя»
В остальных корневых папках Creator Owner убран, и оставлены только нужные группы — я об этом писал.
— по поводу бэкапа — это будет еще один пост, причем хочется коснуться именно системы, принципа бэкапа, которой я придерживаюсь, не расписывая прелести той или иной конкретной программы.
Разве что если PST небольших размеров, до гига — и то… подумайте сорок раз прежде чем сделать это.
Идея была проста — есть список компов, за которыми у определенных пользователей есть PST-архивы.
Зная список компов и список пользователей — получаем точное месторасположение PST-архивов. Дальше уже вопрос чем и куда копировать. (Я пробовал стандартным батником и xcopy.exe, пробовал VBS ObjFSO.CopyFile, пробовал сторонними бесплатными утилитками типа FastCopy.)
Потом уперся в то, что Outlook блокирует PST намертво, и скопировать его при открытом Outlook не получается. Повозился с VSS, в этом мне помогла вот эта статья. Понял что не могу запустить VSS на удаленной машине, и бросил.
Пробовал настроить нечто подобное через шедулер на удаленной машине — но плюнул, как только начал — громоздко и слабо управляемо получалось.
Пробовал скриптом сначала срубать процесс Outlook.exe на удаленной машине, потом копировать файлы — довольно жесткий метод, хотя и работоспособный.
В итоге тот минус, что все эти усилия так и не дают удаленного доступа к архивам — перевесил, и я отказался от идеи «скрипта копирующего PST в сеть»
Достаточно подробно?
Но на тот момент не нашел способа удаленно(!), т.е. запускаясь с сервера, и обходя компы по списку, использовать их, удаленные VSS. Городить запуск скриптов по расписанию у каждого на своей машине- не хотелось, т.к. громоздко получается. Ставить на машины агентов какого-нибудь бэкап-софта — дорого, и опять таки громоздко. Плюс (вернее минус) приходилось принудительно заставлять всех этих людей НЕ выключать компьютеры на ночь, ну и это все равно не решало проблемы удаленного доступа к архивам.
Хотя в ситуации когда сей чудо-девайс уже продается, сомневаюсь, что в Японии этот момент не предусмотрели.
Дешево и сердито :)
т.е. получается, что нужен отдельный комп, который отдельным процессом стягивает логи с контролеров, хитро их там сливает в единую базу и парсит потом по коду событий, вытаскивая описание событий, чтоб можно было понять кто откуда залогинился.
Мне показалось это громоздким, поэтому пошел путем логон-скриптов.
скачал — посмотрел.
В принципе это просто оболочка для powerShell скриптов. Которыми все равно лезть в журнал выкачивать логи, потом парсить их чем-то и как-то и т.д.
А если компов 300 штук, как оно все будет работать?
Как мне в любой момент «нажать кнопку и посмотреть кто где сидит»?
Я вот именно эту схему не смог придумать в ситуации с «парсингом логов». Так то какая разница чем парсить, хоть powerShell хоть VBS хоть CMD.
Справедливости ради признаю, что PowerGUI довольно удобен, но вопросы озвученные выше все равно остаются.
имеете в виду PowerShell? — так какая разница на чем написан скрипт — лишь бы отрабатывал. VBS быстрее кажется, да и чтоб ан XP работал PowerShell его нужно туда ставить, а VBS «по умолчанию» есть
Или вопрос в другом?
По личному опыту никаких проблем с репликацией (в т.ч. межсайтовой, была одна компания, в которой было 6 сайтов, и 7 контролеров домена ) не было.
В очень крупных сетях, думаю можно смотреть в сторону стороннего софта.
А по поводу журнала событий, я думал его парсить, но так и не смог нарисовать простую и рабочую схему системы. Расскажите, как вы это предлагаете сделать, чтобы был результат, аналогичный описанному в посте?
А вообще задачу «где комп находится» конкретно в этой сети решают вручную (заполняя поля Location для объекта Компьютер в AD, например так «10 каб, 234 роз»). Мне лично этот способ не нравится — из-за обилия ручной работы при выдаче\замене\поломке компа. Чревато забывчивостью и скатыванием в хаос.
Еще — называют компьютер именами, которые однозначно его идентифицируют (Glavbuh, BigDirector, Ohrana и т.п.), при замене компа — меняют имя.
Еще — рисуют картинки сетей, с помощью всяких сторонних программ, типа FrendlyPing, hardware Administrator ну или чего помонструознее OpenView там и иже с ними.
Если писать в Custom Attribute — то как потом оттуда доставать данные? еще один скрипт писать, который будет вытаскивать их и складывать в таблицу? как то громоздко… не находите? Программу отдельную — ну тоже… излишне мне кажется.
Что касается поля Department — то оно не обязательно, можно в любое другое, главное чтоб потом было удобно его просматривать, и оно не мешало остальным задачам (например один наш клиент пишет у компьютеров в Department а у пользователей в City, т.к. у Пользователей поле Department занято названиями их отделов, в которых они работают, и отказываться от этого клиент не хотел.
1. имелось в виду версии ОС а не уровни леса\домена. Поправил, для большей ясности.
2. можно также настроить Saved Queries (как на приведенном скриншоте), и тоже видеть все в одном месте. Там тоже довольно много OU, но все собрано в одном месте с помощью Saved Queries.
3. про права на атрибут — вы меня просто повергли в ад. Да! сто тысяч раз да! причем когда писал пост — еще полез было проверить себя, а потом отвлекся и так и оставил. В общем поправил.
Спасибо.
Повторюсь, я не сторонник запретов, не сторонник наказаний (по крайней мере за посещение соцсетей) — свою позицию я описал в посте, видимо неудачно, раз был непонят.
Если будет хоть кто-то, из бессмысленно воюющих, кто, прочитав этот пост, задумается на тему «вот человек тоже запрещал запрещал, в итоге все разрешил, и доволен. А в этом что-то есть!» — считаю что пост написан не зря.