Tutorial: Using .NET GUI Widgets in PowerShell

One of the great unsung features of PowerShell (which forms the foundation of the Exchange Management Shell) is its ability to expose the full range of functionality offered by the .NET framework, and, more specifically, the GUI widgets provided by that framework.  I was blissfully unaware of this until encountering a sample script on "Glen's Exchange Dev Blog".  (That blog, by the way, is an excellent resource, and I highly recommend it. Entirely different Glen, lest there be any confusion. He is far more knowledgable about this stuff than I.)

In the script contained in that blog entry (upon which the following script is largely based) I discovered the wonderful world of rendering GUI elements from within PowerShell scripts. I was able to learn quite a bit about the subject by dissecting that script and a few other examples found around the web, but I was unable to find anything in the way of a tutorial on the topic.  Furthermore, although the .NET frameworks are well-documented on the MSDN website, the proper syntax for accessing those objects via PowerShell is not provided.

What else could I do other than write my own tutorial?

Creative Marketing at its Finest

http://www.youtube.com/experiencewii

Whoever came up with this deserves a nice, fat bonus.

The effect is subtle at first, then.... I really shouldn't describe it. That would spoil the effect.

It does remind me a bit of this.

"Tickling" GC Re-evaluation for Groups via "Set-DistributionGroup"

In an earlier post, I discussed having to use a set-mailbox command to "tickle" Exchange to force it to update custom Address List membership based upon changes made directly to Active Directory. I've now discovered that a similar action is required to update Distribution Group status in the Global Catalog when the group is converted to a mail-enabled security group in ADUC.

As discussed in KB 941318, a Distribution Group cannot be added to Exchange folder sharing permissions via Outlook 2007 against an Exchange 2007 server. When the Distribution Group appears in the GAL selection list, a prohibition icon appears next to the name, and attempting to add it to the DACL results in the following error:

One or more users cannot be added to the folder access list. Non-local users cannot be given rights on this server.

Of course, the solution is to convert the Distribution Group into a mail-enabled Security Group.  Earlier versions of the Outlook/Exchange combo handled this conversion automatically.  Why this functionality has been removed, I haven't a clue, but the fact remains that we now have to perform this conversion automatically.

Of course, my first instinct when I encountered this was to make the change in Active Directory Users & Computers.  All fine and dandy, except that the prohibition symbol didn't go away, and the group still could not be added.  It seems that performing this conversion outside of the scope of Exchange tools doesn't prod Exchange into noticing the change and changing the GAL entry accordingly. This seems to be the case despite the fact that the information returned by a Get-DistributionGroup command reflects the fact that the group has been converted.  Issuing a Set-DistributionGroup command with no arguements other than the group name seems to fix this.

Keep in mind that the Exchange Management Console provides no tool for performing this conversion, nor does (as far as I can find) Exchange Management Shell.

What is the Status of UTMB's BSL-4 Facility

A rather sobering thought has struck me. When Ike struck the Gulf Coast, The University of Texas Medical Branch in Galveston, TX suffered a total loss of power. It doesn't help that their backup generators were located in a basement, which flooded during the storm. Now, UTMB hosts a BSL-4 lab containing some of the deadliest bacteria and viruses known to man. Let that thought percolate through your head for a moment.

I'm currently providing shelter to some friends from Galveston who are worried about what nastiness they'll find in their refridgerator once they are able to return home after who-knows-how-long. Just think along the same lines for UTMB's research labs.

Taking a look at UTMB's web site, I only found this little blurb of relevance to my concerns:

Power coming soon for research samples Here’s more information on dry ice and liquid nitrogen

Posted: 11:35 p.m., Wednesday, Sept. 17, mc

The prospect of getting back on the power grid is getting better and better. In the meantime, we have had very good success in maintaining the integrity of our research samples. To that end, this message is a reminder to continue this tremendous effort until we are fully back on the grid. Click here for more information.

This is somewhat reassuring, but more details concerning the status of the BSL-4 facility itself would be nice. Googling about, I find that I'm not the only one concerned. Ever read Stephen King's The Stand?

Lamest...Bug...Ever....

Entourage has a bug.

I know, that isn't exactly earth-shattering news. Entourage has had many bugs over the years, and still does (not the least of which is the fact that Entourage will sometimes decide, for no apparent reason, to eat mailbox data, as evidenced by many mailbox restores which I've had to perform thanks to that steaming pile of excrement - grrrr). But this one I find especially annoying, not to mention idiotic. Fortunately, it only impacts a small subset of our users, but still....  

We opened a support call with Microsoft PSS about this issue in January of 2007.  After many months (with no progress being made on the case whatsoever), Microsoft unceremoniously closed the case. With our update to Exchange 2007 and the release of Entourage 2008 earlier this year, I had hoped that the problem would go away, but my hopes were unfounded.  A few months ago, we opened a new case on this issue when yet another user complained about the problem, but still there is no resolution.

"Tickling" Custom Address List Re-evaluation Via Set-Mailbox

In our Exchange environment, we have several custom Address Lists whose membership is determined by the presence of particular strings in CustomAttribute1. In the past, populating this field has been a manual process, accomplished by our Exchange admins entering it via the Exchange Management Console (and, pre-2007, via Active Directory Users & Computers). Recently, we introduced some web-based tools to allow our users to set this themselves. Unfortunately, we soon found that, although the attribute was being set properly, the addresses were not being added to the custom Address Lists, but would if we manually entered the item via EMC or EMS.

The web tool uses ADSI calls to populate the field, bypassing Exchange altogether. Addresses also fail to get added to the custom Address Lists if the custom attribute is populated via LDAP.  The only way that the lists get updated is if Exchange somehow notified that the extension attribute has been changed, thus triggering re-evaluation of custom Address List membership. Happily, we found that issuing a simple "Set-Mailbox " command, with no further arguements or flags, is sufficient to accomplish this.