Меню Рубрики

Установка файлового сервера windows server 2012 r2

Как установить и настроить пространство имен DFS

Что такое пространство DFS простыми словами и зачем оно нужно.

Инструкция написана на примере Windows Server 2012 R2 Full. Если используется версия Core, то читайте инструкцию Установка и настройка DFS с помощью Powershell.

Установка DFS

Открываем Диспетчер серверов. Он может быть запущен из панели быстрого запуска.

Нажимаем УправлениеДобавить роли и компоненты.

В открывшемся окне оставляем Установка ролей и компонентов и нажимаем Далее.

В следующем окне выбираем нужный сервер (выбран по умолчанию, если работаем на сервере, а не через удаленную консоль) и нажимаем Далее.

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

  • Службы хранения;
  • Файловый сервер;
  • Пространство имен DFS.

* некоторые из служб уже могут быть установлены. В таком случае ставим галочки только напротив тех, которых не хватает.
** мастер может выдать предупреждение, что для установки службы потребуется установка дополнительных компонентов — соглашаемся.

В следующем окне Выбор компонентов просто нажимаем Далее.

Откроется окно Подтверждение установки компонентов. Нажимаем Установить и после окончания процесса перезагружаем сервер.

Создание пространства имен

Открываем Диспетчер серверов. Выбираем Средства

В открывшемся окне кликаем правой кнопкой по корневому разделу Управление DFS и выбираем Создать пространство имен:

В появившемся окне вводим или выбираем сервер пространства имен — это может быть сам файловый сервер.

Нажимаем Далее. Теперь вводим имя пространства, по которому пользователи будут к нему обращаться, например dfs:

Теперь выбираем тип пространства. В доменной среде лучше оставить Доменное пространство имен:

В противном случае, ставим Изолированное пространство имен и нажимаем Далее.

На следующем шаге проверяем данные и нажимаем Создать.

Создание общей папки в пространстве DFS

Прежде чем настраивать DFS, создаем общую папку на самом файловом сервере.

Теперь в уже открытом инструменте Управление DFS раскрываем Пространства имен, кликаем правой кнопкой мыши по созданному пространству и выбираем Создать папку:

В открывшемся окне задаем имя общей папки DFS и нажмите кнопку Добавить:

Теперь выбираем среди общих папок на сервере нужную и нажимаем OK – еще раз OK – и еще раз OK. Среди списка папок в пространстве DFS появится наша новая папка.

Она будет доступна по пути \\путь к пространству DFS\имя шары или как в нашем примере \\fs1\share

Источник

Настройка отказоустойчивого файлового сервера на Windows Server 2012 R2

В данной статье я расскажу как настроить отказоустойчивый файловый сервер на Windows Server 2012 R2 в домене Active Directory Первым делом убедитесь что сервер введен в домен Active Directory, далее установите роли DFS и файлового сервера

Выберите следующие роли и установите их.

Далее создайте структуру папок на отдельном диске.

Теперь включим общий доступ.

Выберите “расширенная настройка”

Далее выберите “Разрешения” и установите права как на скриншоте.

Теперь нам нужно создать структуру прав для наших каталогов в Active Directory.

Для начала рассмотрим из чего состоит наша файловая структура.

Теперь на ее основе создадим в Active Directory OU – File Sharing

Переходим в консоль пользователи и компьютеры, и создаем OU

Аналогичным путем создадим структуру наших папок

Теперь создадим комплекты прав.

Начнем мы с верхних папок.

Создадим 2-е локальные группы с правами RW и RO , и 2-е глобальные группы с правами RW и RO, и одну локальную L группу для листинга.

Разберем почему именно так.

В глобальных группах хранятся пользователи, для правильной работы глобальные группы входят в локальные.

Локальные группы назначаются на папки. Их членами являются глобальные группы.

Локальные группы лучше использовать если у вас 1 домен, если доменов несколько и между ними настроено доверие нужно использовать универсальные группы.

Рассмотрим на практике, создадим комплект прав для папки Office_Files.

Создадим 2-е глобальные группы :

Создадим локальные группы:

Глобальные группы входят в локальные

Теперь настроим права на папке.

Откройте свойство папки и выберите вкладку безопасность

Добавьте созданные локальные группы

Расставьте права на чтение и запись

Теперь нажмите кнопку “Дополнительно”

Теперь нужно установить права на листинг

Выберите L группу и нажмите изменить

Теперь установите параметры как на скриншоте ниже

Обратите внимание что мы даем доступ только на листинг и только для данной папки.

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

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

Также отключите наследование прав от корневого каталога диска.

По аналогии настроим права на каталог Moscow.

В Active Directory это должно выглядеть так:

Теперь настроим права на папку:

Теперь настроим нижний каталог – HR.

Создаем группы по аналогии.

Должно получится так

Теперь добавим группы GD-MoscowHR-RO и GD-MoscowHR-RW в группу LD-Moscow-L

Это нужно для того чтобы пользователи у которых нет прав на папку Moscow могли попасть во вложенную папку HR.

При этом открывать файлы в папке Moscow они не смогут.

Настроим права на папку.

По аналогии создадим права на остальные папки.

Теперь добавим пространство имен.

Откроем консоль DFS и создадим пространство имен.

Указываем наш сервер.

Указываем название пути DFS.

Включаем режим 2008.

Теперь создадим папку.

Далее указываем путь к папке. Путь можно посмотреть тут, выбрав “open share”.

Теперь по данному пути – \\test.com\office\Office Мы видим нашу общую папку.

Теперь если добавить пользователя в группу GD-MoscowHR-RW, он сможет попасть в папку HR, но не сможет открывать или редактировать файлы в папке Moscow.

В другие папки пользователь тоже попасть не сможет.

Если мы добавим пользователя в группу GD-Moscow-RW, он будет иметь доступ на всю папку Moscow, на чтение и запись.

Если мы добавим пользователя в группу GD-Office_Files-RW, он получит доступ ко всем каталогам.

Теперь рассмотрим настройку ABE.

Создайте следующую структуру в Active Directory.

Откройте общий доступ к папке.

Настройте права на папках.

Теперь создайте папку в DFS.

Должно получится так.

Теперь включим ABE.

В диспетчере сервера откройте “Файловые службы” – “Общие ресурсы”.

Выберите каталог IT, и нажмите свойства.

Далее выбираем параметры, и включаем функцию – “Перечисление на основе доступа”.

Особенность функции ABE в том что она проверяет права пользователя до того как нужно показать папки в проводнике.

Другими словами, пользователь видит только те папки на которые у него есть права.

Для примера дадим пользователю support права на папку Support (добавим его в группу – GD-IT-Support-RW)

Теперь перейдем по пути – \\test.com\office\IT

Как видите пользователь видит только папку Support.

Если мы добавим его в группу GD-IT-NetAdm-RO , то у него появится папка Network administrators с правами на чтение.

На этом настройка ABE закончена.

Учтите, что если в вашей файловой структуре нужно давать права пользователям на под каталоги, минуя корневые папки, то ABE вам не подойдет, т.к. ABE просто скроет от пользователя корневую папку, через которую пользователь попадает в подкаталог.

Перейдем в оснастку – Диспетчер ресурсов файлового сервера.

Настроим мягкую квоту для папки Office_Files.

Настроим жесткую квоту для папки Support.

Теперь настроим блокировку файлов для папки Office_Files.

Выберем типы файлов, которые мы будем блокировать.

Настроим отправку сообщений по электронной почте.

Учтите, без SMTP сервера отправка отчетов работать не будет.

Если вы хотите изменить группы файлов, то это можно сделать тут:

Создадим задачу управления файлами.

Представим что у нас есть папка Exchange. в которой пользователи обмениваются файлами.

Нам нужно сделать так, чтобы раз в период данная папка очищалась, а удаленные данные перемещались в папку Temp

Задаем путь и область.

Задаем свойства управления папками.

Задаем срок действия папки.

Теперь перейдем к настройке репликации.

Настройте сервер реплику (роли и доступы), введите его в домен.

Создаем на сервере реплике общую папку и отключаем наследование.

Назовем ее Office_Files, она будет репликой папки – Office_Files с основного файлового сервера.

Переходим на основной файловый сервер, и открываем консоль DFS.

Выбираем пространство имен, которое хотим реплицировать, и выбираем пункт “Добавить конечный объект папки”.

Указываем общую папку со 2-го сервера.

На вопрос о создании группы репликации отвечаем – да.

Оставляем заполненное по-умолчанию.

Проверяем что указаны 2-а наших сервера, основной и резервный.

Указываем основной сервер.

Выбираем топологию – полная сетка.

Выбираем пропускную способность канала между серверами.

Проверяем все, и выбираем – создать.

Если все прошло успешно, то вы увидите это:

Для отказоустойчивости добавим пространство имен для отображения, на 2-м нашем сервере.

И выберем наше пространство имен.

Должно получится так.

Теперь добавьте 2-й в “серверы пространства имен” на основном сервере.

Теперь пространство имен будет доступно на 2-х серверах.

Также обратите внимание, что настройки диспетчера ресурсов файлового сервера, настройки ABE, не реплицируются на 2-й сервер.

Настройку данного сервера нужно будет производить заново.

Также помните, что DFS репликация файлов работает по принципу – кто последний тот и прав.

Например, если 2 пользователя одновременно отредактируют или создадут один и тот же файл, то DFS реплицирует тот файл, который был создан последним.

А предыдущий файл будет сохранен в папке DfsrPrivate\ConflictandDeleted на сервере разрешившем проблему.

На этом все! Удачной настройки!

Похожие статьи

Комментарии

Спасибо за статью. Очень пригодилась. Вот если убрать прокрутку картинок и добавить назначение групп было бы прекрасно. С Уважением Николай К.

Добрый день! Большое спасибо за отзыв!
Что именно в назначении групп вас интересует? Могу добавить интересующую информацию в статью.

Спасибо за статью! Пригодилось! Задача управления файлами так и не получилась… пришлось скриптами

Забавная статья, грамотно и надёжно. Но к примеру если в одной папке 6 отделов, в каждом отделе по 10-15 личных именных папок у сотрудников, в которые только они смогут заходить и для каждого отдела общая. То получается что для каждой папке, нужно создать по 5 групп. 6х10=60, 60х5=300 это три сотни групп создавать что ли?!

Все зависит от структуры вашей компании.
Для именных папок так делать не имеет смысла. Проще через gpo создавать для юзера папку на шаре, и мапить её как диск. В таком случае юзер будет владельцем папки, и другие зайти в неё не смогут.
Если требуются общие папки, то можно создать шару помойку, с доступом для всех, и как вариант чистить её раз в месяц.

Статья классная! Примерно так же сделано. НО, может где то упустил, зачем создавать столько подразделений для групп безопасности? Ведь при раздаче прав манипуляция идет группами безопасности, а не контейнерами, и объектов GPO нет.

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

Спасибо за статью! Но вот незадача, всё сделал точно так, но все пользователи имеют доступ везде 🙁 То есть права безопасности почему-то не выполняются. Добавление/удаление из групп безопасности пользователей. Вот если задать пользователя на конкретную папку явно, а не через группу AD, то работает…

Посмотрите откуда наследуются права, скорее всего где-то раньше идёт наследование от локальной группы users, или группы everyone.
Попробуйте снять наследование с корня каталога с которого начинается шара, и переназначьте права. Но предварительно сделайте себя владельцем этого каталога.

не могу понять. Вроде всё настроил. права раздал, но почему-то первоначально влияет на доступ вот это:

папка Office_Files->общий доступ->пользователи прошедшие проверку (Authenticated users)

Если стоит изменять и читать, то все пользователи могут изменять и читать все папки. Что не так делаю? заранее спасибо.

Похоже что вы не отменили наследование от родительских объектов, это делается в свойствах безопасности – кнопка дополнительно.
Так же помните что запрещающие права будут иметь приоритет выше.

Теперь перейдем к настройке репликации.
Настройте сервер реплику (роли и доступы), введите его в домен.
Создаем на сервере реплике общую папку и отключаем наследование.
Назовем ее Office_Files, она будет репликой папки — Office_Files с основного файлового сервера.
Распишите этот момент по подробнее, а то некоторые не так хорошо просвещены как другие, но все равно спасибо)

Можете мне описать что именно в этом моменте не ясно? Если нужно могу дополнить.

Здравствуйте. Спасибо за отличную статью. Ответьте пожалуйста на несколько возникших вопросов.
1. Что означает аббревиатуры LD и GD в названиях групп? Если мы оперируем понятиями Local Group и Global Group обозначения поидее должны быть LG и GG соответственно.
2. Почему на основном сервере на каталог “Office_Files” в закладке “Доступ” пользователям “Прошедшим проверку” выдаются права RW, а на сервере-реплике “Пользователям домена” выдаются права на “Полный доступ”. В чем разница?
3. На сервере-реплике нужно настраивать права (закладка “Безопасность”) на все реплицируемые папки или система DFS их реплицирует с основного?

1) тут каждый сам для себя их определяет, можно назвать как хотите)
2) Возможно я не досмотрел, можно выставить и там и там на прошедших проверку.
3) права сами реплицируются, руками их на реплике настраивать не нужно.

Отличная статья! Спасибо огромное! Подробно, доступно и понятно. Буду по ней пробовать.)

Интересная и подробная статья. Спасибо.
Был ли у Вас опыт со сменой домена на существующем сервере dfs, что необходимо предусмотреть?

Что вы подразумеваете под сменой домена?
В таком случае вам нужно данные с сервера мигрировать на другой сервер в другом домене, там жу будут другие группы и структура.
Либо как вариант делать доверие между доменами, перенастраивать сервер на новые группы и потом менять ссылки в DFS, но мне кажется мигрировать данные проще.

Добрый день! Подскажите пожалуйста, новичку в этом деле, последовательность установок ролей и компонентов после чистой установки! Мне надо настроить самый простой файл-сервер на 15-20 пользователей, у которых должен быть доступ к материалам на файл-сервере и только у некоторых привилегии добавлять/изменят. Интересует в какой последовательности, какие роли и компоненты надо установить?

для 15-20 пользователей вам скорее всего не нужно AD.
Поэтому скорее всего вам проще создать группы и пользователей локально, на сервере (через диспетчер сервера , оснастка computer management) и установить только одну роль, файлового сервера. В вашем случае усложнять не требуется, если сервер у вас один, то DFS вам тоже не нужен.

Хорошая статья. Спасибо.
Работа с группами самая трудоёмкая и такого костыля от AD я не ожидал в 21веке.
Когда пользователей и папок много (более 1000) это первичная настройка превращается в ад.
Неужели нет никаких толковых решений что бы убрать этот обезьяний труд?

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

Рассматриваемые здесь квоты применимы к папкам, а не к пользователям (ограничивают объём папок, а не объём размещённой пользователем на сетевом ресурсе информации)? А если надо ограничивать пользователей? По старому через дисковые квоты?

Вы всегда можете использовать квоты для пользовательских папок.
Если у вас общая папка для нескольких пользователей, то вы не можете выставить ограничения на конкретного пользователя, только на каталог.
Возможно что-то изменилось в Server 2016

Добрый день.
Очень интересная статья, дает понимание о стратегии планирования сетевых ресурсов.
Как по мне – чем меньше вложенность, тем лучше.
На данный момент собрался переделывать сетевые ресурсы в своей компании, в связи с излишне усложнившейся структурой папок и прав.
Но вот вопрос – я всегда использовал глобальные группы безопасности для назначения прав на каталоги.
Почитал статью, почитал еще материалы – везде пишут, что для назначения прав на каталоги нужно использовать локальные группы.
Почему?
Что мешает нам создать только глобальные группы и их использовать для назначения прав?

Если простым языком, то у каждого типа группы своя область применения.
Если интересно более подробно можно почитать тут https://msdn.microsoft.com/ru-ru/library/dn579255(v=ws.11).aspx
Вот простой пример разделения ресурсов:
Я хочу дать доступ к шаре бухгалтеров доступ только бухгалтерам , плюс хочу дать им доступ к общим принтерам в их комнате + доступ на sharepoint портал.
Чтобы сделать это удобно и безопасно я выполню следующее:
1) Создам глобальную группу , куда будут входить только пользователи бухгалтерии
2) Создам локальные группы, которые я применю на предоставляемые ресурсы – шары, принтеры, sharepoint и тд.
Локальные группы я создам с точки зрения безопасности, чтобы за пределами моего домена в них никто не мог вступить.
3) Универсальные группы я буду использовать только если мне нужно предоставить доступ пользователя из другого домена

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

Идею понял. Согласен.
Только тогда, как мне кажется. нет нужды в структуре AD городить описанную структуру:
1. Да, мы создали OU, аналогичную файловой структуре общих ресурсов
2. Создали в каждом ресурсе локальные группы на чтение, запись и листинг.
3. А далее есть ли смысл тут же класть локальные группы, аналогичного назначения? А если в каждом OU подразделения создавать глобальную группу безопасности (пресловутая Бухгалтерия, например), и уже их включать в локальные группы, назначенные в правах ресурсов?

Так то понятно, что все индивидуально.

И вот еще какой момент.
Структура создана, пользуемся.
Постепенно все равно начинаются проблемы.
Всегда есть обращения по типу: “вот у нас есть папка на сетевом ресурсе, нужно добавить в нее таких то сотрудников из другого отдела”.
В итоге создаешь в АД еще группы для этой подпапки, включаешь этих пользователей, скидываешь им ярлык.
И все это постепенно разрастается ))
Но деваться от этого некуда, в рамках использования общих сетевых ресурсов. Наверное избажеать этого можно только если убрать сетевые диски для работы сотрудников, и всю работу перевести в CRM, настраивая права там. Но это пока не вариант.

Но вот у меня другой вопрос.
Есть сетевой ресурс, в нем папка, в которой куча других папок.
И на одну из них надо выдать права только определенным людям.
Группы создаем, применяем на папку. Но при этом ведь у нас наследуются группы от папок сверху. И если там у кого-то есть доступ, то и искомой папке он тоже получит доступ.
Можно отключить наследование, но очень не хочется. Потом это не отследить, наглядно нигде не отображается. В отличии от наглядной схемы в АД.
Выход – выносить папку куда то наверх сетевого ресурса, чтобы убрать лишнее наследование. Но это не логично выглядит для пользователей. В рамках одного сетевого ресурса для департамента, есть подпапки отделов. И если выносить в корень ресурса, то лишняя папка там выглядит не в тему.
Или делать отдельный ресурс и ярлык на него кидать в нужное место.
В общем, какие-то костыли все ))
Может я чего-то упускаю?

Источник


Adblock
detector