Converting Mail-Enabled recipient to Mailbox-Enabled recipient

    Out of the box, MS Exchange 2003/2007 do not offer any kind of way converting a mail-enabled recipient (MEU) into a mailbox-enabled recpieint (MBXU).  At first, you would think that scenario is least likely. Mail-enabled recipients forward to outside of exchange organization and why would you create a mailbox.  Well, in complex environments where organization has multiple email systems and a user wants to migrate to exchange but already utilizes AD, or if your organization is going through a complex migration.

    To convert an MEU into MBXU, we could just strip the AD object of exchange attributes and then ask exchange to create a mailbox.  However, you will notice that there might be side effects. Any secondary emails that might be attached to the MEU are now gone.  Secondly, a less trivial issue, is that repliability of emails which contain MEU address book entry is now broken. To fix these both, you’ll need to track secondary emails and legacyExchangeDn of the MEU and append them to proxyAddresses attribute when MBXU is created.

$userIdentity = 'testuser'
$mailboxDatabase = exserver\mbxdb'
$err = @()
$user = Get-MailUser -Identity $userIdentity `
         -ErrorAction SilentlyContinue -ErrorVariable +err
if ($err.count -ne 0)
{
    Write-Error 'The user is not a mail-enabled user.'
    return;
}
$mbxDB = Get-MailboxDatabase -Identity $mailboxDatabase `
        -ErrorAction SilentlyContinue -ErrorVariable +err
if ($err.count -ne 0)
{
    Write-Error "The database value is incorrect."
    return;
}
$extAddress = $user.ExternalEmailAddress
$currAddresses = $user.EmailAddresses
$legDn = $user.LegacyExchangeDn
Disable-MailUser $user -Confirm:$false | Out-Null
$mbxUser = Enable-Mailbox $user -Confirm:$false `
                       -Database $mailboxDatabase 
$addresses = $mbxUser.EmailAddresses
if ($mbxUser.LegacyExchangeDn -ne $legDn) {
    $addresses.add("X500:$legDn")
}
$currAddresses | ?{ $_ -ne $extAddress } | %{
    if ( -not $addresses.Contains($_)) {
        $addresses.Add($_) | Out-Null
    }
}
if ($addresses.Changed) {
    Set-mailbox $mbxUser `
                -EmailAddresses $addresses | Out-Null
}

C# Events and thread-safety

After reading “C# Programming Language”, which is more or less a dictionary of C# language features, I noticed that the spec claims thread-safety in event default accessors.

So code defined like this:

public event SomeEvent;

compiled into something roughly as this:

   1:  private EventHandler __SomeEvent;

   2:  public event SomeEvent {

   3:      add { lock(this) { __SomeEvent += value; }}

   4:      remove { lock(this) { __SomeEvent -= value; }}

   5:  }

Actually, add and remove keywords are translated as add_SomeEvent and remove_SomeEvent methods with [MethodImpl(MethodImplOptions.Synchronized)] attributes and thus equivalent to lock(this) shown above.

However, There is a problem here to achieve thread-safety. Using [MethodImpl(..)] is a bad practice b/c your code is trying to enter a monitor for this object instance. Thus, if another thread of execution obtains the monitor first, your subsequent call to “+=” or “-=” will block and will be hard to troubleshoot.

Instead consider this pattern where you implement custom accessors locking on a private object and give caller to invoke event safely through a method:

private object l_SomeEvent;
private EventHandler __SomeEvent;
public event SomeEvent {
 add { lock(l_SomeEvent) { __SomeEvent += value; }}
 remove { lock(l_SomeEvent) { __SomeEvent -= value; }}
}
public void OnSomeEvent(EventArgs e) {
 EventHandler temp;
 lock(l_SomeEvent) { temp = __SomeEvent; }
 if (temp != null) { __SomeEvent(this,e); }
}