Я хотел бы получить отзывы о лучших практиках, которые вы используете для публикации своей сетевой папки.
Теперь на нашем файловом сервере:
Чтобы легко опубликовать эти общие ресурсы, мы используем сценарий, который запускается при открытии сеанса Windows и сопоставляет букву с этой общей папкой, вот она:
Net use * /delete /yes
NET USE P: \\SRVFILES01\MyName /PERSISTENT:NO
NET USE S: \\SRVFILES01\MyService /PERSISTENT:NO
Проблемы с этим:
Как вы справляетесь с этим в своих организациях? Не стесняйтесь поделиться своими техническими решениями и организациями!
Огромное спасибо,
Мы используем объект групповой политики (Пользователь> Настройки> Параметры Windows> Карты дисков) для сопоставления дисков для личного ресурса пользователя и общего ресурса его отдела. Мы помечаем его как «Переподключение после перезагрузки», поэтому даже если они загружают свой компьютер вне сети, общий ресурс все равно отображается, но с красным крестиком. Затем, когда они возвращаются в сеть, они просто щелкают общий ресурс, и он переподключу.
У меня была такая же проблема несколько лет назад: подключенные общие ресурсы становились недоступными, как только ноутбук отключался от сети.
Пользователь был более чем счастлив, когда я просто создал ярлык на его рабочем столе, указывающий на \\ myserver \ myshare. Кроме того, ОС гораздо быстрее объявила о недоступности общих ресурсов (хотя у меня нет данных, подтверждающих это). Итак, решением было бы создать ярлык на рабочих столах. через GPO например.
Если вы хотите сохранить подключенный общий ресурс, для пользователей портативных компьютеров вы также можете изменить сценарий входа в систему, чтобы проверить, доступен ли сервер, в этом случае не монтируйте его.
Что касается случая, когда сервер выходит из строя, этого не должно быть в первую очередь, и особенно когда пользователям нужен общий ресурс. Если вы можете спланировать обслуживание сервера и поддерживать высокую доступность в целом, второй сценарий не сильно повлияет на конечных пользователей и, следовательно, больше не будет проблемой.
Я бы использовал сценарий:
$computer = "SRVFILES01"
$shares = "\\SRVFILES01\MyName ", "\\SRVFILES01\MyService"
$disks = "R:", "S:"
If (Test-Connection -comp $computer -count 1 -quiet)
{
for ($i=0;$i -lt $shares.Count;$i++)
{
NET USE $disks.Get($i) $shares.Get($i) /PERSISTENT:NO
}
}
Else
{
Net use * /delete /yes
}
И периодически выполнять это через «Запланированные задачи». http://technet.microsoft.com/en-us/library/cc725745.aspx
Вы можете выполнять сценарий удаленно и изменять его без взаимодействия с клиентским ПК.
Мы используем комбинацию методов.
Хранилище приложений: как и Safado, мы используем групповую политику AD для сопоставления дисков, хотя обычно мы используем ее только для определенного хранилища приложений. Если пользователь является членом определенной группы безопасности в AD, применяется групповая политика и отображается диск. Фильтрация безопасности используется, чтобы гарантировать, что конкретная групповая политика применяется только к членам определенной группы безопасности, даже если сама групповая политика связана на уровне домена. Таким образом мы обходим ограничения структуры OU, не обязательно совпадающей с тем, кому нужен подключенный диск. Конечно, соответствующий Список управления дискреционным доступом (DACL) используется в самой общей папке, чтобы гарантировать, что только члены группы имеют права доступа.
Файлы пользователей: на контроллерах домена создается единый общий ресурс, и доступ только для чтения к нему предоставляется всем прошедшим проверку пользователям. Внутри общего ресурса создается папка с тем же именем, что и имя пользователя каждого человека, и учетная запись пользователя является единственной, имеющей доступ (чтение, запись, выполнение) к папке. Перечисление на основе доступа включен для общего ресурса, и поэтому другие пользователи не могут видеть папки других пользователей, независимо от того, им разрешен доступ для чтения к основной общей папке. Раздел профиля пользователя в AD содержит настройки, разрешающие использование одного подключенного диска, и мы используем его только для пользовательских файлов. В этих полях можно использовать макрос% username%, и, как подразумевает макрос, он заменяется фактическим именем пользователя при входе в систему, в результате чего создается подключенный диск с содержимым, специфичным для этого пользователя.
Отказоустойчивость: если подключенные диски должны быть немного более отказоустойчивыми и обрабатывать потерю или отключение одного (или нескольких) контроллеров домена, вы можете использовать DFSR (репликация распределенной файловой системы). Например, пространство имен DFS может быть создано на трех контроллерах домена, а путь UNC пространства имен DFS может использоваться в групповой политике или профиле пользователя AD. Это приведет к настройке, при которой файлы будут доступны, даже если DC выйдет из строя, и, кроме того, позволит системе действовать как CDN, если у вас есть DC в других географических местоположениях, которые являются членами пространства имен DFS.
Как сказал Сафадо, общие ресурсы будут отображаться с красным крестиком, если они не могут подключиться, просто двойной щелчок по общему ресурсу, когда сервер подключен к сети, разрешит доступ.
Примечание: я не смог разместить ссылку на страницу MS для DFSR из-за репутации ниже 10 :-(
Изменить: связывание тонны объектов GPO с верхним уровнем домена - не совсем хорошая идея. Хорошо продуманная структура OU может позволить вам связать объект GPO сопоставления диска с OU, которое содержит только пользователей, которым необходимо смонтировать общий ресурс. В таком случае нет необходимости использовать нюансы фильтрации безопасности, поскольку структура наследования ваших OU уже обрабатывает это. Конечно, это не всегда так ... например, при работе с клиентским доменом AD, которым плохо управляют: P.
У нас была такая же проблема с нашими пользователями VPN.
В основном мы используем Добавить сетевое подключение решить проблему.
В те времена у меня в папке автозагрузки просто был файл bat с SUBST команда, чтобы связать путь с буквой диска.