Majel Barrett Roddenberry Dead at 76

Full story at Yahoo! News.  Interestingly, she had just finished doing voice recordings for the ship's computer in the upcoming J.J. Abrams reboot of the Star Trek franchise.

Time Sinks

Assembler
Magic Pen

The Fantastic Contraption

Entourage Generational-Suffix Bug: Good News & Bad News

As recounted in an earlier post, we've encountered a lovely little bug in Entourage where users whose Display Name ends in a string which can be interpretted as a generational suffix (I, II, III, IV, Jr, Sr, with or without trailing periods) cannot be added to Exchange sharing permissions via Entourage.  PSS has just reported to me that there is a workaround.  I have verified that the workaround indeed works.   The downside is that the workaround requires that the user know the samAccountName of the user whom they wish to add to their sharing permissions.

The workaround is pretty straightforward. In the "Select User" dialog box, click the "Advanced..." button.  In the resulting "Advanced" dialog box, enter the domain name and login name (samAccountName) of the user to be added.

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
}
}

Setting Send Connector Message Size Limits

For quite some time, our Exchange environment has been configured to restrict total message sizes to 30MB, as set in "Transport Settings" under the "Global Settings" tab of the Hub Transport settings. This limit was inherited from our Exchange 2003 settings, so we didn't have to configure it when we went to Exchange 2007. However, we recently had a customer complain that outbound messages were bouncing when their size broke 10MB. I was quite puzzled by this until they passed along a copy of the bounce message, which contained the following:

#550 5.3.4 ROUTING.SizeLimit; message size exceeds fixed maximum size for route ##

Ah ha! Lo and behold, Send Connectors have a default message size limit of 10MB, and we didn't modify this when we created the Send Connector for our 2007 Hub Transport servers. This is easily correctable, either via EMC, or via the following EMS command:

Set-SendConnector 'Connector Name' -maxmessagesize 30MB

Photographic Proof That UT Has Balls!

UT Austin is installing around campus a series of sculptures on loan from the Metropolitan Museum of Art in New York. This one in particular is being put up right in front of the building where I work.


I do not know the title or artist of this piece (installation is still in progress, so no plaque is in place), but it consists (thus far) of two large metal spheres covered with pennies, heads-up on one, tails-up on the other.

I can't help but wonder how long it will take the Powers That Be to notice the unfortunately suggestive placement.

Export-Mailbox Command Crashing PowerShell on Vista - Resolved!

I've been going back and forth with Microsoft on an issue that has been bugging me for a while. Whenever I try to use the Export-Mailbox command on my Vista workstation, PowerShell crashes. This is with a relatively new (less than one month old) Vista install and having re-installing PowerShell and the Exchange management tools. Yet, when I try it on a co-worker's workstation, it works fine.

Finally, Microsoft PSS hit on something that allowed me to find a workaround. After turning off UAC, I could run Export-Mailbox without it crashing PowerShell. Oddly enough, UAC is still active on my co-workers' workstations where I was able to successfully use the command, so the problem is clearly more complex.

Another clue from Microsoft: check the permissions on the registry key "HKLM\Software\Microsoft\Exchange\Exchange Migration". Based upon running TTTrace, I was getting an Access Denied error while trying to hit that key, resulting in the freeing of an internal structure needed to write data to the Application Event Log. The account I was using was a member of a group that was in the local Administrators group, which in turn had Full Control on that key. Perhaps that wasn't sufficient. I gave my account explicit Full Control on the key, turned UAC back on and rebooted. Export-Mailbox worked with UAC on.

Sigh....

Update A further clue: My co-workers were able to run in the command with UAC active and without explicitly giving themselves permissions on the registry key because they were running with elevated permissions, thus sidestepping UAC, whereas I was simply logging in directly to the workstation as the privileged user.

New Distribution Groups in Exchange 2007 Require Sender Authentication by Default

When a new distribution group is created in Exchange 2007, by default it is set to accept messages only from authenticated senders. A group can be set to not require authentication by using the Set-DistributionGroup command to set RequireSenderAuthenticationEnabled to $False.

To see what groups are set to require authentication, use the following command:

Get-DistributionGroup | where {$_.RequireSenderAuthenticationEnabled -eq $True}

Please note that the default settings also do not permit the object in the "Managed By" field to edit group membership.

New Blog for Boat Refit Project

I've been slowly making progress on my trimaran. I've built rudimentary supports to hold up the secondary floats while I detach them, and I've also procured an A-frame engine hoist via Craigslist for lifting the main hull. On top of everything else, this last Sunday, my friend Nyl brought up the plans from which the boat was built, along with a packet containing quotes and receipts from materials used in the original construction, an article written by the designer about boatbuilding on the cheap, a magazine article from 1968 about the controversy over multihull safety which cites the (then) recent disappearance of Arthur Piver, the man who designed my boat. Plus, a photo of my trimaran, in the water, back when it was new - sporting a cabin!

Sure enough, examining the schematics for the Piver Nugget revealed that it could be built in either a cabin or daysailer configuration. Finally knowing the name of the boat and its designer, I was able to locate numerous photos of other Nugget's on the web. It seems that most were built with the cabin configuration.

Anyway, I've now started a new blog over at http://piver-nugget.blogspot.com devoted to tracking my progress on this refit.

Coolest Exchange 2007 Tip Ever!

One of my biggest complaints about Exchange 2007 has been how long it takes for EMS and EMC to start up. This especially becomes an issue with web-based front-ends for PowerShell scripts, which have an unfortunate tendency to time-out.

Now there is a tip on the PowerShell Team Blog which explains how to pre-compile the .NET frameworks using ngen.exe to pre-populate the Native Image Cache, thus speeding up the loading of all things PowerShell-based. The performance gains are impressive, but I suspect that the script would need to be re-run anytime Exchange or the .NET Framework get updated or patched.

I also note that there doesn't seem to be much of a speed boost on the Exchange servers, just on other boxes that use EMS or EMC to manage Exchange. On our web front-end for self-service mailbox management, the EMS scripts run about twice as fast!

Stan Winston: 1946-2008

Special effects and model-making wizard Stan Winston has died at the age of 62 after a three year battle with myeloma cancer. Not only do I have fond memories of his work, but also of a book that he put out back in the eighties on model-making techniques, with the tricks of the trade spelled out in exquisite detail - everything from vacuforming to casting foam latex. Wish I could find it...

A Sad Day for 'Trek' Fans

Three icons of the original Star Trek series have passed away only a few days apart:

• Robert H. Justman, a producer on both ST:TOS and ST:TNG


• Joseph Pevney, who directed many of Trek's most memorable episodes, including "City on the Edge of Forever," "Journey to Babel," "Amok Time," and "The Trouble With Tribbles."


• Alexander Courage, composer of ST:TOS' iconic music.

EMS Goodies: Populating a Distribution Group from a File

Given a text file containing a list of samAccountName items, here is the command to stuff those accounts into a Distribution Group. It is assumed that the group has already been created and that the file is in the current directory.

cat ".\users_to_add_to_group.txt" | get-mailbox | Add-DistributionGroup Member -id "MyGroup"

BOAT!!!

Yesterday I purchased my first sailboat, a 40 year-old homebuilt 24' trimaran. It needs sanding and painting, but is structurally sound and has good sails. Unfortunately, my current vehicle is not beefy enough to tow the thing, mainly due to the weight of the massively over-engineered trailer. Fortunately, I'm currently shopping for a pickup, so I should soon be able to return to Victoria to retrieve my booty.

More EMS Goodies

Reading Secure Strings
If you have a PowerShell script that needs to have the user enter a password, but obviously don't want the input echoing to the screen, try this:

$Password = Read-Host "Please enter password: " -AsSecureString

The variable $Password can then be passed along to commands that require a secure password string as a parameter.

Distribution Group Goodies
To add the ability to Send-As a group:

Add-AdPermission "Group Name" -user "User Name" –AccessRights extendedright -ExtendedRights "send as"

To delegate rights to modify group membership:

Add-ADPermission –Identity "name of distribution group" -User "name of user" -AccessRights WriteProperty –Properties “Member”

More details: Add-ADPermission.

EMS Goodies: Distribution Groups and PowerShell

Here are a few PowerShell scripts that I cobbled together to help with our current mailbox migrations from Exchange 2003 to Exchange 2007. The first, grp_and.ps1, takes the names of two distribution groups as parameters and lists all users who are present in both groups. The second grp_not.ps1, lists all users who are in the first group but NOT in the second group. Note that Exchange 2007 SP1 is required to make use of MemberOfGroup in the recipient filter.

grp_and.ps1

# Script for listing which recipients can be found in both groups passed as arguements

function Usage
{
""
"Usage: .\grp_and [DistributionGroup1] [DistributionGroup2]"
" Lists accounts that are found in both distribution groups."
" Two arguments required."
""
exit
}

# Help Request
if ( ( $Args -eq '-?') -or ($Args.count -ne 2) )
{
Usage
}


$grp1 = $(Get-DistributionGroup $args[0]).Identity.DistinguishedName
$grp2 = $(Get-DistributionGroup $args[1]).Identity.DistinguishedName

""
$grp1
" and"
$grp2
" both contain the following recipients..."
"-------------------------------------------------------"
get-recipient -RecipientPreviewFilter {(MemberofGroup -eq $grp1) -and (MemberofGroup -eq $grp2)}
"-------------------------------------------------------"

grp_not.ps1

# Script for listing which recipients are in the first group but not the second, passed as arguements

function Usage
{
""
"Usage: .\grp_not.ps1 [DistributionGroup1] [DistributionGroup2]"
" Lists accounts that are found in the first group but not the second."
" Two arguments required."
""
exit
}

# Help Request
if ( ( $Args -eq '-?') -or ($Args.count -ne 2) )
{
Usage
}


$grp1 = $(Get-DistributionGroup $args[0]).Identity.DistinguishedName
$grp2 = $(Get-DistributionGroup $args[1]).Identity.DistinguishedName
""
"The following recipients are in "
$grp1
"but are not in "
$grp2
"----------------------------------------------------------------"
get-recipient -RecipientPreviewFilter {(MemberofGroup -eq $grp1) -and (MemberofGroup -ne $grp2)}
"----------------------------------------------------------------"

Major Flaw in Exchange 2007: a Blast from the Past!

KB article 812806 describes a serious bug in Exchange 2000 and Exchange 2003, as well as its fix. The bug manifests itself when an Exchange user sends an SMTP message to an external mailing list address, and the delivery attempt to one or more members of the mailing list generates an NDR, the NDR presented by Exchange to the original sender makes it appear that delivery to the list address itself failed.

Well, this bug has resurfaced in Exchange 2007. A Microsoft PSS support engineer has confirmed to me that the fix described in the aforementioned KB article does not work with Exchange 2007, nor is there a fix in place. An ECR was apparently filed last year to address the issue, but it seems that there has been no progress made on getting a fix out.

Can't Micosoft fix a bug and keep it fixed? Especially on such a blatantly serious bug?

Update: Within minutes of posting this, I received an update from PSS. A hotfix is in the works. Release is tentatively slated for late April.

Laugh. It's funny.

Go go gadget accelerometer!

Exchange 2007: the Good, the Bad, and the Ugly

First of all, let me say that, as an Exchange Administrator, I'm seriously loving the Exchange Management Shell (EMS), the combination of PowerShell with .NET extensions for managing Exchange. Coming from a VMS background, I'm certainly not averse to a command line, and as I get more and more accustomed to the PowerShell syntax, I'm learning to appreciate it more and more. It is powerful, very powerful, and already, despite being early on in my learning curve, I've managed to write several useful scripts for facilitating that staging of mailboxes into groups for transitioning from Exchange 2003 to Exchange 2007. I've even started tinkering with the ability of PowerShell scripts to create their own GUI. If only PowerShell and the Exchange extensions weren't so slow to load initially. What's more, the 64-bit requirement for running Exchange 2007 was a stroke of brilliance. With 32 GB of RAM stuffed into our mailbox servers, Exchange screams. Now I just have to get our page files sized properly.

Of course, the process has not been without its pain points. Microsoft's instructions for installing SCC (Single-Copy Cluster) Clustered Mailbox Servers fails to point out that, when installing an active CMS instance, the cluster service should be stopped on any passive node where an Exchange role has not yet been installed. Otherwise, during the course of the CMS installation, a failover to the unprepared node will try to take place, which will of course fail, leaving the Exchange installation in such an inconsistent state that the only recourse is to completely uninstall Exchange and start the cluster creation from scratch. Also, in earlier versions of Exchange, it had been our standard practice to pre-create the server objects in AD for our Exchange Virtual Servers. This should not be done with 2007. The server objects for the CMS nodes should be created by the installer. We also had to disable the Windows firewall on our mailbox cluster to allow OWA to work correctly, no matter how many holes we punched into it.

We've encountered quite a few oddities with our environment. When a signed message is sent by Outlook from a 2003 mailbox to a 2007 mailbox, the message body appears blank when viewed in OWA Light, or when viewed by the IMAP client on an iPhone. Somehow, the S/MIME headers are being munged in some bizarre way, and the folks at Microsoft PSS are still scratching their heads over that one. But when the signed message is sent via OWA or Entourage, it appears just fine.

The combination of Entourage 2008 and Exchange 2007 is a godsend for our Mac customers (of which we have many in our University environment.) Previously, delegate assignments were severely broken, and the hacks that Microsoft employed to make WebDAV work with recurring meetings came to be a common source of mailbox corruption. I can't recall how many times of had to do mailbox restores to fix this. Now, with the latest version on each end and the use of the more robust Exchange Web Services (EWS) as the intermediary protocol, life is much better. Recurring meetings are handled properly, and delegation assignments work properly. Much to our chagrin, however, as we migrate to 2007, we've had to tell our Entourage users (2004 and 2007) to change their configuration. With Exchange 2003, we told our Entourage users to specify the Exchange server using the OWA URL "https://exchange_front_end_fqdn/exchange", but that doesn't work with 2007. Instead, just the fqdn of the front-end (CAS) alias must be specified, without the URL trappings. Also, while it is commendable that Entourage 2008 tries to use Autodiscover to acquire configuration settings, the results returned are incorrect. Instead of the Exchange Server setting being populated with the name of the server bearing the CAS role (which is what Entourage should talk to in order to communicate with EWS), the CMS holding the mailbox is returned, which will not work if. It is fine if the CAS and Mailbox roles both reside on the same server, but the Entourage developers do not seem to understand that, in an enterprise environment, CAS and MBX roles are segregated, largely because the CAS role cannot be installed on a cluster.

We'll miss Outlook Mobile Access (OMA), but the new version of Outlook Web Access (OWA) is magnificent, provided that you are not a Mac or Linux user (as many of our users are). Even with Exchange 2007 SP1 installed, OWA Light does not offer Deleted Item Recovery or Public Folder access. (These features were also missing from OWA Premium in the RTM version.) Furthermore, opening someone else's shared Calendar on a non-IE browser via the URL https://CAS_FQDN/owa/TARGET_SMTP_ADDRESS/?cmd=contents&f=calendar results in the error "Access to Calendar folders from Outlook Web Access Web Parts is supported only for Internet Explorer 6 and later."

*sigh* So near, yet so far...

Been there, done that....

A couple of YouTube videos reflecting the frustration of those who provide technical support: