Sometimes Servers Just Need A Stern Talking-To

Here I am giving one of my Exchange servers a piece of my mind.

Photo by Ryan Starck

Fixing the "Unable to activate send-on-behalf-of list" Error

This MS Exchange Team Blog article (as well as this follow-up) go into great detail about the history of this notorious error, but erroneously claims that it only occurs in muli-domain environments.  We have the issue here, and we have a single-domain forest.

The short version is that Exchange Server 2003 SP2 introduced changes in the security model for the delegate-setting process which, combined with updates on the client end, result in the following error when a user attempts to modify delegates:

The Delegates settings were not saved correctly. Unable to activate send-on-behalf-of list. You do not have sufficient permission to perform this operation on this object.

This error does not occur for all mailbox, and we've found neither rhyme nor reason for when it does, but there is a fix.

• For Outlook 2003 users apply this patch, then perform the registry modifications described here.
• For Outlook 2007 users apply this patch, then perform the registry modifications described here.
  

Entourage Issues with the Office:mac 12.1.3 Update

First notice I saw about the issue was here:

http://blog.entourage.mvps.org/2008/10/office_1213_update_breaks_sending_exchange_meeting_invitatio.html

 The reported issue is an error -17997 being generated when Entourage users attempt to send meeting invitations. I was unable to reproduce the issue in my own testing, but that was before the following two updates:

http://blog.entourage.mvps.org/2008/10/update_on_1213_problems.html

http://blog.entourage.mvps.org/2008/10/update_on_1213_problems_part_2.html

 

It seems that the problem manifests if the Entourage identity contains POP3 and/or IMAP4 accounts in conjunction with the Exchange account, with the non-Exchange accounts added to the identity PRIOR to the Exchange account.  Both updates mention workarounds. MacBU is aware of the issue and is working on an update.

 

The two workarounds mentioned are:

•  Drag the message from the outbox to the drafts folder and sending it from their (a clumsy workaround at best)
  
• Recreate your Entourage identity from scratch, making sure to configure the Exchange account BEFORE configuring any non-Exchange accounts.  Please note that this will force re-synchronization of the local cache data, which can take a considerable amount of time for large mailboxes.  One way to minimize this would be to configure Entourage to only cache partial messages (In the account settings, Options tab, select “Partially receive messages over x KB”).
  

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.

Counting Mailboxes and Determining Store Sizes

To obtain a breakdown of mailbox counts for each mailbox database in the Exchange organization:

Get-MailboxDatabase | Get-MailboxStatistics | Group-Object -property:database | Sort-Object -property:count | Format-Table count, name -AutoSize

To obtain a count of mailboxes per server:

Get-MailboxDatabase | Get-MailboxStatistics | Group-Object -property:serverName | Sort-Object -property:count | Format-Table count, name -AutoSize

To obtain the total number of mailboxes in your Exchange organization:

Get-MailboxDatabase | Get-MailboxStatistics | Group-Object

(Omitting the Get-MailboxDatabase command will give the count for the current server.)

These examples are wonderful illustrations of the usefulness of the Group-Object cmdlet.

I don't recall where on the web I found it, but the following commands will provide a breakdown of the sizes of all mailbox databases in the organization:

$exchangeservers = Get-ExchangeServer |where-object {$_.admindisplayversion.major -eq 8 -and $_.IsMailboxServer -eq $true }
foreach ($server in $exchangeservers)
{
$db = Get-MailboxDatabase -server $server
foreach ($objItem in $db)
{
$edbfilepath = $objItem.edbfilepath
$path = "`\`\" + $server + "`\" + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + "$" + $objItem.EdbFilePath.PathName.Remove(0,2)
$dbsize = Get-ChildItem $path
$ReturnedObj = New-Object PSObject
$ReturnedObj | Add-Member NoteProperty -Name "Server\StorageGroup\Database" -Value $objItem.Identity
$ReturnedObj | Add-Member NoteProperty -Name "Size (MB)" -Value ("{0:n2}" -f ($dbsize.Length/1024KB))
Write-Output $ReturnedObj
}
}