Windows NameSpace and ABE

Giving a bit of a face list to our File server we have decided to proceed with a Windows DFS Namespace.  One big reason for moving this direction rather than the traditional file shares is quite simply being able to present data in once space and still having the flexibility to distribute the data across several servers.  In this process we have elected to migrate our existing shared network drive to a new location so when we migrate each department we can talk thru storage best practices.  One major reason was to offload our Media storage to a separate server so there was less pain felt when mondo files were being archived on the servers from our Media folks.

We added DFS (2003R2) to our existing file server and configured it to host the name space.  In both 2003 and 2008 server this is a role that needs to be added for the service to be available.  A second server was named our media server and also was added to the namespace.  Here is a good article on the step by step to adding a Domain Namespace.

One item that wasn’t clear to me was DFS Creates a share that houses the links to your data when you add a server to the namespace the local location of the DFS Links SHOULDN’T be the location where your data exists.  The DFS Roots are simply a file structure that tells the namespace how to work and where to point… Don’t make the DFSRoots Shared folder your data location.

Now users can go do \\domain.org\Namespace and access their departments files even if those files live across two separate file servers. 

All was quickly working well except for one of our requirements for this project, enabling Access-Based Enumeration, Microsoft’s name for security trimming on a file server.  While the permissions were working and users couldn’t get to another departments data they could still see the other departments…. and learning from experience if people don’t have access to data then things are better if they can’t see that data is there…  So then started a quest to enable ABE on the namespace. 

We converted our new File server to Server 2008 since we read that DFS Namespaces support ABE.  The problem is the fine print, for ABE to run on a 2008 Namespace you have to have your domain functional level at 2008 to enable a 2008 Namespace.  We aren’t quite there yet since one of our DCs is still a 2003 DC so the quest continued.

Next we found this support document which explains the DFSRoots for each link in the namespace have to have the same ACL as the ACL on the target. 

From KB 907458

If the ACL on the DFS link is not set to match the ACL on the target, the following conditions may be true:

• If the ACL on the link is more restrictive than the ACL on the target, the link will not be displayed. However, if the user knows the name of the link, the user can locate the appropriate path and see the contents of the target.
• If the ACL on the link is less restrictive than the ACL on the target, the link is displayed. However, when the user locates the link, the user sees an “Access Denied” message.

One item wasn’t clear from the support document on our first attempt was fact that the default permissions on the DFS Roots directory overrides ADE and displays all directories to all users, even if they don’t have the rights to actually open those directories. This is because by default on the server ’servername\users’ (the local users account on the server) has read permissions on all directories in the DFSRoots directory.

Example:
Department 1
Has data living on Server 1 X:\NameSpaceData\Department1 with Permissions Domain\Dept1: Full Control
Department 2
Has data living on Server 2 X:\NameSpaceData\Department2 with Permissions Domain\Dept1: Full Control

We wanted to present both as directories in \\domain\Namespace\ as
\\domain\Namespace\Department1 and \\domain\Namespace\Department2

Both appear in the namespace when ABE is enabled since the links to both directories (located in X:\DFSRoots\NameSpaceName) have rights for the local ‘users’.

Its good to now even though they could see the other departments the users without permissions to the other department get “Access Denied”

For our installation the DFSRoots were located e:\DFSRoots\NameSpaceName and the Data was located on the server on E:\NameSpaceData.

We had to set the Permissions on e:\DFSRoots\NameSpaceName:
Administrator Full Control (This folder, subfolders and files)
Local\Users: Read, List (this folder only, NOT This folder, subfolders and files)

Then use the CACLS utility to add read permissions to each department’s group to the appropriate link by navigating the command line to the e:\DFSRoots\NameSpaceName and running the following command:
cacls”DepartmentLinkDirectory” /E /G “Domain\SecurityGroup”:R

This sets the ACL on the Department’s DFS Link to give the domain security group read permissions.  
The Switches
- /E edits the existing permissions vs. replaces the permission on the Link
- /G Grants Specified User access Rights and R is Read.
To set multiple groups:
cacls “DepartmentLinkDirectory” /E /G “Domain\SecurityGroup”:R /G “Domain\SecurityGroup2″:R

After the ACLs are set for the Target Data and the Links when you browse the namespace the user sees the department directories that are appropriate for that user.

Great Support and a Couple Bugs

 Earlier this week we were putting the final touches on deploying Facility Scheduler to all our users.  This is an exciting event since we have been in the development stages of FS for over 18 months with the team at ACS and it was finally time to make it available to all our staff. 

We elected to make this available to our staff the same way we have made ACS Desktop available, with a terminal server. 
We followed the steps to install Facility Scheduler on the terminal server several weeks ago and it worked with no problems.  Since we installed the application there had been an update, which we ran under the admin user account on the server.  Jeremie made the application avaiable to all users so we decided to check that the application would work for all users.  It was a good thing we checked since the application for each user went into a loop trying to update the application even though it was already updated.  A quick call to support pointed us to the Program Manager for Facility Scheduler, Darci Shelley.  We work with Darci often and participates in our confrence calls that happen every other week with ACS so we were confident Darci could help us fix the problem… except she wasn’t on call and I didn’t have her contact info… so Jeremie and I sent Dean Lisenby a tweet for some help. We explained to Dean our problem of the next day’s go live demo for all staff and quickly Dean responded and had contacted Darci at home and told us she was online and available to assist us once her kids were in bed.  Once Darci was online she helped us work thru our issues with the application and troubleshooting our problem for over an hour all while at home.  While working with Darci we identified a bug in the current version of Facility Scheduler running on a Terminal Server that will have to be updated before the next release.  So two thumbs up to Darci for providing top notch support even when she didn’t “have to”.

Instructions for deploying Facility Scheduler on a terminal server:
1) Install ACS Facility Scheduler as an administrator.
2) Once the installation is complete, go to C:\Documents and Settings\Administrator\Local Settings\Application Data.
3) Copy the ACSTechnologies folder.
4) For each user on the Terminal Server, paste the folder in the following location: C:\Documents and Settings\username\Local Settings\Application Data.
5) To place a shortcut on the Terminal Server desktop for all users, go to Start->Programs->ACS Technologies, right click on ACS Facility Scheduler, and select Copy.
6) Go to C:\Documents and Settings\All Users\Desktop, go to Edit, and select Paste.
Now when any user logs into Terminal Services, they will have an icon on their desktop to launch ACS Facility Scheduler. The first time they open Facility Scheduler, it will show the admin user name, but once they have entered their user name for Facility Scheduler, this name will be saved and will show for each subsequent login.

Optional Alternative when installing Facility Scheduler:
You can copy the ACSTechnologies folder to the C:\Documents and Settings\Default User\Local Settings\Application Data.  Then any new user profile created will include the Facility Scheduler application.  This worked for us since we had to do some account clean up to get rid of old Terminal Server profiles.  We deleted all TS profiles except the admin user’s profile and had users login “fresh”.  When they logged in the users had the icons and access to the application.

Now a FYI on a couple ACS bugs we have found this week
Bug #1
The update feature for Facility Scheduler application doesn’t work for any users other than the admin user who’s login you used to install the application.   The temporary work around until the fix is released is to follow the above procedure again and overwrite the ACSTechnologies Folder for all users.
Bug #2
When updating to 10.0.12 from a previous version the Icons for Ministry Scheduler and other ACS modules vanish for all users including the local administrator.  After running the 10.0.12 update our users noticed that random ACS icons that were on their desktops or in the start menu were gone.  After a call to the MegaChurch support group we found out that support has noted this is a know issue that they though was resolved, but obviously hadn’t been fixed.   The solution is to go into ACS Utility Manager by going to Start>All Programs> ACS> ACS Tools> Utility Manager and then selecting Rebuild Program Group.  This utility recreates all the default shortcuts in the start menu and desktop for the all user profiles.
 
And lastly just while I am on the topic of ACS “issues” I am left wondering the status of some past “Big Ticket” issues (I realize they aren’t small tasks and I don’t expect solutions overnight…but how are the projects coming along?):

1) When will ACS Desktop Suite allow a username to be more than 8 characters?  The 8 character limit was something I raised concern about over a year ago (11/5/07) but this issue still isn’t resolved.  If we had the ablity to use more than 8 characters we could use the Windows login integration in ACS but since almost 100% of our userIDs are more than 8 positions we cant… When will this be resolved?  Or better yet when will the ACS Desktop suite integrate to AD for authentication and setting rights thru AD groups?

2)  When will the Exchange/GAL Sync tool be ready for beta testing?  Rumors were that it would be ready for the ACS convention in the Spring… now its November…

3)  What is the status of the ACS Outlook Plugin and Vista Gadget  to search ACS records from Outlook and the Vista Gadget tool bar?  Rumors are that the Outlook Plugin is ready now and the gadgets are comming soon… how do we find out about this stuff?

4)  What is the status of the Silverlight Screen Display Beta that was expected to be released by mid October?

5)  When will ACS technical services have a blog or some vehicle to communicate these types of bugs to the users rather than the current scenario where customers have to “find” these bugs before ACS support says “Oh, yea we knew about that”.  I know this type of info isn’t appropriate for the corperate blog, but there shold be some way that customers that want this information to be able to subscribe to this via a RSS feed.