[EDIT: See the Drupal handbook for the current PDF]

This year has not gone as I had expected for a variety of reasons, but that's all right.

Long term sustainable documentation with Drupal is complex. Drupal core moves and changes in ways that have unpredictable effects on documentation. Modules get absorbed into others, some removed, technologies added, behavior changed. Adding on the additional explosive growth of the contributed modules it's mind boggling. How to structure documentation in a way that people can have defined targets for what 'must' be updated vs random one time contributed document that only applies to a particular configuration?

The three main books for people,(install / customization / developer ) are currently at 1414 printed pages. That's an insane number to maintain. The developer handbook itself is generally kept up to date in the key areas by several developers who understand the benefit of being able to look up something they've figured out.

Customization has theming and it would be nice to break that out to it's own book, but so far the folks who have said they were going to do this have not done so. I have someone working on stuff for Drupal 6 theming so I still have hope for the future there.

So, what is the one thing we need to do better on for a major version release? Installation and configuration.

When my co-worker (who is interested in learning PowerShell too) asked me how to get a list of all the members of a given Security group, I didn't have a ready answer for him. I hadn't had occasion to learn how to do that yet and a quick search didn't show anything obvious or simple.

I had read in various blog posting and on the Microsoft newsgroups about Quests PowerShell extensions. As they were supposed to make some Active Directory related tasks easier, I thought this was the perfect time to try them out.

One download and install later I was looking through the 109 page Active Roles Management Shell for Active Directory guide and there in the table of contents was the Get-QADGroupMember commandlet on page 59.

This gets us name type and DN. To much information and not quite what we need. So off to our favorite discovery tool

This lets us discover the properties that allow us to use PowerShell's filtering capabilities. As my co-worker needs the logonname and the displayname, we came up with this final code.

The total time it took to get here was about 10 minutes. My co-worker is now even more excited about learning PowerShell. So much to learn, so little spare time.

We have been exporting some mailbox information manually and I was sort of tired of doing it that way. I thought I'd try to make it work with PowerShell to automate it and add some consistency. It took some experimentation and here it is.

It saves to a file, ServerName-Date.csv in the directory it's run from. It has Display Name, Storage Group Name, Store Name, Mailbox size (in kb like ESM) and Date Discovered Absent in DS (which is short for when the Active Directory account the mailbox was associated was deleted).