Windows всегда ассоциировалась с графическим интерфейсом, и долгое время win-админы считали благом отсутствие необходимости запоминать консольные команды. Но с увеличением возможностей использование GUI уже не казалось таким простым. Настройки приходится искать среди многочисленных вложенных диалоговых окон. Попытки все оптимизировать, менять местами и добавлять новые визарды только усиливали путаницу. Появился Server Core, вместо одного сервера приходится управлять уже десятками, нередко выполняя однотипные операции. В итоге админы вернулись к консоли.

 

Базовые операции

На самом деле развитие консольных утилит все это время тоже не стояло на месте. Список команд не сильно изменился: net, netdom, whoami, скрипт активации slmgr.vbs, программа управления службами sc, сетевые утилиты для настройки и диагностики ipconfig, netsh, netstat/nbtstat, arp/getmac, ping, tracert, nslookup и многие другие. После анонса PowerShell появилась официальная информация, что привычные утилиты развиваться больше не будут, на смену им придут командлеты.

Такая судьба постигла консольный вариант диспетчера сервера ServerManagerCmd.exe и утилиту установки компонентов OCSetup.exe, которые, появившись в Win2008, пропали уже в Win2012. Теперь для установки компонентов из консоли используются командлеты Install-WindowsFeature и Add-WindowsFeature. Консольные утилиты по-прежнему привычнее, чем командлеты, но результат, полученный при помощи PowerShell, позволяет выбирать больше параметров, фильтровать их, обрабатывать в скриптах. А главное — теперь нужные данные можно получить не только с локальной, но и с удаленной системы, и в удобном виде. Все это говорит о том, что нужно уже быть готовым к переменам.

В последних редакциях ОС ярлык для запуска cmd.exe спрятали подальше в меню. Правда, и особой необходимости в его использовании нет, так как все традиционные консольные команды можно вводить непосредственно в консоли PowerShell (хотя есть и нюансы), обладающей несомненным преимуществом — автодополнением (по Tab). Постепенно на замену старым добрым утилитам появляются соответствующие командлеты, которые выдают аналогичный результат. Попробуем разобраться со всеми операциями по порядку, рассмотрим типичные задачи с использованием консольных команд и PowerShell.

Проверяем состояние сетевых интерфейсов при помощи PowerShell
Проверяем состояние сетевых интерфейсов при помощи PowerShell

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

> netdom renamecomputer Win01 /newname:SRV01
> netdom join SRV01 /Domain:example.org /OU:ou=ouname,dc=example,dc=org /UserD:DomainAdmin /PasswordD:password

Те же операции при помощи PowerShell выглядят даже понятней.

PS> Rename-Computer –NewName SRV01
PS> Add-Computer -domainname example.org -OUPath "OU=ouname=example,DC=org"

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

> Sc config winrm start= auto
> Net start winrm

А вот командлетов для управления запуском сервисов несколько: Get-Service, Start-Service, Set-Service, Stop-Service, Resume-Service. Их назначение говорит само за себя.

PS> Set-Service -name winrm -status Running -StartupType Automatic
 

Sconfig.cmd

Запоминать команды админы Win не очень любят, в системе можно найти удобную оболочку для большинства консольных команд Sconfig.cmd. Изначально она разрабатывалась для Server Core, но в Win2012R2 доступна и в режиме полной установки сервера. Sconfig не требует знания всех ключей и позволяет, перемещаясь по 15 пунктам, быстро произвести основные установки или выполнить некоторые команды: добавить сервер в домен или рабочую группу, сменить имя компьютера, добавить локального администратора, настроить удаленное управление через WinRM и удаленный рабочий стол, настроить сеть, Windows Update, время и дату, перезагрузить и выключить компьютер. Нужно помнить, что скрипт использует стандартные консольные утилиты и если они пропадут в следующем релизе, то, скорее всего, не будет и Sconfig.

Sconfig.cmd упрощает работу ленивым админам
Sconfig.cmd упрощает работу ленивым админам

А вот с монтированием сетевых дисков не все так просто. Традиционно эта операция выполняется при помощи net use:

> net use E: \\SRV01\users /Persistent:Yes

Его аналогом считается командлет New-PSDrive (от PowerShell Drive), но здесь есть проблема, которая многим неочевидна и порождает кучу вопросов.

PS> New-PSDrive –Name E –PSProvider FileSystem –Root \\SRV01\users

При помощи New-PSDrive создается так называемый диск PowerShell, который доступен только в текущем сеансе консоли и только в PowerShell. То есть при помощи проводника, WMI, средствами .NET Framework, net use подключиться к такому диску нельзя. Это неочевидно, но в документации это явно прописано. Просто ее мало кто читает.

Чтобы постоянно использовать диск, необходимо экспортировать сеанс, в котором добавлен диск, или сохранить команду New-PSDrive в профиле PowerShell, или изначально использовать командлет New-Object:

PS> $net = New-Object -ComObject WScript.Network
PS> $net.MapNetworkDrive("E:", "\\SRV01\users")

И только в PowerShell 4.0 появился параметр –Persist, позволяющий монтировать PS-диски постоянно.

PS> New-PSDrive –Name E –PSProvider FileSystem –Root \\SRV01\users –Persist

Для работы с дисками и разделами консоль Windows предлагает две утилиты: diskpart и fsutil. Они не очень удобны и информативны, а поэтому малопопулярны и их часто заменяют альтернативными разработками. Получим статистику по разделу.

> fsutil fsinfo statistics C:

Команда «Get-Command disk» выдаст несколько командлетов, но в нашем примере они не очень помогают, и, чтобы получить информацию о свободном месте, по-прежнему приходится обращаться к WMI:

PS> Get-WmiObject Win32_LogicalDisk -ComputerName SRV01 -Filter "DeviceID='C:'" | Select-Object Size,FreeSpace

Доступ к файлам в Win традиционно регулируется двумя утилитами — takeown и icacls (есть еще и cacls, но она признана устаревшей), вполне справляющимися со своими обязанностями. Например, чтобы сделать текущую учетную запись (должна входить в группу админов) владельцем каталога, достаточно ввести:

> takeown /f c:\temp пуе

Утилита icacls позволяет управлять списками контроля доступа. Для примера, сохраним ACL в файл и восстановим его:

> icacls c:\temp\* /save acl.txt /T
> icacls c:\temp\ /restore acl.txt 

Та же операция при помощи PowerShell выглядит проще:

PS> Get-Acl c:\temp | Set-Acl -Path c:\temp
 

Управление BYOD при помощи PowerShell

Одна из самых больших проблем, с которыми сталкиваешься при работе с моделью BYOD, — отсутствие управления устройствами пользователей. В Win2012R2 этим заправляет Device Registration Service (DRS), при регистрации на устройство устанавливается сертификат, а в AD создается новый объект устройства.

Этот объект устанавливает связь между пользователем и устройством, создавая нечто вроде двухфакторной аутентификации. Пользователи получают доступ к корпоративным ресурсам, которые были недоступны, когда они работали за пределами доменной сети. Для работы потребуется роль Active Directory Federation Services (AD FS) и собственно служба DRS (устанавливается при помощи командлета Install-AdfsFarm). Теперь инициализируем службу и приступаем к регистрации устройств пользователей.

PS> Initialize-ADDeviceRegistration -ServiceAccountName example\adfsfarm
PS> Enable-AdfsDeviceRegistration

В консоли AD FS Management переходим к Authentication Policies, выбираем Edit Global Primary Authentication и активируем Enable Device Authentication. Теперь, используя командлет Get-AdfsDeviceRegistration, можем просматривать и подтверждать устройства (подробнее).

Настройки сети

Комплект консольных сетевых утилит достаточно хорошо известен администраторам, ведь их приходится использовать довольно часто, как при установке, так и для диагностики. Настраивают сетевой интерфейс при помощи netsh interface. Для примера просмотрим список и для одного из доступных установим IP и DNS-сервер:

> netsh interface ipv4 show interfaces
> netsh interface ipv4 set address name="1" source=static address=192.168.1.10 mask=255.255.255.0 gateway=192.168.1.1.
> netsh interface ipv4 add dnsserver name="Local" address=8.8.8.8 index=1
Смотрим сетевые настройки
Смотрим сетевые настройки

Для установки и изменения параметров сетевого интерфейса при помощи PowerShell 3.0 и выше используются командлеты New-NetIPAddress и Set-NetIPAddress.

PS> Get-NetIPInterface
PS> Set-NetIPAddress –InterfaceAlias Ethernet –IPv4Address 192.168.1.10 –PrefixLength 24 –DefaultGateway 192.168.1.1
PS> Set-DNSClientServerAddress –InterfaceAlias Ethernet -ServerAddresses "192.168.1.10","8.8.8.8"

Причем New-NetIPAddress позволяет задавать несколько IP для одного интерфейса. Вместо InterfaceAlias можно использовать индекс InterfaceIndex, который легко узнать в выводе Get-NetIPInterface.

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

PS> Get-NetRoute
PS> New-NetRoute -DestinationPrefix "0.0.0.0/0" -NextHop "10.10.10.1" -InterfaceAlias Ethernet
Таблица маршрутизации, полученная при помощи route и Get-NetRoute
Таблица маршрутизации, полученная при помощи route и Get-NetRoute

Аналогом ping служат два командлета Test-Connection и Test-NetConnection (сокращенно tnc). Первый очень простой и напоминает обычный ping, второй позволяет проверить доступность определенного порта или системы с разных ПК. Например, посмотрим, на каких ПК в группе включен RDP, и проверим подключение к example.org с двух систем:

PS> Test-NetConnection -ComputerName example.org -source localhost, SRV02
PS> (Get-ADComputer -LDAPFilter "(name=office*)").DNSHostName | Test-NetConnection -Port 3389

Но иногда вместо одной команды придется запомнить несколько командлетов. Так, состояние сетевых интерфейсов традиционно можно узнать при помощи ipconfig. До Win2012/8, чтобы сделать то же самое при помощи PowerShell, приходилось обращаться непосредственно к WMI. Например, нам нужны МАС- и IP-адреса:

PS> Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=TRUE | Select MACAddress,IPAddress
 

Переменная patch

В качестве команд Win может принимать любой файл с расширением exe, bat, cmd, com, js, msc и vbs, который расположен в текущем каталоге или прописан в переменной PATH. Просмотреть значение PATH очень просто. Для этого вводим «echo %PATH%» или используем команду set (set > filename.txt). В консоли PowerShell — «echo $Env:PATH» или «Get-ChildItem Env:». Чтобы изменить, просто дописываем нужный каталог:

> set PATH=%PATH%;C:\example

или используем GUI (My Computer -> Свойства системы -> Дополнительно -> Переменные среды -> Path). Средствами PowerShell изменить значение можно, установив SetEnvironmentVariable:

PS> [environment]::SetEnvironmentVariable('path',"$env:Path;C:\example",'Machine')

И только в PowerShell 3.0 появился простой аналог ipconfig, точнее, несколько. Например, командлет Get-NetIPAddress выдает подробную информацию об интерфейсах, а Get-NetIPConfiguration (алиас gip) позволяет получить информацию о сетевых настройках: IP интерфейса, шлюза и DNS. Добавив дополнительные параметры, например –Detailed, получим больше данных.

Профильтровав их вывод, мы можем заменить «ARP –a» выводящую таблицу МАС-адресов и GETMAC — отображающую MAC-адреса сетевых адаптеров локального или удаленного компьютера. Есть уже и готовые скрипты. Например, PingMultipleServerWithTraceroute.ps1 (goo.gl/0iLeyg) позволяет проверить подключение к нескольким серверам и запустить аналог tracert к неответившим системам.

Управление WFAS

Настройка брандмауэра Windows в режиме повышенной безопасности WFAS (Windows Firewall with Advanced Security) традиционно производится при помощи netsh advfirewall, появившейся в ОС начиная с Win2k8/Vista и практически не изменившейся с тех пор. Контекст advfirewall позволяет использовать семь команд (export, import, dump, reset, set, show и help) и четыре субконтекста (consec, firewall, mainmode и monitor). Просмотреть подробности можно, использовав ключ help или '/?', да и в Сети доступно достаточное количество примеров. Например, команда set позволяет сконфигурировать профили, show — просмотреть состояние. Смотрим настройки по умолчанию, активируем профили и для Domain действием по умолчанию установим блокировку.

> netsh advfirewall show allprofiles
> netsh advfirewall set allprofiles state on
> netsh advfirewall set domainprofile firewallpolicy blockinbound

Официальная информация гласит, что в следующих релизах netsh может пропасть, а использовать следует командлеты PowerShell, позволяющие к тому же контролировать еще больше функций. Командлеты NetSecurity доступны только в PS 3.0, для их использования в Win2012/8 их необходимо импортировать Import-Module NetSecurity. При помощи Get-Command firewall получим список из 27 командлетов (полный список командлетов модуля — goo.gl/Aj9Mg4). Ситуацию упрощает то, что названия командлетов пересекаются с командами netsh.

Настройкой Windows Firewall можно управлять при помощи почти 30 командлетов
Настройкой Windows Firewall можно управлять при помощи почти 30 командлетов

Теперь тот же пример, но средствами PS:

PS> Get-NetFirewallProfile
PS> Set-NetFirewallProfile -All -Enabled True
PS> Set-NetFirewallProfile –Name Domain –DefaultInboundAction Block

Как видим, командлеты выглядят даже проще. Вместо параметра All можно указать на конкретный профиль: –Profile Domain,Public,Private.

Смотрим профили Windows Firewall
Смотрим профили Windows Firewall

Доступны и прочие функции. Например, можем исключить Ethernet-интерфейс из профиля Public.

PS> Set-NetFirewallProfile -name Public -DisabledInterfaceAliases Ethernet

Чтобы вернуть настройки в исходное состояние, достаточно вместо Ethernet установить NotConfigured. Дополнительные параметры командлета Set-NetFirewallProfile позволяют настроить журналирование, добавить IP, порт, протокол и многое другое. Все манипуляции с правилами производятся при помощи семи командлетов: New|Set|Copy|Enable|Disable|Remove|Rename-NetFirewallRule. Чтобы просмотреть установленные правила, используем командлет Get-NetFirewallRule, при помощи фильтров мы можем легко отобрать нужные. Например, блокирующие и все, что касается IE:

PS> Get-NetFirewallRule -Enabled true -Action block 
PS> Get-NetFirewallRule -DisplayName “*IE*”

Создадим правило, блокирующее исходящие соединения для IE в двух профилях.

PS> New-NetFirewallRule -Program “C:\Program Files\Internet Explorer\iexplore.exe” -Action Block -Profile Domain, Private -DisplayName “Block IE” -Description “Block IE” -Direction Outbound 

Теперь к правилу можем добавить протокол, порт и IP удаленной и локальной системы.

PS> Set-NetFirewallRule -DisplayName “Block IE” -Protocol TCP -RemotePort 80 -RemoteAddress “10.10.10.1-10.10.10.10” -LocalAddress “192.168.1.10”

При создании или изменении мы можем группировать правила, используя параметр –Group, и впоследствии управлять не одним правилом, а всеми входящими в группу, при помощи -DisplayGroup. Чтобы отключить правило, воспользуемся

PS> Disable-NetFirewallRule -DisplayName “Block IE”

Заключение

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

 

INFO

Список параметров командлета можно узнать при помощи Show-Command, например Show-Command Get-NetFirewallRule.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    8 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии