Мы работаем над переходом с Novell на Active Directory. Во время перехода мы собираемся оценить наши сопоставления дисков в свете текущих стандартов, чтобы увидеть, соответствует ли то, что мы делаем, по-прежнему, соответствует ли они лучшим практикам, упрощаем администрирование ресурсов и т. Д. В настоящее время у нас есть 11 различных сопоставления дисков, которые отображаются. Мне кажется, что это слишком много и довольно запутанно для конечных пользователей. Эти сопоставления дисков также, по-видимому, относятся к некоторому более старому соглашению, существовавшему в организации, которое в конечном итоге было примерно следующим:
Это очень запутанная структура для пользователей, как конечных пользователей, так и ИТ-специалистов в нашей организации. Я хотел бы узнать о лучших отраслевых практиках и о том, как другие проектируют схемы дисков. О чем нужно знать, и как вы компенсируете или контролируете эти предметы? Что следует учитывать с точки зрения управления и обслуживания?
Нашими клиентами будут Windows XP, Windows Server 2003, Windows 7 Pro и Windows Server 2008. Позже мы хотели бы включить клиенты Linux и Macintosh OS X (10.6 или новее) в наши сопоставления дисков.
Мы будем очень благодарны за любую помощь, идеи, ресурсы или ссылки, которые вы можете предоставить.
По моему собственному скромному мнению, если вы сможете обойтись без понятия «буквы диска» ... забудьте их совсем. Пути UNC могут продвинуть вас намного дальше, и вы не столкнетесь с конфликтами имен. Вы также можете объединить различные имена серверов и общие ресурсы в один (или несколько) корней DFS. Это обеспечит единый UNC-путь, к которому можно будет обратиться, чтобы найти любые и все соответствующие общие ресурсы для пользователей ... и предоставит возможности для настройки репликации, переключения при отказе и масштабируемости.
Оставьте C: в качестве системного тома. Насколько я не могу поверить, что это все еще происходит, это все еще происходит, когда программное обеспечение жестко запрограммировано для установки на C: (эти разработчики должны быть убиты).
Следующие несколько строк после C: (E :, F :, G :) оставьте зарезервированными для физических устройств (CD / DVD, съемные носители и т. Д.).
Кроме того, я пытаюсь сопоставить вещи с тем, с чего они начинаются (очевидно, с ограниченной степенью успеха, поскольку количество сопоставлений дисков увеличивается).
H: = Домашний диск
P: = Проектный диск или личный диск
и т.д...
Мы столкнулись с этим вопросом по той же причине полтора года назад. Есть три основных проблемы:
Из-за 1 и 3 мы все еще использовали буквы дисков через год после перехода на Microsoft. Пользователи медленно привыкают к адресации UNC для некоторых вещей, но наш общий том, массивный, монолитный том, необходимо было разделить из-за причин размера в SAN. Вместо того, чтобы заставлять всех работать с UNC, мы выяснили, как делать тома, подключенные к каталогам, в кластере.
Если у вас есть возможность (например, очень мало пользователей Mac), Microsoft DFS может упростить задачу. Создайте единую букву диска, при этом каталоги верхнего уровня, по сути, являются старым сопоставлением букв дисков. В чистой среде Windows это может хорошо работать. Однако все, что использует Samba, не может ее использовать. У пользователей есть только одна буква диска, и переход от 14 букв диска к одной с путями типа «S: \ K-Drive \» очень прост. У нас много пользователей Mac, поэтому мы не могли пойти по этому пути.
Буквы дисков, которые мы стандартизировали в нашем сценарии входа в систему (еще один пережиток времен Novell):
Мы также управляли реестром букв дисков в нашей группе администраторов Windows. Если диск отображается в сценарии входа в систему, он документирует, кто это делает. Это избавит вас от лишних хлопот, если два отдела захотят сопоставить Т: ездить в разные места и иметь общий персонал.
Я могу порекомендовать следующие стандарты:
Я использую N: для СЕТИ. Он отображается в иерархию DFS, которая охватывает несколько серверов в прозрачной структуре папок для пользователей.
Я использую другие буквы в зависимости от ситуации на серверах (X: = dataa, S = Sql, T = Temp, L = logs - обратите внимание, что это для серверов, поэтому TEMP - это ключ для временных баз данных).
Обычно пользователи всегда видят только одно дерево. Есть два других по техническим причинам (не нанесены на карту).
В основном мы используем диск P: для личного диска пользователя. И S: стремление к доле компании. Это две основные буквы дисков, которые мы используем.
Одна из хороших практик, поскольку вы будете использовать Active Directory, - это использовать объекты групповой политики, чтобы решить, кто получит букву диска, а кто нет. Вы можете настроить сценарии входа в систему для сопоставления общего диска на основе фильтра группы безопасности.
Например, у вас есть расчетный отдел, которому нужен доступ к диску Q :. Вы должны настроить новый объект групповой политики, который будет иметь сценарий входа в систему для сопоставления диска Q и применить фильтр безопасности к группе Billing_security_group, так что они будут единственными, кто получит диск Q.
Подробнее о фильтрации групп безопасности здесь: http://technet.microsoft.com/en-us/library/cc781988(WS.10).aspx
См. Мой комментарий к сообщению о сквиллманах.
В одной среде, которую я поддерживаю:
и т. д.
Я бы также добавил, что вы, вероятно, захотите реализовать перечисление на основе доступа при переходе на Windows. Novell делает это изначально, но это не позволяет пользователям видеть файлы или папки, к которым у них нет доступа.
Не отображайте каталог для конкретного пользователя. Перенаправьте их папку «Мои документы» в общий сетевой ресурс с помощью GPO.
Затем задайте компании несколько деловых вопросов. Как люди работают, с какой информацией они имеют дело на общем / групповом уровне. Выберите несколько крупных (отделы, клиенты, проекты) и сопоставьте диски с верхним уровнем каждого из этих каталогов.