Fedoseyev.ru

Я люблю Windows больше, чем UNIX. Мне в ней комфортнее. Я лучше понимаю механизмы ее работы. Я лучше понимаю, как ей управлять, как выполнять базовые задачи администрирования — как оптимизировать производительность, как бэкапить, как восстанавливать, как автоматизировать, как защищать от угроз безопасности. Я хорошо понимаю, ЧТО и ЗАЧЕМ в Windows надо обслуживать, а не только КАК. Поэтому web-серверы я по возможности тоже организовываю на Windows. Исторически так не принято: многие web-решения требуют минимальную среду для выполнения, а Windows — среда далеко не минималистичная. Тем не менее ее можно очень неплохо оптимизировать, причем всего за пару минут.

1. Оптимизация служб.

Для web-сервера не требуются и могут быть отключены следующие службы:

• Alerter
• ClipBook
• Computer Browser
• DHCP Client
• DHCP Server
• Fax Service
• File Replication
• Infrared Monitor
• Internet Connection Sharing
• Messenger
• NetMeeting Remote Desktop Sharing
• Network DDE
• Network DDE DSDM
• Print Spooler
• TCP/IP NetBIOS Helper Service
• Telephony
• Telnet
• Uninterruptible Power Supply

2. Оптимизация дисковой подсистемы.

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

3. Оптимизация сети.

Перво-наперво отключаем поддержку всего, кроме TCP/IP, на сетевом интерфейсе(ах) сервера. После этого отключаем поддержку LMHOSTS Lookup и NetBIOS over TCP/IP.

Все. 2 потраченные минуты приводят к тому, что в чистом виде система потребляет порядка 300 Мбайт памяти при 0% загрузке процессора. Это при включенном мощном антивирусе (Symantec Endpoint Protection). Для пущей оптимизации можно также подкрутить реестр, разрегистрировать ненужные dll, удалить лишние компоненты системы, включить HTTP Keep-Alives и сделать еще кучу полезных вещей, доведя систему до состояния резвой анорексички.

Отдельно советую по возможности использовать Windows Server 2003 — для web-сервера редко требуется 2008 или, упаси бог, 2012 версия ОС.

admin Default Windows Server

Проблема: в оснастке Server Manager (в русской версии, видимо, Управление Сервером) возникает ошибка управления ролями с лаконичной надписью «Error».

С указанной в заголовке ошибкой я столкнулся на производственном сервере Hyper-V после очередной установки обновлений от Microsoft. Для наглядности графическая демонстрация:

Детали ошибки сообщали некоторые более конкретные и вразумительные подробности: Unexpected error refreshing Server Manager: Exception from HRESULT: 0x800F0818. Также предлагалось подробнее изучить события Applications and Services Logs -> Microsoft -> Windows -> Server Manager -> Operational (после изучения документации, нашел второй вариант ошибки: Server Manager: Unexpected error refreshing Server Manager: No signature was present in the subject. (Exception from HRESULT: 0x800B0100). Нижеприведенное решение позволит избавиться и от нее тоже).

Объяснение: проблема возникает из-за вмешательства посторонних служб (индексирования Windows, антивируса и пр. сервисов, работающих в фоне), кэширования записи на диск или «прочих ошибок» (нравится объяснение?) при установке обновлений, из-за которого неверно или неполностью копируются пакеты обновлений с расширением .MUM и связанные с ними .CAT.

Решение:

1. Запустите Microsoft Update Readiness Tool (брать здесь: http://support.microsoft.com/kb/947821)
2. После получения сообщения об успешном окончании работы утилиты, откройте получившийся log-файл C:\Windows\logs\CBS\Checksur.log
У меня он содержал следующее:

<…>

Checking Package Manifests and Catalogs
(f) CBS MUM Corrupt 0x00000000 servicing\Packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum  Expected file name Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name

<…>

Unavailable repair files:
 servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum
 servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.cat

Итак, проблема возникает из-за неверного содержимого двух файлов. В их названиях содержится наименование KB, в которых эти файлы содержатся. У меня это KB979916. Google подсказал, что это обновление безопасности .NET Framework 3.5.1.

3. Скачайте пакеты обновлений по вашим KB и скопируйте их в корень диска C:.  По своему КВ я брал обновление отсюда: http://www.microsoft.com/downloads/en/details.aspx?familyid=a49532d7-53f6-4190-aaf6-b1a818924764&displaylang=en
4. Теперь нам необходимо получить права  на директорию C:\Windows\Servicing\Packages. Запускаем консоль cmd с правами администратора и выполняем следующие команды:

Сделаем текущего пользователя владельцем директории:

Дадим пользователю (у меня это admin из домена domain.local, поэтому запись выглядит как admin@domain) полный доступ к директории:

5. Распаковываем скачанные ранее пакеты обновлений. Мой называется Windows6.1-KB979916-x64.msu и лежит в корне диска C:

Создадим в корне диска C: небольшую структуру каталогов (каталог TMP и вложенный в него каталог CAB), которые будут служить временным хранилищем для распаковываемых данных:

Распакуем MSU-файл с каталог TMP:

В каталоге C:\TMP появится файл с именем Windows6.1-KB979916-x64.cab. Распакуем его в каталог C:\TMP\CAB:

6. Найдите в каталоге C:\TMP\CAB файлы Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum и Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.cat, о повреждении или отсутствии которых нам сообщила на 2-м шаге Microsoft Update Readiness Tool. Скопируйте их в каталог C:\Windows\Servicing\Packages и перезапустите Server Manager, чтобы убедиться, что проблема решена:

Второй вариант предполагает, что нужных файлов вы не нашли. В этом случае присвойте файлам update.cat и update.mum из каталога C:\TMP\CAB имена, на отсутствие или повреждение которых состалась Microsoft Update Readiness Tool на 2-м шаге.

Вуаля!

P.S. Если ошибка не пропала, повторите инструкцию сначала.

admin Default Troubleshooting, Windows Server

Для управления групповыми политиками в Windows Server я обычно использую Group Policy Management Console. Когда один из рядовых серверов домена на базе Windows Server 2003 x64 был повышен до DC, я обнаружил, что при попытке выполнить на нем модификацию объекта групповой политики (команда Edit… из контекстного меню GPO) возникает ошибка: «Windows cannot find ‘gpedit.msc’. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.» При этом модификация GPO остается возможной, но строго через запуск MMC и добавлении в нее оснастки Group Policy Object Editor. Естественно, это неудобно, и лишает GPMC всей ее прелести.

Перейдем к решению. Фактически, в 64-битной Windows все оснастки управления (*.msc) подразделяются на 32- и 64-битные версии, и размещаются в разных каталогах: 32-битные в %windir%\system32, 64-битные — в %windir%\syswow64. Вышеописанная ошибка возникает из-за того, что в директории syswow64 отсутствует оснастка gpedit.msc. Для того, чтобы эта проблема решилась, достаточно выполнить следующую команду:

Ее успешное выполнение будет озвучено так:

После этого ошибка возникать не будет.

admin Default GPMC, Troubleshooting, Windows Server

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

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

Представим себе ситуацию: вы администрируете домен AD крупной компании с сетью филиалов, разбросанных по всей России. Согласно установленному регламенту, вы отвечаете за создание учетных записей пользователей (любого подразделения, любого филиала) в AD и для каждого объекта обязаны заполнять следующие атрибуты:

— имя и фамилия;
— выводимое имя;
— почтовый индекс;
— почтовый ящик (неэлектронный!);
— город;
— страна или регион;
— путь к перемещаемому профилю пользователя (в каждом филиале используются свои серверы хранения профилей);
— отдел;
— организация;
— руководитель.

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

Пускай в день вам приходится создавать до 10 учетных записей для сотрудников организации, естественно, в разных филиалах и подразделениях.

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

Я расскажу, как этого избежать.

Один из способов автоматизировать создание учетных записей пользователей – создавать их из шаблонов. Но сперва нужно создать сами шаблоны.

Допустим, грядет существенное увеличение штата финансового отдела главного, московского, подразделения организации, и нам предстоит создать довольно много учетных записей для его новых сотрудников.

В оснастке управления пользователями и компьютерами AD развернем OU Finance и создадим нового пользователя со следующими учетными данными:

Теперь откроем его свойства и заполним вышеуказанные атрибуты:

Заодно сразу же присоединим его к группе безопасности финансового отдела:

Готово. Обратите внимание, что я сразу отключил шаблонную учетную запись, чтобы ее невозможно было использовать для авторизации в домене.

Теперь мы можем использовать эту учетную запись для создания новых. Для этого необходимо вызвать контекстное меню учетной записи и выполнить команду Копировать…

При ее выполнении будет вызвано окно копирования объекта с пустыми атрибутами Имя, Фамилия, Полное имя, UPN и пр. Заполним их данными гипотетического сотрудника финансового отдела Ивана Петрова:

После выполнения копирования, учетная запись будет создана со всеми атрибутами, заполненными для _user_finance_template. Приведу в качестве примера скриншот свойств учетной записи во вкладке Член групп:

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

admin Default AD, Windows Server

Управление Active Directory – не просто работа, а целое искусство, требующее, помимо академических знаний об ее архитектуре, навыки проектирования согласно бизнес-требованиям организации в ИТ-инфраструктуре и умения автоматизировать рутинные операции с целью минимизации допущения ошибок.

В рамках данного поста я рассмотрю управление объектами AD из командной строки.

В Windows Server 2008 существуют следующие инструменты командной строки для управления AD:
— Dsadd – создание объекта в каталоге;
— Dsget – возврат указанных атрибутов объекта;
— Dsmod – модификация указанных атрибутов объекта;
— Dsmove – перемещение объекта;
— Dsrm – удаление объекта и его дочерних объектов;
— Dsquery – выполнение запроса на основе параметров и возврат списков объектов с такими параметрами.

Большинство команд DS имеют 2 модификатора: тип и имя DN объектов.  К примеру, для создания учетной записи пользователя Ivan Ivanov в подразделении Finances, используется команда:

В данном случае модификатор user указывает на тип создаваемого объекта (User, он же Пользователь), имя DN – Ivan Ivanov. Так как имя пользователя содержит пробел, то имя DN целиком заключается в кавычки.

Для выполнения манипуляций с атрибутами объектов используются Dsquery, Dsget и Dsmod. Например, отыщем всех пользователей AD, имя которых начинается с Ivan:

Dsquery возвратила нам имя DN объекта Ivan Ivanov.

Модифицируем ему атрибут Office, содержащий номер кабинета, в котором сидит сотрудник:

Заполненные атрибуты объектов AD могут существенно упростить управление AD, послужив критериями поиска объектов и их модификации. Команды DS поддерживают конвейеризацию входных данных. Это позволяет использовать результаты выполнения Dsquery или Dsget в качестве входных данных.

Чтобы стало понятнее, я приведу пример.

Скажем, вы управляете территориально-распределенным доменом с большим количеством филиалов. Для создания списков рассылки, отдел кадров просит вас предоставить им адреса электронной почты всех сотрудников, например, тамбовского и воронежского филиалов. Сбор такой информации вручную может занять довольно много времени, да и мало кого вдохновит. Но если при создании учетных записей пользователей в AD тамбовские и воронежские администраторы сразу же заполняли атрибуты объектов пользователей, то это будет для вас пустяковым делом на одну минуту.

Я не стал заполнять лабораторную среду большим количеством объектов и их атрибутами, чтобы можно было выполнять поиск с такими условиями. Однако, запросить для примера номера кабинетов, в которых сидят пользователи с именем Ivan, в ней можно:

Все просто, не правда ли?

Для закрепления материала, рассмотрим мини-сценарий:
1. Просмотрим список учетных записей пользователей, имена которых начинаются с Ivan;
2. создадим новый OU под названием Tr;
3. перенесем учетную запись пользователя Ivan Ivanov в OU Tr;
4. удалим OU Tr вместе со всеми дочерними объектами;
5. Еще раз просмотрим список учетных записей пользователей, имена которых начинаюся с Ivan.

Я создал в корне диска сценарий командной строки scenario.cmd следующего содержания:

Его выполнение происходило так:

Как видите, выполнение шага 5 выдало пустой результат. Это значит, что сценарий отработал верно.

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

admin Default AD, Windows Server

По умолчанию, для контроллеров домена действует политика, запрещающая подключения к ним через RDP членам группы Remote Desktop Users, если они не входят в группу Domain Admins. При попытке подключения такого пользователя к DC, появляется сообщение: «To log on to this remote computer, you must be granted the Allow log on through Terminal Services right. By default, members of Remote Desktop Users group have this right. If you are not a member of the Remote Desktop Users group or another group tha has this right, or if the Remote Desktop User group does not have this right, you must be granted this right manually.»

Определенная логика в такой политике есть, но бывают ситуации, когда на DC развертываются службы, управляемые не доменными администраторами. И в этом случае возникает необходимость предоставить им возможность управления сервером с соответствующим делегированием полномочий. Как было упомянуто, добавление администраторов в группу Remote Desktop Users не срабатывает. Зато срабатывает следующее:

1. Открываем из меню Start -> Settings -> Control Panel -> Administrative Tools -> Terminal Services Configuration;
2. В разделе Connections открываем Properties соединения RDP-Tcp;
3. Во вкладке Permissions добавляем учетную запись, которой требуется доступ к серверу через Remote Desktop, и даем ей необходимые права (User Access, например):

4. Празднуем победу.

admin Default Windows Server, Дела админские, Удаленное администрирование

Случается, возникает необходимость восстановить исходное состояние политик для домена и для контроллеров домена (например, настроить все заново проще, чем перестроить после предыдущего системного администратора; либо возникают ошибки при применении GPO, а RSoP не выявляет ошибочно настроенную политику). Для этого существует программа dcgpofix.

При ее запуске, будут утеряны все изменения объектов групповой политики Default Domain Policy и Default Domain Controllers Policy (даже в том случае, если они были переименованы). Отдельно восстановить политики по умолчанию для домена или для контроллеров домена можно, используя ключ /target с указанием параметра dc или domain. Для использования dcgpofix в среде с различными версиями Active Directory, следует использовать ключ /ignoreschema.

Перейдем к примерам. Восстановим исходное состояние политики контроллеров домена в среде с разными версиями AD:

Результат выполнения команды можно увидеть, запустив редактор объектов групповых политик и проверив «дефолтность» Default Domain Controllers Policy.

admin Default AD, Windows Server, Дела админские

Одна из самых непротиворечивых концепций безопасности гласит, что без крайней необходимости работать под учетной записью администратора не следует. Особенно под учетной записью администратора домена. Однако, решение административных задач, требующих повышенных привилегий, эта концепция не отменяет. Удаленный доступ к серверу через Remote Desktop – это лишние телодвижения, да и, опять же, небезопасно. Наиболее подходящий путь – локальный запуск нужных оснасток управления с использованием команды RunAs, которая позволяет администратору выполнять любые задачи в системе, зарегистрировавшись в ней с использованием учетной записи рядового пользователя.

Для управления удаленными серверами Windows я использую пакеты Administrative Tools для своей клиентской ОС. Они доступны для загрузки с сайта Microsoft:

Windows Server 2003 Administration Tools Pack: http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en

Microsoft Remote Server Administration Tools for Windows Vista: http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en

Remote Server Administration Tools for Windows 7: http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en

Установив соответствующий вашей системе пакет администрирования, вы получите доступ прямо со своего компьютера к большинству оснасток управления серверами, таких как Active Directory Domains and Trusts, Active Directory Sites and Services, Active Directory Users and Computers, Distributed File System, DNS, Group Policy Editor, DHCP и пр.

Для запуска любой из оснасток с привилегиями доменного администратора, применим команду RunAs. Например, запустим оснастку Active Directory Users and Computers от имени пользователя admin, принадлежащего к домену domain.ru:

Синтаксис RunAs достаточно прост, чаще всего с ней используются следующие ключи:

1) /user – имя пользователя;

2) /netonly – использование полномочий только для доступа к удаленным ресурсам;

3) /env – использование текущего окружения, без создания окружения, характерного для указанного ключем /user пользователя;

4) /profile – загрузка профиля пользователя;

5) /noprofile – загрузка профиля пользователя не будет осуществляться.

По аналогии можно запускать любую из оснасток, входящих в состав Administration Tools:

Active Directory Domains and Trusts — domain.msc

Active Directory Sites and Services — dssite.msc

Active Directory Users and Computers — dsa.msc

Computer Management — compmgmt.msc

Distributed File System — dfsgui.msc

DNS — dnsmgmt.msc

DHCP – dhcpmgmt.msc

Group Policy Editor — gpedit.msc

Local Security Settings — secpol.msc

Routing and Remote Access — rrasmgmt.msc

Само собой, оснастки для управления локальными ресурсами, которые по умолчанию установлены в любой Windows-системе, начиная с Windows XP, можно использовать и для администрирования удаленных систем. Приведу список самых используемых:

Services – services.msc

Device Manager — devmgmt.msc

Disk Management — diskmgmt.msc

Local Users and Groups — lusrmgr.msc

Shared Folders — fsmgmt.msc

Напоследок напомню, что для работы RunAs необходимо, чтобы была запущена служба Secondary Logon.

admin Default Software, Windows Server, Безопасность, Удаленное администрирование

В большинстве организаций, даже прошедших путь оптимизации бизнес-процессов и автоматизации документооборота, до сих пор активно используются файловые серверы, служащие хранилищами важной корпоративной информации. Системный администратор, ответственный за сохранность данных на файл-серверах, должен позаботиться не только о развертывании надежной системы резервного копирования, но и о максимальном сокращении времени простоев. Я рассмотрю самый что ни на есть частный случай: организацию, размещенную в разных корпусах гипотетического делового центра, с сетью филиалов.

Итак, исходные данные: головной офис с размещением сотрудников в двух разных корпусах, один филиал. Файл-серверы установлены в обоих корпусах головного офиса и в филиале. Между корпусами лежит оптика, с филиалом установлен VPN-канал из первого корпуса головного офиса.

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

Для решения данной задачи мы будем использовать технологию компании Microsoft, метко названную Distributed File System (DFS). DFS была разработана для упрощения доступа к данным и управления ими. В Windows Server 2003 R2 к ней был добавлен механизм репликации, получивший вполне прогнозируемое название DFSR (Distributed File System Replication). Если вкратце описать схему работы DFS, то это будет выглядеть примерно так:

На рисунке условно изображены 3 файл-сервера, каждый из которых служит хранилищем разных общих директорий. Сервер DFS образует корень из этих директорий и открывает к ним общий доступ под именем Summary Data. Клиенты, в свою очередь, имея необходимость использовать данные со всех трех серверов, обращаются только к DFS, который обеспечивает им централизованный доступ к нужным ресурсам. Вполне логично: ни к чему пользователю помнить UNC-пути к отдельно взятым файл-серверам, он должен везде и всегда иметь привычную, удобную рабочую среду.

Вернемся к нашей задаче. Пока наша схема сети выглядит примерно так:

Для наведения порядка в этом бедламе нам потребуется установить службы DFS на серверах. В Windows 2003 это делается через оснастку Add/Remove Windows Components:

В Windows 2008 – через мастер добавления ролей:

После установки служб DFS, запускаем оснастку Distributed File System. Она работает в стандартной среде MMC, слева в меню жмем правой кнопкой мыши (далее – ПКМ) единственный пункт и выбираем New Root. Запустится мастер настройки корня DFS. Он может быть доменным, либо изолированным:

Выбираем доменный, после чего выбираем домен, в котором будет размещено дерево логических имен DFS:

После этого нам останется только выбрать сервер, на котором будет размещен корень…

…и мы приступим непосредственно к его созданию:

Свой корень я назову Corporate FS (сокращение от Corporate File Server) и помещу его в директорию C:Corporate FS

Корень готов. Приступим к присоединению к нему файл-серверов и установке реплик. На корневом DFS-сервере я создал на диске C: общую директорию Main Office Documents с данными, на сервере SRV2 – такую же, но пустую, и на сервере SRV3 директорию Branch Office Documents, тоже с данными.

Теперь жмем на наш корень ПКМ и выбираем New Link. Первым линком будет наш общий ресурс Main Office Documents:

Аналогично добавляем \Srv3Branch Office Documents. В конце концов мы получаем следующую DFS-структуру:

Чуть позже мы ее протестируем. Но пока мы еще не решили задачу резервирования данных. Я продемонстрирую простейшую схему репликации: данные из общей папки с SRV1 будут копироваться на SRV2. Полную репликацию всех сетевых ресурсов и корня DFS рассматривать не будем, так как настраивается она аналогичным образом. Одного примера будет вполне достаточно.

Жмем ПКМ на линк Main Office Documents и выбираем New Target. В появшившемся диалоговом окне выбираем сетевой ресурс с таким же именем на SRV2, ставим галочку в чекбоксе Add this target to the replication set и жмем Ок:

Появится окно с предложением сразу же сконфигурировать репликацию. Нажимаем Ок и попадаем в мастер настройки репликации. На первом этапе нам предложат выбрать директории для хранения временных файлов репликации:

Оставляем по умолчанию и жмем Next. На следующем шаге нам будет предложено выбрать топологию репликации. Вариантов всего 4:

— Ring (кольцо) – реплика будет обмениваться информацией с двумя соседними;

— Hub and spoke (звезда) — выделяется основная реплика, с которой обмениваются информацией все остальные;

— Full mesh (полносвязная сеть) — все реплики обмениваются информацией друг с другом;

— Custom (пользовательская) – каждая пара реплик настраивается вручную.

Мы создаем схему резервирования, при которой, в случае выхода из строя оптического канала связи между корпусами головного офиса, сотрудники из второго здания не потеряют доступ к файловым ресурсам, и результаты их трудов за время ремонта оптики тоже не пропадут, поэтому нам подходят полносвязная и кольцевая топологии. Выберем полносвязную, нажмем Ок и убеждаемся, что настойка применена:

Для наглядной проверки репликации я создал на сервере SRV1 в C:Main Office Documents несколько папок и файлов:

По умолчанию репликация происходит раз в 15 минут. По прошествии этого времени данные благополучно появились без моего вмешательства и на SRV2:

Можно выполнить принудительную репликацию командой:

Осталось опубликовать DFS в Active Directory и протестировать его доступность. Для публикации кликаем ПКМ по корню DFS, выбираем Properties и в открывшемся окне переходим на вкладку Publish:

Обратите внимание: так как наш корень DFS доменный, а не изолированный, при обращении к нему может использоваться конструкция UNC только с названием домена, без уточнения имени сервера. Кстати говоря, DFS с точки зрения клиентской ОС – не более чем обычная общая папка, то есть доступна по UNC и может быть подмонтирована как сетевой диск. Нажимаем Ок.

В качестве тестера может выступить любой доменный клиент. Я воспользуюсь сервером SRV3:

В корне Corporate FS, как и предполагалось, ссылки на файл-серверы головного офиса и филиала. Впрочем, по ссылкам мы попадаем туда же, куда и задумывали. Система работает, алиллуйя.

Итак, что же дает нам DFS?

1. Логическое представление общих ресурсов, находящихся на разных серверах/рабочих станциях, работающих под управлением разных ОС. Для администратора это рай: и централизованное управление, и упрощенное представление для пользователей, а значит меньше инструктажей и головной боли.

2. Организацию отказоустойчивых схем хранения информации. Для каждого общего ресурса DFS позволяет создать почти неограниченно много реплик, что не только снижает риск потери данных, но и обеспечивает горячее резервирование, когда выход из строя целого сервера никоим образом не отражается на работе пользователей: они просто переключаются на другой сервер, даже не подозревая об этом.

3. Балансировку нагрузки. В основном, на сетевые интерфейсы.

4. Прозрачность соответствия логического представления данных и их физического расположения. Сотрудник из офиса деревни Ольховка Кировской области может работать с файл-сервером, расположенном на Барбадосе, также, как если бы он стоял у него в соседнем кабинете. Впрочем, сотрудник наверняка и так в этом будет уверен, глядя на DFS.

Айс, не правда ли?

admin Default DFS, Windows Server, Отказоустойчивость, Резервное копирование, Хранение данных

Наконец добрался до Windows 2008 Server Core. Первые тесты впечатлили, причем впечатлили сугубо положительно.

Server Core — это вариант установки Windows Server 2008, обеспечивает минимальную среду для выполнения ролей сервера.

Сервер на базе Server Core поддерживает следующие роли:
1. Доменные службы Active Directory и AD LDS;
2. DNS-сервер;
3. DHCP-сервер;
4. Файл-сервер;
5. Сервер печати;
6. Сервер потоков мультимедиа (stream server);
7. Веб-сервер (IIS).

Для сервера Server Core интерфейсом по умолчанию является командная строка. Начальная настройка производится именно из-под командной строки. После настройки сервера им можно управлять удаленно с помощью подключения к серверу терминалов, консоли MMC или средств командной строки с поддержкой удаленного использования.

Основными преимуществами установки Server Core являются уменьшение объема обслуживания, уменьшения уязвимости сервера (за счет снижения количества элементов и приложений), сокращения объема работ по обслуживанию (за счет сокращения количества приложений и служб) и уменьшение объема необходимого свободного места на диске (установка Server Core требует 1 Гбайт места на диске и требует около 2 Гбайт для работы системы после установки).

Есть и подводные камни. Обновить предыдущую ОС (в т.ч. Windows Server 2008) до Windows 2008 Server Core невозможно, поддерживается только чистая установка. Также нельзя обновить уже установленную Server Core до полной версии Windows Server 2008. Так что прежде чем внедрять Server Core, необходимо четко представлять себе весь объем функционала, обеспечение которого ляжет на сервер.

admin Default Server Core, Windows Server, Windows Server 2008

Краткий конспект по переносу DC (единственного в домене), являющегося по совместительству сервером глобального каталога и носителем ролей FSMO, на новый сервер:

1. Делаем опись ресурсов на старом DC (чаще всего это DNS, DHCP, WINS, File Server, Print Server).

2. Создаем на старом сервере резервную копию system state с помощью ntbackup.

3. Инсталлируем на новый сервер Windows Server 2003.

4. Поднимаем его до дополнительного контроллера домена и перезагружаем.

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

6. Инсталлируем DNS-сервер на новый контроллер.

7. Если на старом DC есть WINS, то инсталлируем его на новый и переносим базу данных.

8. Переносим роли FSMO на новый DC.

9. Снимаем роль глобального каталога со старого сервера и перезагружаем его.

10. Понижаем старый контроллер до рядового сервера.

11. Переносим настройки сервера печати (например, с помощью Windows Print Migrator).

12. Переносим настройки файлового сервера (с помощью Microsoft File Server Migration Toolkit).

13. Инсталлируем DHCP-сервер на новый контроллер и переносим на него параметры со старого (указав в параметрах сервера IP-адреса новых DNS и WINS).

14. Перерегистрируем клиентские компьютеры на новый DHCP с помощью команд ipconfig /release и ipconfig /renew.

admin Default AD, How-To, Windows Server