Get-LocalUser Does Not List AD Computernames from Domain Controller

The Get-LocalUser cmdlet queries only the local Security Accounts Manager (SAM) database on the specific machine where it runs. It does not query Active Directory or remote domain controllers by design, which is why AD computer accounts and domain users are invisible to this command. To list domain objects, you must use Active Directory-specific PowerShell modules instead.

Understanding Local vs. Domain Context

To troubleshoot why Get-LocalUser fails to show domain data, it is essential to understand the fundamental difference between local and domain identity management. Windows operating systems maintain two distinct repositories for user and group identities: the local SAM database and the Active Directory database. The Get-LocalUser cmdlet is strictly bound to the former. When you execute this command on a workstation or server joined to a domain, it retrieves only the accounts that were created directly on that specific machine using local credentials. This limitation is intentional for security and performance reasons. Querying the local SAM is extremely fast because it involves reading a local file system structure. In contrast, querying Active Directory requires network communication with one or more domain controllers, authentication against Kerberos tickets, and parsing of LDAP results. If Get-LocalUser attempted to fetch domain objects every time it was called, it would significantly degrade system performance and create unnecessary network traffic. Therefore, the absence of AD computer names from its output is not a bug; it is the expected behavior. If you are looking for a quick diagnostic step to verify this, simply run Get-LocalUser | Select-Object Name. You will see a short list of local administrators, standard users, and system accounts like Guest or Administrator. None of these entries will correspond to the hundreds or thousands of computer accounts stored in your Active Directory Users and Computers console. This confirms that the cmdlet is working correctly but looking in the wrong place for your desired data. For those managing automated tasks, it is worth noting that scripts relying on Get-LocalUser to inventory domain assets will always return empty sets regarding AD objects. This can lead to confusion when troubleshooting why a script seems to ignore domain resources. Similar issues often arise when scheduling scripts, as seen in our guide on Powershell Script Not Running in Task Scheduler, where context mismatches cause unexpected failures. Ensuring your script uses the correct module for the target scope prevents these logical errors.

Correct Cmdlets for Active Directory Objects

To retrieve Active Directory computer names and other domain objects, you must utilize the Active Directory module for PowerShell. This module provides cmdlets that interact directly with the directory service via LDAP. The primary cmdlet for listing computer accounts is Get-ADComputer. Unlike Get-LocalUser, this command requires connectivity to a domain controller and appropriate permissions within the domain. The basic syntax for retrieving all computer accounts in the current domain is straightforward. You can run Get-ADComputer -Filter * to fetch every object classified as a computer. This command returns properties such as Name, DistinguishedName, Enabled, and LastLogonDate. By default, Get-ADComputer returns a limited set of properties to optimize performance. If you need additional details, such as the IP address or operating system version, you must explicitly request them using the -Properties parameter. For example, to get a clean list of just the names and enabled status, you might use:

Get-ADComputer -Filter * -Properties Enabled | Select-Object Name, Enabled

This approach gives you full visibility into the domain's computer inventory. You can also filter by specific criteria, such as finding computers that have not logged on in over 90 days, which is useful for cleanup operations. Understanding how to negate options in these filters can be tricky, so refer to our article on How can I directly negate options in PowerShell? if you encounter syntax issues with complex queries.

Handling Remote and Cross-Domain Queries

In larger environments, you may need to query domain controllers from remote machines or across different domains. The Get-ADComputer cmdlet supports the -Server parameter to specify a particular domain controller. This is useful for directing queries to a specific site or for troubleshooting replication issues. Additionally, if you are working in a multi-domain forest, you can use the -DomainController parameter to ensure consistency. When running these commands remotely, ensure that the RSAT (Remote Server Administration Tools) feature is installed on the client machine. Without RSAT, the Active Directory module will not be available, and attempts to call Get-ADComputer will fail with a "command not found" error. This is a common pitfall for new administrators who assume PowerShell core includes all legacy modules by default. Another consideration is the execution context. If you are running a script under a service account or scheduled task, verify that the account has read permissions on the Active Directory partition. Insufficient permissions can result in empty results or access denied errors, even if the syntax is correct. For more insights on securing and automating these scripts, check our resource on Stopping a Windows 11 PowerShell Script Task in Task Scheduler.

Frequently Asked Questions

Why does Get-LocalUser return an error on a domain controller?

Get-LocalUser works on domain controllers but still only lists local accounts. It does not throw an error unless you provide invalid parameters. The confusion usually stems from expecting domain objects, which it cannot display. Use Get-ADUser or Get-ADComputer for domain-level queries.

Can I use Get-LocalUser to find domain admins?

No, Get-LocalUser cannot identify domain groups or members. It only sees local groups like "Administrators" on the local machine. To find domain administrators, you must query the Active Directory module using Get-ADGroupMember on the "Domain Admins" group.

What happens if I run Get-ADComputer without internet access?

Get-ADComputer relies on internal DNS and Active Directory services, not general internet access. However, it requires network connectivity to a domain controller. If the DC is unreachable due to firewall rules or network isolation, the command will timeout or fail with an RPC error.

Is there a way to list both local and AD users in one command?

No single native cmdlet combines both sources because they reside in completely separate databases. You must run Get-LocalUser and Get-ADUser separately and then merge the results manually in PowerShell using Select-Object and array manipulation.

Do I need RSAT to run Get-ADComputer on Windows 10?

Yes, modern versions of Windows 10 and 11 do not include the Active Directory module by default. You must install the RSAT tools via Settings > Apps > Optional Features or using PowerShell with Add-WindowsCapability.