After reading this post at StackOverflow, I realized that I was probably wrong to think it was OK to directly access the registry keys that Windows uses to keep track of installed services. Though the names and locations of the keys probably won’t change any time soon, it’s always better to use a higher level of abstraction when dealing with Windows internals. In this case, WMI fits the bill very nicely.

I had not written any WMI-related code up til now, simply because I’ve always been able to find other methods to get the information I need. But after reading that post and knowing of a particular program of mine that does access the registry directly to determine the start mode for a service, I decided to re-write that code to use WMI via the System.Management namespace in the .NET framework.

I came across a couple of different C# samples on the web and was able to modify them to fit my needs. Below is a new class I created for service management that will hopefully grow over time.


My thanks go out to Mitchel Sellers for informing me that DotNetNuke has a bulk install feature. I had a need to modify an existing Windows service so it could silently update some DNN modules. I was able to make it work in this same service a couple years ago by modifying the DNN 4.3 source code to allow the main DotNetNuke.dll library to function outside of a web application (no easy feat, that). From there I could use the PaInstaller class to load a module. But then it wouldn’t work against 4.9.0 portals.

When I tried to do the same thing with the 4.9.0 source, it failed miserably. It just wouldn’t create an instance of SqlDataProvider, no matter how much I coaxed it. The better way was to have my service download the new module files (zips) to the install/module folder under the portal’s root, create an HttpWebRequest to http://mysite/install/install.aspx?mode=installresources, then parse the response to check for success.

The response parsing was easier than I thought it would be. I did the bulk update first using a web browser so I could see what I was dealing with. The HTML itself was nice in that it put non-blank space elements between each module name and result, so I could use Split() to break everything out. I ignored the first two elements of the resultant array since it contained all the unimportant stuff before the list of modules, then simply looped over the array and verified the word Success was in each even-numbered element, like so:

I’m not sure why I had never heard of this feature over the course of developing several custom DNN modules, even though I’ve spent untold hours sifting through the forums at dotnetnuke.com and the Internet at large for detailed information on the portal’s architecture. In any case, that was the one new thing I learned that day.


A recent project of mine required querying Active Directory for all the groups in which a given user is a member, or if there isn’t a domain then searching the local machine. It also had to return all groups defined in a given domain. In the course of putting the code together, I created a library for future projects that needed to perform such queries. I recently made a major improvement to the code that retrieves a user’s AD groups and thought it would be good to share what I have so far.

It’s based on some bits of code I found on the web. Initially GetADGroupMembership would only return the first-level Active Directory groups the user was in, but that’s no good if the user is in a group that is in another group that is in yet another group that’s the one you really care about. So I added some recursion to bring up the entire group chain. It seems to perform well enough with our domain, which admittedly doesn’t have a great deal of nesting.

Update: this library has grown and improved quite a bit over time, and I recently converted it to C# and posted it on CodePlex.