Как в powershell изменить пользователя ad set-aduser
Содержание:
Установка модуля Active Directory для Windows PowerShell
По умолчанию в системе установлены не все модули Windows PowerShell, некоторые из них добавляются во время установки соответствующей роли или компонента. Например, если Ваш сервер не является контроллером домена, соответствующего модуля PowerShell (RSAT-AD-PowerShell) для администрирования Active Directory в нем нет, т.е. использовать командлеты PowerShell для управления AD Вы не сможете. Однако Вы можете установить модуль PowerShell для работы с Active Directory. Именно это мы сейчас и рассмотрим, при этом я покажу два варианта установки модуля RSAT-AD-PowerShell — это с помощью «Мастера добавления ролей и компонентов», т.е. используя графический интерфейс и, конечно же, с помощью Windows PowerShell.
Процесс установки модуля Active Directory для Windows PowerShell такой же, как и установка остальных компонентов и средств удаленного администрирования в Windows Server 2016, поэтому если Вы умеете устанавливать роли или компоненты сервера, то с установкой RSAT-AD-PowerShell Вы легко справитесь.
Запускаем «Диспетчер серверов» и нажимаем «Управление ->Добавить роли или компоненты».
На первом окне можем сразу нажать «Далее».
Шаг 3
Далее выбираем тип установки, мы хотим установить компонент, поэтому выбираем первый пункт «Установка ролей или компонентов», жмем «Далее».
Затем выбираем сервер, на который будут установлены роли и компоненты, жмем «Далее».
Шаг 5
На этом шаге нам предлагают выбрать роли для установки, а так как мы не собираемся устанавливать роли, сразу жмем «Далее».
Шаг 6
На шаге выбора компонентов мы ищем пункт «Средства удаленного администрирования сервера -> Средства администрирования ролей -> Средства AD DS и AD LDS -> Модуль Active Directory для Windows PowerShell» и отмечаем его галочкой, жмем «Далее».
Шаг 7
Проверяем выбор компонентов и жмем «Установить».
Начнется процесс установки модуля Active Directory для Windows PowerShell.
Он будет завершен, когда мы увидим сообщение «Установка выполнена на …», нажимаем «Закрыть».
Установка модуля RSAT-AD-PowerShell с помощью PowerShell
Если Вы не хотите щелкать мышкой по окошкам мастера, то Вы можете легко выполнить процедуру установки компонентов с помощью нашего любимого Windows PowerShell, кстати, таким способом это делается, на мой взгляд, гораздо проще и быстрей.
Для установки модуля Active Directory для Windows PowerShell запустите оболочку PowerShell и выполните следующие команды (вместо командлета Add-WindowsFeature можно использовать Install-WindowsFeature).
Import-Module ServerManager Add-WindowsFeature -Name "RSAT-AD-PowerShell" –IncludeAllSubFeature
Смотрим список командлетов PowerShell для работы с Active Directory
Для того чтобы проверить, что у нас установился необходимый модуль PowerShell давайте, выполним команды, которые покажут нам количество командлетов для работы с Active Directory и сам список этих командлетов.
Чтобы узнать, сколько у нас командлетов для администрирования Active Directory пишем вот такую команду
Get-Command -Module ActiveDirectory | Measure-Object
А для того чтобы посмотреть полный перечень командлетов пишем следующую команду, т.е. результат работы Get-Command мы не передаем по конвейеру командлету Measure-Object.
Get-Command -Module ActiveDirectory
Мы видим, что нас появилось 147 командлетов для работы с Active Directory, которые мы теперь можем использовать для администрирования AD.
На этом все, надеюсь, материал был Вам полезен, удачи!
Нравится1Не нравится
Работа с журналами сообщений
После настройки систем и сервисов роль админа сводится к наблюдению за их правильной работой и отслеживанию текущих параметров. В PS заложен целый ряд *-Eventlog командлетов, позволяющих легко считать записи в журнале событий как на локальной, так и удаленной системе. Данные легко сортируются и отбираются по нужным критериям. Например, чтобы вывести только последние события из журнала безопасности на двух компьютерах, используем параметр «Nevest» с указанием числового аргумента:
Теперь выведем только события, имеющие определенный статус:
А вот так можно собрать все данные об успешной регистрации пользователей (события с EventID=4624):
Как вывести все установленные роли и компоненты Windows Server?
Чтобы вывести список всех доступных ролей и компонентов Windows Server используется командлет . Если выполнить его без параметров, появится информация обо всех компонентах.
Как вы видите, отображается название компонента (Display Name), его системное имя (Name) и состояние (Install State: Installed, Available или Removed). Список ролей и компонентов представляет собой дерево со вложенными ролями, которое напоминает то, которые вы видите при установке ролей через графический Server Manager. Для установки и удаления ролей и компонентов через PowerShell, вам нужно знать их системное имя, которое содержится в столбце Name.
Совет. Если роль или функция находится в состоянии Removed, значит ее установочные файлы удалены из локального репозитария системы (уменьшение размера папки WinSxS) и вы не сможете установить эту роль.
Роли и компоненты удаляются из образа так:
Чтобы установить удаленную роль, воспользуйтесь командлетом:
(понадобится доступ в Интернет)
Либо вы можете восстановить компоненты их дистрибутива с вашей версией Windows Server:
Вы можете вывести список установленных компонентов сервера:
Судя по скриншоту, данный сервер используется как файловый сервер (роли FileAndStorage-Services, Storage-Services). Большинство оставшихся компонентов используются для управления и мониторинга сервера.
Если вы не знаете точно имя роли, можно использовать знаки подстановки. Например, чтобы проверить какие из web компонентов роли IIS установлены, выполните (немного сократим синтаксис):
Вы можете получить список установленных компонентов на удаленном Windows Server:
Судя по установленным ролям Print-Services и Print-Server, этот сервер используется в качестве сервера печати.
Вы можете использовать командлет Get-WindowsFeature для поиска серверов в домене, на которых установлена определенная роль. Вы можете искать на серверах в определенном OU Active Directory с помощью командлета Get-ADComputer из модуля ActiveDirectory for PowerShell, или по указанному списку серверов (). Например, нам нужно найти все файловые сервера c ролью FileAndStorage-Services в указанном контейнере AD (я использую редактор PS — Visual Studio Code)
В результате у нас появился список серверов, на которых установлена данная роль.
Parsing dsquery.exe Output
If, for some reason, you’re stuck parsing dsquery.exe output, here’s just a random example of me retrieving server names for everything under a certain OU (made a bit anonymous: OU=Servere,OU=Boxes,dc=ad,dc=company,dc=no / ad.company.no/Boxes/Servere):
PS C:\> $dsq = dsquery computer -limit 0
PS C:\> $dsq
"SERVERDCNAME,OU=Domain Controllers,DC=ad,DC=company,DC=no"
PS C:\> $SrvStrings = $dsq | where { $_ -like '*OU=Servere,OU=Boxes,dc=ad,dc=company,dc=no*' }
PS C:\> $SrvStrings
"CN=X2-443-OS0020,OU=Servere,OU=Boxes,DC=ad,DC=company,DC=no"
# You can use "OU=" (or whatever is appropriate) rather than "\w{1,2}=" -
# it's an attempt at being flexible - and to allow for commas in CNs
PS C:\> $Servers = $SrvStrings | %{ if ($_ -match '^"CN=(.+?),\s*\w{1,2}=') { $matches } }
PS C:\> $Servers
X2-443-OS0020
PS C:\>
BITS: требования к ОС и версии PowerShell
Протокол BITS впервые был представлен еще в Windows XP, для управления заданиями BITS в которой можно было использовать утилиту bitsadmin.exe. Утилита все еще поддерживается, однако считается устаревшей. Для управления заданиями BITS предпочтительно использовать специальные командлеты PowerShell.
Для работы по рассматриваемому сценарию нам потребуется ОС не ниже Windows Vista или Windows Server 2008, и PowerShell не ниже версии 2.0. Современные версии Windows 10 и Windows Server 2016 / 2012 R2 протокол BITS полностью поддерживают.
Совет. Возможно использовать и Windows Server 2003. В этом случае придется установить специальное обновлений KB 923845 и PowerShell V2.0.
Поддержка BITS требуется как на стороне клиента, так и сервера.
The ADManager Plus way
In organizations, it’s a rarity that we come across such simple straightforward scenarios like the ones listed above. Real-life use cases involve a multitude of things. Often, administrators need to program extensively in PowerShell, research syntax, and iterate multiple times for correctness; all these tasks can turn into a nightmare for administrators. PowerShell scripts for Active Directory sure is empowering, but at what cost? Often, the cost of extensive scripting is prolonged work hours.
The biggest limitation to PowerShell reports is that they aren’t actionable. AD admins need to get work done from a single window without having to toggle between multiple consoles.
Here’s how you can save yourself from the burden and monotony of creating, testing and executing unending lines of PowerShell scripts to generate reports on AD user accounts.
User reports from ADManager Plus give complete insight into the Windows Active Directory domain. ADManager Plus makes generating reports a breeze, even for organizations with multiple domains, organizational units (OUs) and numerous users.
ADManager Plus offers a comprehensive list of pre-built Active Directory user reports, for efficient, trouble-free management and reporting on user accounts. Other key advantages include:
- Fully web-based, intuitive UI that lets you customize required reporting fields
- Option to schedule reports and automate report generation
- OU specific report generation
- Export reports in various formats: CSV, Excel, PDF, HTML, and CSVDE
- Compliance-based reports (SOX, HIPAA, etc)
User reports are important to get vital information, including which users have remote user logon permissions or are mailbox enabled, or have OMA/OWA enabled. ADManager Plus features an array of schedulable reports on user objects, categorized into General User Reports, User Account Status Reports, User Logon Reports, and Nested Users Reports.
User Logon reports offers a peek into the user logon history or information. AD admins can generate reports on inactive users (users who have not logged on for a certain period), users who have logged on recently, users who have never logged on, and enabled users. The logon hour based report shows the allowed and denied logon hours or time frame for users.
Admins can decipher fine-grained group membership information from the Nested Users Report. These reports display detailed information about users in a particular group and the multiple groups a user belongs to.
Actionable User Reports
Say you are planning to delete inactive accounts from a specific department. If you are planning to get this done using native Active Directory tools and PowerShell, this could take you a day or more. After multiple iterations, you might be able to finally script what you need.
On the other hand, ADManager Plus gives you the liberty of carrying out the same task with just a few clicks. Run the Inactive users report, specify the desired OU using the smart filter, and delete inactive users all from the same screen.
Thus ADManager Plus easily addresses the AD reporting challenges caused by PowerShell.
ADManager Plus can help you meet your . Generate a whole set of must-have reports and use them as a key resource when facing . You can find a list of Active Directory reports that are relevant to SOX compliance in the SOX Compliance section.
Featured links
- Active Directory Logon Reports
- Active Directory Password Reports
- Active Directory Computer Reports
- Active Directory Group Reports
- Active Directory OU Reports
- Active Directory Reports Scheduling
- Active Directory Security Reports
- Active Directory Exchange Reports
- Active Directory GPO Reports
- Active Directory NTFS Reports
- Active Directory Policy Reports
- Active Directory Reports for SOX Compliance
Using DirectorySearcher/AdsiSearcher
If this is the absolute best way of doing this, I do not know, but it seems quite likely that it’s no crime against humanity given my experimentation and inspection of the (computer) objects returned by DirectoryServices.DirectorySearcher.
Here’s the output from my home lab’s AD (these indeed are all the computers in the Active Directory):
PS C:\prog\PowerShell> .\Get-Computers-DS.ps1 2008R2ESXI2 2008R2ESXI SRV2003R2ESXI SIEMENS WIN7ESXI WINXPESXI WIN2K VISTA64ESXI SERVER2003 XPTANKET SERVER2008 esxi WINXPSSD
Basically with DirectoryServices.DirectorySearcher, the real magic is in the LDAP query, and you might have to inspect returned objects to see what their properties are. The LDAP query is specified via the Filter property of the directory searcher object, and in this case it is «(objectClass=Computer)«.
Also be aware that the property you index is case-sensitive, and that they’re all listed as lower-case when you look at the returned System.DirectoryServices.ResultPropertyCollection object.
Here is a ready-made script that’ll just dump every single computer from the AD of the first available domain controller, using Windows’ method for detecting domain controllers:
#Set-StrictMode -Version Latest
#$ErrorActionPreference = 'Stop'
$DirSearcher = New-Object System.DirectoryServices.DirectorySearcher('')
$DirSearcher.Filter = '(objectClass=Computer)'
# These properties are part of a DirectoryServices.ResultPropertyCollection
# NB! These properties need to be all lowercase!
$DirSearcher.FindAll().GetEnumerator() | ForEach-Object { $_.Properties.name }
I should also mention that there’s a type accelerator in PowerShell v2 (I don’t know about v1.x), which allows you to skip a few steps like this (notice the two quotes after the type accelerator):
PS C:\> $DirSearcher = '' PS C:\>
Targeting A Specific OU With ADSI/LDAP/DirectorySearcher
To target a specific OU/container, change the following line in the script above (this example is valid in my home lab):
$DirSearcher = New-Object DirectoryServices.DirectorySearcher('LDAP://OU=Clients,OU=Hjemme,DC=svendsen,DC=local')
So here I prepended «LDAP://» to the distinguished name of the OU, enclosed it in a string and cast it to an ADSI object, which was then used to to create a System.DirectoryServices.DirectorySearcher object. This targets the OU svendsen.local/Hjemme/Clients. Using «System.» first when declaring the object type is optional.
If you were to use the type accelerator, it would look like this:
$DirSearcher = 'LDAP://OU=Clients,OU=Hjemme,DC=svendsen,DC=local'
Цигиль-цигиль
Теперь, собственно, как и при помощи чего проверять эффективность написанного скрипта. Разработчики Microsoft не стали усложнять нам жизнь, и в PS из коробки включен специальный командлет Measure-Command, позволяющий замерить время выполнения команды или скрипта.
Из командной строки PS реализован прямой доступ к командам оболочки CMD, объектам COM, WMI и .NET, поэтому очень удобно определять разницу во времени исполнения самых разных утилит. Просто вводим запрос в строке приглашения. Для примера произведем два замера:
Отсюда видно, что нэйтивные команды в PS выполняются значительно быстрее.
