The term 'get-ADComputer' is not recognized as the name of a cmdlet
I’m watching this tutorial (https://www.youtube.com/watch?v=UVUd9_k9C6A&t=1640s) about PowerShell. At 2:57:50, the instructor runs Get-ADComputer . But when I try to run the same command, I get the following error message:
How can I make it work?
Know someone who can answer? Share a link to this question via email, Twitter, or Facebook.
-
The Overflow Blog
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.3.11.43304
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Не распознано как имя командлета Что делать
ПК
PowerShell может быть пугающим инструментом. Иногда что-то может пойти не так, а когда это происходит, сообщения об ошибках часто невероятно загадочны и далеко не всегда полезны. Термин ‘term is not recognized as the name of a cmdlet’ — это, пожалуй, самая распространенная ошибка, которую пользователи получают в PowerShell, и она легко может привести к куче потраченных впустую часов, заполненных неудачными попытками выяснить, в чем причина.
Знание того, где искать решение — это, пожалуй, самый ценный инструмент в арсенале любого программиста, и ключевыми навыками здесь являются технические знания и исследовательское мастерство. Вот несколько идей о том, где искать решение, когда всплывает эта ужасная ошибка.
Ошибки правописания
Ошибки кода часто возникают в правописании, не потому что вы не знаете, как правильно написать команду, а обычно потому, что иногда нужно работать быстро, чтобы закончить задачу до срока. Ошибка в написании имени команды решается просто: проверьте правописание.
Конечно, это может показаться не слишком полезным, но знание того, что всегда следует начинать процесс устранения неполадок именно с этого, может оказать огромную помощь. Не начинайте поиск неисправностей с поиска ошибок пути и отсутствующих модулей, потому что все может свестись к обычной орфографической ошибке.
Ошибки пути
Использование неправильного пути — более распространенная ошибка, чем вы думаете. Например, если вы попытаетесь запустить скрипт, перейдя в папку scripts и запустив его, он сработает. В противном случае, если вы попытаетесь выполнить его из корневой папки, может возникнуть ошибка командлета.
Аналогично, вы можете получить ошибку «не распознано имя командлета», если вызовете внешнюю функцию, не указав предварительно путь. Если вы получаете ту же ошибку, даже если функция существует в том же сценарии, скорее всего, причина в ошибке написания или пути. Избежать этой проблемы можно, сделав функцию глобальной (добавьте слово ‘global’ к имени функции).
Пропущенные модули
Если ни один из двух предыдущих вариантов возникновения ошибки не подходит к вашей проблеме (но, пожалуйста, тщательно проверьте наличие вышеперечисленных причин), сообщение об ошибке команды может появиться из-за того, что не загружен определенный модуль. Модули — это наборы команд, которые расширяют функциональность PowerShell. Обычно команда в модуле связана с определенным продуктом, ролью Windows или функцией. Например, модуль содержит команды, связанные с Hyper-V, Microsoft Azure или Exchange Server.
В любом случае, запуск неродной команды PowerShell будет невозможен без загрузки модуля, определяющего эту команду. В Windows есть множество модулей, которые содержат команды PowerShell для нестандартных функций Windows, таких как упомянутые выше. Хотя новые версии PowerShell загружают эти модули автоматически, старые версии требуют загрузки необходимых модулей вручную.
Другие ошибки
Хотя три вышеупомянутые ошибки являются наиболее распространенными причинами ошибок командлета, существует также множество других. Неправильные диапазоны функций тоже входят в их число, но многие из этих ошибок, как правило, специфичны для конкретного компьютера. Возможно, вам поможет поиск решения с помощью команды «[введите точную ошибку]» в Google. Скорее всего, другие люди сталкиваются с такой же ошибкой, и решение может уже существовать.
Когда речь идет о PowerShell, никогда не следует воздерживаться от обращения к Google, даже если речь идет о простой орфографической ошибке.
PowerShell и Windows
Пожалуй, самое важное, что следует отметить здесь, это быть осторожным . Если вы используете PowerShell на домашнем компьютере, худшим сценарием будет восстановление или перестройка системы. Компьютеры компании, с другой стороны, обычно отличаются, поэтому с ними лучше быть осторожнее.

Какова ваша худшая история ужасов, связанных с командной строкой? В чем причина ошибки? Как вы ее исправили? Поделитесь своими мыслями и вопросами в разделе комментариев ниже.
Пытаемся автоматизировать процессы с помощью Powershell
Подскажите, пожалуйста, вы пробовали протестировать использование зашифрованного пароля на других ПК или тестили только на своей машине? Насколько я помню, я когда-то пытался сделать подобное и удивился, почему не работает на других компьютерах. Потом, когда стал разбираться, то оказалось, что если попробовать зашифровать пароль так, как указано в статье, то дешифровка возможна только под аккаунтом пользователя, под которым осуществляется шифрование. Для того, чтобы использовать зашифрованный пароль из файла на другой машине/под другим пользователям, то нужно указывать AES-ключ через параметр -Key.
Может я устарел, но синтаксис powershell для меня ужасен, как язык инопланетян. Использую для автоматизации JScript и VBScript, иногда BAT файлы. Не вижу ни одной причины для изучения powershell
Обожаю PowerShell за возможность работать с .net библиотеками (включая поддержку работы с приватными полями и методами)
https://blog.netspi.com/using-powershell-and-reflection-api-to-invoke-methods-from-net-assemblies/
Это ооочень расширяет возможности.
По теме обсуждения PowerShell, вчера была интересная презентация кросс-платформенного PowerShell 7 на базе .Net Core.
Очень любопытно: создавали ВМ-ки, KeyVault для хранения credentials, онлайновый Storage и переброска файлов в него из локалки.
Кстати, PS скрипты прекрасно редактируются и дебажатся из бесплатной кроссплатформенной VS Code.
Кто это пытается использовать очень быстро понимает, что:
1. Нужно проверять доступность, иначе ждем пока не отвалится по таймауту.
2. Использовать Jobы, потому что есть тысяча причин по которой запрос повиснет мертвым грузом, плюс распараллеливание процесса.
3. Нужно проверять что за DNSHostName скрывается именно тот хост, который нужен, ибо DNS может указывать на IP который занял уже другой хост при использовании DHCP, либо при не настроенной очистке DNS записей.
ну и из общего совета: иногда быстрее и надежнее сделать через schtasks c последовательным созданием/выполнением/удалением задания. Менее удобно в части получения результатов выполнения команды, но не зависит от WinRM и версии винды и повершелки.
Get adcomputer не распознано как имя командлета
Командлет Get-ADObject может не запускаться в Windows Server 2008 R2 , несмотря на то, что в документации Microsoft написано, что он присутсвует в данном дистрибутиве Windows.
При запуске Get-ADObject появляется ошибка:
Имя "Get-ADObject" не распознано как имя командлета, функции, файла скрипта или выполняемой программы. Проверьте правильность написания имени, а также наличие и правильность пути, после чего повторите попытку.
+ CategoryInfo : ObjectNotFound: (Get-ADObject:String) [], CommandNotFoundException
На самом деле этот командлет есть, и располагается он в инструменте "Active Directory Administration with Windows PowerShell" ( https://technet.microsoft.com/ru-RU/library/dd378937.aspx ). По опыту, данный инструмент нормально работает как минимум в Power Shell v.2.
Чтобы командлет стал доступен, необходимо выполнить команду импорта модуля:
После этой команды все командлеты для управления доменом станут доступны. Доступны они будут в текущем сеансе Windows Power Shell.