Exchange

One of the most frequent questions I receive concerns namespace design.

I covered this recently in an article geared towards Exchange 2010. However, it quickly became apparent I needed to revisit this topic specifically for Exchange 2013. Especially with the big GUI rewrite.

So, let’s get started!

What’s in a namespace

Namespace is very important.

Not only does namespace govern services like Outlook Web App, or, ActiveSync, but it also governs items such as the distribution of the Offline Address Book, or, the Autodiscover service.

A correct namespace design is key.

That seems a little counterproductive, doesn’t it?

Isn’t the whole point of a Mail Contact to put an external address in your Global Address List?

Well, yes and no.

There are certain situations where you may not want an external contact to be generally available to your user base.

Take this scenario for example.

You are the sole IT person at your company. You contract an external company to perform network monitoring 24×7. Your devices email out alerts to a distribution list. This distribution list contains two people. Yourself and the mail contact for the monitoring company. You both get the alerts. They are your safety net when you aren’t looking.

Their email address is helpdesk@contractor.com. You also have an internal support email of helpdesk@yourcompany.com. To remove any chance that your users may pick the wrong helpdesk you decide you must hide the email of the contractor.

So, how do you hide a Mail Contact from your Global Address List?

It depends on the version of Exchange you are running.

In this article, we will explore how to do this for both Exchange 2010 and 2013. Let’s tackle the 2010 side first.

You just upgraded to Exchange 2013.

Congrats!

Now you plan to change the location of the database files.

You open the EAC, browse to the database tab, only to have trouble finding a way to move the database files.

Right-clicking the database does nothing. None of the buttons seem to indicate a way to do it. So, now what?

One of the frequent questions I receive concerns namespace design. I had previously covered this in my series Migrating Exchange from 2003 to 2010. However, with the recent restrictions on SSL certificates, I felt it necessary to revisit this topic with a dedicated article.

So, let’s get started!

What’s in a name

Namespace is very important.

Not only does namespace govern services like Outlook Web App, or, ActiveSync, but it also governs items such as the distribution of the Offline Address Book, or, the Autodiscover service.

A correct namespace design is key.

As mentioned in a previous blog post the end-of-life deadline for Exchange 2003 looms on the horizon. That being said, I discussed last time the process and syntax for upgrading the Recipient Update Policies in Exchange 2003 to the new Email Address Policies in Exchange 2010. Following a similar theme, this post will discuss how to upgrade the Address Lists in Exchange 2003 to 2010.

Like before this process is conducted in the Exchange Management Shell and like before if you tried to edit those Address List in the Exchange Management Console you would receive an error that the Address Lists were created in a legacy version of Exchange and need to be upgraded.

The specified address list could not be edited. Address lists created by using legacy versions of Microsoft Exchange must be upgraded by using the "ForceUpgrade" parameter of the "Set-AddressList" cmdlet.

Typically these are the commands you would need to run.