Error uninstalling Exchange Server 2003: One or more users currently use a mailbox store on this server.

So, you're transitioning your Exchange 2003 environment to an Office 365 environment and desparately want to drop kick your Exchange 2003 server out the door.  After migrating everyone's email, you open ESM, delete all of the mailboxes and start to uninstall Exchange.  But then, this frustrating message shows up:

The component "Microsoft Exchange Messaging and Collaboration Services" cannot be assigned the action "Remove" because:
- One or more users currently use a mailbox store on this server.  These users must be moved to a mailbox store on a different server or be mail disabled before uninstalling this server.

Thanks for leaving me the fun part of trying to guess who you think still has a mailbox.

Fortunately, there's an easy way to do this.

Let's say your server name is EXCH01.

1. Launch Active Directory Users and Computers.
2. In the navigation pane, right-click on your domain and select Find from the context menu.
3. In the Find Users, Contacts, and Groups window, click the Advanced tab.
4. Click the Field button, point to User, and then select Exchange Home Server.
5. Set the Condition field to Ends With.
6. Enter the Exchange mailbox server you're decommissioning in the Value field (in our example, EXCH01).
7. Click Add.
8. Click Find Now.
9. Once the list of users is displayed, you can right-click on the user, select Exchange Tasks, and then select Remove Exchange Attributes from the list of options.  Acknowledge the warning, and repeat for each user.
10. Restart Exchange setup.

Quick-n-Dirty User Management for Office 365 Hybrid Deployments

Over the past several months, we have deployed Office 365 to dozens of organizations. Several of the larger environments have asked for integration between the on-premise Active Directory environment and the Office 365 environment. For this, Microsoft has provided a roadmap using Active Directory Federation Services (ADFS) and Directory Synchronization (DirSync). This is a great solution for end users, but can be onerous for the system administrator--especially if the customer has been migrated from Exchange 2003.

When running in any sort of Hybrid mode (or having transitioned from Exchange 2003 on-premise), there are two attributes that need to be updated/maintained with the on-premise AD in order to keep things moving along:

- proxyAddresses
- targetAddress

The proxyAddresses multi-valued attribute is used to store all of the various addresses that are bound to a user. These include (but are not limited to) SMTP and X.400 addresses. In an on-premise Exchange environment, this attribute is used to store the addresses assigned by various recipient policies.

The targetAddress attribute stores the unique "onmicrosoft.com" address assigned to each user. During a transition, mail intended for the @domain.com address skips local mailbox delivery and is automatically forwarded to the address stored in this attribute. If the local Exchange server is kept on-line for local SMTP routing, these attributes *must* be populated for each new user, otherwise mail delivery to them from on-premise services utilizing the Exchange environment will fail.

To work around this, I've put together a very low-end script utilizing the Quest ActiveRoles cmdlets. You will need to install these on either a workstation or server in your environment and then then save the follwing script as a .ps1 file (replacing the placeholders with your own) on the same computer where you have installed the ActiveRoles PowerShell environment.

Write-Host "Please enter the Active Directory ID of the user to update:"
$SamID = Read-Host
$PrimaryDomain = "domain.com"
$SecondaryDomain = "domain2.com"
$Office365Domain = "domain.onmicrosoft.com"

Get-QADuser $SamID Set-QADUser -ObjectAttributes @{targetaddress="SMTP$SamID@$Office365Domain"}
Get-QADUser $SamID Add-QADProxyAddress -Address $SamID@PrimaryDomain -Primary
Get-QADUser $SamID Add-QADProxyAddress -Address $SamID@SecondaryDomain
Get-QADUser $SamID Add-QADProxyAddress -Address $SamID@Office365Domain

Exchange Delegates

I recently found myself in a spot where I needed to troubleshoot a delegate issue--a user was set as a delegate but no longer was with the company and didn't have a mailbox anymore, so periodic NDRs were being generated for mail destined for the delegate.

To discover all of the mailbox for which this person had been a delegate, I ran the command (on a domain controller or machine that had ldifde.exe):

ldifde -f delegates.txt -d "dc=domain,dc=com" -r "(publicDelegatesBL=CN=First Last,OU=AppropriateOU,dc=domain,dc=com)" -l name,publicDelegatesBL

Active Directory holds delegate information in two attributes--publicDelegates (listing which users are delegates of "n" mailbox) and publicDelegatesBL (listing which users "n" mailbox is a delegate of).

To find out all of the the mailbox of Aaron Guilmette in OU=Home,DC=aaronguilmette,DC=com:

ldifde -f delegates.txt -d "dc=domain,dc=com" -r "(publicDelegates=CN=Aaron Guilmette,OU=Home,DC=aaronguilmette,DC=com)" -l name,publicDelegates

To find out all of the mailboxes for which Aaron Guilmette in OU=Home,DC=aaronguilmette,DC=com is a delegate:

ldifde -f delegates.txt -d "dc=domain,dc=com" -r "(publicDelegatesBL=CN=Aaron Guilmette,OU=Home,DC=aaronguilmette,DC=com)" -l name,publicDelegatesBL

To find out all of the delegate relationships for a domain:

ldifde -f delegates.txt -d "dc=domain,dc=com" -r "((publicDelegates=*)(publicDelegatesBL=*))" -l name,publicDelegates,publicDelegatesBL

Hope this is helpful to some of you.

History of Active Directory

Great little blurb, for those of you interested in how it all began.

http://blog.joeware.net/2008/08/11/1420/

This post features several snippets of email from a newsgroup. The best comments come from one of the integral parts of the DS team, Don Hacherl.