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

Using Export-Mailbox CmdLet to export to PST file

In order to export mail to a PST file, EMS requires an Outlook MAPI to be present. Otherwise,

That means you must use 32-bit version of the Exchange Management Tools on an Outlook-installed workstation because 64bit EMS process cannot load 32-bit MAPI subsystem.

Thus, I quickly ran through a Vista 32bit set up steps.

1. Install Outlook

2. Install IIS Requirements

3. Install 32bit Exchange Management Tools, here.

Done!

New Drop of Gallio 3.0.4 is out

New drop of Gallio is up and ready. It has a number of feature improvements, discussed at here. My main concern is R# 4.1 integration.
Download it now at here.

Working with Active Directory Dates

Recently, my friend and colleague asked me about how to limit an ldap search to only return objects that were created after a certain date. 'whenCreated' should be a logical choice to solve that. However, this attribute has an interesting format, see this reference. So, i marked up a few functions to help us work with the date naturally within Powershell.

function ConvertToAdDate([DateTime]$date) {
   "{0:0000}{1:00}{2:00}{3:00}{4:00}{5:00}.0Z" -f $date.year,$date.month, `
           $date.day, $date.Hour, $date.Minute, $date.Second
}
function ConvertFromAdDate([String] $date) {
   $pattern = `
      '^(?<year>\d{4})(?<month>\d{2})(?<day>\d{2})(?<hrs>\d{2})`
              (?<min>\d{2})(?<sec>\d{2})\.0Z$'
   $match = [regex]::Match($date,$pattern)
   if ($match.success) {
       $result = New-Object System.DateTime($match.groups["year"].value,`
           $match.groups["month"].value,$match.groups["day"].value,`
           $match.groups["hrs"].value,$match.groups["min"].value, `
           $match.groups["sec"].value,[DateTimeKind]::Utc)
       $result.ToLocalTime()
   } else {
       $null
   }
}

Purging Mailboxes In Exchange 2003

I have recently demonstrated how to Purge a mailbox in Exchange 2007 but did not show anything for Exchange 2003. Here is what I do to purge mailboxes on Exchange 2003 server.

$list = gwmi -ComputerName "ex2k3srv" -Class Exchange_Mailbox -Namespace Root\MicrosoftExchangeV2 | ?{ $_.DateDiscoveredAbsentInDS -ne $null }
$list | %{ $_.Purge() }

For IT admins and Sales guys!!!

It's been all over the web. Still, I need to post this link b/c I'll be coming back to it for entertainment for awhile.

http://www.thewebsiteisdown.com/salesguy.html

Purging Mailboxes in Exchange 2007

We all know how vastly different Exchange 2007 Management Console (EMC) is from Exchange System Manager (ESM) in Exchange 2003. The other day I had to test a migration for work and realized that I no longer have an easy ability to purge mailboxes through EMC just like I used to in ESM:

Under the hood, selecting Purge in ESM calls Exchange_Mailbox.Purge method.
In Exchange 2007, WMI is gone. So Powershell comes to the rescue.
After reviewing "Remove-Mailbox" reference at TechNet, it sounds like "-Permanent" should be piped when removing the user and that's it. However, things are not that simple.
If mailbox is already disassociated, then I can query a list of disconnected mailboxes like this:

Get-MailboxStatistics | ?{ $_.DisconnectDate -ne $null}

Now, I need to pipe the "Remove-Mailbox", but which parameters do I choose?
It took me some mocking around but it turns out this is what you need:

Get-MailboxStatistics | ?{ $_.DisconnectDate -ne $null} | `
 %{ Remove-Mailbox -Database "Mailbox Database" `
    -StoreMailboxIdentity $_.MailboxGuid -WhatIf:$false} 

PowerShell Team is working hard, and for a good reason

So, I am involved lately in issues other than Exchange administration. However, I've always liked to keep tabs on what's new. Powershell team recently came out with their new CTP2 of Powershell V2. The hot buzz so far is Remoting features, but they do require understanding of WinRm. Anyone who wants to stay in the Exchange development scene for a few years to come would need to understand both platforms.

exchMasterAccountSid bytes again, and again.

I have recently spent a considerable amount of time supporting one of our customers who for some reason was unable to perform MAPILOGONEx command via MFCMAPI. We were issuing the OPENSTORE_USE_ADMIN_PRIVILEGE OPENSTORE_TAKE_OWNERSHIP which translate to using Administrative Previleges.

After much speculation about lack of permissions, it turned out that customer's environment was at Exchange 2003 SP2 but did not have a fix for msExchMasterAccountSid issue. That same issue that even had msexchange.org guys write a tool, NoMas. Apparently, Information Store disallows the administrative permission resolution as well. NoMas can help a lot with the short-term workaround, while applying KB916783 ensures the correct behavior.

Now, I need to actually look at some of our apps and review their functionality under this scenario.

Changing focus of the blog a bit

Ok,
so I went quiet a bit just as I planned to blog more. The reason is simple. I have swapped jobs . Now, entrached in development as opposed to IT support, my focus is still with MS Exchange and Messaging. However, my day-to-day tasks are now involve looking deeper at AD integration with Exchange (various versions) and with time MAPI.

Getting Export-Mailbox Cmdlet to work

After installing Exchange 2007 SP1 Management Tools on Windows 2003 SP2 x86 and Outlook 2007 with SP1, the export-mailbox cmdlet was returning this error:

Export-Mailbox : Error was found for "Name" () because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221233

Running FixMapi.exe from the command prompt easily fixes the problem.

Entourage 2004/2008 caveat in Exchange 2007 environment

One thing that I found is a bit frustruating the lack of documentation regarding Entourage connectivity to Exchange mailboxes in co-existence scenario.

The first challenge actually happened a few weeks when our team has deployed Exchange 2007 CAS farm to replace our existing Exchange 2003 FE. We found that by default when deploying CAS role, it will enable legacy virtual directories to support OWA for exchange 2003 mailboxes but not WebDAV to support Entourage. Thus, our team had to set it manually via GUI or ADSI IIS provider in powershell. Big thanks to Nathan Winters and his article to elaborate on this.

The second challenge came when a mailbox was migrated to Exchange 2007 CMS. Entourage 2004/2008 started to display "Unexpected Error (170)". My initial research kept pointing me to KB947802, however that was not the problem as I verified that HTTP protocol settings exist in AD. The actual solution to the error message ended up KB931350. It appears Entourage users must now enter a fully qualified URL to their mailbox https://domain.com/exchange/user@domain.com. This does not look too apealing at all. It's time to change the user docs!

ActiveSync caveat in Exchange 2007 co-existence scenario

In Exchange 2003 FE/BE configuration, Active Sync default virtual directory authentication is set to basic. Admins have to rely to transport level security, such as IPSEC, to secure proxying credentials from frontends to backends.
By introducing CAS role as a replacement for FE, our group immediately ran into problems. The toughest problem was actually to set "Integrated Authentication" because ds2mb service will overwrite our attempt to set it in IIS snap-in. We found this KB, thanks to my co-worker, and that enabled us to set the correct authentication option.

Migration WorkShop: How do I set up Journaling?

I've only experimented with journaling in Exchange 2003, so I do not have too much experience with this. However, curiosity was killing me. In 2003 environment, journaling is enabled per mailbox store basis. The similar functionality is available in 2007 using standard Journaling:
Enable Journaling: Set-MailboxDatabase -JournalRecipient
Disable Journaling: Set-MailboxDatabase -JournalRecipient $Null

If you want to find out more about premium Journaling, which requires enterprise CALs, then waltz over here.

Migration WorkShop: Can Exchange Security Groups be moved to another OU or Domain?

As the Microsoft White Paper, here, points out that the Exchange Universal Groups (USG) are added to otherWellKnownObjects AD mutli-valued attribute. This means that AD will maintain the location of the groups, their distinguished name. Therefore, it should be safe to move the groups to another OU or even another domain.