Two years review, look back with Active Directory Administrative Center

Common Tasks
Search
  • Advanced search options...
Tags
Archives
Archives
MSDN Blogs > Li Xiong > Two years review, look back with Active Directory Administrative Center

Two years review, look back with Active Directory Administrative Center

Rate This
20 Aug 2011 11:18 AM
  • Comments 3

Windows Server 2008 R2 has been released about 2 years now. It’s time to review my previous project which ships with Win2k8R2.

The project was ADAC -- Active Directory Administrative Center. The main purpose for ADAC was to replace the old MMC snapin – ADUC. ADAC was designed in the following background:

  1. Windows Server 2008 R2 introduced the new Active Directory management interface which was based on powershell. New features may not be convenient to use with old LDAP/ADSI style interface. A new UI management tool was required to reflect this change.
  2. The old MMC snapin was first created with WinNT4. There was little change in the past decade. There were many new UI concepts which can help the management tasks, but were difficult to apply to the old MMC.

In this background, we wanted the new UI tool (ADAC) to be able to:

  1. Fully replace the old ADUC MMC snapin, if the environment supports ADAC. (The environment condition is included here because ADAC requires enabling Win2k8R2 features). There should be no main stream task that ADAC does not support but ADUC does. When the admin is familiar with ADAC, she should forget about ADUC.
  2. Bring new UI concepts to admin to simplify the management works. For common tasks, if old ADUC requires 10 mouse clicks, ADAC should simplify it to less than 5 clicks.
  3. Survive for the next decades as the main management UI to support new Windows Server Active Directory features.

We created the following specified features in ADAC:

  1. Apply new UI concepts, like Win7 style navigation bar, no model dialog, quick task in main page and pin/unpin features.
  2. In property page, use sections to replace tabs. Using tab means you cannot see everything together. Using section brings great usability improvements.
  3. Make the creation UI and view UI the same. ADUC uses wizard style UI for creation and property page style for view. By putting the two UI the same in ADAC, users can work on the same information in the same place.
  4. Make important information easy to touch, like the last-logon-time and when-created property. In ADUC, the admin needs to turn on the advanced feature and get these properties from the attribute editor.
  5. Make the UI customizable by allowing the user to pin and unpin the favorites containers in the left navigation bar.
  6. Add muti-domain and muti-forest support. Admin can add many domains in different forests into the single tool, and manage them cross domains.
  7. Design the query feature in the scenario based way. Try to hide the technique details from the end user. The query in ADUC simplify maps the LDAP attribute query concept into UI. We redesigned that into scenarios like “query for user who is going to expire in X days”. We also added the feature to show the LDAP expression in which the scenario maps to.

From the feedback in communities, these improvements were proved to be very successful. People really like the new UI.

However, we also had several features that we planned, but did not add into the new tool. The main reason was resource constrains. R2 release was a short release after Windows Server 2008. The release timeframe was mainly aimed with a small set of new features.  As ADAC was created from the scratch, the timeframe was not perfect for us to balance the catch-up and new features. So the first priority for us was to make sure no function regression from ADUC, and new features came after that. It turned out that we did not have enough time to make ADAC perfect. Specifically, we observed the following items, but did not have time to fix them:

  1. The new Active Directory features in Windows Server 2008 R2 were not supported. Like the Service Account, and the most important one: recycle bin.
  2. The UI performances in some areas were worse than ADUC, like the startup time and batch operations. Using WPF was one reason, and the other reason was about the new API interface. The new API was web service based. It required more round trips so the performance was worse when batch jobs were requested.
  3. The query feature may not be accurate because the domain policy was not taken into account. If we take domain policy settings, the complexity would increase dramatically in the product. We decided to drop it and document the special cases. (ADUC did not have this feature too).
  4. We did not provide SDK or any way to let user extend ADAC. This was a regression from ADUC. In ADUC, the user could create COM based property sheet, and register it under display-specifier. ADUC loads the user defined sheet when property opens. In ADAC, we did not provide a way to let user add new UI sections. To compensate that, we only load the ADUC sheets into a separate section, which should include the user defined sheet.
  5. Several small function regressions from ADUC. Like ADAC does not support creating new user by copy-paste from an existing one. When setting the home folder of the customer, ADAC does not help check and set the folder permission automatically.

From the community feedbacks, some items really caused troubles. This article is a good place for ADAC features and feedbacks (in the comment section). And this link shows the question raised against ADAC in MSDN forum.

About me:

I was one of the testers for ADAC. I owned the following areas in ADAC:

  1. User management.
  2. Query.
  3. UI automation framework.

The whole ADAC team (dev, test and pm) was in China. I worked on ADAC form day-1, until it shipped. After that, the product was transferred back to Redmond.

, , ,
Leave a Comment
  • Please add 4 and 4 and type the answer here:
  • Post
Comments
  • 21 Aug 2011 7:00 AM

    "When setting the home folder of the customer, ADAC does not help check and set the folder permission automatically."

    I think this is a much bigger flaw than let on.  Creating users is an administrative task, whereas creating folders and setting permissions on them is more of a technical task.  When you ask administrative-type staff to work on technical items, such as folder permissions, you tend to have some mistakes.  Having that automated through ADAC should be a priority.

  • 21 Aug 2011 9:49 AM

    Thanks Arposh for this information. I remember we used another way to avoid the security issue. The home folder is not created every time when a new user gets created. This is always a configuration step which should be triggered manually. ADUC helps the folder creation and permission setting. ADAC does not create the folder automatically. Instead, it asks the administrator to create the folder and sets the permissions. Otherwise it should throw an error to indicate this.

  • Parrotlover77
    16 Feb 2012 3:10 PM

    I really REALLY need custom filters.  The ones that are included are amazing and it's not like ADUC can do any of that, but it's too limiting.  Let me type in some raw LDAP and save it, please!

    Also, in ADAC, it says "Group" in the type column for all group types (Global, Domain Local, and Universal).  This is a show-stopped for me.  We are one of the few shops that apparently actually follows AGDLP and frequently my junior admins create DL groups as G groups incorrectly, which can cause problems down the road.  In ADUC, I just sort by type and it segregates the group types.  I can easily see if any of the groups in the OU where we keep DL groups are typed as G and then easily convert them to DL.  In ADAC, I have to look at each group individually, which is pretty crappy.  

    I look forward to the day when ADAC completely replaces ADUC.  It's a good starting point and awesome at the more mundane tasks (SEARCH, password reset, etc.) but it's not quite a complete ADUC replacement yet...

Page 1 of 1 (3 items)