PowerShell solution lets you control ABE on multiple shares
| Downloads |
|---|
| 129552.zip |
Access-based enumeration (ABE) is a feature that first appeared in Windows Server 2003 SP1. In short, it prevents users from seeing files and directories they can't access when they navigate to a share. When ABE is disabled, users can see the existence of all files and folders when they open a share. If they try to open an item they don't have permission to access, they get an “access denied” message. In contrast, if ABE is enabled, the user simply doesn’t see the files and folders they don't have permission to access.
ABE is disabled by default in Windows Server 2003 but enabled by default in Windows Server 2008 and later. You can change that default using the Abecmd.exe command-line tool. However, this tool is missing an important functionality, so I created an alternative solution.
Abecmd.exe’s Downfall
Abecmd.exe is part of the Windows Server 2003 Access-Based Enumeration package. This Windows installer package also includes a white paper on ABE and an ABE GUI for Windows 2003. (Windows 2008 and later includes a built-in GUI that’s part of the Share and Storage Management console.)
With Abecmd.exe, you can easily enable or disable ABE on a computer’s shares on a case-by-case or global basis. However, you can’t view the ABE status for multiple shares on a computer at the same time. I’m perplexed as to why this functionality wasn’t included in the command-line tool. With this functionality, you could easily manage ABE on multiple shares because you could use a script to check each share’s status and change it if needed.
So, I created a solution that lets you easily manage ABE on multiple shares and even multiple computers. This solution consists of three components:
- ShareABE.exe. This command-line program can detect whether ABE is enabled, enable ABE, and disable ABE on a single share. When detecting ABE, it returns an exit code of 1 if ABE is enabled or 0 if it’s disabled. When you use it to enable or disable ABE, it returns an exit code of 0 to indicate success. Any other number indicates a failure. If a failure occurs, ShareABE.exe returns a real error code. For example, it returns an error code of 53 when the network path wasn’t found, 2310 when the share didn’t exist, and 5 when access was denied. You can use the Net Helpmsg command to check the error code.
- Get-ABE.ps1. This PowerShell script uses ShareABE.exe to detect whether ABE is enabled for one or more shares on one or more computers.
- Set-ABE.ps1. This PowerShell script uses ShareABE.exe to enable or disable ABE for one or more shares on one or more computers.
You must be a member of the Administrators group to change the ABE state. If you’re changing the ABE state for shares on the local computer, you must launch PowerShell or Cmd.exe under elevated permissions. To change ABE on a share for a remote computer, you must be a member of the Administrators group on the remote computer; elevation doesn’t matter in this case. If you aren’t a member of the Administrators group on the computer hosting the share, ShareABE.exe returns an error code of 5.
You can download this solution by going to the top of this page and click the Download the Code Here button. Besides including the two scripts and the command-line program, the 129552.zip file includes the program’s Free Pascal source code in case you’re curious.
The solution works on Server 2003 and later, and unlike Abecmd.exe, it even works on Windows 7. I have used the solution with NTFS shares. If you want to use ABE on DFS shares, see “How to implement Windows Server 2003 Access-Based Enumeration in a DFS Environment” or “How to enable Access-Based Enumeration for a Distributed File System (DFS) Share in Windows Server 2008".
To use the solution, copy ShareABE.exe, Get-ABE.ps1, and Set-ABE.ps1 to a directory in your Path (e.g., SystemRoot\system32). The scripts require PowerShell 2.0. If necessary, adjust the PowerShell script policy to enable scripts to run. I recommend using the RemoteSigned policy. (If you’re unfamiliar with the PowerShell policies, see "Running PowerShell Scripts Is as Easy as 1-2-3".)





