Разработчик софта или сетевой администратор, заявляющий простым пользователям "Знать надо такую-то консольную команду" или "Надо просто запретить делать то-то и то-то" или "Надо помнить десяток совершенно искусственных особенностей системы", в итоге должен быть вышиблен с работы со свистом. И чем раньше, тем лучше.
Замечания пописаны про конкретную самодостаточную систему. И негоже кивать на левые к ней примочки.
Теперь конкретно:
При установке системы на диск с IDE интерфейсом UltraATA (а сейчас большинство такие), перед переключением в режим Windows всё может остановиться с сообщением Inaccessible_Boot_Device. Ожидается, что на IDE интерфейсе материнской платы должен быть установлен драйвер поддержки UltraATA. Но для интерфейсов, изначально не предназначенных поддерживать этот протокол, не существует таких драйверов! Что имеем? Диск работает, программа инсталляции его видит, ведёт установку, доходит до режима Windows и почему-то останавливается. Что ж другие системы, включая Windows NT4, работают?
Устанавливая сервер, человек привычно назначает ему некий IP-адрес и прописывает адреса шлюза и DNS. Нормальный человек первым адресом DNS напишет адрес того DNS, через который связывается с Интернет. И рискует постепенно стать ненормальным из-за невозможности наладить работу создаваемого первого контроллера домена Active Directory. Фирма Microsoft в глубинах своего сайта вскользь замечает, что первым должен указываться собственный адрес сервера! Разумный разработчик системы, получив в мастере установки Active Directory задание на создание первого контроллера в домене, сделал бы это автоматически. И сообщил.
Если Вы на хорошо работающем сервере установите второй IP-адрес в качестве основного, а бывший основной сделаете дополнительным, сервер DHCP свихнётся. Он показывает, что исправно раздаёт клиентам адреса из заданного диапазона, но в действительности клиенты их не получают!
В DHCP при удалении в окне Leases всех розданных клиентам адресов удаляются и все резервирования в окне Reservations! Какая связь?
Оснастка управления сервером WINS упорно ищет его на сетевом интерфейсе с наибольшим номером. Если же на этом интерфейсе действует фильтр TCP, посмотреть на собственный WINS вообще невозможно иначе как с другого компьютера. В отличие от DNS, серверу WINS невозможно назначить обслуживаемые IP-адреса.
В настройках свойств IP сетевого интерфейса невозможно установить фильтр на запрет какого-либо порта или протокола. Только на разрешение. К тому же там написана неправда - якобы фильтр ставится сразу на все интерфейсы. Ничего подобного, у каждого персональная настройка.
При установке в своей сети второго контроллера домена администратор рискует надуть вас инфаркт, упорно получая ответ о невозможности связи с первым контроллером. Система не удосуживается намекнуть, что имя домена совпадает с именем, существующим в Интернете.
Парольный доступ к ресурсам возведён в фетиш. Почти всё держится на том, что пользователь крепко помнит и хранит в секрете свой заветный пароль. А как же многопользовательские рабочие места со сменным персоналом? Пароль, который знают пятеро! А как же женские коллективы типа бухгалтерии, где пароли сообщаются друг другу вслух в присутствии посетителей? Жди налёта хулиганов. Предлагается только одно - ограничение входа по имени рабочей станции. Общий смех. Подделывать имя компьютера не умеют только ясельники. Отчего бы не дать возможность ограничить дополнительно MAC-адрес сетевой карты, IP-адрес или подсеть - тогда пароль могут знать все, но никто не прорвётся на сервер с постороннего компьютера! Забывакам и трёкалам пароль можно было бы вообще не устанавливать.
Файловый сервер - коллективное хранилище. Но кто-то из коллектива может переполнить это хранилище и пострадают все. Представим себе диск в один гигабайт. На нём десять папок, в каждой из которых трудится над документами свой коллектив в десять человек. Итого сотня файлописак. Предусмотреть бы возможность ограничения размера папок, чтобы установить ограничение в 100 мегабайт на каждую папку - и порядок обеспечен. Но нет такой возможности. Зато появилось понятие дисковой квоты. Глупость невероятная: ограничивается объём данных, которые может записать конкретный пользователь на весь диск. Администратор что, должен каждого ограничить десятью мегабайтами? Его съедят завтра же (и пространство, и администратора)!
Люди у нас грамотные, сами неплохо организовывают своё рабочее место. Вот тут-то им и закавыка: невозможно простым способом подключить в качестве сетевого диска какую-либо папку, входящую в ресурс, предоставляемый сервером. Во всех версиях Windows отсутствует пункт "Подключить как сетевой диск" в контекстных меню папок, вложенных в серверный ресурс.
Вот объединили на сервере неких пользователей в группу и дали этой группе права на некие ресурсы. Потом появляется новый пользователь, достойный допуска к тем же ресурсам. Что делаем? Правильно, добавляем новичка в упомянутую группу. И что? А ничего! Не получит он сразу прав на ресурсы, в отличие от уже существующих в группе товарищей. Надо догадаться, что новый член группы должен перевойти в сеть.
На файл-сервере невозможно создать "Корзину" для файлов, хотя бы удалённых клиентами, не говоря уж о перезаписанных. Стёр клиент или криво отредактировал файл на сервере и со слезами звонит админу. А чем админ поможет? Да и в корзине легче ответить на вечный вопрос "Кто стёр файл?". В Windows Server 2003 наконец-то появилась возможность назначить папке Shadow Copy и установить людям Shadow Copy Client. Тогда можно использовать стёртые и перезаписанные файлы!
С файл-сервера невозможно оповестить о чём-либо рабочие станции Windows 9x. Уж если в сетевой конфигурации клиента указано "Входить в домен такой-то", так почему бы майкрософтцам не поставить winpopup в автозагрузку?
На файл-сервере невозможно сделать так, чтобы пользователь, имеющий какие-то права только на одну из внутренних папок некоего ресурса, не видел названий соседних папок и файлов.
Невозможно запретить пользователю удалить папку, к которой он имеет полный доступ. Если пользователь случайно удалит корень своего популярного ресурса, то саму папку не жалко. Жалко потом заново ставить на неё разрешения для всех клиентов.
Администратору сервера важно знать какие файлы и кем открыты в данный момент. Это чтобы не огорчить критичных клиентов необходимым перезапуском сервера. Но соответствующая оснастка спокойно показывает давным-давно закрытые файлы как открытые.
По умолчанию пользователи файл-сервера перемещают файлы внутри ресурсов вместе с правами на эти файлы. Вот к чему это приводит. Создал человек в некоей закрытой для других папке файл и переместил этот файл в папку, открытую людям на чтение. И люди видят этот файл, а открыть/скопировать не могут. Прав не имеют. Ещё хуже, когда человек переместил себе в рабочую папку чужой файл и использовал его в качестве шаблона для набивки своих конфиденциальных данных. Бывший владелец файла будет иметь на него все права. Такую подлянку никто даже не ожидает.
После истечения срока действия пароля система не даёт клиенту ни единой возможности войти под старым паролем и установить новый. Все отпускники, командировочные и больничники - к администратору. Если пользователю сервера уже давно была установлена опция "Пароль никогда не устаревает", а потом администратор одумался и снял её, то система вместо того, чтобы логично предложить пользователю при первом входе сменить пароль, просто отсекает ему вход. Смена пароля самим администратором тоже не помогает - изменённый пароль остаётся устаревшим.
Вы - администратор. Надавали серверной системе важных регулярных заданий в планировщике задач и рады как всё славно выполняется. Перед отъездом в отпуск на всякий случай сменили свой пароль и отбыли. Вернувшись, будете сражены печальной вестью: задания не выполнились ни разу! В планировщике вводится и имя, и пароль пользователя. Если же Вы сменили пароль абсолютно штатными системными манипуляциями, задания просто перестанут выполняться. К тому же, пароли в планировщике почему-то слетают при переходе на летнее/зимнее время.
Отключение на сервере ненужных служб приводит к непредсказуемым и необъяснимым плачевным результатам. Так, без спулера печати почему-то не устанавливаются обновления. А кому он нужен на файл-сервере?
Любая железяка имеет право сломаться. Ломаются и контроллеры доменов. Вместо ушедшего из жизни сервера администратор хочет подключить новёхонький. Он прозорливо удаляет имя усопшего сервера из списка контроллеров домена в соответствующей оснастке. Вводит в домен новый контроллер с прежним именем, грузит его должными задачами ... Эх, жаль беднягу. Теперь системный журнал событий замучает его сообщениями о наличии дубликата имени контроллера. Хоть опять всё сноси и ставь заново. Оказывается, чтобы действительно удалить контроллер из домена, нужно кропотливо поработать утилитой командной строки Ntdsutil. Без подробных инструкций с этим делом никому не справиться.
Мелкая неисправность может привести к крупным неприятностям. Вышла из строя плата сетевого интерфейса. Спокойно меняем её на новую. Выглядит всё нормально. В системе присутствует только новая железка и её драйвер, но при попытке назначить прежний ip-адрес система призывает хорошенько подумать - дескать, этот адрес уже назначен временно отсутствующему устройству. Но где оно, это устройство? Как его удалить? Никаких следов, кроме обильных записей в реестре (причём, некоторые из них защищены от удаления). Но адрес всё же назначаем, всё нормально работает. За исключением пустячка - система теперь загружается безобразно долго. Ждёт, видимо, не оживёт ли виртуальное привидение.
Вполне можем захотеть, чтобы DNS-сервер осведомлялся у других серверов об отсутствующих у него адресах, но не давал бы таких данных никаким другим серверам. Это вроде просто - в закладочке Forwarders прописываем нужные сервера, а в закладочке Advanced ставим галочку Disable recursion. И утопаем в жалобах клиентов о невозможности попасть на нужные интернет-сайты. Перепроверяем что же мы там наконфигурировали - всё выглядит нормально. Так бы дурами и померли, не подвернись оснастка, предназначенная для Windows 2003 Server. В ней тот же сервер выглядит иначе - Forwarders вообще не активны (ни включить, ни выключить), а в закладочке Advanced нас ждёт отгадка - к словам Disable recursion в скобочках приписано also disables forwarders!
Даже после штатного вывода из работы контроллера домена утилитой dcpromo, в DNS остаётся его GUID. Подключаем новый контроллер домена с тем же именем. Внешне всё выглядит гладко. Но GUID этого имени в DNS остался старым! И постепенно зреет страшная бомба из-за отсутствия репликаций между контроллерами.
Простой и эффективный способ резервного копирования файлов с помощью запускаемого по расписанию bat-сценария xcopy, таит в себе засаду. Как только этой славной утилите попадется файл с полным именем пути, превышающим 260 символов, она лаконично ругнётся Insufficient memory и прекратит трудиться.
Фирма Microsoft предпочитает грести денежки на сертификации армии специалистов поддержки, а не прилагать усилия и достигать сертификации в России своих продуктов по высоким классам безопасности.
Зы добовляем и от себя
Наверх
