Рубрика: Windows

Как отправить сообщение всем терминальным пользователям Server 2016 RDS

 

В Windows Server 2016 в консоли Server Manager в разделе управления настройками ролей Remote Desktop Services при выборе определённой Коллекции нам доступно окно управления клиентскими подключениями к серверам нашей фермы RDS, однако по какой-то странной причине разработчики этой самой консоли посчитали что функцию выбора более одного пользователя для отправки сообщения реализовывать не нужно, …наверно чтобы администраторам жизнь мёдом не казалась..

Как отправить сообщение всем терминальным пользователям Server 2016 RDS

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

[idea]

# $ConnectionBroker – Активный сервер RDCB. Если не указан, будет произведена попытка выявить его автоматически (для этого обязательно чтобы скрипт выполнялся на одном из серверов фермы RDS)

# $SessionHostCollection – Имя RD-коллекции в которой нужно вывести сообщение.

#

$ConnectionBroker = “”

$SessionHostCollection = “KOM-AD01-RDCOLL”

$MessageTitle = “Сообщение от тех.поддержки SAP”

$MessageText = “Уважаемые коллеги!

В связи с проведением работ по расчету зарплаты –

просьба в программе SAP Персонал с 11:00 до конца дня

с табельными номерами не работать!”

If ($ConnectionBroker -eq “”) {

$HAFarm = Get-RDConnectionBrokerHighAvailability

$ConnectionBroker = $HAFarm.ActiveManagementServer

}

$Sessions = Get-RDUserSession -ConnectionBroker $ConnectionBroker -CollectionName $SessionHostCollection

ForEach ($Session in $Sessions) {

Send-RDUserMessage -HostServer $Session.ServerName -UnifiedSessionID $Session.UnifiedSessionID -MessageTitle $MessageTitle -MessageBody $MessageText

}

[/idea]

В результате все активные пользователи на всех серверах фермы RDS получат всплывающее сообщение которое трудно не заметить… image

 

 

Пример скрипта скачать Сообщение всем пользователям

Запуск PowerShell скрипта из проводника с правами администратора

В Windows скрипты PowerShell (расширение .PS1) по умолчанию не ассоциированы с исполнимым файлом PowerShell.exe. При двойном щелке по файлу сценария PS1 открывается окно тестового редактора notepad.exe. Запустить файл PS1 на выполнение в среде PowerShell можно из контекстного меню проводника, выбрав пункт Run With PowerShell. Однако такой сценарий запускается в рамках сессии пользователя, без прав администратора. Хотя для тех же файлов скриптов .bat, .cmd, имеется отдельный пункт меню Run As administrator. В случае с PowerShell приходится открывать консоль Power Shell с повышенными правами и указывать полный путь к файлу скрипта. Не очень-то удобно.

Рассмотрим, как добавить в контекстное меню проводника File Explorer для файлов с расширением *.ps1, пункт, позволявший запустить скрипт PowerShell с правами администратора.

Запустите редактор реестра (regedit.exe)

Перейдите в ветку HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\shell

HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\shell

Создайте подраздел с именем runas и перейдите в него

Внутри раздела runas создайте пустой строковый параметр (String Value) с именем HasLUAShield (этот параметр добавит иконку UAC в контекстное меню проводника)

В разделе runas создайте вложенный подраздел command

HasLUAShield

В качестве значения параметра Default раздела command укажите значение:

[code]powershell.exe “-Command” “if((Get-ExecutionPolicy ) -ne ‘AllSigned’) { Set-ExecutionPolicy -Scope Process Bypass }; & ‘%1′”[/code]

powershell.exe Command

Теперь, если щелкнуть ПКМ по любому *.PS1 файлу, в контекстном меню можно выбрать пункт Run as administrator

PowerShell скрипт ps1 - RunAsAdministrator

Совет. Если скрипт отрабатывает быстро, пользователь успевает только увидеть появившееся и быстро исчезнувшее окно PowerShell. А что делать, если результат выполнения скрипта должен остаться на экране для просмотра пользователем?

Чтобы после окончания работы скрипта, окно консоли PowerShell не закрывалось, необходимо добавить в строку параметр –NoExit:

[code]powershell.exe –NoExit “-Command” “if((Get-ExecutionPolicy ) -ne ‘AllSigned’) { Set-ExecutionPolicy -Scope Process Bypass }; & ‘%1′”[/code]

Готовый reg файл скачать: ps1-ot-administratora

 

Источники: https://blog.it-kb.ruhttp://winitpro.ru

Настройка TS Easy Print на сервере терминалов Windows Server 2016

 

Технология TS Easy Print является альтернативой стандартной службе печати, появилась впервые в Windows Server 2008R2.

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

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

Необходимо лишь наличие клиента удаленного рабочего стола версии 6.1 (или старше) и .NET Framework 3.0 SP1 (или старше).

Настройка

Чтобы включить данную технологию необходимо зайти в редактор групповых политик gpedit.msc :

 Конфигурация компьютера\

 Административные шаблоны\

 Компоненты Windows\

 Службы удаленных рабочих столов\

 Узел сеансов удаленных рабочих столов\

 Перенаправление принтеров

перенаправлять только используемый по умолчанию принтер клиента — вкл

Настройка TS Easy Print на сервере терминалов Windows Server 2016

использовать в первую очередь драйвер принтера Easy Print — отк

Настройка TS Easy Print на сервере терминалов Windows Server 2016

сервер сначала будет пытаться печатать с помощью драйвера принтера и только если его не найдет обратится к драйверу easy print.

Далее выполняем настройку изоляции драйверов печати.

Данная функция доступна также с Windows Server 2008.

Для этого перейдем в раздел редактора групповых политик:

 Конфигурация компьютера\

 Административные шаблоны\

 Принтеры\

выполнять драйвера принтеров в изолированном виде — вкл

Настройка TS Easy Print на сервере терминалов Windows Server 2016

переопределить параметр совместимости выполнения драйвера печати , сообщенный драйверов печати — вкл

Настройка TS Easy Print на сервере терминалов Windows Server 2016

Для корректной работы данный технологии необходимо, чтобы на сервера был установлен принтер Microsoft XPS Document Writer.

Настройка TS Easy Print на сервере терминалов Windows Server 2016

Настройка Easy Print на этом окончена.

Источник

Как удалить все metro-приложения в Windows 10

Как удалить все metro-приложения в Windows 10

После установки Windows 10 в системе уже будут предустановлены metro-приложения из магазина Microsoft Store. Они начинают обновляться, также добавляться новые программы и игры, даже без вашего ведома. Все бы наверно ничего, но по большей части все эти приложения бесполезны, мало кто ими пользуется на самом деле.

 

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

DelWindows10Apps

Распаковать

Далее, нажимаем на скачанном файле правой кнопкой и выбираем пункт «Выполнить с помощью PowerShell»

Внимание!

При запуске скрипта возможно появление предупреждающего сообщения: «Execution Policy Change». Нажмите на клавиатуре «Y» и Enter, чтобы дать разрешение на удаление.

Ждем, пока отработает скрипт. Он удалит все metro-приложения на которые у него хватит прав доступа.

Также удалятся калькулятор, магазин приложении Windows Store, музыка Groove.

Открываем Все параметры -> Приложения через центр уведомлений (значок в правом нижнем углу экрана) и удаляем оставшиеся приложения вручную.

Теперь в меню пуск, как видим, пусто. Приложения удалены! Можно перезагрузить компьютер.

gpedit.msc

Но это еще не все, со временем некоторые приложения и игры могут заново установиться в системе фоном, не спрашивая разрешения пользователя.

P.S. Вернуть все приложения можно выполнив следующую команду в PowerShell (от администратора:

[code]Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}[/code]

 

 

Источник

Вносим изменения в реестр

Скачиваем файл реестра по этой кнопке:

disable_installation_metro

Распаковать

Щелкаем на этом файле правой кнопкой мыши и выбираем пункт «Слияние»

Соглашаемся на внесение изменений в реестр

Содержимое файла реестра

[code]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Cloud Content]

“DisableWindowsConsumerFeatures”=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager]

“SilentInstalledAppsEnabled”=dword:00000000

[/code]

Выключаем рекомендации в настройках

Открываем параметры Windows 10  комбинацией клавиш  WIN+I или нажав «Все параметры» в боковой шторке

Нажимаем кнопку «Персонализация» и выключаем флажок «Иногда показывать предложения в меню Пуск»

Запрет в групповых политиках

Нажимаем на клавиатуре комбинацию клавиш WIN+R и в появившемся окне вводим:

[code]gpedit.msc[/code]

После нажатия на Enter откроется редактор локальной групповой политики. Идем по пути Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Содержимое облака и меняем Выключить возможности потребителя Windows на «Включено».

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

Источник

Автоматический вход при загрузке Windows

В том распространённом случае, когда вы доверяете своему домашнему и/или офисному окружению и не пытаетесь ограничить доступ к Windows, предлагаем при помощи нескольких простых шагов настроить автоматический вход в аккаунт:

    • Сделайте правый клик на кнопке «Пуск» в левом нижнем углу экрана. Щёлкните по пункту «Выполнить».
    • Введите команду netplwiz и запустите её выполнение.

    [code]netplwiz[/code]

    • В открывшемся окне «Учётные записи пользователей» снимите галочку напротив пункта «Требовать ввод имени пользователя и пароля».
    • Укажите свой пароль и повторите его ввод.

    Как настроить автоматических вход в аккаунт при загрузке Windows 10

    Поздравляем, экран входа в систему больше не будет беспокоить ваши нервы!

Пользователь домена и локальный администратор

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

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

Запускаем оснастку «Active Directory — пользователи и компьютеры» и создаем глобальную группу безопасности. Для ясности назовем ее «Администраторы локальных машин»

Предоставление прав локального администратора на машинах домена пользователю

 

Далее, запускаем оснастку «Управление групповой политикой» и создаем новый объект групповой политики. Для ясности, назовем политику «Локальные администраторы (PC)» /я обычно помечаю, на что действует та или иная политика. В данном случае PC — на компьютер/

Предоставление прав локального администратора на машинах домена пользователю

Далее, изменяем созданную политику. Выбираем ветку: «Конфигурация компьютера» → «Конфигурация Windows» → «Параметры безопасности» → Группы с ограниченным доступом

Предоставление прав локального администратора на машинах домена пользователю

И выбираем Добавить группу…

При добавлении группы указываем ранее созданную группу «Администраторы локальных машин»

Предоставление прав локального администратора на машинах домена пользователю

Далее добавляем запись в нижней части «Эта группа входит в:»

Предоставление прав локального администратора на машинах домена пользователю

Указываем группу «Администраторы»

Предоставление прав локального администратора на машинах домена пользователю

Жмем Ок. Политика создана.

Предоставление прав локального администратора на машинах домена пользователю

Можно посмотреть политику перейдя на вкладку «Параметры»

Предоставление прав локального администратора на машинах домена пользователю

Как видно, политика применяется к компьютеру и включает группу «домен\Администраторы локальных машин» во встроенную группу локальных администраторов компьютера.

Теперь, можно создать подразделение, например, «Рабочие станции», поместить туда компьютеры, для которых необходимо применить политику

Предоставление прав локального администратора на машинах домена пользователю

После этого следует назначить подразделению созданную нами политику.

Предоставление прав локального администратора на машинах домена пользователю

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

Такое решение удобно тем, что при необходимости можно легко изменить список лиц с правами локального администратора или включать/отключать существующий список по мере необходимости.

Как видно из примера, все достаточно просто и, надеюсь, понятно.

ВАЖНО!!! Используя данный метод, появляется возможность входа на сервера с такой учетной записью.
Данный вопрос изучается.

 

Источник

Как очистить корзину сразу у всех пользователей Windows

Корзина файлов – одна из самых замечательных возможностей операционных систем. Вспомните только, сколько раз вам приходилось восстанавливать из неё случайно удалённый файл. Не будь корзины, проблем из-за случайно нажатой в “проводнике” клавиши Delete было бы очень много. Но у всякой медали есть обратная сторона. Удалённый файлы занимают место. Корзину можно очистить, но только на своём собственном рабочем столе, а что делать, когда на ПК работает несколько пользователей и некоторые из них не заботятся об освобождении места. Нужен простой способ быстро удалить файлы из корзины других пользователей компьютера. Проще всего это сделать через командную строку.

Командная строка в Windows порой позволяет творить чудеса. Вот и для такой необычной операции, как удаление файлов из корзины другого пользователя нашлась команда. Чтобы её выполнить запустите приложение командной строки (cmd.exe). Это можно сделать через меню Пуск:

В окне командной строки, в зависимости от вашей операционной системы наберите указанную ниже команду и нажмите клавишу “Enter”:

Для Windows 7, 8 или для Server 2008:

[code]rd /s c:\$Recycle.Bin[/code]

Для Windows XP или Server 2003:

[code]rd /s c:\recycler[/code]

comand-line-2

Система запросит подтверждение, введите “Y” и нажмите клавишу “Enter”:

comand-line-3

Система очистит корзины всех пользователей Windows на данном компьютере.

Обратите внимание, что команда содержит имя диска на котором установлена операционная система. Если у вас она установлена на другом диске, впишите его имя в команде.

P.S. Иконка корзины на рабочем столе при выполнении этой команды автоматически не обновляется. Это произойдёт несколько позже, когда “Проводник” Windows обновит данные об удалённых файлах.

Планировщик задач, перезагрузка ПК по расписанию.

В Windows XP :

Пуск – Панель управления – ярлык “Назначенные задания”

либо

Пуск – Все программы – Стандартные – Служебные – Назначенные задания

В Windows 7 :

Пуск – Панель управления – Администрирование – Расписание выполнения задач

либо

Пуск – Все программы – Стандартные – Служебные – Планировщик заданий

В Windows 8 :

Пуск – Панель управления – Администрирование – Расписание выполнения задач

Заходим в планировщик задач:
Зажимаем Пуск+R, вводим в строку

[code]C:\\Windows\system32\taskschd.msc /s.[/code]

Создаём Простую задачу:

Вводим Имя задачи, жмём Далее.


Оставляем галочку на Ежедневно и жмём Далее.


Далее вписываем нужное Время для перезагрузки и жмём Далее.


Оставляем галочку на Запустить программу, снова жмём Далее.


В поле Программа или сценарий вводим

[code]C:\Windows\System32\shutdown.exe[/code]

в поле Добавить аргументы вводим -r и снова давим Далее, и Готово.

 

Для повторения задачи каждые N часов надо проделать эти действия сколько

нужна устанавливая разное время.

Также для автоматического выключения ПК надо проделать тот же путь,

только в поле Добавить аргументы вводим -s.

Источник

7 способов выполнить команду на удалённом компьютере

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

Так как задача эта популярная, то и способов её решения существует множество. Начиная от групповых политик (в которых можно применять для этой цели сценарии входа в систему или автозагрузки), и заканчивая мощными системами управления, вроде System Center Essentials или System Center Configuration Manager. Но я в этой статье хочу рассмотреть методы, которые доступны сразу из командной строки или файлов сценариев, а также не требуют предварительной установки агентов и прочей суматохи. Впрочем, какие-то предварительные требования конечно есть. Например, у вас должны быть административные полномочия на том компьютере, на котором вы хотите выполнить команду (за исключением сценария с «проксированием», но об этом позже).

PsExec.exe

Один из моих любимых способов для решения этой задачи это утилита командной строки PsExec.exe написанная Марком Руссиновичем, которую вы можете свободно скачать с сайта Windows SysInternals. Ссылку на неё вы можете найти в конце статьи. Она не требует установки в систему, вы можете просто скопировать её в одну из папок, содержащихся в переменной окружения %path% и вызывать из любой оболочки командной строки: Cmd или PowerShell.

Использовать PsExec очень просто. Например, чтобы выполнить ipconfig /flushdns на компьютере main, достаточно запустить следующую команду:

[code]psexec \\main ipconfig /flushdns[/code]

Команда ipconfig будет запущена на компьютере main под вашими учетными данными. После завершения работы ipconfig весь текстовый вывод будет передан на ваш компьютер, а кроме того будет возвращён код выхода команды (error code). В случае если команда выполнилась успешно, он будет равен 0.

7 способов выполнить команду на удалённом компьютере

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

Ключ -d говорит PsExec что ненужно дожидаться выполнения команды, а достаточно лишь запустить её, и забыть. В этом случае мы не получим выходных данных от консольной утилиты, но зато сможем не дожидаясь завершения предыдущей команды запускать другие. Это очень полезно, если вам необходимо запустить, например установщик программы на нескольких компьютерах.

По умолчанию PsExec выполняет команды в скрытом режиме, то есть на системе где выполняется команда, не будут выводиться никакие окна или диалоги. Однако есть возможность изменить это поведение, с помощью ключа -i . После него можно указать номер сессии, в которой выводить окна, а можно и не указывать, тогда интерфейс будет отображен в консольной сессии.

Таким образом, чтобы вывести окно с информацией о версии операционной системы на компьютере main, следует запустить PsExec таким образом:

[code]psexec -i \\main winver.exe[/code]

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

[code]psexec @c:\comps.txt systeminfo.exe[/code]

Ну и одной из самых полезных способностей PsExec является возможность интерактивного перенаправления ввода/вывода между компьютерами, что позволяет нам запустить, например, cmd.exe на удалённом сервере, а давать ему команды и получать результаты на локальном компьютере.

7 способов выполнить команду на удалённом компьютере

Каким образом работает PsExec? 

Всё гениальное просто. В ресурсах исполняемого файла PsExec.exe находится другой исполняемый файл – PSEXESVC, который является службой Windows. Перед выполнением команды, PsExec распаковывает этот ресурс на скрытую административную общую папку удалённого компьютера, в файл: \\ИмяКомпьютера\Admin$\system32\psexesvc.exe. Если вы с помощью ключа -c указали что необходимо скопировать исполняемые файлы на эту систему, они тоже скопируются в эту папку.

По завершению подготовительных действий, PsExec устанавливает и запускает службу, используя API функции Windows для управления службами. После того как PSEXESVC запустится, между ним и PsExec создаётся несколько каналов для передачи данных (вводимых команд, результатов, и т.д.). Завершив работу, PsExec останавливает службу, и удаляет её с целевого компьютера.

Windows Management Instrumentation (WMI)

Следующий способ реализации этой популярной задачи, о котором я хочу поведать – использование Windows Management Instrumentation. WMI присутствует во всех операционных системах Microsoft, начиная с Windows 2000, и даже на Windows 9x его можно установить из отдельного пакета. WMI включён по умолчанию, и не требует дополнительной настройки. Для его использования достаточно административных прав, и разрешенного на брандмауэре протокола DCOM. WMI предоставляет огромные возможности для управления системами, но нас сейчас интересует лишь одна из них.

Для запуска процессов нам потребуется метод Create класса Win32_Process. Использовать его достаточно несложно. В PowerShell это делается следующим образом:

[code]$Computer = “main”
$Command = “cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt”
([wmiclass]”\\$Computer\root\cimv2:Win32_Process”).create($Command)[/code]

Здесь в качестве запускаемого процесса я указал cmd.exe, а уже ему, в качестве аргументов передал нужную команду. Это необходимо в случае если вам нужно использовать переменные окружения удалённого компьютера или встроенные операторы cmd.exe, такие как «>» для перенаправления вывода в файл. Метод Create не дожидается завершения процесса, и не возвращает результатов, но зато сообщает нам его идентификатор – ProcessID.

Если вы используете компьютер, на котором пока не установлен PowerShell, вы можете вызвать этот метод WMI и из сценария на VBScript. Например, вот так:

Листинг №1 – Запуск процесса используя WMI (VBScript) 

[code]Computer = “PC3”
Command = “cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt”
Set objWMIService = GetObject(“winmgmts:\\” & Computer & “\root\cimv2:Win32_Process”)
Result = objWMIService.Create(“calc.exe”, Null, Null, intProcessID)[/code]

Но гораздо проще воспользоваться утилитой командной строки wmic.exe которая предоставляет достаточно удобный интерфейс для работы с WMI и входит в состав операционных систем, начиная с Windows XP. В ней чтобы запустить, например калькулятор на компьютере main достаточно выполнить следующую команду:

[code]wmic /node:main process call create calc.exe[/code]

Разумеется, возможности WMI не ограничиваются только запуском процессов. Если вам интересно дальнейшее изучение этой технологии, я рекомендую ознакомиться со статьями Константина Леонтьева, посвященными WMI, ссылки на которые вы можете найти в конце статьи.

WSH Remote Scripting

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

Итак, для запуска сценария на другом компьютере с помощью WSH нам понадобится сделать следующее:

  1. Права администратора на удалённом компьютере. Это само собой разумеется, и требуется почти для всех остальных методов запуска, перечисленных в этой статье.
  2. Разрешить WSH Remote Scripting создав в системном реестре строковой параметр Remote равный “1” в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
  3. Из-за ошибки описанной в статье базы знаний Microsoft с номером 311269, на системах с Windows XP может понадобиться выполнить команду wscript –regserver
  4. Если на компьютерах используется брандмауэр, то в нём необходимо разрешить обращения к DCOM. Причем сделать это надо не только на управляемом компьютере, но и на том с которого вы хотите запускать сценарий.
  5. В системах Windows XP с пакетом обновлений 2 и выше, необходимо изменить параметры безопасности DCOM. Это можно сделать с помощью групповой политики. В узле Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options следует установить разрешения следующим образом:
    1. DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
      Выдать группам Anonymous Logon и Everyone разрешения Allow Local и Allow Remote Access
    2. DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
      Выдать группе Administrators разрешения Allow Local Launch, Allow Remote Launch, Allow Local Activation, Allow Remote Activation
      Группе Everyone – Allow Local Launch, Allow Local Activation

Ну и после всех этих процедур, можно попробовать запустить свой сценарий на другом компьютере.

Пример сценария, который использует эту технологию:

Листинг №2 – WSH remote scripting (VBScript) 

[code]Set objController = CreateObject(“WshController”)
Set objRemoteScript = objController.CreateScript(“C:\test.vbs”, “PC5”)WScript.ConnectObject objRemoteScript, “remote_”
objRemoteScript.Execute
Do While objRemoteScript.Status <> 1
WScript.Sleep 1000
Loop
MsgBox “Script complete”
Sub remote_Error
Dim objError
Set objError = objRemoteScript.Error
WScript.Echo “Error – Line: ” & objError.Line & _
“, Char: ” & objError.Character & vbCrLf & _
“Description: ” & objError.Description[/code]

На второй его строчке, в качестве параметров для функции CreateScript указывается путь к файлу сценария, который будет выполнен на удаленном компьютере и собственно имя этого компьютера.

Более подробную статью об этой технологии можно прочитать в статье Advanced VBScript for Microsoft Windows Administrators – Chapter 6: Remote Scripting (см. Ссылки).

Планировщик заданий (Task Scheduler)

Планировщиком заданий можно управлять из командной строки используя две утилиты – at.exe и schtasks.exe. Обе эти утилиты позволяют указать имя удалённого компьютера для создания задания, и, следовательно, позволяют решить нашу задачу. Но подробно мы рассмотрим лишь schtasks.exe, так как она предоставляет гораздо больше возможностей.

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

[code]schtasks /create /s server6.td.local /tn install /tr \\main\data\install.cmd /sc once /st 13:00 /ru system[/code]

Важно понимать от имени какой учетной записи будет выполняться задача. В этом примере я указал для параметра /ru значение system, следовательно, для выполнения установки учетной записи компьютера будет необходим доступ на чтение в сетевую папку с дистрибутивом программы.

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

Листинг №3 – Установка программы с последующим удалением задания (Windows Batch) 

[code]msiexec /qn /package \\server\share\subinacl.msi
if exist “c:\program files\Windows Resource Kits\Tools\subinacl.exe” (
subinacl /tn Install_Subinacl /f
)[/code]

WinRM (WS-Management)

WinRM – это реализация открытого стандарта DMTF (Distributed Management Task Force) от Microsoft, которая позволяет управлять системами с помощью веб-служб. Углубляться в устройство технологии я не буду, а лишь кратко опишу, что необходимо для её использования.

Версия WinRM 1 и выше входит в состав операционных систем, начиная с Windows Vista и Windows Server 2008. Для Windows XP и Windows Server 2003 можно установить WinRM в виде отдельного пакета (см. ссылки).

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

[code]winrm quickconfig[/code]

Чтобы winrm не спрашивал подтверждения, можно добавить к вызову ключ -quiet. Узнать информацию о более тонкой настройке можно посмотреть встроенную справку winrm:

[code]winrm help config[/code]

Если на управляемом компьютере работает веб-сервер, WinRM никак ему не помешает, хоть и использует по умолчанию стандартные порты HTTP. Он будет перехватывать лишь подключения, предназначенные специально для него.

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

  1. Настроить службу WinRM (Windows Remote Management) на автоматический запуск
  2. Настроить элемент групповой политики Computer Configuration \ Administrative Templates \ Windows Components \ Windows Remote Management (WinRM) \ WinRM Service \ Allow automatic configuration of listeners. Тут нужно указать диапазоны IP-адресов с которых разрешаются подключения.
  3. Разумеется, еще вам будет необходимо разрешить подключения на соответствующие порты (по умолчанию 80) в брандмауэре Windows.

Независимо от того используется ли порт HTTP (80) или HTTPS (443) трафик, передаваемый WinRM шифруется (если конечно вы не отключите эту опцию). Для аутентификации по умолчанию используется протокол Kerberos.

Но хватит о настройках, лучше перейдем непосредственно к использованию. Хоть утилита winrm позволяет настраивать службу WinRM, а также выполнять, например, WMI запросы, нам более интересна другая – winrs. Буквы RS тут означают Remote Shell. WinRS работает очень похоже на PsExec хотя и использует технологию WinRM. Имя компьютера задаётся ключом -r, а после него следует команда, которую нужно выполнить. Вот несколько примеров:

[code]winrs -r:Core ver.exe[/code]

Так как winrs и так использует cmd.exe в качестве удалённой оболчки, в командах можно легко обращаться к удалённым переменным окружения, или использовать другие встроенные команды cmd.exe:

[code]winrs -r:Core “dir c:\temp > c:\temp\list.txt”[/code]

Как и PsExec, утилита winrs позволяет открыть интерактивный сеанс на удалённом компьютере:

[code]winrs -r:main cmd.exe[/code]

Эта функция аналогична telnet сессии, но использование winrs однозначно лучше telnet и даже PsExec, с точки зрения безопасности. Независимо от того используется ли порт HTTP (80) или HTTPS (443), трафик, передаваемый WinRM шифруется (если конечно вы не отключите эту опцию). Для аутентификации по умолчанию используется протокол Kerberos.

Windows PowerShell 2.0 Remoting

Хотя вторая версия Windows PowerShell на момент написания статьи находится еще в состоянии бета тестирования, о её возможностях в области удалённого выполнения команд определённо стоит рассказать уже сейчас. Попробовать его своими руками вы можете либо, загрузив предварительную версию (см. ссылки) либо в составе бета-версии Windows 7 или Windows Server 2008 R2.

Инфраструктура PowerShell Remoting основана на WinRM версии 2.0, и поэтому наследует все преимущества этой технологии, такие как шифрование передаваемых данных, и возможность работать по стандартным портам HTTP/HTTPS. Но благодаря богатым возможностям языка Windows PowerShell, и его способностям работы с объектами, мы получаем еще большие возможности. На данный момент пакет WinRM2.0 тоже находится в состоянии бета-тестирования, и доступен для загрузки только для систем Windows Vista и Windows 2008. В системы Windows 7 и Windows Server 2008R2 он будет встроен изначально, как и PowerShell 2.0.

Обновление: К моменту публикации статьи на ItBand.ru, финальные версии PowerShell 2.0 и WinRM 2.0 доступны уже для всех поддерживаемых платформ. В состав Windows Server 2008R2 и Windows 7 они уже включены как неотъемлемые компоненты системы, а для Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 все необходимые компоненты можно получить в виде пакета называемого Windows Management Framework.

Перед тем как воспользоваться всеми этими преимуществами, PowerShell Remoting необходимо активизировать, на управляющем, и управляемых компьютерах. Сделать это просто, запустив командлет (команду Windows PowerShell) Enable-PSRemoting. Причем если добавить ключ -Force то никаких подтверждений запрошено не будет. Этот командлет при необходимости вызовет winrs quickconfig, и создаст исключения в брандмауэре Windows, так что никаких дополнительных действий выполнять не нужно.

После этого вы сможете легко выполнять команды на других компьютерах используя командлет Invoke-Command (или его псевдоним icm):

[code]Invoke-Command -ComputerName Main -ScriptBlock {netsh interface dump > c:\ipconfig.txt}[/code]

Разумеется команду можно заранее поместить в переменную, а для параметра -ComputerName указать имена не одного, а сразу нескольких компьютеров. Следующая последовательность позволяет вывести версию файла Explorer.exe сразу с трех компьютеров.

[code]$Command = {(get-item c:\Windows\explorer.exe).VersionInfo.FileVersion}
Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $Command[/code]

Как видно на, можно передавать сразу несколько команд в одном блоке, помещать их результаты выполнения на нескольких компьютерах в переменную, а затем обрабатывать на рабочей станции используя возможности Windows PowerShell по работе с объектами.

Впрочем, возможности PowerShell Remoting на этом только начинаются. С помощью командлета Enter-PSSession вы можете войти в интерактивную сессию Windows PowerShell на удалённом компьютере. Выйти из такого сеанса можно использовав командлет Exit-PSSession, или просто exit.

Командлет New-PSSession создает сессии на удалённых компьютерах, указатели на которые можно поместить в переменную, а затем передавая её как аргумент для Invoke-Command выполнять команды сразу на нескольких компьютерах, в постоянном окружении. Пример вы можете увидеть на скриншоте, где я выполняю последовательность команд сразу на нескольких компьютерах из списка [code]c:\computers.txt.[/code]

Проксирование

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

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

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

Чтобы избежать этих проблем, но, тем не менее, разрешить выполнение конкретной команды, можно использовать методику, которая называется “проксированием”.

Работает она следующим образом. На компьютере постоянно работает сценарий с высокими привилегиями. Например, в нашем случае он будет запущен из-под учетной записи, обладающей правами администратора на файловом сервере. По сигналу пользователя он будет выполнять одну, заранее определённую команду. В этом примере – закрывать все файлы, открытые по сети.

Для организации этой системы мы поместим на сервере, например, в папке c:\scripts\ командные файлы Server.cmd и Action.cmd.

Листинг №4 – Server.cmd (Windows Batch) 

[code]set trigger=c:\commandShare\trigger.txt
set action=c:\scripts\action.cmd
set log=c:\scripts\log.txt
:start
if exist %trigger% start %action% & echo %time% %date%>>%log% & del %trigger%
sleep.exe 5
goto start[/code]

Листинг №5 – Action.cmd (Windows Batch) 

[code]for /f “skip=4 tokens=1” %%a in (‘net files’) do net files %%a /close
exit[/code]

Server.cmd будет ждать знака от пользователя (создание файла в определенном месте), и получив его, запускать файл с командами – Action.cmd. Разумеется, в эту папку пользователи не должны иметь никакого доступа. Автоматический запуск Server.cmd при запуске компьютера можно организовать, просто создав соответствующую задачу в планировщике:

[code]schtasks /create /ru domain\administrator /rp /sc onstart /tn ProxyScript /tr c:\scripts\server.cmd[/code]

После параметра /ru указывается учетная запись, под которой будет выполняться сценарий (в нашем случае она обладает правами администратора на сервере), так как после параметра /rp пароль не указан – он будет запрошен при создании задачи. Параметр /sc позволяет указать момент запуска сценария, в нашем случае – при включении компьютера. Ну а /tn и /tr позволяют указать имя задачи, и исполняемый файл.

Теперь, для того чтобы пользователь мог подать сценарию сигнал, мы создадим папку c:\commandShare и сделаем её доступной по сети. Доступ на запись в эту папку должен быть только у тех пользователей, которые будут запускать команду.

После этого достаточно будет поместить пользователю на рабочий стол файл Run.cmd.

Листинг №6 – Run.cmd (Windows Batch) 

[code]echo test > \\server\commandShare\trigger.txt[/code]

При его выполнении, от имени пользователя, будет создаваться файл \\server\commandShare\trigger.txt. Сценарий Server.cmd, заметив его, запустит на выполнение со своими привилегиями файл Action.cmd, добавит запись в файл c:\scripts\log.txt о текущем времени, а затем удалит trigger.txt чтобы не выполнять команду снова до следующего сигнала пользователя.

В сценарии Server.cmd используется утилита Sleep.exe, позволяющая сделать паузу в выполнении сценария на заданный в секундах промежуток времени. Она не входит в состав операционной системы, но её можно взять из набора Resource Kit Tools (см. ссылки) и просто скопировать на любой компьютер.

Ссылки

Скачать PsTool в составе PsExec с этого сайта.

PsExec.exe скачать с сайта Microsoft

Windows SysInternals

Ранее статья была опубликована в журнале Windows IT Pro RE в №4 за 2009 год. 

Василий Гусев 

http://xaegr.wordpress.com/

Настройка синхронизации времени в домене Active Directory

Топология синхронизации времени среди участников Active Directory

Среди компьютеров, участвующих в Active Directory работает следующая схема синхронизация времени.

  • Контроллер корневого домена в лесу AD, которому принадлежит FSMО-роль эмулятора PDC (назовем его корневым PDC), является источником времени для всех остальных контроллеров этого домена.
  • Контроллеры дочерних доменов синхронизируют время с вышестоящих по топологии AD контроллеров домена.
  • Рядовые члены домена (сервера и рабочие станции) синхронизируют свое время с ближайшим к ним доступным контроллером домена, соблюдая топологию AD.

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

Синхронизация клиентов корневого PDC может осуществятся как с его внутренних часов, так и с внешнего источника. В первом случае сервер времени корневого PDC объявляет себя как «надежный» (reliable).

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

Конфигурация NTP-сервера на корневом PDC

Конфигурирование сервера времени (NTP-сервера) может осуществляться как с помощью утилиты командной строки w32tm, так и через реестр. Где возможно, я приведу оба варианта.

Включение синхронизации внутренних часов с внешним источником

  • [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters]
    “Type”=”NTP”

  • w32tm /config /syncfromflags:manual

Объявление NTP-сервера в качестве надежного

  • [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig]
    “AnnounceFlags”=dword:0000000a

  • w32tm /config /reliable:yes

Включение NTP-сервера

NTP-сервер по умолчанию включен на всех контроллерах домена, однако его можно включить и на рядовых серверах.

  • [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer]
    “Enabled”=dword:00000001

Задание списка внешних источников для синхронизации

  • [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters]
    “NtpServer”=”time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8”

  • w32tm /config /manualpeerlist:”time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8″

Флаг 0x8 на конце означает, что синхронизация должна происходить в режиме клиента NTP, через предложенные этим сервером интервалы времени. Для того, чтобы задать свой интервал синхронизации, необходимо использовать флаг 0x1. Все остальные флаги описаны в библиотеке TechNet.

Задание интервала синхронизации с внешним источником

Время в секундах между опросами источника синхронизации, по умолчанию 900с = 15мин. Работает только для источников, помеченных флагом 0x1.

  • [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient]
    “SpecialPollInterval”=dword:00000384

Установка минимальной положительной и отрицательной коррекции

Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig]
“MaxPosPhaseCorrection”=dword:FFFFFFFF
“MaxNegPhaseCorrection”=dword:FFFFFFFF

Все необходимое одной строкой

w32tm.exe /config /manualpeerlist:”time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 pool.ntp.org,0x8″ /syncfromflags:manual /reliable:yes /update

Полезные команды

  • Применение внесенных в конфигурацию службы времени изменений
    w32tm /config /update
  • Принудительная синхронизация от источника
    w32tm /resync /rediscover
  • Отображение состояния синхронизации контроллеров домена в домене
    w32tm /monitor
  • Отображение текущих источников синхронизации и их статуса
    w32tm /query /peers

Особенности виртуализированных контроллеров домена

Контроллеры домена, работающие в виртуализированной среде, требуют к себе особенного отношения.

  • Средства синхронизации времени виртуальной машины и хостовой ОС должны быть выключены. Во всех адекватных системах виртуализации (Microsoft, vmWare и т. д.) присутствуют компоненты интеграции гостевой ОС с хостовой, которые значительно повышают производительность и управляемость гостевой системой. Среди этих компонентов всегда есть средство синхронизации времени гостевой ОС с хостовой, которое очень полезно для рядовых машин, но противопоказано для контроллеров домена. Потому как в этом случае весьма вероятен цикл, при котором контроллер домена и хостовая ОС будут синхронизировать друг друга. Последствия печальны.
  • Для корневого PDC синхронизация с внешним источником должна быть настроена всегда. В виртуальной среде часы не настолько точны как в физической, потому как виртуальная машина работает с виртуальным процессором и прерываниями, для которых характерно как замедление, так и ускорение относительно «обычной» частоты. Если не настроить синхронизацию виртуализированного корневого PDC с внешним источником, время на всех компьютерах предприятия может убегать/отставать на пару часов в сутки. Не трудно представить неприятности, которые может принести такое поведение.

Источник: http://argon

Как установить Active directory в windows server 2008R2

Когда вы уже поставили windows server 2008R2 все обновили настроили статику назвали свой компьютер как нужно (об этом тут), у меня это будет для примера DC, то можно приступать.

Открываем Диспетчер сервера, это централизованный и краеугольный инструмент Microsoft по добавлению ролей, но все тоже самое можно сделать и через powershell. Нажимаем добавить роли

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

Выбираем Доменные службы Active Directory.

Дальше мастер скажет, что нужно поставить компоненты NET.Framework 3.5.1, жмем добавить

Жмем далее.

В следующем окне нас подробно познакомят c Active directory, жмем ДАлее

Жмем установить. Процесс быстрый буквально пару минут.

Видим, что Active Directory установилась успешно

После установки в диспетчере ролей мы видим ошибку и ее текст, мол введите в пуске dcpromo.exe и будут вам счастье, так и поступим.

Открываем пуск и пишем dcpromo.exe

Дальше нас поприветствует мастер установки Active directory. Жмахаем Далее.

Щелкаем далее.

Создаем новый домен в новом лесу.

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

Начнется проверка уникальности имени нового леса.

Выбираем режим работы домена windows server 2003 , я выбрал этот режим для того чтобы показать как поднимается режим работы, вы же выбирайте сразу 2008R2, чтобы получить все его преимущества о которых позже.

Выбираем уровень леса тоже windows server 2003 по тем же причинам.

Дальше нам скажут, что вам еще поставят DNS сервер. Жмем далее.

Спросят про делегирование, жмем ДА.

В следующем окне, нам покажут и предложат папки размещения Базы данных.

Попросят придумать и ввести пароль Администратор, пароль должен включать в себя большую букву, маленькую и цифру и быть не менее 6 символов.

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

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

Иногда может получиться что сеть видится не как доменная, а как неопознанная. Это происходит когда в настройках ip прописывается днс сервер вида 127.0.0.1. Его нужно сменить на нормальный вида 10.10.10.1.

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

На этом роль можно считать полностью развернутой, простейшие вещи с Active directory мы разберем в следующей статье:) Так же если вы изначально задали неправильное имя контроллера домена и хотите его сменить то посмотрите Как переименовать контроллер домена в Windows Server 2008 R2-2 часть через утилиту netdom

Материал сайта Pyatilistnik.org