Today I'll show you a neat little solution I deployed in an environment recently as a solution for a centralized Start Menu based on Active Directory group membership. It enables users to see and use networked applications they have rights to from their Start Menu and it enables administrators to easily allow and disallow users access to these applications.
In the past on this blog I showed you cool usages of Active Directory within real-life deployments. These usages can be considered Active Directory Real Life tricks and the Unsolicited Remote Assistance post I wrote two years ago can be considered as a first post of the kind.
In an environment with a lot of applications running from the network, the customer was looking for a centralized Start Menu, where individual people could be given access to these applications based on Active Directory group membership.
I installed a new Windows Server 2003 server with Service Pack 2. I installed it with a 20GB C:\ drive and made the rest of the RAID container a D:\ drive. I made it a member of the Active Directory domain. I installed the i386 Access-based Enumeration package and created shares called Shared and Apps for two folders with the same name on the data volume of the server. I created a subfolder called StartMenu in the Shared share and enabled Access-based Enumeration on both folders.
I made an inventory of all the applications in use on the network and gathered installation and licensing instructions per application. I then went forward with installing all applications in the Apps share and placing shortcuts to these programs in the StartMenu folder on the Shared share. I also copied the Start Menu items I found useful from the default Start Menu to this folder. (Accessories, etc)
After installing each application and making a shortcut for it I made three Global Security groups in Active Directory:
Data group ServerName Apps Application Name CH
Membership of this group provides Modify NTFS rights to the folder where an application is stored.
Data group ServerName Apps Application Name RX
Membership of this group provides Read and Execute NTFS rights to the folder where an application is stored.
Application group Application Name
Membership of this group provides access to the shortcut to an application from the shared Start Menu.
I then changed the Security on the subfolder on the Apps share to exclude anything but the default Administrators, OWNER and CREATOR rights and add both data groups with their appropriate rights. I also touched the Security on the subfolder in the StartMenu folder in the Shared share to exclude anyone but the default Administrators, OWNER and CREATOR rights and added the Application group with Read and Execute rights. Depending on the application I then added the Application Group as a member of one of the data groups.
The last step is to configure a policy for an Organizational Unit with useraccounts you want to enjoy the centralized Start Menu. The policy settings I applied were:
- Remove common program groups from Start Menu
Located in the User Configuration\Administrative Templates\Start Menu & Taskbar portion of a default Group Policy Object, this policy setting disables the usage of the shortcuts in the Start Menu located in C:\Documents and Settings\All Users.
- Start Menu
Located in the User Configuration\Windows\Settings\Folder Redirection portion of a default Group Policy Object, this policy settings when double clicked allows to redirect the Start Menu for useraccounts in any of the three ways:
- Basic – Redirect everyone's folder to the same location
- Advanced – Specify locations for various user groups
- Not configured
I enabled the first Group Policy setting and configured the second setting to do a basic redirection to redirect to the following location: \\ServerName\Shared\StartMenu.
As an alternative to the centralized Start Menu implementation above you may opt to:
- use a login script in which you create shortcuts
Administrators would have no overview of shortcuts and their validity and it's hard to troubleshoot without scripting knowledge.
- use a login script or Group Policy Preferences to copy shortcuts
By placing the shortcuts on a central location (for instance the NETLOGON folder) you can copy them using a login script or Group Policy Preferences. When users find the location of these shortcut however they can access them and find out properties on the applications.
- Make shortcuts hidden when they don't apply
You can place all shortcuts for all applications in your image or in a redirected folder and use a login script to hide shortcuts. This approach uses the principle of the Start Menu not displaying hidden shortcuts. I classify this approach as security by obscurity, because when you right-click on the Start Menu button you can still use the explorer to browse through the items. Depending on your Folder Options you can see hidden items. It's a cosmetic solution only.
- Redirect Start Menus per Organizational Unit (OU)
In some environments departments and their respective Organizational Unit (OU) can be used to redirect the Start Menu per department. From my experience however a 100% one-on-one relationship never exists. Some people belong to multiple departments, sometimes people need to access applications used primarily in other departments, people move between departments, but still need their applications, etc.
When your challenge is to implement a centralized Start Menu solution take a good look at the following technologies:
- Windows Server 2003
- Active Directory
- Access-based Enumeration
- Folder redirection
They can be combined in a very useful way!
Windows Server 2003 Access-based Enumeration
Recommendations for Folder Redirection
MSTerminalServices.org: How To Configure Folder Redirection
Profile and Folder Redirection In Windows Server 2003
Folder Redirection feature in Windows