This morning we published the first look at the Ignite session catalog providing you a better view of what to expect at Ignite. Ignite brings together the Exchange Conference with TechEd and other Microsoft technology events. By attending Ignite, you’ll have access to a broad set of content on Microsoft’s technologies, including detailed content from the teams that build the products and the experts who deploy and use the technologies.

The initial Ignite session catalog includes over 50 sessions on Exchange and Outlook. We will continue adding more sessions leading up to the event. Use this pre-filtered search link to begin reviewing the content we are planning for Ignite. In addition to first look at the sessions, we are sharing an expanded view of the featured speakers you can expect to find at Ignite.

Veterans of past MEC events, Greg Taylor and Jeff Mealiffe, took some time to talk to us about what to expect at Ignite. Check this out as they coin the new Ignite descriptor - #BREEP!

Mark your calendars for an #IgniteJam on Twitter

Join us on February 3^rd at 9:00 am PT, when we’ll have the whole event team and a few speakers ready to chat with you on Twitter. We’ll be ready to answer your questions about the event and hear what you’re excited about in terms of community experiences and things to do in Chicago. Add the event to your calendar with this link.

To participate in the #IgniteJam

1. Log in to Twitter on Feburay 3^rd, at 9:00 a.m. PT. For easier real-time participation, use Twubs and join us at: twubs.com/ignitejam.
2. Introduce yourself and include the hashtag #ignitejam and tag us at @MS_Ignite.
3. Watch for questions coming from @MS_Ignite and chime in with your answers and commentary, using the hashtag #ignitejam.

So sign-up now and we’ll see you in Chicago!

I’m happy to announce that the Exchange performance virtual team within Microsoft Support has produced some fantastic new performance guidance content for Exchange 2013 users, and it is now available on TechNet at http://aka.ms/Ex2013PerfContent. This is a compilation of resources that we’ve previously published, guidance presented at Microsoft events since the release of Exchange 2013, and things that we have learned through the process of providing support to customers deploying the product.

Clearly this is just a starting point, and we will be updating this content on an ongoing basis as we continue to learn more about how Exchange works in your deployments. Let us know what you think!

Jeff Mealiffe
Principal PM Manager
Office 365 Customer Experience

The process of recovering deleted users or mailboxes in a hybrid or cloud-only organization can be frustrating. When dealing with these scenarios, customers would sometimes end up with multiple mailboxes for a single user, find that some emails are missing, or even lose data associated with other services. Often, they would find those situations difficult to troubleshoot and they would call Microsoft support for help.

For a long time now, Exchange Online has had a capability called "soft delete" that allows a user to recover a mailbox with very little effort. Let’s take a look at how a mailbox recovery should be approached.

Scenario: User Is Accidentally Deleted Along with Their Mailbox

First, you need to know if the deleted user was managed on-premises or in the cloud.

If the user was managed in the cloud:

If the source of authority for the user is in the cloud (meaning they are not sync’d from on-premises Active Directory), you can restore the user from the Admin Portal at http://portal.office.com. Navigate to Users, and select Deleted Users. There you will see the option to restore the user.

If user was synchronized from on-premises AD:

If the user account was being synchronized from on-premises you should restore the user on-premises. The mailbox will automatically reconnect.

IMPORTANT NOTE: Recreating the user on-premises will not have the same effect because the Globally Unique Identifier (GUID) used in the recovery process would be different.

The proper way to restore a deleted user is documented at http://support.microsoft.com/kb/2619308. That’s it! There is no need to take any additional actions.

What If These Actions Do Not Work?

There could still be times when "soft recovery" actions will not fix the user's account. For instance, the user may have a corrupt account or the account may have been permanently deleted. Another possibility is that the user is no longer with the company, but the mailbox is used as a job-related mailbox and needs to be available to a new user. 

For these scenarios we have the New-MailboxRestoreRequest cmdlet. This allows you to merge the data from one user or archive mailbox to another user, or you can archive the active mailbox. Unlike the recovery process above (which is the best approach), New-MailboxRestoreRequest allows you to merge the data from a soft-deleted mailbox into an alternate active mailbox or archive mailbox.

Why Is This a Benefit?

Previously, if you could not recover both the user and the mailbox, you would have to perform an unsupported process of hard-deleting a mailbox. This process was unreliable and sometimes caused a ripple effect on other services such as SharePoint and Lync. If the process failed, you were left with very limited options, and ultimately had to call support.

IMPORTANT NOTE: We are in the process of disabling the old method of recovering a mailbox which involved using Get-RemovedMailbox and New-Mailbox –RemovedMailbox. You will soon find that these methods will no longer be available, which is a good reason to get familiar with new options.

What Do I Need To Do To Take Advantage of This New Option?

All you need to do is create a new user with a mailbox and merge the data. The way you create the user with a new mailbox will depend on if you use DirSync or the Microsoft Online Portal to create users.

1. Create the user and Mailbox.

Using DirSync:

• Create the user and remote mailbox from the on-premises Exchange management tools.
• Force a directory synchronization.

Not Using DirSync:

• Log into http://portal.office.com.
• Create and license the user.

2. Run the cmdlet to merge the accounts. This is done from PowerShell connected to Exchange Online.

A) Connect PowerShell to Exchange Online. To do this, see http://technet.microsoft.com/en-us/library/jj984289(v=exchg.150).aspx

B) Run the following Command and retrieve the GUID for the soft-deleted mailbox that you want to restore: Get-Mailbox -SoftDeletedMailbox

C) Run a cmdlet similar to the following to restore the mailbox: New-MailboxRestoreRequest -SourceMailbox <GUID from Step 2B> -TargetMailbox <GUID from Step 1>

NOTE 1:  If the mailbox source and/or target is an archive, use the following switches (-SourceIsArchive and/or -TargetIsArchive)

NOTE 2: The value in Step 2C calls for the account GUIDs, but they can take other values such as an SMTP address or a UPN. The reason we recommend using GUIDs is to reduce the chances that there will be any confusion or conflict between the source and destination.

Are there limitations?

This merge capability does have some limitations. For instance, you cannot merge data from a source mailbox that is active. Let’s say you have a user (Jane) who is still licensed and using her mail. You would be unable to merge her data into Tom’s mailbox with this new approach. This new process is not meant to be used for backup and duplication purposes; this is a recovery tool only.

Another time when this tool will not work is when the mailbox is hard-deleted. If you manually remove a user account in Office 365, and then remove the user from the Recycle Bin, the mailbox would be hard-deleted. This is the potentially damaging scenario that was briefly discussed above. Again, this merge approach is for recovering soft-deleted mailboxes when the normal recovery options are not available to you.

Timothy Heeney

Back at the release of Exchange Server 2013 CU1 we made some necessary changes to the way OWA logoff works. Those changes had the unfortunate side-effect of breaking the way TMG spotted a user’s attempt to logoff, thereby breaking that scenario.

Well, we have some more changes in mind for OWA logoff once again, and we’re taking the opportunity this time to FIX the TMG logoff issues at the same time. A better result all around we are sure you will agree.

And one more thing, this is a heads up, as we’re delivering this change in CU8.

So what are we changing? Well simply put, instead of sending you back to the logon form when you log out, we’re sending you to a new static logoff page, recommending you close your browser.

Why would we want to do that? Well, it means we have a more consistent logoff experience now whether the authentication used is FBA, Basic or Integrated Windows, the message gets presented for all. It also means we decouple log on and logoff, which means each can potentially be changed in some way without impacting the other.

So here’s the old, pre-CU8 way;

When using OWA, and when you click on sign out:

1. The client initiates logoff with the request to “/owa/logoff.owa”
2. Client then gets a 302 redirect to “/owa/auth/logon.aspx”

And you’re back at the logon page.

When using ECP, and the user clicks on sign out:

1. The client initiates logoff with the request to “/ecp/logoff.aspx”
2. Client gets a 302 redirect to “/owa/logoff.owa”
3. The client then gets another 302 redirect to “/owa/logon.aspx”

And you’re back at the logon page again.

Now here’s how we’re doing it in CU8 by default.

When using OWA, and when you click on sign out:

1. Client initiates logoff with the request to “/owa/logoff.owa”
2. The server sends to client a 302 redirect to the landing page “/owa/auth/signout.aspx”

Now you’re at the new signout.aspx page.

When using ECP and the user clicks on sign out:

1. Client initiates logoff with the request to “/ecp/logoff.aspx”
2. Client gets a 302 redirect to “/owa/logoff.owa”
3. Client gets a 302 redirect to the landing page “/owa/auth/signout.aspx”

And again you’re at the new signout.aspx page.

So now that you understand what we changed and why, why do you care? And why are we telling you now? We expect a large portion of our customers likely don’t need to care too much as the changes will be invisible to you, but some of you may need to (as our KB articles say) ‘consider the following’ scenarios;

You are using TMG and have it configured to watch for logoff.owa to signify a user was logging off. If you have that configuration today it will simply start to work again. That’s great news, isn’t it?

Regardless of TMG, it still might be important to you to know about this if you have any third party applications integrated into Exchange. We know of a few that have come to depend upon the behavior we introduced with CU1, and we know at least one (as they are participants in our TAP which makes them very smart fellows) who has already made the changes they needed to make to accommodate this in preparation for CU8 being publically available.

So what if the third party vendor solution you have wasn’t aware of this change, and once you install CU8 things break? Well, there are two things you can do;

1. Ask your vendor why, if they develop third party add-in apps for Exchange are they not reading our blog…. J And ask them when they will be fixing their app so it works with your CU8 or later deployment.
2. You can put in a temporary reversion to the older (CU1 and later) behavior. This change is only supported with CU8 or later, and the ability to make this reversion will potentially be removed from future updates – so don’t get used to using it, and don’t forget CU9 or later will wipe any web.config changes you make.

The legacy logoff mode can be enabled (disabling redirect to signout.aspx) by changing 3 web.config files.

And don’t forget, the next Cumulative Update will reset this manual modification, so be prepared to do it again if you must after CU9 releases. Ideally though, if the reason you are doing this is to allow some third party app to work, that app should be updated to live with the new behavior.

The final, and perhaps the most important scenario is that this change introduces an install order dependency, something we thankfully have quite rarely, but something you need to pay attention to on this occasion.

Simply put, if a user’s mailbox is on a CU8 Mailbox server but connecting through a CU6 or earlier CAS, they will see an issue at OWA logoff due to this change. What about if you have CU7 CAS you ask? Well we made enough code changes in CU7 that this situation doesn’t crop up. So to put it simply once again, if your CAS is on CU7, or CU8, or if you have only multi-role servers at CU7 or later, no problem, none, not at all.

So, what’s the best way to make sure you won’t hit an issue? Keep up to date of course, as that means all your servers are already at CU7, so you have nothing to worry about.

What if on the other hand you are coming from CU6 or earlier and you expect users might be using OWA during the window in which you plan to install CU8?

Well if you have separate CAS/MBX roles (and if you do… why?) then we recommend you update all the CAS first. Then you can update the Mailbox servers in any order you like. That’s the simplest solution by far.

If, on the other, other hand, you have all multi-role servers (well done you, we like you), and they are CU6 or earlier, then you have three choices;

• Upgrade them all to CU7 before you begin your CU8 rollout.
• Accept there may be some funky issues during that upgrade window and simply decide you want to live with it.
• Do a rolling upgrade and be smart with your load balancing pool so all incoming connections hit only upgraded CU8 CAS. If you don’t have any idea what that means or how to do it, it’s not the option for you. Take the first option.

We hope this gives you what you need to successfully get your servers to CU8 and hope you TMG stalwarts are once again happy and pleased the logoff experience is properly working again.

Greg Taylor
Principal PM Manager
Office 365 Customer Experience

I’m happy to announce support for use of an Azure virtual machine as an Exchange 2013 Database Availability Group witness server. Automatic datacenter failover in Exchange 2013 requires three physical sites, but many of our customers with stretched DAGs only have two physical sites deployed today. By enabling the use of Azure as a third physical site, this provides many of our customers with a cost-effective method for improving the overall availability and resiliency of their Exchange deployment.

You can learn more about the deployment and configuration process, as well as learn about our best practices in the TechNet Library article.

It’s important to remember that deployment of production Exchange servers is still unsupported on Azure virtual machines, so it’s not yet possible to stretch a DAG into Azure. This announcement is limited to deployment of a file share witness in the Azure cloud. Also note that this is not related to the “Cloud Witness” feature in the Windows Server Technical Preview. Stay tuned for future announcements about additional support for Azure deployment scenarios.

Jeff Mealiffe
Principal PM Manager
Office 365 Customer Experience