I've been doing MMC AD extensions, for a while. Learning, and using trial and error.

Before you ask, why I do this? I like to do things that not often is done! So, at my 10th implementation of a varation on 'some address book' or 'shopping basket' through ASPX or whatever technology for some customer (no offense, thanks to those customers for hiring me) I get bored.

So I choose a new product, that I soon will release.

There are some reaons why this is hard. MS, are you listening? :)

1) How to deal with testing and active directory?

Just a few years ago, it was nearly impossible for developers, to develop extensions for the Active Directory snapin where modifying the domain schema was involved.

You first had to opt for a OID for your company. That's not to hard. But then, you start testing your code. And you find you can't undo schema changes, so easily your changes so you start enumerating IDs and names for each test-run, your test environment becomes messed with unrelated stuff and objects that are 'no longer valid'.

Through virtual server 2003, SP1, I find myself a lot happier, because you just can undo a virtual disk modification, and your active directory schema is back to before your test. But still, a reboot is involved. Maybe some admin-guru, could tell me that restoring the active directory is not so difficult at all. Anyway, a reboot is involved there as well!

Microsoft, here speaks one of your customers (echo... :) )! Please have us edit/delete our own attributeSchema and Classschema objects. I'm sure this request has been done a lot of times, but no, for some reasons, this seems too difficult to implement?

So why do I spent so much lines about testing your snapins and schema changes on AD? Because, I lost many hours, and even a full day, because the schema got once out of sync. And to get all DC's in sync again, you'd go back to an old copy of the virtual windows image but I had to rebuild a lot of things before this image was up and running.
If Windows would allow us to do something like in SQL server, 'ad hoc' updates (including deletes) on system tables for advanced and skilled users, it would be a good thing.

2) The second problem, is how to develop good code while the docs lack. The MSDN sdk folks, wrote us a lot of samples, sure they work, but they all are MFC and some samples, even were prepared and never updated for us, during the time Windows 2000 was designed. So the samples, use pure C++, they mess with messages and hooks(sorry, no offense to anyone) and if each template would need it's own static hooking code, I would find myself helpless because my C++ power is not that great.

Personally, I choose not to develop using MFC code. I like ATL and WTL and ..., a lot on this subject has been written by others.

And where is a good example of the implementation of the  CSnapInPropertyPageImpl  class (atlsnapin.h) or IDsAdminNewObjExt?
And why does geticon return no icon when I validly reference an iconresource in my dll? There are more issues, but I won't bother you about them.

So I decided, to refine sample code integrate it in my dialogs, and clean up the samples to get a minimized working sample. The final result is really cute, and understandable. I will publish such a sample soon.

3) When you read the MSDN docs, you soon realize, that the docs contain lots of bugs and unclear statements. You have to find it all yourselves. Don't get confused by the MMC 1.2 and 2.0 docs, because you'll discover, that the snapin for Active Directory, really uses some other interfaces and not the fancy new stuff that the MMC 1.2 and higher use.

Microsoft soon will release the SDK for MMC 3.0. I've said this before, but this is just a managed implementation of the unmanaged one. A lot of Pinvoke plumbing would not be needed that you -would- need, if you would do the same using C# and the well known MMC managed open source API on sourceforge.net.
Still, I choose not to go for this solution which is beta 2 for now. Because that beta, assumes your are doing MMC 1.2 and higher, while the Active Directory snapin does depend on some other interfaces and ADSI apis. There you are busy writing and testing your own P-invokes and you also should tell your clients, to install the NET framework version 2. I wonder, I have no hard numbers, how much clients would be willing to do this.

4) The fourth challence, and this is a very subjective one, that is, how good are your C++ and windows UI skills? You need to know about internationalization, ADSI, Win32, NT Security, a lot of C++ dialog stuff, debugging technics and keep your code generic so it would run on all domains.

5) The fifth challence, is really a huge lack in the AD Snapin design as follows: As you can see, when you open the Active Directory snapin, all property sheets, are having a standard UI and tabs. If you develop your own extension, only a -few dialogs- are to your exposal, such as the DirectoryObject picker. But what about the security tab? 'Member of' and 'members' tabs? What about the 'Security' and 'Object' tab? Yes, by some non-published snapin IDs you can have some of them. But MS did not document this, so MS could break this feature in future releases. Be prepared, to build those tab all -again- yourselves!

 

Which language? C++ or C#?

If you look at the skill requirements a developer needs to cover, you'll conclude that you could use both languages for snapins for Active Directory, but that C++ still has more power to windows. And that C# is not really the -rad- tool you would expect to implement all fancy features.

Personally, I'm not a windows UI guy at all, so all the API's related to DCs and HWNDs were historically based on some Microsoft Visual Basic 6 API hacking :), so you'll understand, that's not too hot for a real C++ freak :)

At a conclusion, I can say that, after all, developing extensions for the AD is really not that difficult. It is only that wide spread on technologies, and software and documentation borders refrain you from quickly getting some result (before you give up).

If the Active Directory and AD Snapin team would follow the IIS path, (b.t.w I am an IIS MVP :) ), they will find a lot more 3rd party extensions making tools. And more businesses will go for Microsoft Active Directory instead of Sun, Novell etc. because of those nifty features and lots of snap ins they have at 'their fingertips'.

Why IIS? Because personally, I find IIS the most open server platform and best documented and supported on Windows there is.