This post provides an overview of Access Based Enumeration on Windows Server 2003, some limitations, advantages and information on controlling ABE in an Windows MSCS environment. Advantages: Notes: Controlling ABE in a cluster environment Other solutions considered CPU usage and end-user response times Access Based Enumeration whitepaper: Access Based Enumeration: Enabling ABE with DFS: Implementing home folders on a cluster server: Windows Server 2008 failover clustering: Scripting Entry Points: Create a generic application resource type: Generic script cluster resource:
With a standard Windows file server, for users to map the share and view the directories they have access to, all users require the list directory right at the root of the share. The client would then see all directories, and receive access denied errors if they try to navigate to any sub-folder without NTFS access.
To provide access control similar to Netware, Microsoft have introduced Access Based Enumeration in Windows Server 2003 SP1. This provides a method of displaying only files and folders that a user has access to, rather than displaying all objects in the tree.
The best description I can give is that ABE will hide what you don't have access to, as opposed to ensuring you can see what you do have access to. For example, if you have .\A .\A\B and .\A\B\C, and you have access to C but you don't have access to B, C will be hidden through the explorer GUI.
While this allows for a seamless migration from Netware-based file servers, there are several potential limitations:
Access Based Enumeration is controlled through SMB share settings for each instance of the lanmanserver service – each physical node in the cluster. These settings are not cluster-aware, and will be lost during a cluster fail-over operation.
To ensure that ABE follows virtual cluster nodes during failovers, a generic cluster application can be created, running the abecmd.exe to verify that ABE is enabled after failover. The cluster application will be dependant on the file share resource, run for each file share.
Resource Type - Generic Cluster Application
Resource Name - <share> ABE
Description - <share> ABE
Dependencies - <share>
Command - cmd.exe /k abecmd.exe /enable <share>
Current Directory - %SystemRoot%
Interact with Desktop - De-selected
Other solutions I've considered for controlling ABE in a Windows file and print cluster environment included:
The biggest concern is response times, as the Microsoft whitepaper on ABE determines that with 150,000 files, the operation of ‘reading shared directories’ increase from 12 seconds to up to 58 seconds. However, there is no detail on the type of test performed or the hardware used.
On a 2003 cluster with several million files and more than a terabyte of data, no performance impacts have been noticed when accessing folder structures through shares with ABE enabled.
Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.
Controlling ABE in a cluster environment
Other solutions considered
CPU usage and end-user response times
Access Based Enumeration whitepaper:
Access Based Enumeration:
Enabling ABE with DFS:
Implementing home folders on a cluster server:
Windows Server 2008 failover clustering:
Scripting Entry Points:
Create a generic application resource type:
Generic script cluster resource: