Comments 37
Какие серверы непосредственно хранят файловые ресурсы (железо, дисковая система, сетевые интерфейсы)?
Какая-то СХД используется или всё на локальных дисках? Дисковые полки? RAID-массивы?
Правильно ли я понимаю, что DFS у вас используется только для того, чтобы выстроить единое дерево из распределённых в сети SMB-шар? А резервирование путём дублирования данных на несколько серверов с DFS-репликацией между ними у вас не используется? Тема резервирования/кластеризации в статье не раскрыта.
> оставили права Creator owner для подпапок
Оставлять права по умолчанию Full control для Creator/Owner — это дурной тон. Обязательно среди юзеров найдётся какой-нибудь продвинутый умник, который полезет настраивать права на созданную им папку и выкинет оттуда вообще всех кроме себя. В итоге потом не пройдёт бэкап этой папки или скрипт по переносу данных на другой сервер споткнётся на этой папке.
Вернуть права админы, разумеется, смогут, но это потерянное время и лишние заботы — лучше их себе не создавать и не давать юзерам полных прав никогда. Всегда раздавать юзерам права не выше Modify и только конкретным доменным группам (а на юзерские папки конкретным доменным юзерам). Creator/Owner вообще на самом верхнем уровне иерархии расшаренных папок удалить из ACL.
Кстати, тема бэкапов в статье тоже не раскрыта.
Какая-то СХД используется или всё на локальных дисках? Дисковые полки? RAID-массивы?
Правильно ли я понимаю, что DFS у вас используется только для того, чтобы выстроить единое дерево из распределённых в сети SMB-шар? А резервирование путём дублирования данных на несколько серверов с DFS-репликацией между ними у вас не используется? Тема резервирования/кластеризации в статье не раскрыта.
> оставили права Creator owner для подпапок
Оставлять права по умолчанию Full control для Creator/Owner — это дурной тон. Обязательно среди юзеров найдётся какой-нибудь продвинутый умник, который полезет настраивать права на созданную им папку и выкинет оттуда вообще всех кроме себя. В итоге потом не пройдёт бэкап этой папки или скрипт по переносу данных на другой сервер споткнётся на этой папке.
Вернуть права админы, разумеется, смогут, но это потерянное время и лишние заботы — лучше их себе не создавать и не давать юзерам полных прав никогда. Всегда раздавать юзерам права не выше Modify и только конкретным доменным группам (а на юзерские папки конкретным доменным юзерам). Creator/Owner вообще на самом верхнем уровне иерархии расшаренных папок удалить из ACL.
Кстати, тема бэкапов в статье тоже не раскрыта.
Каждый раз начиная пост, я понимаю, что можно писать и писать. И пост тогда будет километровой длины, скучным и нудным. Поэтому пытаюсь сокращать, выбирая ограниченные темы или вопросы. Отсюда видимо и куча ваших вопросов.
По порядку:
— перечисление железной составляющей на мой взгляд излишне, т.к. цель была рассказать про систему организации файлохранилища, именно логическую, структурную его часть. По части железа — это можно еще не одну простыню наваять.
— DFS, вы правильно заметили, здесь используется только для структуризации данных. Для резервирования с репликацией, необходимо как минимум иметь еще столько же дискового места «про запас», а в данной компании с этим пока туговато. Резервирование средствами DFS я впервые попробовал уже на 2008 server, понравилось, и думаю посвятить этому отдельный пост. Там кстати ABDE интересно встроен на уровне самой DFS ну да вы наверняка и сами об этом знаете.
— Creator Owner в ACL для Users мы оставили с одной единственной целью: ради предельно простого и автоматического создания сетевой папки для конкретного пользователя. Еще раз опишу механизм: на корневую папку (и только на нее, без наследования) у доменных пользователей есть права «Обзор папок\создание папок», и стоят права Creator Owner на все нижеследующие объекты, причем права уровня Write\Modify, а не FullControl. Логин скрипт от имени пользователя проверяет наличие папки вида %username%, если ее нет — то создает ее и монтирует в сетевой диск.
В итоге пользователь на все нижележащее имеет нормальные права (не Full Control! а Write\Modify), а админы не парятся по поводу «создать папку для еще одного пользователя»
В остальных корневых папках Creator Owner убран, и оставлены только нужные группы — я об этом писал.
— по поводу бэкапа — это будет еще один пост, причем хочется коснуться именно системы, принципа бэкапа, которой я придерживаюсь, не расписывая прелести той или иной конкретной программы.
По порядку:
— перечисление железной составляющей на мой взгляд излишне, т.к. цель была рассказать про систему организации файлохранилища, именно логическую, структурную его часть. По части железа — это можно еще не одну простыню наваять.
— DFS, вы правильно заметили, здесь используется только для структуризации данных. Для резервирования с репликацией, необходимо как минимум иметь еще столько же дискового места «про запас», а в данной компании с этим пока туговато. Резервирование средствами DFS я впервые попробовал уже на 2008 server, понравилось, и думаю посвятить этому отдельный пост. Там кстати ABDE интересно встроен на уровне самой DFS ну да вы наверняка и сами об этом знаете.
— Creator Owner в ACL для Users мы оставили с одной единственной целью: ради предельно простого и автоматического создания сетевой папки для конкретного пользователя. Еще раз опишу механизм: на корневую папку (и только на нее, без наследования) у доменных пользователей есть права «Обзор папок\создание папок», и стоят права Creator Owner на все нижеследующие объекты, причем права уровня Write\Modify, а не FullControl. Логин скрипт от имени пользователя проверяет наличие папки вида %username%, если ее нет — то создает ее и монтирует в сетевой диск.
В итоге пользователь на все нижележащее имеет нормальные права (не Full Control! а Write\Modify), а админы не парятся по поводу «создать папку для еще одного пользователя»
В остальных корневых папках Creator Owner убран, и оставлены только нужные группы — я об этом писал.
— по поводу бэкапа — это будет еще один пост, причем хочется коснуться именно системы, принципа бэкапа, которой я придерживаюсь, не расписывая прелести той или иной конкретной программы.
а опишите плиз как именно подключаете папку?
Можно чем то вроде вот такого скрипта:
On Error Resume Next
Set Network = WScript.CreateObject(«Wscript.network»)
Set oShell = CreateObject(«Shell.Application»)
Set FSO = CreateObject(«Scripting.FileSystemObject»)
'==================================================
'Создаем папку пользователю с именем его логина
'==================================================
UName = Network.UserName
If Not fso.FolderExists("\\domain\root\Users\" & UName) Then
Set objFolder = FSO.CreateFolder("\\domain\root\Users\" & UName)
End If
'==================================================
'Подключаем диск и даем ему имя
'==================================================
Network.RemoveNetworkDrive «Z:»
DiskPath = "\\domain\root\Users\" & UName
Network.MapNetworkDrive «Z:», diskpath
oShell.NameSpace(«z:\»).Self.Name = «UsersFolder»
WScript.Quit 
«Все папки 1 уровня (кроме users) были сделаны вирутальными, т.е. реальными шарами были папки 2 уровня.» Поясните, пожалуйста, что Вы имели ввиду данной фразой? И как реализовали это?
Отвечу картинкой 
Это не рабочая среда, это просто пример. Здесь:
root — корень DFS
Department, Level1 — это виртуальные папки уровня 1 (т.е. они нигде не рсшарены, они есть только в структуре DFS)
HR, Marketing, Level2 — это линки(ссылки) DFS, которые ссылаются на реальные сетевые папки. Это видно на примере папки marketing.
таким образом система остается
— структурированной (четко видно где что лежит. департаменты, пользовательские папки, общие папки и т.п.)
— постоянной (например путь в каталог HR всегда будет вида \\domain\root\deprtment\HR) независимо от того на каком сервере эта папка находится.
— гибкой (можно увеличить свободное пространство в папке Marketing, просто перенеся его на сервер с большими дисками и поправив линк в DFS, пользователи ничего не заметят)
— централизованной (для изменения ее достаточно изменить линк в консоли DFS, дальше все автоматически, не нужно бегать по пользователям и менять им сетевые диски и заниматься подобной ерундой)
Достаточно подробно и понятно?
Это не рабочая среда, это просто пример. Здесь:
root — корень DFS
Department, Level1 — это виртуальные папки уровня 1 (т.е. они нигде не рсшарены, они есть только в структуре DFS)
HR, Marketing, Level2 — это линки(ссылки) DFS, которые ссылаются на реальные сетевые папки. Это видно на примере папки marketing.
таким образом система остается
— структурированной (четко видно где что лежит. департаменты, пользовательские папки, общие папки и т.п.)
— постоянной (например путь в каталог HR всегда будет вида \\domain\root\deprtment\HR) независимо от того на каком сервере эта папка находится.
— гибкой (можно увеличить свободное пространство в папке Marketing, просто перенеся его на сервер с большими дисками и поправив линк в DFS, пользователи ничего не заметят)
— централизованной (для изменения ее достаточно изменить линк в консоли DFS, дальше все автоматически, не нужно бегать по пользователям и менять им сетевые диски и заниматься подобной ерундой)
Достаточно подробно и понятно?
Если не сложно ответьте на один вопрос по поводу DFS и репликации.
Когда пробовали на 2003, получили большие странности с 1C, да и вообще с обычными документами. Создалось впечатление, что каждое подключение само выбирало откуда физически брать файлы или куда писать из двух подключенных сетевых шар. При чем при работе 1человека замечено не было, а когда пустили в бой сразу же посыпались жалобы. Типа только что файл сохранили, а теперь его нет. В 1С вообще магические вещи происходили.
Когда пробовали на 2003, получили большие странности с 1C, да и вообще с обычными документами. Создалось впечатление, что каждое подключение само выбирало откуда физически брать файлы или куда писать из двух подключенных сетевых шар. При чем при работе 1человека замечено не было, а когда пустили в бой сразу же посыпались жалобы. Типа только что файл сохранили, а теперь его нет. В 1С вообще магические вещи происходили.
Вероятно вы использовали DFS уровня 2003, в выпуске 2003 R2 служба DFS, была очень серьезно переработана, что сделало ее использование уже приемлемым. В компании где работаю я (500+ сотрудников) используется DFS для совместной работы пользователей в 7 офисах, которые находятся в разных странах. Могу сказать, что для документов которые реплицируются через VPN например в Аргентину могут быть серьезные задержки, поэтому приходится пользоваться прямыми ссылками. Если же два ваших сервера будут стоять в одном сайте, да еще и соединены по гигабиту скажем — то никаких серьезных проблем быть не должно. Кстати рекомендую очень полезную статью 10 causes of slow replication
Репликация в DFS это довольно своеобразная штука. По опыту могу сказать следующее:
— DFS сама выбирает куда, на какую реплику послать запрос. Критерии выбора довольно туманны, возможно по скорости ответа сервера-хранилища.
— Ни о каких кластерных технологиях тут речь не идет. DFS — это НЕ ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР!!! Основная цель репликации — это дублирование содержимого папки в другие места (например в филиалы, в другие отделы и т.д.)
— по разным причинам репликация папок может задерживаться на некоторое время, т.е. происходить не моментально.
Соответственно реплицировать любую используемую (не статическую) базу данных средствами DFS бессмысленно. Вы свою ситуацию описали очень точно: 1с-ка в один момент времени обращалась в одну реплику в другой момент времени — в другую. От чего и происходили разные веселые странности :)
на мой взгляд вообще есть два реальных применения репликации DFS:
1. репликация каких то общих, редко изменяемых папок в филиалы, другие отделы и т.п. (например в главном офисе есть папка с приказами\инструкциями\списками, эта папка реплицируется в удаленные филиалы. Соответственно когда в филиале обращаются по DFS пути, их автоматически пробрасывает на ближайшую реплику)
2. своего рода онлайн-бэкап, без особых усилий. я сам в 2003 так не делал, а в 2008 — делал, получалась вполне рабочая схема. Это когда содержимое папки реплицируется, но одна из реплик, т.н. запасная, «выключается», т.е. DFS на нее не ссылается, а просто реплицирует туда данные как может и когда может, и все. В критический момент, когда основная шара упала (сломался сервер) вы в консоли DFS ВЫКЛючаете основную реплику, и ВКЛючаете запасную, и у пользователей становятся видны относительно свежие данные (состояние от 1-2 сек, до получаса назад).
— DFS сама выбирает куда, на какую реплику послать запрос. Критерии выбора довольно туманны, возможно по скорости ответа сервера-хранилища.
— Ни о каких кластерных технологиях тут речь не идет. DFS — это НЕ ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР!!! Основная цель репликации — это дублирование содержимого папки в другие места (например в филиалы, в другие отделы и т.д.)
— по разным причинам репликация папок может задерживаться на некоторое время, т.е. происходить не моментально.
Соответственно реплицировать любую используемую (не статическую) базу данных средствами DFS бессмысленно. Вы свою ситуацию описали очень точно: 1с-ка в один момент времени обращалась в одну реплику в другой момент времени — в другую. От чего и происходили разные веселые странности :)
на мой взгляд вообще есть два реальных применения репликации DFS:
1. репликация каких то общих, редко изменяемых папок в филиалы, другие отделы и т.п. (например в главном офисе есть папка с приказами\инструкциями\списками, эта папка реплицируется в удаленные филиалы. Соответственно когда в филиале обращаются по DFS пути, их автоматически пробрасывает на ближайшую реплику)
2. своего рода онлайн-бэкап, без особых усилий. я сам в 2003 так не делал, а в 2008 — делал, получалась вполне рабочая схема. Это когда содержимое папки реплицируется, но одна из реплик, т.н. запасная, «выключается», т.е. DFS на нее не ссылается, а просто реплицирует туда данные как может и когда может, и все. В критический момент, когда основная шара упала (сломался сервер) вы в консоли DFS ВЫКЛючаете основную реплику, и ВКЛючаете запасную, и у пользователей становятся видны относительно свежие данные (состояние от 1-2 сек, до получаса назад).
Пользователь получает доступ к тому серверу, который находится в его сайте и который быстрее всего откликнулся на запрос.
DFS можно и нужно использовать для отказоустойчивости. В случае падения одного сервера пользователи прозрачно перенаправляются на реплику, практически ничего не замечая.
DFS можно и нужно использовать для отказоустойчивости. В случае падения одного сервера пользователи прозрачно перенаправляются на реплику, практически ничего не замечая.
Вы точно уверены что БД стоит реплицировать средствами DFS в пределах одного сайта?
Я бы лично не рекомендовал.
Кроме того, насколько мне известно в механизме репликации DFS любой редакции нет способа выбрать какой документ «правильнее». по умолчанию принимается последний отредактированный. А это вполне может создать ситуацию, когда скажем два сотрудника открыли один документ, причем один на одной реплике, другой — на второй. Оба поработали, оба сохранили в разное время. После репликации останется только одна версия, так которая была изменена последней.
Я все таки считаю, что отказоустойчивость лучше реализовывать кластерными технологиями, либо если уж есть только DFS то схемой с выключенной репликой (я чуть выше описал).
Я бы лично не рекомендовал.
Кроме того, насколько мне известно в механизме репликации DFS любой редакции нет способа выбрать какой документ «правильнее». по умолчанию принимается последний отредактированный. А это вполне может создать ситуацию, когда скажем два сотрудника открыли один документ, причем один на одной реплике, другой — на второй. Оба поработали, оба сохранили в разное время. После репликации останется только одна версия, так которая была изменена последней.
Я все таки считаю, что отказоустойчивость лучше реализовывать кластерными технологиями, либо если уж есть только DFS то схемой с выключенной репликой (я чуть выше описал).
Вот-вот. От DFS в 2003 остались одни отрицательные впечатления, логика работы абсолютно непредсказуемая, синхронизация медленная.
БД — нет, не стоит :)
А ситуация которую вы описали с документами возможна если пользователи работают даже с одной реплики, так что две реплики тут не сильно что то меняют. У нас по семь реплик в семи офисах, люди работают — все нормально.
А ситуация которую вы описали с документами возможна если пользователи работают даже с одной реплики, так что две реплики тут не сильно что то меняют. У нас по семь реплик в семи офисах, люди работают — все нормально.
> по разным причинам репликация папок может задерживаться на некоторое время,
> т.е. происходить не моментально.
Особенно когда юзеры понаоткрывают офисные документы из DFS-папок на редактирование и так и не закрывают их целый день или по несколько дней. Пока он его не закроет репликация этого заблокированного файла не начнётся.
> т.е. происходить не моментально.
Особенно когда юзеры понаоткрывают офисные документы из DFS-папок на редактирование и так и не закрывают их целый день или по несколько дней. Пока он его не закроет репликация этого заблокированного файла не начнётся.
> DFS сама выбирает куда, на какую реплику послать запрос.
Некоторая настройка порядка выбора DFS-реплики там всё же есть:
— Random order (случайный выбор DFS-реплики).
— Lowest cost (перенаправлять запрос на наиболее близкую к клиенту DFS-реплику).
— Exclude targets outside of the client's site (перенаправлять запрос только на DFS-реплики внутри сайта клиента).
Некоторая настройка порядка выбора DFS-реплики там всё же есть:
— Random order (случайный выбор DFS-реплики).
— Lowest cost (перенаправлять запрос на наиболее близкую к клиенту DFS-реплику).
— Exclude targets outside of the client's site (перенаправлять запрос только на DFS-реплики внутри сайта клиента).
Описанная вами схема достаточно очевидная,
а за Windows Server 2003 Access-based Enumeration спасибо.
а за Windows Server 2003 Access-based Enumeration спасибо.
Спасибо, очень интересная и полезная статья.
Как вы смотрите на такой вариант для папок пользователей:
— папка пользователей хранится локально на компьютере;
— используется aerofs или что-то что обеспечивает синхронизацию с сервером.
Для чего это нужно:
— «дешевое» резервирование, если отказал файловый сервер то пользователь может продолжить работу, в том время как ИТ поднимает резервный сервер или восстанавливает работоспособность;
— отсуствие различных колизий при открытие файлов по сети;
Какие вижу проблемы:
— безопасность, нужно сделать так чтобы директория была с прозрачным шифрованием, а ключ для расшифровки использовался был бы паролем от входа (иначе для пользователя это будет несколько сложно).
Какие видите проблемы у этого варианта?
Как вы смотрите на такой вариант для папок пользователей:
— папка пользователей хранится локально на компьютере;
— используется aerofs или что-то что обеспечивает синхронизацию с сервером.
Для чего это нужно:
— «дешевое» резервирование, если отказал файловый сервер то пользователь может продолжить работу, в том время как ИТ поднимает резервный сервер или восстанавливает работоспособность;
— отсуствие различных колизий при открытие файлов по сети;
Какие вижу проблемы:
— безопасность, нужно сделать так чтобы директория была с прозрачным шифрованием, а ключ для расшифровки использовался был бы паролем от входа (иначе для пользователя это будет несколько сложно).
Какие видите проблемы у этого варианта?
Проблема на мой взгляд только одна — я не знаю что такое aerofs :)
Возможно вы говорите про оффлайновые папки (так это, или очень похожее на это, называется в Windows), но если так, то мне лично оффлайновые папки не нравятся по многим причинам. При красивой на первый взгляд идее, они довольно тяжко реализованы, что по мере роста объемов данных приводит к тормозам, порче кэша, и прочим неприятностям. Нервирует.
дешевое резервирование можно реализовать с помощью DFS, я чуть выше писал про это в комментариях, и в одном из постов опишу подробнее. Там переключение будет не полностью автоматическим, но зато быстрым и глобальным, и данные будут лежать в сети.
Шифрование же — вещь обоюдоострая. По крайней мере не забывайте про агента восстановления (ну или как он называется, чтоб можно было восстановить, если пользователь забыл-пароль\потерял-ключ). В Windows-среде есть возможность использовать EFS, с сертификатами на уровне домена, что в принципе вы и описываете, но на практике в большинстве случаев достаточно грамотных NTFS прав.
Возможно вы говорите про оффлайновые папки (так это, или очень похожее на это, называется в Windows), но если так, то мне лично оффлайновые папки не нравятся по многим причинам. При красивой на первый взгляд идее, они довольно тяжко реализованы, что по мере роста объемов данных приводит к тормозам, порче кэша, и прочим неприятностям. Нервирует.
дешевое резервирование можно реализовать с помощью DFS, я чуть выше писал про это в комментариях, и в одном из постов опишу подробнее. Там переключение будет не полностью автоматическим, но зато быстрым и глобальным, и данные будут лежать в сети.
Шифрование же — вещь обоюдоострая. По крайней мере не забывайте про агента восстановления (ну или как он называется, чтоб можно было восстановить, если пользователь забыл-пароль\потерял-ключ). В Windows-среде есть возможность использовать EFS, с сертификатами на уровне домена, что в принципе вы и описываете, но на практике в большинстве случаев достаточно грамотных NTFS прав.
Шары с включенным АВЕ быстро открываются? Какое количество файлов, папок в них?
Заметной разницы не увидел по отношению к шаре с выключенным ABE.
По числу папок-файлов рекордов думаю не было, честно говоря, даже не задавался этим вопросом. Общий объем данных колебался от 100 до 1200 гб, если это чем то поможет.
По числу папок-файлов рекордов думаю не было, честно говоря, даже не задавался этим вопросом. Общий объем данных колебался от 100 до 1200 гб, если это чем то поможет.
Общий объем не влияет. Количество файлов в папке, да, если верить документу. Хотя такую кучу надо еще умудриться накидать.
Интересует вопрос, про использование DFS с ноутбуками. Сталкивались ли вы с проблемами при использовании DFSс мобильными пользователями? Настраивали ли синхронизацию или всем пользователям можно подключаться по VPN откуда угодно?
Очень интересует этот вопрос. Количество мобильных устройств на фирмах растёт и что им делать «в поле», когда их документы перенаправляются на сервер не совсем понятно. Синхронизацию папок, вроде бы, советуют отключать при использовании DFS, а VPN тоже всем давать жирно.
Очень интересует этот вопрос. Количество мобильных устройств на фирмах растёт и что им делать «в поле», когда их документы перенаправляются на сервер не совсем понятно. Синхронизацию папок, вроде бы, советуют отключать при использовании DFS, а VPN тоже всем давать жирно.
DFS работает одинаково что на ноутбуках что на рабочих станциях. Я не вижу принципиальной разницы между ними. Главное — это чтобы они находились в одной среде, были доступны DNS сервера домена, файловые сервера и.тд.
Оффлайн синхронизацию я сколько раз делал — столько раз потом и плевался. Мне очень не нравится то что получается, то как оно реализовано, хотя идея в общем неплохая.
Вообще вопрос «что делать когда нотбуков много», это отдельный интересный вопрос, и боюсь своего рецепта я вам не дам, т.к. его нет. В моем опыте те организации, с которыми я работал, либо не использовали ноутбуки принципиально, либо не использовали на нотбуках перенаправления папок, оставляя все данные физически на ноутбуке. А если пользователю срочно было нужно то, чего у него нет на рабочем столе — то вопрос решался почтой. Как то так.
VPN всем — на мой взгляд тоже жирновато, хотя, конечно, все зависит от специфики организации, были компании где это практиковалось, и все были довольны.
Оффлайн синхронизацию я сколько раз делал — столько раз потом и плевался. Мне очень не нравится то что получается, то как оно реализовано, хотя идея в общем неплохая.
Вообще вопрос «что делать когда нотбуков много», это отдельный интересный вопрос, и боюсь своего рецепта я вам не дам, т.к. его нет. В моем опыте те организации, с которыми я работал, либо не использовали ноутбуки принципиально, либо не использовали на нотбуках перенаправления папок, оставляя все данные физически на ноутбуке. А если пользователю срочно было нужно то, чего у него нет на рабочем столе — то вопрос решался почтой. Как то так.
VPN всем — на мой взгляд тоже жирновато, хотя, конечно, все зависит от специфики организации, были компании где это практиковалось, и все были довольны.
Может быть имелась в виду схема имен?
т.е. по умолчанию DFS создается не-FQDN. После небольшой правки реестра, ресурсы DFS принудительно прописываются как FQDN. Например, \\company\ROOT -> \\company.local\ROOT.
Соответственно, снимается проблема разрешения «коротких» имен и доступа к ресурсам.
Автономные папки же, очень не рекомендуется включать с общими ресурсами. Но вот с папками пользователя (мои документы/рабочий стол) вкупе с их перенаправлением на сервер, получается весьма удобно для случаев порчи ноутов в поездках. Если этого не делать, возникает очень острый вопрос резервной копии данных юзера.
т.е. по умолчанию DFS создается не-FQDN. После небольшой правки реестра, ресурсы DFS принудительно прописываются как FQDN. Например, \\company\ROOT -> \\company.local\ROOT.
Соответственно, снимается проблема разрешения «коротких» имен и доступа к ресурсам.
Автономные папки же, очень не рекомендуется включать с общими ресурсами. Но вот с папками пользователя (мои документы/рабочий стол) вкупе с их перенаправлением на сервер, получается весьма удобно для случаев порчи ноутов в поездках. Если этого не делать, возникает очень острый вопрос резервной копии данных юзера.
просто для файлов помоек с вами согласен, DFS и ваша древовидная структура оправдывается себя. Но для работы с для работы с документами между пользователями надо уже использовать SharePoint.
могу попробовать написать, просто тема огромнейшая ))
А как DFS работает с MacOSX?
Sign up to leave a comment.
Опытные мелочи-3, или «Центральное Файлохранилище»