Рабочая группа windows server 2012

Как вы знаете, в Windows Server 2012 появилась возможность управлять несколькими удаленными серверами централизованно, из одной консоли Server Manager. В этой статья я опишу настройки, необходимые для удаленного управления серверами, находящимися в рабочих группах.

В качестве подопытных возьмем 2 сервера:

SRV4 — локальный сервер, с которого будет производится управление.
SRV12 — удаленный сервер, которым будем управлять.

Первым делом заходим на локальный сервер SRV4 и проверяем, доступен ли SRV12 для входяших соединений по порту 5985 TCP.

Затем добавляем SRV12 в доверенные узлы (Trusted Hosts). Если список доверенных узлов пуст, то воспользуемся командой:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value SRV12

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

Set-Item WSman:\localhost\Client\TrustedHosts -Value SRV12 -Concatenate

Открываем оснастку Server Manager, переходим в раздел All Servers, кликаем по ней правой клавишей мыши и выбираем пункт «Add Servers».

Переходим на вкладку DNS и в поле Search вводим имя удаленного сервера, в нашем случае SRV12. Выделяем найденный сервер и кликаем по стрелке, отправляя его в раздел выбранные (Selected). Жмем ОК.

SRV12 появляется в списке серверов, но для управления он пока недоступен. Кликаем на нем правой клавишей и выбираем «Manage As».

В открывшемся окне вводим имя пользователя, от имени которого будет производится удаленное управление. Поскольку сервер находится в рабочей группе, надо указать локальную учетную запись, входящую в группу администраторов на сервере SRV12. Чтобы не вводить данные каждый раз, отмечаем галочку «Remember my credentials» и жмем OK.

А вот теперь одна тонкость, которую нужно учесть. Заключается она в том, что любой пользователь кроме встроенной учетной записи администратора не может удаленно подключиться к локальному компьютеру с правами администратора, даже если он является членом группы «Администраторы» на этом компьютере.

Это настройки безопасности по умолчанию, и чтобы их изменить, необходимо на удаленном сервере выставить в 1 значение параметра реестра LocalAccountTokenFilterPolicy. Поэтому заходим на сервер SRV12, открываем окно PowerShell с правами администратора и вводим команду:

New-ItemProperty -Name LocalAccountTokenFilterPolicy -Path
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -PropertyType Dword -Value 1

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

Источник

Вы еще не знакомы с Windows Server 2012? Мне вот уже «посчастливилось» настраивать на нем терминальный сервер. Честно говоря, совершенно не понятно зачем было пихать новый ленточный интерфейс в сервер — логика Microsoft последнее время не поддается объяснению.

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

Однако всё оказалось решаемо, пусть и с некоторыми дополнительными действиями, о которых узнал c technet.microsoft.com.

Настраиваем роль терминального сервера на WinServer 2012 без поднятия домена

Принципиальных отличий в установке Windows Server 2012 от Windows Server 2008 R2 нет, потому этот этап пропустим. Замечу, что операционная система прекрасно ставится с флешки, на которую был записан образ (давно уже не использую CD/DVD — медленно и нудно). Перейдем непосредственно к установке роли RDS на сервере.

Для этого запустим Диспетчер серверов (Server Manager), и перейдем в поле Локальный сервер (Local Server)

Далее запускаем мастер добавления ролей и компонентов, где выбираем тип установки Установка ролей или компонентов (Role-based or feature-based installation)

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

Первой установим компоненту Лицензирование удаленных рабочих столов (Remote Desktop Licensing)

После завершения процесса, запускаем Диспетчер лицензирования удаленных рабочих столов (RD Licensing Manager), в котором активируем наш сервер лицензий и устанавливаем пакет терминальных лицензий (например: Windows Server 2012 — RDS Per User CAL, 5 шт.).

Никаких новшеств здесь нет, а потому описывать подробно данный процесс не стану (возможно раскрою тему в одной из будущих статей — жду ваших предложений и комментариев).

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

Вторым этапом устанавливаем компоненту Узел сеансов удаленных рабочих столов (Remote Desktop Session Host).

После установки этой компоненты у нас появится Средство диагностики лицензирования удаленных рабочих столов (RD Licensing Diagnoser), которое сообщит нам ошибку об отсутствии сервера, раздающего терминальные лицензии (скриншота с ошибкой к сожалению не сделал, приведен уже работающий вариант сервера).

Стоит заметить, что в оснастке отсутствуют инструменты управления, которые были в Windows Server 2008 R2, т.е. возможности добавления сервера лицензий нет.

Настраиваем локальные политики для серверов находящихся в рабочей группе

Осталось самое интересное. Исправить данную ситуация не сложно — достаточно настроить всего две локальные политики. В строке терминала пишем gpedit.msc и изменяем соответствующие ключи.

Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Лицензирование — Использовать указанные серверы лицензирования удаленных рабочих столов (добавляем имя нашего сервера)

Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Лицензирование — Задать режим лицензирования удаленных рабочих столов (выбираем тип лицензий)

Англоязычный вариант:

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing — Use the specified Remote Desktop license servers (добавляем имя нашего сервера)

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing — Set the Remote licensing mode (выбираем тип лицензий)

Установка компоненты — Remote Desktop Web Access

Если, в качестве клиента требуется использовать браузер, устанавливаем дополнительную компоненту Remote Desktop Web Access. Тутвообще все просто, нужно лишь разрешить мастеру добавить то, что он хочет, в частности IIS. После окончания установки, на клиентской машине в браузере сервер должен ответить и показать страницу Remote Web Access.

Обратиться к серверу терминалов через браузер можно по адресу https://ip/rdweb

Подписывайтесь на канал

Яндекс.Дзен

и узнавайте первыми о новых материалах, опубликованных на сайте.

Источник

Итак, вы решили разделить ресурс созданного облачного сервера на несколько пользователей и определили, что подключаться они будут к серверу средствами клиента удаленных рабочих столов. В стандартном варианте Windows Server имеет две лицензии удаленного рабочего стола для использования администраторами в целях настройки сервера. Если к серверу требуется подключение более двух клиентов, нужно активировать и настроить службу сервера терминалов.

Настройка сервера терминалов Windows Server не зависит от того, каким способом установлена операционная система. Это может быть как аппаратный сервер, на которой Windows Server установлена нативно, без использования гипервизора, так и виртуальный сервер.

Наиболее частое применение терминального сервера Windows встречается в работе организации с 1С Предприятие. Настройка сервера для 1С в базом варианте не отличается от настройки для других использований.

При установке служб терминального сервера Windows Server учитывайте, будет ли использоваться сервер в доменной среде или продолжит пребывать в рабочей группе. Далее опишем базовую настройку терминального сервера в Windows Server 2012 R2 в рабочей группе как типовую для большинства небольших инсталляций, например на виртуальных или VPS серверах.

Если вы еще не заказали сервер у нас, сейчас — самое время! Будет что настраивать. Мы предлагаем как одиночные виртуальные VPS серверы, так и целое облако IaaS , где могут быть несколько серверов, объединенных в единую сеть!

Настройка службы сервера терминалов в Windows Server 2012 R2

В случае, если доменную среду использовать не планируется:

Запустить средство управления «Диспетчер серверов»

Меню «Пуск» -> «Диспетчер серверов» или выполнить консольную команду «servermanager.exe»

2. Выбрать меню «Управление» -> «Добавить роли и компоненты»

3. В пункте «Тип установки» выберите «Установка ролей и компонентов»

4. Далее сервер, на который будут установлены роли и компоненты. В нашем случае – это имя локального компьютера

5. Выбираем дополнительную роль сервера: «Службы удаленных рабочих столов»

6. Пропускаем выбор компонентов и переходим к выбору на странице «Службы ролей», выбираем и добавляем следующие компоненты: «Лицензирование удаленных рабочих столов» и «Узел сеансов удаленных рабочих столов»

7. Выберите, разрешено ли мастеру добавления ролей и компонентов перезагрузить сервер автоматически, или это необходимо будет сделать вручную (рекомендуется в случае, если в данный момент с сервером работают другие пользователи)

8. Жмем кнопку Установить и дожидаемся полного завершения установки ролей после перезагрузки сервера

9. Запустить средство управления «Диспетчер серверов» и выбрать меню «Средства» -> «Terminal Services» -> «Средство диагностики лицензирования удаленных рабочих столов»

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

11. Необходимо задать режим лицензирования и выбрать соответствующий сервер лицензирования

Заходим в редактор локальной групповой политики сервера – можно использовать консольную команду gpedit.msc

Следующий путь: «Конфигурация компьютера» -> «Административные шаблоны» -> «Компоненты Windows» -> «Службы удаленных рабочих столов» -> «Узел сеансов удаленных рабочих столов» -> «Лицензирование»

Потребуется изменить следующие параметры политики:

«Использовать указанные серверы лицензирования удаленных рабочих столов» -> «Включено» в поле «Использовать серверы лицензий» необходимо указать имя сервера лицензирования – в нашем случае, это WS2012R2RUS (имя компьютера можно посмотреть здесь: Система -> Полное имя компьютера)

«Задать режим лицензирования удаленных рабочих столов» -> «Включено» в поле «Укажите режим лицензирования для сервера узла сеанса удаленных рабочих столов» выбрать режим «На устройство» или «На пользователя»

12. Необходимо активировать сервер лицензирования на локальном компьютере. Для этого переходим в Диспетчер серверов -> Средства -> Terminal Services -> Диспетчер лицензирования удаленных рабочих столов

Выбираем сервер по имени нажимаем на него правой кнопкой мыши и выбираем «Активировать сервер»

В мастере рекомендуется выбирать «Метод подключения» — «Авто» и указывать актуальные данные о пользователе. Если вы все сделали правильно, сервер получит статус «Активирован»

Осталось только установить приобретенные RDS-лицензии и можно начинать их использование. Дополнительные лицензии RDS для наших облачных серверов можно заказать в личном кабинете, а заботливая поддержка поможет их вам установить!

Таким образом достаточно быстро можно настроить терминальный сервер в Windows Server и приступить к настройке прав и ролей пользователей, а также к настройке ваших приложений. Например, использовать сервер для 1С или другого программного обеспечения. Не забудьте дополнительно проверить ваши настройки безопасности, а также активировать встроенный антивирус.

Источник

“Как установить роль RDS на Windows Server 2012 в рабочей группе?” — такой вопрос часто звучит на форумах TechNet.
Для многих этот вопрос и сейчас актуален, поэтому стоит рассказать, как настроить роль RDS на таком сервере. Особенного отличия в установке операционной системы Windows Server 2012 от Windows Server 2008 R2 нет, потому
этот этап пропустим. После инсталляции обязательно стоит проверить системный журнал на наличие ошибок. Установку обновлений системы и драйверов устройств также пропустим. Замечу, в случае «нестандартного» поведения
системы при выполнении простых операций, лучше переустановить OS заново. Особенно проявляется, если образ установочного диска «битый». После завершения базовой настройки OS, можно переходить к установке роли RDS.

Для этого запустим “Server Manager” и сделаем переход в поле “Local Server”

Далее запустим мастер установки ролей и компонентов и выберем тип установки “Role-based or feature-based installation”.

Установку всех компонент роли RDS можно производить сразу, но для лучшего понимания, разделим на части.
Первой установим компоненту Remote Desktop Licensing.

После завершения процесса у нас должна появиться консоль RD Licensing Manager,
в ней мы должны активировать наш сервер лицензий и установить пакет терминальных лицензий. Например: Windows Server 2012 — RDS Per Device CAL, 10 шт.

Следующая компонента — Remote Desktop Session Host.

После установки этой компоненты у нас появляется консоль RD Licensing Diagnoser, в которой мы видим ошибку об отсутствий лицензий и сервера лицензий. Также стоит заметить, что в оснастке отсутствуют
инструменты управления, которые были в Windows Server 2008 R2, т.е. возможности добавления сервера лицензий нет.

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

Start->Run->gpedit.msc

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing —
Use the specified Remote Desktop license servers (добавляем имя нашего сервера)

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing —
Set the Remote licensing mode (выбираем тип лицензий)

Пуск->Выполнить->gpedit.msc

Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Лицензирование —
Использовать указанные серверы лицензирования удаленных рабочих столов
(добавляем имя нашего сервера)

Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Лицензирование —
Задать режим лицензирования удаленных рабочих столов (выбираем тип лицензий)

Также можно использовать альтернативный метод, подробности смотрите в статье:
Руководство по установке службы роли Узла сеансов удаленных рабочих столов без службы посредника подключений к удаленному рабочему столу в Windows Server
2012

Идем далее. Установка компоненты — Remote Desktop Web Access.

Ничего особенного в установке Remote Desktop Web Access нет, лишь разрешаем мастеру добавить дополнительные компоненты, в частности IIS. После окончания установки, на клиентской машине в браузере сервер должен ответить и показать страницу Remote Web Access.
Строка: https://ip/rdweb

Терминальный сервер готов!

Последний шаг, добавление пользователей на сервер.

Источник

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

1. У каждого пользователя должна быть своя папка
2. Папка должна быть у каждого отдела
3. Есть общие папки для сотрудников разных отделов, для рабочих групп.

~~4. Должна быть общая папка помойка~~

— это мнение сугубо только пользователей.

Для упрощения работы пользователей было принято решение, что это должна быть одна точка входа. Как правило, это что-то вроде SharePoint. Но кроме двух серверов с Windows Server 2012 больше не было ничего.

Вот как было решено поступить.

1. Единой точкой входа решил сделать «Мои документы», хранится на файл-сервере. И поменять место хранения не проблема.
2. Не стали разбивать по отделам сотрудников, за основу взяли рабочие группы. Т.е. не важно в каком отделе работает сотрудник, но если у него есть документы, с которыми работает кто-то еще, то их объединяли в рабочую группу.
3. В каждой пользовательской папке должны быть ярлыки на группы, в которых он состоит.
4. Пользователь должен иметь права на отправку файлов в другие отделы. Индивидуально можно и по почте отправить, а вот рассылка группе по почте крупных файлов заставляет быстрее разбухать ящики пользователей.

Структура папок на сервере простейшая, три расшаренные папки:

user — поименные папки пользователей, создавались автоматически и с нужными правами;
group — создавались вручную, параллельно с созданием рабочей группы, права для группы на изменение;
send — папка для отправки документов в другие рабочие группы, чистим ежедневно.

А теперь по пунктам подробно, как это было реализовано.

1. Папки пользователей

Через GPO поменяли места хранения. Но т.к. после применения все добро из моих документов начинает копироваться на сервер, у некоторых это >20Gb, то мы прибегли к фильтру безопасности. Создали объект, связали со всем доменом, почистили фильтр безопасности и добавляли по одному пользователю. Так смогли разгрузить сеть.

2. Папки рабочих груп

Для этого в AD создали подразделение, для своего удобства. Внутри подразделения на создавали группы соответствующие нашим рабочим группам. Параллельно создавали одноименные папки в папке group и нарезали права. В каждой папке есть ссылка на папку из send где будут лежать входящие документы.

3. Единая точка входа через Мои документы

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

OU=Рабочие группы — объект где хранятся наши рабочие группы.

Import-Module ActiveDirectory
$Groups=Get-ADGroup -Filter * -SearchBase "OU=Рабочие группы,DC=domain,DC=local" -Properties *|Select Name,Members #получаем список групп, нам нужно тольок её имя и список членов
foreach ($Group in $Groups) {
$GroupFolders='\\имя сервера\group\'+$Group.Name #формируем путь ссылки

$LinkGroupFolders=$GroupFolders+"\_Входящие документы.lnk" #в папке группы создаем ярлык на папку входящих документов для отдела, именно там появляются aqks переданные от другого отдела

# Создание ссылки и назначение правка на папку входящие документы
$oShell1 = New-Object -COM WScript.Shell
$oShortcut1 = $oShell1.CreateShortcut($LinkGroupFolders)
$oShortcut1.TargetPath = '\\имя сервера\send\'+$Group.Name
$oShortcut1.Description = "Входящие документы для "+$Group.Name
$oShortcut1.Save()
$acl1 = Get-Acl $LinkGroupFolders
$addacl1 = New-Object System.Security.AccessControl.FileSystemAccessRule($Group.Name, "FullControl", "Allow")
$acl1.AddAccessRule($addacl1)
$acl1 | Set-Acl $LinkGroupFolders
#  Создание ссылки и назначение правка на папку входящие документы

$User="" #обнуляем переменную после предыдущего прогона
$User=Get-ADGroupMember -Identity $Group.Name -Recursive |Select SamAccountName #Получаем список пользователей группы
if($User.count){ #Если пользователей меньше 2х то папка рабочих групп и не нужна
foreach ($Users in $User) {
#Ссылки на группы
$UserFolder='\\имя сервера\user\'+$Users.SamAccountName+"\Мои документы\_Группа "+$Group.Name+".lnk" #тут создать ссылку
$oShell = New-Object -COM WScript.Shell
$oShortcut = $oShell.CreateShortcut($UserFolder)
$oShortcut.TargetPath = $GroupFolders
$oShortcut.Description = "Совместная рабочая группа "+$Group.Name
$oShortcut.Save()
$acl = Get-Acl $UserFolder
$addacl = New-Object System.Security.AccessControl.FileSystemAccessRule($Users.SamAccountName, "FullControl", "Allow")
$acl.AddAccessRule($addacl)
$acl | Set-Acl $UserFolder

#Создание ярлыка на отправка документов, со списко всех рабочих групп
$UserFolder='\\имя сервера\user\'+$Users.SamAccountName+"\Мои документы\_Отправка документов.lnk" #тут создать ссылку
$oShell = New-Object -COM WScript.Shell
$oShortcut = $oShell.CreateShortcut($UserFolder)
$oShortcut.TargetPath = '\\имя сервера\send\'
$oShortcut.Description = "Передача документов по отделам"
$oShortcut.Save()
$acl = Get-Acl $UserFolder
$addacl = New-Object System.Security.AccessControl.FileSystemAccessRule($Users.SamAccountName, "FullControl", "Allow")
$acl.AddAccessRule($addacl)
$acl | Set-Acl $UserFolder
}
}
}

4. Отправка файлов

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

Import-Module ActiveDirectory
$Groups=Get-ADGroup -Filter * -SearchBase "OU=Рабочие группы,DC=domain,DC=local" -Properties *|Select Name,Members #получаем список групп, нам нужно тольок её имя и список членов
foreach ($Group in $Groups) {
$CreateSendFolders="\\имя сервера\send\"+$Group.Name
$BackupFolderst=Get-Date -Format "yyyy.MM.dd HH-mm-ss"
$BackupFolderst2="\\Имя сервера резервных копий\e$\send\"+$Group.Name

Move-Item -Path $CreateSendFolders -Destination $BackupFolderst2"_"$BackupFolderst #Переносим папку, переименовав её, добавив в конец дату формирования копии
New-Item -Path $CreateSendFolders -ItemType "directory" #Создаем новую пустую папку

#Назначаем права
$aclSendFolders = Get-Acl $CreateSendFolders
$addaclSendFolders2 = New-Object System.Security.AccessControl.FileSystemAccessRule($Group.Name, "CreateDirectories,DeleteSubdirectoriesAndFiles,ExecuteFile,ListDirectory,ReadData,ReadExtendedAttributes,ReadPermissions", "Allow")
$aclSendFolders.AddAccessRule($addaclSendFolders2)
$addaclSendFolders = New-Object System.Security.AccessControl.FileSystemAccessRule($Group.Name, "CreateDirectories,DeleteSubdirectoriesAndFiles,ExecuteFile,ListDirectory,ReadData,ReadExtendedAttributes,ReadPermissions","ContainerInherit,ObjectInherit","InheritOnly", "Allow")
$aclSendFolders.AddAccessRule($addaclSendFolders)
$aclSendFolders | Set-Acl $CreateSendFolders

#Пользователям домена даем права на добавление файлов и просмотр структуры
$aclSendFoldersAll = Get-Acl $CreateSendFolders
$addaclSendFoldersAll = New-Object System.Security.AccessControl.FileSystemAccessRule("Пользователи домена", "CreateDirectories,CreateFiles,ListDirectory", "Allow")
$aclSendFoldersAll.AddAccessRule($addaclSendFoldersAll)
$aclSendFoldersAll | Set-Acl $CreateSendFolders
}

#Удаляем старый копии, старее одного месяца
$OldDate = (Get-Date).AddMonths(-1)
Get-ChildItem -Path  \\Имя сервера резервных копий\e$\send\ -Recurse | Where {$_.LastWriteTime -le "$OldDate"} | Remove-Item -Recurse

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

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

Источник