2. Конфигурация рабочих станций

Одной из первичных задач любого администратора сети должно стать создание конфигураций рабочих станций, которые были бы постоянными и едиными. В таком случае, если возникнут какие-либо проблемы, обслуживающий персонал сети будет располагать полной информацией о рабочей конфигурации пользователя. Невозможность сделать это обычно приводит к существенному увеличению времени и затрат, необходимых для устранения неисправностей, и повышает стоимость эксплуатации машины. К несчастью, пользователи имеют тенденцию экспериментировать со своими рабочими станциями, изменяя настройки конфигурации или устанавливая нелицензионное программное обеспечение. Это может привести к тому, что система будет работать нестабильно, а также затруднять процессы обслуживания и отладки. Поэтому администраторам настоятельно рекомендуется предпринимать ряд ограничительных мер по отношению к рабочим станциям сети, чтобы предотвратить эти неавторизованные эксперименты. Такие возможности, как создание профилей пользователей и правил системной политики, являются базовыми инструментами, которые можно использовать в системах Windows для выполнения указанных задач независимо от предполагаемого уровня ограничительных мер для пользователей сети. Применяя эти инструменты, можно ограничить набор программ, разрешенных для запуска в данной системе, запретить доступ к отдельным элементам операционной системы, а также контролировать использование сетевых ресурсов. Эти инструменты, как и некоторые другие, являются частью того, что фирма Microsoft называет Zero Administration Initiative (ZAI, инициатива нулевого администрирования). Сущность ZAI неправильно понимается многими людьми, которые склонны считать, что ее цель заключается в создании рабочей станции, не требующей вообще никакого обслуживания и административного вмешательства любого рода. На самом же деле, ZAI была разработана для того, чтобы не допускать проведения пользователями мероприятий по системному администрированию, для которых они не имеют соответствующей квалификации. С помощью настройки тщательно спланированной и протестированной конфигурации и последующего запрещения любых ее изменений пользователями можно значительно уменьшить стоимость обслуживания рабочих станций. Проведение ограничительной политики и уменьшение количества пользователей, имеющих доступ к рабочим станциям, способно привести к серьезным последствиям, поэтому администраторы всегда должны учитывать возможности пользователей сети, прежде чем принимать подобные решения. Неопытные пользователи компьютеров могут счесть очень удобным и даже приветствовать ограниченную конфигурацию, изолирующую их от сложных и непонятных элементов операционной системы. Однако пользователи с более высоким уровнем навыков в сфере применения компьютеров вполне могут негативно воспринять ограничение доступа лишь небольшой частью возможностей компьютера, из-за чего в свою очередь может упасть эффективность их работы.

2.1 Размещение приложений и данных

Одной из главных задач любого администратора сети является принятие решения о том, в каком именно месте сети будут храниться определенные данные. Рабочим станциям сети требуется доступ к файлам операционной системы, приложениям и рабочим файлам, поэтому определение мест расположения этих элементов представляет собой важнейшую часть процесса создания стабильной и безопасной сети. Некоторые администраторы вообще не контролируют, где пользователи хранят свои рабочие файлы. К счастью, большинство приложений, работающих в среде Windows, устанавливаются по умолчанию в каталог C:\Program Files локального диска, и это уже обеспечивает некоторую меру последовательности, если нет ничего более существенного. Некоторые приложения даже создают рабочие каталоги по умолчанию на локальном диске, однако оставлять пользователей наедине с их собственными устройствами, когда речь идет о хранении файлов данных, обычно представляет собой крайне опасную практику. Многие пользователи не имеют вообще никаких или имеют очень мало знаний о структуре каталогов своих компьютеров, а также не обладают опытом в управлении файлами. Это может привести к тому, что файлы для разных приложений окажутся беспорядочно "свалены" в один общий каталог и оставлены без всякой защиты от случайного повреждения или удаления.

Размещение операционной системы на сервере. На заре Windows запуск операционной системы с диска сервера являлся практической альтернативой установки ОС на каждую рабочую станцию. Хранение файлов операционной системы на сервере позволяло администратору не только предотвратить их повреждение или случайное удаление, но и обновлять версию ОС для всех рабочих станций одновременно. Подобное решение также помогает экономить дисковое пространство локальной машины. Однако с годами емкость диска средней рабочей станции возросла неимоверно, а размер самой операционной системы Windows превысил все мыслимые пределы.

В настоящее время простая установка стандартной операционной системы на отображенный диск сервера уже не может считаться практичной. Рабочая станция, использующая операционную систему Windows 95/98 или Windows NT/2000, Windows XP должна загрузить многие мегабайты информации только для запуска системы. Если умножить эту цифру на общее количество рабочих станций сети, исчисляемое сотнями, можно легко представить, что общий объем сетевого трафика, генерируемого при этом, будет способен лечь тяжким грузом даже на самую быструю сеть. Кроме того, недостаток дискового пространства более не является проблемой, когда самые обыкновенные рабочие станции оснащаются жесткими дисками, способными хранить от 80 до 750 Гбайт информации и даже больше. Установка операционной системы на локальный диск представляется в большинстве случаев более очевидным решением. С другой стороны, в настоящее время появился целый ряд новых технологий, позволяющих снова сделать практичной исполнение операционной системы Windows с сервера. Однако в нынешнем варианте рабочие станции не загружают операционную систему целиком с диска сервера. Вместо этого, рабочие станции функционируют в качестве клиентов-терминалов, которые соединяются с сервером терминалов. Операционная система и приложения рабочей станции фактически исполняются сервером, в то время как функции терминала исчерпываются исключительно вводом/выводом. В результате, рабочие станции требуют минимального количества ресурсов, так как сервер берет на себя львиную долю нагрузки.

При использовании подобной схемы терминалы могут быть относительно слабыми компьютерами, исполняющими программу эмуляции терминала, или же специализированными терминалами Windows, разработанными для запуска исключительно клиентского программного обеспечения. В любом случае, стоимость подобной рабочей станции даже близко нельзя сравнивать с ценой нового персонального компьютера, чье аппаратное обеспечение достаточно для исполнения индивидуальной копии Windows NT/2000 или Windows XP. Операционная система Windows NT 4.0 имеет специальную версию, поддерживающую данную технологию, которая носит название Windows NT Server Terminal Server Edition, a операционная система Windows 2000 и Windows XP уже включает возможность сервера терминалов в основной набор. Существуют также продукты независимых разработчиков, обеспечивающие аналогичные возможности, наиболее известным из которых является WinFrame от Citrix Systems.

Эксплуатация сети Windows, основанной на терминалах, коренным образом отличается от обслуживания стандартной ЛВС, и данный вариант нельзя назвать альтернативой для тех сетей, что уже используют полные версии операционных систем Windows на своих рабочих станциях. Однако, если формируется новая сеть или проводится масштабное расширение, использование терминалов Windows может стать одним из тех вариантов решения, которые следует рассмотреть.

Размещение приложений на сервере. Запуск приложений с диска сервера вместо диска рабочей станции представляет собой еще один способ обеспечения стабильной рабочей конфигурации для пользователей и сведения к минимуму нагрузки по администрированию сети. В простейшей форме процесс сводится к установке приложения обычным образом с указанием каталога сетевого диска, вместо локального каталога, в качестве места расположения файлов программы. Однако приложения Windows никогда не отличались простотой, поэтому в реальности этот процесс выглядит намного сложнее. Запуск приложений с диска сервера имеет как достоинства, так и недостатки. Положительным фактором, как и в случае с размещением на сервере операционной системы, можно назвать экономию пространства локальных дисков, защиту файлов приложений от повреждения или удаления, а также возможность улучшения и обслуживания единственной копии приложения, а не индивидуальных копий на каждой рабочей станции. Среди недостатков на первый план выступает тот факт, что приложения, размещенные на сервере, обычно работают сравнительно медленнее, чем их локальные аналоги, а также генерируют существенный объем сетевого трафика и не могут функционировать, если сервер неисправен или недоступен по иным причинам. Во времена DOS приложения были самодостаточными и обычно состояли не более чем из одного программного каталога, который содержал все файлы данного приложения. Тогда можно было установить приложение на сервер и позволить другим системам использовать его, просто запуская исполняемый файл. Сегодняшние приложения Windows намного сложнее, и программа их инсталляции не исчерпывается простым копированием файлов.

Кроме программных файлов приложение Windows обычно включает определенные установки системного реестра, наличие некоторых DLL-файлов Windows, которые должны присутствовать на локальном диске, а также процедуру создания строк в меню кнопки Start (Пуск) и пиктограмм, необходимых для запуска приложения. Если есть желание совместно использовать несколькими рабочими станциями приложение, размещенное на сервере, то, как правило, по-прежнему придется провести его полную установку на каждой машине. Это делается для того, чтобы быть уверенным, что каждая рабочая станция имеет соответствующие файлы Windows, установки реестра и пиктограммы, необходимые для работы приложения. Один из способов практической реализации приложения, размещенного на сервере, заключается в проведении полной инсталляции программы на каждую рабочую станцию, с указанием имени одного и того же каталога сервера в качестве места расположения файлов программы в каждом отдельном случае. Таким образом, каждая рабочая станция получит все необходимые файлы и модификации, а на сервере останется всего одна копия файлов приложения.

Другой важной проблемой является способность поддерживать индивидуальные параметры конфигурации для каждой рабочей станции, получающей доступ к приложению. Например, если один из пользователей модифицирует интерфейс совместно используемого приложения, весьма нежелательно, чтобы эти изменения отражались на других пользователях. В результате, каждый из пользователей приложения должен поддерживать собственную копию параметров конфигурации данного приложения. Является это простой или сложной задачей и выполнимо ли вообще, целиком и полностью зависит от того, где именно данное приложение хранит свои конфигурационные установки. Если, например, установки сохраняются в системном реестре или INI-файле Windows, в процессе инсталляции будет создана отдельная конфигурация для каждой рабочей станции. Однако, если по умолчанию установки конфигурации приложения размещаются вместе с файлами программы на сервере, то следует предпринять ряд шагов, направленных на то, чтобы не допустить ситуации, когда изменения, вносимые одним пользователем, аннулируют изменения других пользователей.

В некоторых случаях существует возможность конфигурирования приложения для хранения установок конфигурации в альтернативном месте, что позволяет переместить их на локальный диск каждой из рабочих станций или в индивидуальный каталог каждого пользователя на сервере. Если такой возможности нет, данное приложение нельзя считать подходящим для совместного использования в сети. Во многих случаях наиболее практичным способом исполнения приложений, размещенных на сервере, является применение приложения, которое имеет свои собственные сетевые возможности. Например, Microsoft Office позволяет создавать на сервере точку управляемой инсталляции (administrative installation point), которую можно затем использовать для установки приложения на рабочие станции. Проводя каждую инсталляцию, можно выбирать, будут ли файлы приложения копироваться на локальный диск, запускаться с диска сервера или распределяться между сервером и рабочей станцией.

Хранение рабочих файлов. В большинстве современных сетей Windows как операционная система, так и файлы приложений устанавливаются на локальных дисках рабочих станций. Однако по-прежнему только от администратора сети зависит принятие решения о том, где именно будут храниться файлы данных, создаваемые и изменяемые пользователями. При решении данного вопроса следует обращать особое внимание на некоторые принципиальные моменты, а именно, доступность этих файлов для пользователей и их безопасность. Естественно, пользователи должны получать доступ к своим файлам данных, но существуют также файлы, которые должны совместно использоваться многими пользователями. Важные файлы данных также должны быть защищены от модификации и удаления неавторизованным персоналом и к тому же дублироваться на альтернативном носителе в целях страховки от непредвиденных обстоятельств, например, выхода диска из строя или пожара. Рабочие файлы могут иметь различный формат, что не может не отражаться на том, каким способом их надлежит хранить. Например, документы индивидуальных пользователей, созданные с помощью текстовых редакторов или электронных таблиц, предназначены для использования одним человеком в каждый момент времени, в то время как базы данных поддерживают одновременный доступ нескольких пользователей. В большинстве случаев файлы баз данных хранятся на компьютерах, исполняющих приложения серверов баз данных, поэтому администраторы могут регулировать доступ к ним с помощью разрешений файловой системы и защищать регулярным резервным копированием. Другие типы файлов могут требовать дополнительного планирования. Так как операционные системы Windows 95/98 и Windows NT/2000 Windows XP все относятся к одноранговым сетевым операционным системам, можно разрешить пользователям хранить свои документы как на локальных дисках, так и на дисках сервера, и по-прежнему иметь возможность их совместного использования с другими пользователями сети. Однако есть несколько достаточно веских причин, по которым более правильным решением представляется хранение всех рабочих файлов на жестких дисках сервера. Первая и наиболее важная из этих причин заключается в том, что так намного проще защищать файлы от потери из-за сбоя диска рабочей станции. Серверы с большей вероятностью оснащены всевозможными защитными механизмами, такими как, например, RAID-массивы или зеркальные тома. Кроме того, серверам проще использовать резервное копирование. В конце концов, серверы позволяют сделать данные доступными в любое время, тогда как рабочая станция может быть выключена при отсутствии пользователя. Вторая причина относится к управлению доступом. Несмотря на то, что и серверы, и рабочие станции Windows имеют сходные возможности по предоставлению определенных прав конкретным пользователям, сами пользователи крайне редко обладают достаточным уровнем навыков или желанием для того, чтобы эффективно защитить свои собственные файлы. Поэтому администраторам сети намного проще управлять правами на одном сервере, чем на множестве рабочих станций. Еще одна немаловажная причина состоит в том, что присутствие дисков совместного использования у каждой рабочей станции делает крайне трудным обнаружение конкретной информации в сети. Если только бегло взглянуть на домен Windows NT/2000 или Windows XP и увидеть там десятки или сотни компьютеров, каждый из которых имеет собственные ресурсы совместного использования, можно легко понять, насколько сложной будет задача по определению местоположения конкретного файла. Ограничение ресурсов совместного использования рамками относительно небольшого числа серверов способно упростить подобный процесс. В результате наилучшей стратегией для большинства сетей Windows представляется установка операционной системы и всех приложений на локальные диски рабочих станций в сочетании с хранением всех рабочих файлов на серверах сети. Наиболее распространенная практика заключается в создании на сервере индивидуального каталога для каждого пользователя, причем пользователю предоставляется полный контроль над собственным каталогом. Затем следует сконфигурировать все приложения для хранения рабочих файлов в этом каталоге по умолчанию, чтобы никакой ценной информации не оставалось на локальном диске. В зависимости от нужд пользователей сети вы можете сделать домашние каталоги частными (private), чтобы только данный пользователь имел доступ к своему каталогу, или же разрешить всем пользователям доступ типа "только чтение" к индивидуальным каталогам других пользователей. Это позволит каждому пользователю совместно использовать любой рабочий файл с другим пользователем, просто сообщив ему имя и место расположения этого файла.

При создании учетной записи пользователя в домене Windows NT или объекта пользователя в Active Directory операционной системы Windows 2000 существует возможность одновременного создания индивидуального каталога для данного пользователя с помощью диалогового окна. По умолчанию пользователям предоставляется полный контроль над их домашними каталогами, а всем остальным доступ полностью запрещен.

Контроль конфигурации рабочей станции. В организации, состоящей из опытных пользователей, каждого пользователя можно предоставить самому себе в вопросах конфигурации рабочего стола Windows. Знающие пользователи могут создавать свои пиктограммы на рабочем столе, управлять собственными ярлыками меню кнопки Start (Пуск), самостоятельно вьщелять для обозначения дисков определенные буквы. Однако далеко не всякая организация может похвастаться большим количеством опытных пользователей, и поэтому намного удобнее предоставить администратору сети возможность сформировать стабильную и жизнеспособную конфигурацию рабочих станций.

Отображение дисков. Многие неопытные пользователи не имеют четкого представления о сущности сети и о том, как диск сервера может обозначаться определенной буквой на локальной машине. Пользователь может иметь диск, обозначенный буквой F, который соответствует диску определенного сервера, и полагать, что системы остальных пользователей сконфигурированы таким же образом. Если распределение букв для обозначения дисков на рабочих станциях не является постоянным, могут возникать недоразумения, когда, например, один пользователь говорит другому, что файл находится на диске F, а фактически эта буква соответствует совсем другому диску совместного использования. Для того чтобы избежать подобных сложностей, администраторам следует создать стратегию стабильного отображения дисков для пользователей, совместно применяющих одни и те же ресурсы. В качестве примера можно привести тот факт, что, в большинстве случаев, пользователи имеют в качестве своего "домашнего сервера" сервер отдела или рабочей группы, поэтому очень хорошей идеей будет обозначение диска этого сервера одной и той же буквой на всех рабочих станциях. Если в сети есть серверы приложений, предоставляющие свои ресурсы всем пользователям сети (например, сервер базы данных компании), тогда каждая система сети должна обозначать диск этого сервера одной и той же буквой. Реализация даже таких минимальных мер позволит значительно уменьшить число надоедливых звонков озадаченных пользователей в службу технической поддержки сети. Для реализации стабильного набора букв, соответствующих дискам пользователей, можно применять скрипты входа в сеть. Они содержат команды net use, отображающие диски определенных серверов при каждом подключении пользователя к сети. Правильное структурирование этих команд позволит создать единый скрипт входа в сеть для многочисленных пользователей. Например, для выделения буквы диска, обозначающей домашний каталог каждого пользователя, можно использовать следующую команду: NET USE X: /home

Чтобы обозначить командный файл в качестве файла скрипта входа в сеть, необходимо указать его имя в диалоговом окне User Environment Proffle утилиты User Manager for Domains операционной системы Windows NT 4.0. В системе же Windows 2000 и Windows XP, имя этого файла следует указать на вкладке Proffle (Профиль) диалогового окна Properties (Свойства) объекта данного пользователя в консоли Users and Computers, входящей в Active Directory.