Exchange Server 2013 preview

Microsoft about a month ago allowed people to download and try out next version of Exchange, dubbed Exchange server 2013.
I have played with it for a while and have some comments on what I think is good and bad.

If I refer to the Exchange team blog article http://blogs.technet.com/b/exchange/archive/2012/07/23/the-new-exchange.aspx

Reduced costs by optimizing for next generation of hardware
I think the reduced IO is good as focusing on design for upcoming hardware is also good even though not that many companies buy into the DAS story but instead still use different SAN technologies. This can be discussed for a very long time and both technologies have its advantages. I have done implementations with both DAS and SAN storage for Exchange and looking in the rear view mirror a lot of errors in Exchange storage has not been in the DAS area but with management error of the SAN storage/infrastructure. The reduced IO demand is of course good regardless of whatever storage you use.
Store.exe has now been rewritten in managed code and each database runs its own version of store.exe which make them more isolated from each other so if one crash the other DB’s will continue to run without interruption.
Yes. Exchange still uses the ESE database engine.

Significantly reduced operational overhead for high availability
Have you ever tried to do a site failover? There are some challenges and it will take time with verification between steps. Steps have been easier and work has been done in Exchange to make failovers a better experience for clients. One important thing is that Exchange only accepts client connection done by HTTPS/RPC, or in other words, Outlook Anywhere is used everywhere which simplifies namespace planning a lot. Easier configuration on Load Balancer where we now only need to configure for layer 4 affinity instead of using Layer 7 as in Exchange 2007/2010.
Exchange 2013 also has an additional service “Microsoft Exchange Health Manager” which will monitor many different aspect of Exchange and not only trigger alarms but will also take actions such as do database reseed, restart services etc.

Decrease the amount of time spent managing your system while maintaining control
Administration
In Exchange 2010 is done by either PowerShell or the rather slow Exchange Management Console. In Exchange 2013 there is no EMC, it is replaced by EAC (Exchange Administration Console), a web GUI based on ECP but with much more functionality than ECP. It is not that slow as the old EMC and perform rather well, the sad story is that it is using the Metro interface with sometimes hard to figure out icons and a lot of unused space on the screen.
If you need to do something more advanced or repetitive, you should of course switch to Exchange Management Shell which is still used in the background from EAC.
Don’t know if time administer your Exchange environment will be smaller with Exchange 2013 than it is today just because switching to webGUI.

Automatically protect Exchange availability from surges in traffic
This means that things going on inside Exchange database that don’t have to happen at once is given a lover priority and is performed at a later time freeing up resources for things that need to happen quickly.

Cloud on your terms
Not that much going on here compared to Exchange 2010 Service Pack 2 as I see it.

Automatically protect your email from malware
Exchange has now a service for malware protection, Microsoft Forefront Filtering Management Service (FMS). This gives organizations a descent built in protection from scratch. If you need something better you can install the good old anti-spam agents and if you need something even more sophisticated you ought to look outside Exchange to Exchange online protection with forefront or some non-Microsoft solution.

Protect your sensitive data and inform users of internal compliance policies with Data Loss Prevention (DLP) capabilities
DLP functionality is to block information from leave Exchange. The classic is to block email with credit card information, but you can of course define what information you don’t want to be sent to internet. For organizations that need this, this is very good.

Allow compliance officers to run In-Place eDiscovery across Exchange, SharePoint, and Lync – from a single interface
Exchange 2013 index engine is replaced with FAST, same as used in SharePoint. Levering FAST functionality administrators can search for information in Exchange and SharePoint from a single interface. Also very good for organizations which need to do eDiscovery.

Allow users to naturally work together – while compliance is applied behind the scenes
Remember that outlook has the ability to connect to a document library in SharePoint. Outlook still can do this but also group the document library together with a “site mailbox” in Exchange. For this to work automatically you need Outlook 2013, Exchange 2013 and SharePoint 2013 together with some configuration in SharePoint. Only time will tell if this is something people will use.

Modern Public Folders
There is not much news here except at the server side where Public folders now use the same replication technology we have been using in DAG’s in Exchange 2010, so no more replication messages with SMTP mail between public folder databases. There is migration path for this where admin some point in time decide to do the cutover from the old replication technology to the new one. This could be critical if you have a lot of public folders today and planning is a must. Once the cutover is done we can hopefully take advantage of a more stable and faster replication than the very old one used now. Public Folder data is after the migration maintained in public folder mailboxes which you can have multiple if you like.

OWA
OWA has as usual gone through a facelift. This time it also has been designed to work well on other devices than regular PC’s such as phones and devices with smaller screens. An offline version is also available but it has some prerequisite such as IE10.

Modern people search and bring all contacts together
makes is easier to find contacts from several sources without having the mess with duplicates and easier find the correct contact. This is a good thing for end user.

OWA canvas makes calendar more useful
This is a good one for users using OWA.

Application in OWA
Administrators can now install applications in OWA to make OWA extendable. Only time will tell what applications will be available and actually provide valuable to end users.

Other insight and thoughts
Architecture in Exchange has changed. Remember when Exchange 2007 was introduced it has split the installation in different roles. Now the thinking of roles has changed again and we have only Mailbox and Client Access role left. Mailbox role is now not only the old mailbox role with its databases but a complete installation of Exchange including Unified Messaging. Services you don’t want to run can simply be disabled. The new Client Access is not the same as the old CAS, it is much lighter and act as a proxy against the mailbox role. It is sometimes called Client Access Front End (CAFE). New CAS also have some transport ability, but it is the same here as for CAS, it is only proxy SMTP traffic back to the mailbox role. All this will make the new CAS much lighter and if you today have a bunch of Exchange 2010 CAS servers you can probably be fine with a much smaller number of new CAS servers. Traffic between CAS and mailbox is https which gives the system ability to have CAS and mailbox servers in different sites without users being redirected.

There exist no Exchange 2013 Edge server role yet and if you want to use Edge server role you have to wait a while or use 2010 SP3 Edge.

Exchange 2013 can be installed on either Windows 2008 R2 SP1 or the new Windows 2012. One good thing if we use Windows Server 2012 is that clustering functionality is built-in in the standard version of Windows (there is no Windows Server 2012 Enterprise edition) which is good for license cost.

Upgrades cannot be done by inserting a DVD and run setup. Upgrades is performed by installing Exchange 2013 in parallel with you current Exchange environment that must be either Exchange 2007 or 2010 so if you’re on Exchange 2003 or earlier versions, you must first upgrade to 2007 or 2010 and then to 2013.

Outlook clients is of course the best client with most functionality even though OWA is pretty close to Outlook 2013 which of course is the preferred client since several new server functions need new client to understand them, such as DLP and site mailboxes. Microsoft made some changes in both outlook 2003 and Exchange 2010 to make outlook 2003 work correctly but this will not happen with Exchange 2013. That means you need Outlook 2007/2010 or 2013.

Some of these things might change since this is only a preview of Exchange 2013 and Microsoft will provide us with more information all the way until the finished product. Until then you can read up on the TechNet documentation about Exchange 2013 http://technet.microsoft.com/en-us/library/bb124558(v=exchg.150)

Exchange 2013 preview

Interested in seeing next version of Exchange? Look no further than to Exchange 2013 evaluation resources where you can read up on what's new and download the preview.

Both Office 2013 and Lync 2013 also has a preview available Office 2013 preview and Lync 2013 preview

Exchange 2010 Service Pack2 Update Rollup 3

Microsoft released a new update for Exchange 2010.

Download link Update Rollup 3 for Exchange 2010 SP2 (KB2685289)

This one includes several good fixes, for example RPC Client Access Cross-Site connectivity issues and the annoying Synchronization of an organizational forms library fails

Read the complete list of fixes this rollup includes

Move mailbox to free up space in databases

Admins are from time to time doing mailbox moves. Reason could be several but the goal is often to create some white space in mailbox databases.

By moving mailboxes to a different database you think it will create "holes" in the source database, and that's true until you the source server is Exchange 2010 service pack 1. With Service Pack 1 the behavior changed to leave the data it the source database until it get cleaned up when the mailbox retention limit is reached. http://technet.microsoft.com/en-us/library/ff829913.aspx
Reason for the change is that mailbox data should be easily accessed in a catastrophic failure before having a proper backup of the target database.

But what if you really want to create some space in the database now?
You could change the mailbox retention timeout to low number of days or even zero days. This might not be suitable solution and then you have to clean up the left-overs manually.
Article above say that mailboxes is in a soft-deleted state so they can be found with this command.

Get-MailboxStatistics -Database <databasename> | where {$_.DisconnectReason -eq "SoftDeleted"}

To clean up, you use the cmdlet Remove-StoreMailbox.

To make it work you do this is to steps. First save the mailboxes you want to delete in a variable.

$mbxs = Get-MailboxStatistics -Database databasename_you_want_to_clean_up | where {$_.DisconnectReason -eq “SoftDeleted”}

and then you delete them

$mbxs | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState SoftDeleted -Confirm:$false}

This will trigger a process to clean up in the database and you can follow it creating whitespace with this command

Get-MailboxDatabase -Status | Sort-Object name | Format-Table Name, DatabaseSize, AvailableNewMailboxSpace

or for a specific database

Get-MailboxDatabase -Identity databasename -Status | Format-Table Name, DatabaseSize, AvailableNewMailboxSpace

 

Remove-StoreMailbox is the same command used for purging deleted mailboxes.

$mbxs = Get-MailboxStatistics -Database databasename_you_want_to_clean_up| where {$_.DisconnectReason -eq “Disabled”}

and then

$mbxs | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState Disabled -Confirm:$false}

After you purged disabled or softdeleted mailboxes you should have created some whitespace for mailboxes to grow in without growing the EDB file.

Happy purging.

Update Calendar folder permission

Most admins have one time or another come across the need for changing permission on individual folders in mailboxes.
Most common cases I have seen this is for calendar folder in resource mailboxes.
This is an easy task but some challenges exist. To start with you use the MailboxFolderPermission cmdlet to set/add/remove permissions.

To read the existing permission on the calendar folder, run.

Get-MailboxFolderPermission -Identity LasseP

And you will see the following output.

FolderName : Top of Information Store
User : Default
AccessRights : {None}
Identity : Default
IsValid : True

FolderName : Top of Information Store
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

You see the usual Anonymous and Default permission group. Interesting here is that you see the permission for “Top of Information Store” which is the root folder in the mailbox.


To get permission for a specific folder you have to specify this as a parameter and here we must know the exact folder name. This gives us some interesting challenges for Multilanguage organization because the calendar folder can have different names.
So if I specify the calendar folder name in Swedish

Get-MailboxFolderPermission -Identity LasseP:\Kalender

I get an error because the folder name is not “Kalender”, but when specifying the English name I get what I want.

Get-MailboxFolderPermission -Identity LasseP:\Calendar

FolderName : Calendar
User : Default
AccessRights : {AvailabilityOnly}
Identity : Default
IsValid : True

FolderName : Calendar
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

Folder name must also be correct when using Set/Add-MailboxFolderPermission.
So how do we know the calendar folder name for a mailbox?
Here is neat trick we can use to get the name with Get- MailboxFolderStatistics cmdlet.

Get-MailboxFolderStatistics -Identity LasseP -FolderScope Calendar | Select-Object -First 1).Name

The output will be a text string with the calendar folder name, in our example it is “Calendar”.
Selecting only the first object is needed because users can have more than a single calendar folder and we want only the default calendar folder in the mailbox which is returned first.
Next step is to update the ACL with new permission, and here we have one more challenge. We need to figure out if we want to add permission or change existing reason for this is that we have two cmdlet to use, Add-MailboxFodlerPermission and Set- MailboxFodlerPermission. Each one of them will give an error if used in the wrong context.

To add a new user (or a group) to the ACL, run.

Add-MailboxFolderPermission -Identity LasseP:\Calendar -User Eva -AccessRights Reviewer

This will grant user Eva the reviewer permission on LasseP’s calendar folder.
Running the same cmdlet again will give you an error with “Add-MailboxFolderPermission : An existing permission entry was found for user: Eva”.

To change the permission you must use Set-MailboxFolderPermission

Set-MailboxFolderPermission -Identity LasseP:\Calendar -User Eva -AccessRights Owner

The vice versa is true if you run Set-MailboxFolderPermission and the user being granted permission is not in the ACL you will get an error saying “Set-MailboxFolderPermission : There is no existing permission entry found for user: Axel”
So before we can update the folder permission you must know if the user/group is already member of the ACL. This is accomplished by using Get-MailboxFolderPermission, this we already tried earlier.
To make things easier without issuing multiple commands I created a script.

Update-CalendarFolderPermission.ps1

########################################
# Update-CalendarPermission.ps1 -Identify <mailbox> -User <xxx> -Permission <permission>

param
(
    [Parameter(Mandatory = $true, HelpMessage="Enter a mailbox where you apply permission to")]
    [ValidateNotNullOrEmpty()]
    [string]$Identity ,

    [Parameter(Mandatory = $true, HelpMessage="Enter a user/group who will be granted the permission  syntax domain\xxx might be needed")]
    [ValidateNotNullOrEmpty()]
    [string]$User = "",
    
    [parameter(Mandatory = $true, HelpMessage="Enter a valid permission set")]
    [ValidateSet("ReadItems","CreateItems","EditOwnedItems","DeleteOwnedItems","EditAllItems","DeleteAllItems","CreateSubfolders","FolderOwner","FolderContact","FolderVisible","None","Owner","PublishingEditor","Editor","PublishingAuthor","Author","NonEditingAuthor","Reviewer","Contributor","AvailabilityOnly","LimitedDetails","Remove")]
    [string]$Permission = ""
)

#Add Exchange 2010 Management Shell if needed
if (! (Get-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:SilentlyContinue) )    {
    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:Stop
}

$MBX = Get-Mailbox $identity

$CalendarName = (Get-MailboxFolderStatistics -Identity $MBX.alias -FolderScope Calendar | Select-Object -First 1).Name
$folderID = $MBX.alias + ':\' + $CalendarName

if ($Permission -eq 'remove') {
    # special case, remove permission from user
    Remove-MailboxFolderPermission -Identity $folderID -User $User -Confirm:$False
}
else {
    $i = @(Get-MailboxFolderPermission -Identity $folderID -User $User -ErrorAction SilentlyContinue).count
    if ($i -eq 0) {
        # not in ACL, add permission
        Add-MailboxFolderPermission -Identity $folderID -User $User -AccessRights $Permission > $Null
    }
    else {
        # user is already in ACL, change permission
        Set-MailboxFolderPermission -Identity $folderID -User $User -AccessRights $Permission
    }

    # display new permission for $user
    Get-MailboxFolderPermission -Identity $folderID -User $User
}

Script isn't that hard to follow, there is some required input parameters needed. When this is handled, script continue with figuring out the calendar folder name then add or set permission depending on if user is already on ACL.

I also built in a special case where you could set permission to "remove" to remove the user from ACL on the calendar folder.


An example would be.

Update-Calendarpermission -identity Eva -User Lassep -Permission ReadItems

This will grant Lassep Read permission on Eva's calendar folder.


Script don't accept pipelining from other commands so if you want to update permission on multiple mailboxes you need to do this with two lines of code instead.

$mbx = Get-Mailbox conf*
foreach($mb in $mbx) { .\update-calendarpermission.ps1 -Identity $mb.Alias -User Lassep -Permission ReadItems}

First line is save mailboxes you want to change permission on into the $mbx variable.

Second line calls the Update-CalendarPermission script once for each mailbox in the $mbx variable.

The two line script will grant LasseP Read Permission on all 'conf*' mailboxes


now, go and play with this is a lab before running it on every mailbox in your production environment.