Установка Hyper-V R2 в режиме Core

Установка Hyper-V R2 в режиме Core

С 19 августа компании, обладающие лицензиями Software Assurance (SA), а с 1 сентября все остальные, уже начали потихоньку переходить на Windows Server 2008 R2. Те кто еще не начал, уже об этом задумываются. Многие, конечно, пока подождут, но готовиться уже потихоньку начинают.
В версии R2 теперь роль Hyper-V доступна во всех редакциях Windows Server 2008 R2, а так же появилась специальная, бесплатная редакция: Hyper-V Server 2008 R2. Но многие предпочитают покупать Windows Server Enterprise 2008 R2 или самую старшую версию Datacenter. Связано это прежде всего с вопросами лицензирования. Под "корпоративной" версией можно запустить до четырех "стандартных" или "корпоративных" виртуальных серверов бесплатно, под старшей версией это число не ограничено. Но даже покупатели Windows Server Standart 2008 R2 будут использовать Hyper-V, так как лицензия позволяет запускать один виртуальный сервер бесплатно, но при этом открываются все преимущества виртуализации. И никто не мешает поставить на тот же сервер Linux или WEB сервер. Но есть и ограничения, первое – R2 редакции теперь доступны только для x64 платформы, и для получения максимального колличества бесплатных лицензий для виртуальных серверов необходимо чтобы используемая на железе Windows Server 2008 использовалась только для целей виртуализации. Поэтому основная роль, которые будут ставить первый пользователи R2 – это Hyper-V.
Так как сервер будет устанавливаться с ограниценным числом ролей, и к нему предъявляются более жесткие требования по безопасности и обслуживанию, то сам сервер следует устанавливать в режиме Core. Установка сервера в различных редакциях мало чем отличается, но для ясности все приведенное в статье отностится к Windows Server Enterprise 2008 R2 Core, буду рассматривать русскую редакцию сервера (с коментариями для английской).
Итак, какие этапы нужно выполнить в производственной среде для установки сервера Hyper-V. Первый этап подготовительный, второй – собственно установка сервера, третий – настройка удаленного управления сервером, третий – поднятие роли Hyper-V.
На первом этапе важно проверить, чтобы оборудование было совместимо с технологией Hyper-V, продумать какие будут устанавливаться виртуальные машины, куда они будут "смотреть", сколько нужно сетевых карт. Желательно (но не обязательно) предусмотреть дополнительную сетевую карту, которая будет использоваться исключительно в целях управления сервером.
Второй этап очень прост. Сама установка занимает довольно мало времени, и очень проста. Тут есть следующие особенности. Во-первых, если у вас специфическое оборудование, то на первом этапе вы уже подготовили драйвера для установки. Во-вторых, при установке локализованных версий следует выбирать язык ввода с клавиатуры (самый нижний ComboBox) "США" (для английский версий оставить выбор по умолчанию "USA") остальной выбор сделать в соответствии с регионом. Ну и не забыть ввести пароль администратора (хотя не задать его не получится).
А вот последующие этапы рассмотрим поподробнее и пошагово, так как они вызывают множество проблем.
Сначала, так как работать непосредственно на сервере не очень удобно, настроим удаленный доступ через службу RDP. И именно через удаленный рабочий стол сможем выполнять практически все остальные операции.
Для этого после входа на рабочий стол (собственно это и не стол практически, одна командная строка), выполним следующие команды:
cscript //h:cscript

scregedit /ar /0
разрешит подключения к удаленному рабочему столу для администрирования

scregedit /cs /0
отключает повышенный уровень безопасности, установленный по умолчанию в Windows 

scregedit /im /1

ipconfig

Первая команда позволит выполнять последующие команды без ввода дополнительных букв, и переходов в нужные каталоги, установив по умолчанию cscript.exe для запуска скриптов. Вторая команда разрешает удаленные подключения к рабочему столу с помощью службы RDP. Третья – разрешает использовать клиенты RDP предыдущих версий (если дальнейшую установку Вы будете производить, используя сервер R2 или Windows 7, то эту команду выполнять не обязательно). Четвертая команда на данном этапе не совсем нужна, она позволяет удаленно управлять IPSEC. Впрочем после ввода сервера в домен применятся политики безопасности домена, и если они до этого не были заданы, то нужно все эти праметры задать для всего домена в политиках. Крайняя команда покажет IP адреса которые присвоены всем сетевым интерфейсам, запомните любой адрес который подходит для управления, и используйте его для входа удаленным рабочим столом. На этом этапе я рекомендую перезагрузить компьютер (хоть это и не обязательно), так как это первая загрузка, и, возможно, операционной системе требуется доустановить драйвера к специфическому оборудованию.
Теперь можно войти в ситему с помощью удаленного рабочего стола. И первым делом поставим недостающее оборудование (ну а если не была найдена ни одна сетевая карта, то оборудование придется доставлять за консолью сервера). Для установки оборудования на сервере core есть несколько способов. Иногда хватает просто запуска установочного файла типа setup.exe, или запуском его в "тихом" режиме. Можно использовать команду Pnputil:
Pnputil -i -a
Например следующей командой можно добавить все драйвера, предварительно загруженные на сервер, для плат Intel:
Pnputil -i -a c:\Data\intel\All\*.inf

При установке будет выдано сообщение об успешной или неуспешной установке (например, не найдено оборудование для этого драйвера) и может быть выдано окно предупреждения о том что драйвер не подписан. Именно потому, что при выполнении некоторых операций возникают окна с вопросами и уведомлениями, установку нужно производить либо через консоль, либо через удаленный рабочий стол, хотя есть и другие способы (часть из которых будет рассмотрена ниже).
После установки драйверов, не перезагружаясь сменим имя компьютера.
netdom renamecomputer %COMPUTERNAME% /NewName:НОВОЕ-ИМЯ-СЕРВЕРА

shutdown /r /f /t 0
Первая команда устанавливает новое имя компьютера, посмотреть предыдущее, при необходимости можно множеством способов, например командой hostname. Вторая команда приводит к незамедлительной принудительной перезагрузке компьютера. Настоятельно рекомендую для серверов использовать именно эту команду с ключем /f (в том числе и с графическим интерфейсом), хотя на новом, только установленном сервере этот ключик совершенно не обязателен.
После перезагрузки, до ввода компьютера в домен, необходимо настроить все сетевые интерфейсы, и задать начальные параметры системы.
Настроим сетевые интерфейсы:
ipconfig /all

netsh interface ipv4 show interfaces

netsh interface set interface name="Подключение по локальной сети" newname="DMZ"
netsh interface set interface name="Подключение по локальной сети 3" newname="LAN"
netsh interface set interface name="Подключение по локальной сети 2" newname="Control"
netsh interface ipv4 set address name="Control" source=static address=172.19.25.101 mask=255.255.0.0 gateway=172.19.25.1 gwmetric=1
netsh interface ipv4 add dnsserver name="Control" address="172.19.22.2" index=1
netsh interface ipv4 add dnsserver name="control" address="172.19.12.1" index=2
ipconfig /all
Первые две команды покажут существующие интерфесы. Следующими тремя, переименуем их в более короткую форму, но главное, несущий смысл (да и чтобы самим потом не запутаться), старое имя интерфейса покажут обе предыдущие команды. Нужно отметить, что это выполнять совсем не обязательно, и в командах изменения сетевых настроек вполне можно вместо имени использовать номер, выводимый второй командой. Шестая команда задаст статический адрес и шлюз по умолчанию. Следующие две адреса серверов ДНС. В этих трех командах, вместо имени интерфейса можно использовать его номер, но с номерами можно легко запутаться. Нужно установить адреса только для интерфейса управления, так как все интерфейсы, используемые в дальнейшем для виртуализации все равно будут иззменены. Также совершенно не обязательно изменять адреса на статические, можно использовать и динамические, выдаваемые DHCP сервером, но во избежании проблем при обслуживании, лучше выдать статический адрес. Имена лучше задавать латинскими буквами, несмотря на то, что кирилица полностью поддерживается. Если у Вас одна сетевая карта, или у Вас нет отдельного сетевого адаптера для управления, то адреса пока можно не задавать. Последней командой посмотрим правильно ли применились изменения. Сделать это нужно обязательно, так как при вводе команд, можно легко ошибиться.
Перезагружаться на этом этапе нет смысла, так как все изменения вступают в силу немедленно. Также если вы изменяете сетевой интерфейс через который зашли на сервер через удаленный рабочий стол, то возможно придется перезайти снова (никакие данные не потеряются) по новому IP адресу (но если в команде была допущена ошибка, то придется топать к консоли).
Далее выполним команду: control intl.cpl, что позволит настроить раскладку клавиатуры, смену сочетания клавиш для всех пользователей в домене. Также выставим дату и время (проще всего сделать командами date и time, хотя сохранилась и панель control timedate.cpl).
Теперь все готово для ввода сервера в домен. Этот этап можно выполнить позднее, или вообще не вводить компьютер в домен, но правильнее чтобы он был в домене, правильно под все такие сервера завести отдельное подразделение в политике домена и очень аккуратно и жестко ее настроить. Также для компьютеров в домене упрощается управление и обслуживание.
NETDOM JOIN %COMPUTERNAME% /Domain:ДОМЕН /UserD:Administrator /PasswordD:ПАРОЛЬ_АДМИНИСТРАТОРА_ДОМЕНА

shutdown /r /f /t 0

Первая команда добавляет сервер в домен, нужно указать имя пользователя и пароль в домене, имеющего право на добавление компьютеров в домен. Также в этой команде можно сразу указать подразделение и другие параметры. Вторая, уже знакомая команда, перезагружает сервер.
После перезагрузки настроим удаленное управление. Этот этап вызывает множество проблем, в основном из-за применения новых технологий, поэтому попробую описать все варианты настройки.
winrm quickconfig -quiet
netsh advfirewall set allprofiles settings remotemanagement enable
netsh advfirewall firewall set rule group="Удаленное администрирование" new enable=yes
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
netsh advfirewall firewall show rule name=all
Третья и четвертая команды – это одна и таже команда но для разных локализаций операционной системы. Если задать наименование группы на лругом языке, то ничего страшного не произойдет – просто не найдется ни одного правила. Первая команда настраивает службу WinRM, остальные включают правила во встроенном фарьеволе для разрешения удаленного управления. Вполне возможно что у Вас эти правила уже настроены политикой домена, и ничего включать не придется, но выполнить их не помешает. Крайняя команда информационная, она покажет все правила фарьевола и в каком они состоянии находятся.
После этого нужно настроить клиент с которого сервер будет управляться (внимание! клиент, а не сервер) Пусть для примера это будет Windows 7. Если это будет другая операционная система, то, возможно, Вам придется доставить поддержку WinRM.
winrm quickconfig -quiet
winrm set winrm/config/client @{TrustedHosts="172.19.25.101,*.clevelus.ru"}
winrs -r: [-u:]
winrs -r:172.19.25.101 cmd
cd /
dir
Первая команда уже знакома, она настраивает службу WinRM на клиенте, так же как и на сервере. Второй вы разрешаете клиенту удаленно управлять серверами, и через запятую должны указать либо IP адреса, либо имена компьютеров, которыми можно управлять. Можно поставить и звездочку, но лучше в целях безопасности указывать конкретные IP адреса или имена. После выполнения второй команды вы уже можете управлять удаленным сервером с командной строки с помощью команды WinRS (третья команда). Четвертая команда яркий пример использования, выполните ее для входа на сервер. Выполнив крайние две команды, убедитесь, что вы "находитесь" на сервере.
Теперь установим необходимые роли на сервер. Выполним последовательно команды, лучше выполнять их через удаленный рабочий стол (если Вы еще не отключили его убедившись в простоте и мощи WinRS).
oclist

start /w ocsetup NetFx2-ServerCore

start /w ocsetup MicrosoftWindowsPowerShell

start /w ocsetup BestPractices-PSH-Cmdlets

start /w ocsetup ServerManager-PSH-Cmdlets

start /w ocsetup Microsoft-Hyper-V

Первая команда покажет список всех ролей сервера и их состояние. Подобная команда из PowerShell(PS) имеет более дружелюбный вид, да и вообще возможно Вам придется управлять сервером именно через PS. Также на этом этапе установим и роль Hyper-V. После выполнения всех команд перезагрузимся (сервер сам должен Вас об этом "попросить". Префикс "start /w" нужен для того, чтобы дождаться окончания выполнения предыдущей команды, иначе тяжело выяснить, закончилась установка роли или нет (при использовании WinRS и всплывающем окне, команда может "никогда" не закончиться, поэтому под "чистой" командной строкой лучше не использовать).
После перезагрузки введем команду: powershell. И все дальнейшие действия можно выполнять под консолью PS (или можно запусть вторую консоль).
Следующие три команды, выполненные из под PS, показывают как можно управлять ролями несколько более эффективно, первая из которых добавляет нужный функционал.
Import-Module Servermanager

Get-WindowsFeature

Add-WindowsFeature
Выполните их последовательно без параметров, чтобы ознакомиться.
Далее выполним из под PS три команды, на чем закончим конфигурировать удаленный доступ:
Enable-PSRemoting -force
Set-PSSessionConfiguration Microsoft.Powershell -ShowSecurityDescriptorUI
Get-Help about_Remote_Troubleshootingаа
Первая команда донастраивает удаленный доступ. Ее можно запускать сколько угодно раз, ничего страшного не случится. При выполнении второй команды появится окошко задания разрешений, добавьте туда пользователей, которые будут удаленно управлять этим сервером. Третья команда выведет локализованную справку по проблемам и способам решений при удаленном доступе. Также есть замечательная утилитка hvremote.wsf, которая может помочь настроить удаленный доступ как на сервере так и на клиенте, если ничего не получается. Но пользоваться ей нужно аккуратно, но если ничего не получается, – она может очень помочь.
Теперь нужно донастроить клиент, если пользователь и компьютер находятся не в домене. Хотя все-таки сам компьютер рекомендую в домен добавить – некоторые вопросы управления могут быть сразу сняты (при этом не обязательно входить в него под учетной записью домена). Для этого в "Панель управления\Все элементы панели управления\Диспетчер учетных данных" добавьте запись для доступа к ресурсу с учетной политикой пользователя домена, имеющего право на управление сервером.
Теперь можно запускать средства управления сервером с локальной машины, и самое интересное для нас в этой настройке: "Диспетчер Hyper-V". Если вы еще не установили на локальный компьютер "Средства удаленного администрирования сервера", то в самый раз это сделать, или можно управлять с другого сервера 2008 R2, установленного, например в виртуальной машине. Для Windows 7 средства можно взять тут.
Для того чтобы создавать и управлять виртуальными машинами нам осталось донастроить Hyper-V и, возможно, донастроить сетевые на на сервере.
Запускаем оснастку, подключаемся к выбранному серверу по полному имени. Если не получилось подключиться, топроверьте, все ли предыдущие шаги выполнены. Если Вы работаете не под учетной записью пользователя домена, но на компьютере включенном в домен, возможно удобнее будет запустить оснастку следующим образом:
runas /noprofile /user:ДОМЕН\ПОЛЬЗОВАТЕЛЬ cmd

mmc %SystemRoot%\system32\ServerManager.msc
но это не обязательно. В настройке роли Hyper-V выберем (подключим) сервер. Вначале выберем "Параметры Hyper-V" и зададим пути по умолчанию для виртуальных машин и дисков. Далее запустим диспетчер виртуальной сети. Предварительно на сервере выполним команду ipconfig /all, чтобы внимательно посмотреть на все интерфейсы.

Если названия сетевых карт будут совпадать, то возникнут сложности. Галочку "Разрешить совместное использование …" нужно ставить в том случае, если Вы хотите чтобы был создан виртуальный адаптер на сервере на этом интерфейсе. Сам интерфейс после того как будет использован Hyper-V будет отлучен от локальной сети, о чем Вам будет выдано предупреждение.

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

про виртуализацию

Виртуализация VMware, Hyper-V, Citrix и виртуальные машины
С Гилёва

Строим инфраструктуру на базе продуктов MS

интересная статья, правильная

Итак, собственно руководство. Начинаем.
0. Я очень люблю Hyper-V. Ставим Server 2008 в core mode и при прочих равных разворачиваем инфраструктуру на виртуальных машинах.
0.1 Бэкапы бэкапы бэкапы. Не вводим в строй ни одну систему не разобравшись как мы будем проводить резервное копирование.
1. Ставим сервер, поднимаем Active Directory. Поднимаем основные службы DNS, DHCP. При первой возможности ставим второй серер, на котором также поднимаем AD. Хотя многие мелкие организации этим пренебрегают, это очень важно, ибо если помрёт единственный контроллер домена будет очень очень грустно. Настраиваем синхронизацию времени на контроллере домена с внешими источниками эталонного времени. NTP.
1.1 DNS. Подумайте заранее про то, как будет называться ваш домен, будет ли название совпадать со врешним именем или отличаться от него. Почитайте про Split DNS. Людям удобно запоминать единые адреса для сервисов. Например mail.yourdomain.ru — всегда должно быть почтой вне зависимости снаружи или изнутри сети компании работает сотрудник. Если DNS имена наружней и внутренней сети различаются — поднимите внутри сети зону yourdomain.ru
1.2 DHCP. Фиксированных адресов быть не должно. Используйте Reservation для MAC адресов устройств. Это нужно чтобы вы могли в любой момент владеть полной информацией по распределению адресов в сети.
1.3 Заводим в AD всех пользователей. Каждому подразделению выделяем Organizational Unit в соответствии с иерархией организации. Распихиваем пользователей по OU. Для каждого OU создаём группу, в которую включаем всех пользователей. Каждому пользователю — по учётной записи. Никаких записей «Кладовщик» для 12 кладовщиков разом. Для учетных записей компьютеров также желательно иметь отдельную иерархию OU в соответствии с иерархией организации — так легче привязывать групповые политики для всех ПК отдела.
1.4 Даём секретарям права на изменения полей номера телефонов в AD. Обучаем. Заполнять и поддерживать эти данные в актуальном состоянии теперь их обязанность. Они-же или HR должны поддерживать в актуальном состоянии название должности и отдела в AD у всех сотрудников. Также, при переводах сотрудников, администратор перетаскивает учетки в нужный OU, меняет членство в группах. Делаем регламент — как пользователь попадает в нашу сеть при приёме на работу, что мы делаем при его увольнении, при переводе в другой отдел. Вводим стандарты на формирование Login name и почтовых адресов сотрудников.
2. Загоняем компьютеры пользователей в домен.
3. По возможности лишаем пользователей прав администратора. Часть ПО при своей рядовой работе хочет писать данные в запрещённые по умолчанию места — отлавливаем это с помощью специального ПО, например Process Monitor, тонко настраиваем права. Единожды разобравшись с программой — выписываем к каким ветвям реестра и каталогам у неё дополнительно должен быть доступ, делаем настройки, распространяем их с помощью Group Policy на подходящий OU. С помощью GP цепляем людям ближайшие принтеры. Добавляем в логин скрипт ПО, собирающее данные по нашим ПК — название, кто логинился, какое стоит железо, IP адрес, МАС адрес и так далее и складывающее всё это добро на сервер.
4. При необходимости ограничиваем доступ ко внешним накопителям, например с помощью Device Lock.
5. Настраиваем корпоративный антивирус, следим за его обновлениями
6. Поднимаем и настраиваем WSUS. Не бойтесь, расставляться будут только обновления, утверждённые Вами.
7. Расшариваем на сервере файловые ресурсы. Бъёмся смертным боем, чтобы ресурсы расшаривались на группы, а не на персональных сотрудников. Иначе очень скоро система прав превращаются в кашу, невозможно дать новому сотруднику права аналогичные другому сотруднику, уже работающему и так далее. Очень важно донести до руководства почему нужно делать именно так и получать от них заявки на изменения прав в таком разрезе.
8. Поднимаем SQL сервер. Он нам понадобится, чтобы хранить там базы 1С и вообще вещь хорошая.


Все наши пользователи работают с расшаренными ресурсами на сервере. Мы неплохо защищены от вторжений вирусов. Таким образом мы более менее обустроили рабочие места сотрудников.


9. Поднимаем и настраиваем ISA сервер для доступа в Инет. Сейчас его преемник ForeFront TMG, мы пока не внедряли. Настраиваем Proxy autodiscovery и/или прописываем всем наш прокси в IE групповыми политиками, прописываем внутреннюю сеть в адресе исключений — доступ к ней мимо прокси. Не забываем подумать и проверить, как будут работать ноутбуки вне нашей сети. Не будут ли они пытаться лезть в инет через проки?
9.1 Нстраиваем правила для доступа пользователей наружу. Правил, разрешающих доступ куда угодно исходя из IP адреса сотрудника — такого по минимуму, только для коммуникатора директора. Создаём группы в AD по типу доступа, например: «только по белому списку», «куда угодно». Засовываем в эти группы группы подразделений. Например группу «Склад» запихиваем в группу «Только белый список». Создаем на ISA белый список сайтов, чёрный список сайтов, настраиваем правила с правами доступа в соответствии с группами AD и списками сайтов. Для клиент-банков и прочего ПО, которое не умеет авторизоваться на нашем сервере — в ISA включаем монитор, смотрим куда ОНО ломится и разрешаем весь трафик на IP сервера клиент-банка не на базе учетной записи пользователя, а на базе IP компьютера, в идеале прописываем ещё и протоколы.
Общая логика правил на ISA — весь трафик за очень редкими исключениями должен ходить через наш шлюз по правилам, которые привязаны к доменной учетке пользователя.
Лично я не люблю ISA Firewall Client, мы всегда обходимся без него и вам советую. Все настройки на сервере это централизация.
9.2 Если у нас есть филиалы — тоннель между ISA серверами, если у нас есть удаленные пользователи — VPN доступ в нашу сеть.
9.3 Если нужны хорошие ограничения для пользователей — например Иванов может качать не больше 200Мб в день — Bandwith Splitter
9.4 Все логи, конечно, храним на SQL сервере и не за семь дней, а минимум за 45 — когда-нибудь точно понадобится сформировать отчет кто сколько скачал за месяц.


Наши пользователи работают в Инете. Доступ в Интернет чётко разграничен правилами. Все ходы у нас записаны для последующих разборов. Удалённые пользователи имеют возможность подключаться и работать внутри нашей сети.


10. Поднимаем сервер терминалов. Загоняем на него пользователей, работающих из дома, тех кто активно работает с нашими ресурсами из удалённого филиала, возможно часть офисных пользователей.
11. Поднимаем Certification Authority, оно будет нужно.
12. Поднимаем Exchange Server. Почта пользователей должна лежать на нём, никаких Личных Папок — только для давних архивов. Работа пользователей — через Outlook. Если организация помешана на безопасности — Message Mirror почты на отделный адрес, задумываемся о том, как часто мы будем очищать его и куда будем архивировать его содержимое. Проверяем работу Global Address List, создаём его offline версию. Настраиваем ограничения на размер письма, ящика и так далее. Настраиваем на сервере антивирус и антиспам. Настраиваем коллективные почтовые ящики типа support@yourdomain.ru, даём ответственным права писать от имени саппорта, обучаем их. Настраиваем Public Folders запихиваем туда общие календари переговорных, демостендов и так далее, думаем что ещё у нас есть коллективного. Если сочтёте удобным — ведём личные календари в Оutlook и шарим их начальству. Общую систему задач на базе задач Outlook делать не нужно — задачи Outlook неудобны для коллективной работы.
13. Публикуем наш Exchange через ISA, проверяем прохождение внешней почты в обе стороны, не забываем про open relay, подписываем всё что нужно сертификатами, проверяем работу Outlook Web Access, включаем OMA, публикуем RPC over HTTP. У пользователей ноутбуков настраиваем Outlook на RPC over HTTPS, кэширование и offline address book. Если нужно кэшировать содрежимое общих папок — их нужно в Outlook добавить в Избранные папки, а затем в Избранное.


У нас работает почта, люди могут подключаться с помощью Outlook как изнутри сети, так и извне — достаточно только доступа в Интернет. Мы можем работать с помощью Web интерфейса, а также с наших мобильных устройств. Отовсюду мы видим одно и то же содержимое ящика.
Мы научились коллективно работать с адресами типа Support@yourdomain.ru


14. Читаем про Unified Communications. Настраиваем Office Communications Server, дружим его с нашей офисной АТС. Настраиваем маршрутизации и номерные планы. Настраиваем его дружбу со списком пользователей из AD.
Расставляем заинтересованным пользователям Office Communicator, выдаём гарнитуры.


Звонки через office communicator на другие офис коммуникаторы, внутренние телефоны, город. Всё без дополнительных префиксов. Коммуникатор знает всех пользователей из AD, вместе с их внутренними и мобильными телефонами.


15. Поднимаем Sharepoint Server. Засовываем туда красивый список сотрудников, данные о днях рождения сотрудников, но без года рождения (девушки волнуются), новости компании. Потом начинаем создавать там структурированное хранилище информации, пытаемся, чтобы основная часть файловой помойки плавно переехала туда. Позже подтягиваем туда рабочие процессы, заявки и так далее. Перекидываем туда резервирование переговорных и прочее, что держали в общих папках.
16. Если мы активно работаем с проектами — разворачиваем Project Server.


У нас появился корпоративный портал — единое место для справочной информации, основных рабочих процессов, структурированное файловое хранилище.


Описываем основные приёмы работы с нашей инфраструктурой, а лучше делаем видеокурсы. Выкладываем в места общего пользования (я про сервер), тренируем людей туда заглядывать по оповещениям на портале — там будет описываться работа с новыми сервисами. Вносим ознакомление с этими документами одним из обязательных пунктов для первого дня работы нового сотрудника.
Если что-то забыл — пишите. Неосвещённой осталась тема Microsoft System Center, обязательно почитайте про него, но это продукт нацеленный нести блага не рядовым пользователям, а системным администраторам.