List Network Shares and Mapped Drives on a Windows Workstation with PowerShell

When a user reports a network share that appears unfamiliar — for example a drive letter pointing to an unexpected server, NAS, or IP address — the fastest way to diagnose it is directly on the affected workstation with PowerShell. Windows exposes two distinct concepts that are often confused:

• Local SMB shares — folders the workstation itself is publishing to the network (enumerated with Get-SmbShare).
• Mapped network drives — remote shares the workstation has connected to, typically shown as drive letters like Z: (enumerated with Get-SmbMapping, Get-PSDrive, or net use).

This recipe walks through both sides so you can quickly determine whether a suspicious share is hosted on the workstation, mapped from a legitimate file server, or coming from an unexpected host (rogue device, stale GPO mapping, shadow IT NAS, or lateral-movement indicator).

After completing this recipe you will have:

• A complete list of SMB shares published by the workstation, including hidden administrative shares.
• A complete list of mapped network drives with their drive letter, remote UNC path, and connection status.
• The resolved IP address behind any hostname-based mapping, so you can confirm whether the share is coming from your primary file server or an unexpected host.
• A reusable PowerShell script (Get-WorkstationShareInventory.ps1) that captures all of the above in one pass and can be run locally or against a remote computer via Invoke-Command.

Things to watch out for:

• User context matters. Mapped drives are per-user. If you run PowerShell as Administrator (elevated), you will not see drives mapped in the standard user session. Run as the affected user, or inspect the user's HKCU:\Network registry hive.
• Remote execution requires WinRM. Invoke-Command needs PowerShell remoting enabled on the target. RMM-delivered execution is usually simpler in the field.
• Don't blindly remove unknown shares. Hidden admin shares (C$, ADMIN$, IPC$) are created by Windows and required by many management tools. Deleting them will break backups, RMM, and AD management.
• A share pointing to an unexpected IP is a potential security signal. If you find a mapping to a host that is not documented (not your file server, not a sanctioned NAS), treat it as a possible indicator of compromise or shadow IT until proven otherwise — capture the output before disconnecting.
• Legacy OS caveat. Get-SmbShare / Get-SmbMapping require PowerShell 3.0+ and the SmbShare module (Windows 8 / Server 2012 and later). On older systems, fall back to Get-WmiObject Win32_Share and net use.