iOS 6 Issues with Exchange

There have been some reports that iOS 6 is not working properly for many Exchange users... Apparently there are two issues:

Push E-mail

Push delivery of e-mail does not work, meaning users have to manually check for e-mails. It seems that this issue is not carrier or device specific and rebooting or reconfiguring the Exchange accounts only “fixes” the issue temporarily.

Meetings

This second issue happens when users decline a meeting invitation from an iOS 6 device. Instead of simply sending a notification to the meeting organizer, iOS 6 sends meeting cancellation notices to the entire group of attendees, cancelling the invitation for everyone!

In the environment where I work, we don’t seem to be experiencing any of these issues. Initially I asked colleagues if they were having any problems with push e-mail and they were all working fine (I believe our ServiceDesk has not received any calls regarding this yet – we have 651 devices on iOS 6 so far).

As to the second issue, I tested it three times with different users and with the new iPad, iPhone 4S and iPhone 5 and couldn’t replicate the issue...

However, this seems to be affecting many, many Exchange 2007/2010 organizations out there, so please be aware of this and test it!

UPDATE: The Exchange Team has just published a post on this: iOS6 devices erroneously take ownership of meetings!

UPDATE 2: looks like Apple has released an update for iOS 6 (available via iTunes and wirelessly) which supposedly fixes the issues of this OS with Microsoft Exchange meetings! More information here.

List Litigation Hold Users and Size

A feature introduced in Exchange 2010 RTM and that is being used more and more it Litigation Hold. It is used during a lawsuit, investigation or similar events to preserve mailbox items from inadvertent or purposeful modification or deletion by the user (or someone with access to the mailbox) and from automated deletion by retention policies. Until the hold is removed, deleted items are not purged from the mailbox database and if a mailbox item is modified, a copy of the original item is also retained. These are returned in Discovery searches performed when the mailbox is on Litigation Hold. Any retention policies applicable to the mailbox don't need to be suspended. Because messages continue to be deleted as expected (except from the Recoverable Items\Purges folder!), users may not notice they're on Litigation Hold.

 

To check if there are any users in your organization currently enabled for Litigation Hold, simply run the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True}

If you want to check the Recoverable Items folder size for all mailboxes on Litigation Hold, i.e. how many data is being held by Litigation Hold, use the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True} | Get-MailboxFolderStatistics –FolderScope RecoverableItems | FT Identity, FolderAndSubfolderSize

 

Or if you simply want to check a single mailbox:

Get-MailboxFolderStatistics <user> -FolderScope RecoverableItems | Select Identity, FolderAndSubfolderSize

Hope this helps!

How to Determine Continuous Replication Mode (Block Mode or File Mode)?

In Exchange 2007 and 2010, Continuous Replication operates by shipping copies of the logs created by the active database copy to the passive database copies. With Exchange 2010 SP1, this is known as Continuous Replication - File Mode as the log file is only copied once it is full (1MB). But SP1 introduces a new form of continuous replication known as Continuous Replication - Block Mode. In block mode, when an update is written to the active database log file it is immediately copied to the passive mailbox copies, thus reducing the latency between the time a change is made on the active copy and the time that same change is replicated to a passive copy. This way, if a failure occurs on the active copy, the passive copies will have been updated with most or all of the latest updates.

However, Block Mode is only active when continuous replication is up-to-date in file mode. The Log Copier component monitors the copy and replay queue lengths of databases as transaction logs are generated and takes care of transitioning into and out of block mode automatically.

To determine if continuous replication is operating in block mode or file mode, use the following cmdlet:

Get-Counter -ComputerName <<DAG_Member_Name>> -Counter “\MSExchange Replication(*)\Continuous replication - block mode Active”

The output will be something similar to:

Timestamp                 CounterSamples

---------                 --------------

04/09/2012 11:39:46       \\MBX1\\msexchange replication(mdb31)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb32)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb33)\continuous replication - block mode active : 0

Here, the “1” means that block mode is active while a “0” means it is not. However, note that your active databases will always show “0”, we are just interested in the passive copies!

Mailboxes Quarantined due to Troubleshoot-DatabaseSpace.ps1 Script

Exchange 2010 SP1 added a new script called Troubleshoot-DatabaseSpace.ps1 that is used to detect excessive growth of database and log drive volumes. This script can be run manually by administrators but if you have Microsoft System Center Operations Manager (SCOM) 2007 it is run automatically every 15 minutes.

This script performs the following actions:

1. Track log generation rate for the highest log generators (mailboxes) per database. This helps determine which users are logging too heavily and potentially causing space issues;

2. Track available disk space for both database and log files. If either of these is within a configurable threshold of being full (25% by default), further action must is taken;

3. Track log generation rate. If it appears that the disk is going to run out of space within the value specified by the HourThreshold parameter (12 hours by default and based on the log generation rate), further action is taken;

4. If all of the above conditions are fulfilled, the script determines the list of top 25 users who accessed the database during the last 1 hour period. The script then quarantines the top high-usage mailboxes for 6 hours, during which they will not have access to e-mail;

5. If the troubleshooter is unsuccessful at dropping the log generation rate to below the threshold level, it will write out events that translate into health model alerts. At this point, the script removes the database from provisioning by running the Set-MailboxDatabase cmdlet with the ExcludeFromProvisioning parameter set to $True against the specified database;

When mailboxes are quarantined, you will see entries in the Registry of the mailbox server hosting that database/mailbox in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\"server_name"\Private-"DB.Guid"\"Mailbox_Guid"

To check the events logged by this script go to the mailbox server you want to check and then Event Viewer -> Application and Services Logs -> Microsoft-Exchange-Troubleshooters/Operational. Note that if you run the script manually through the Shell it will not produce any output - you have to check the Event Viewer.

If you run the script manually without any parameters or if you have SCOM running this script automatically, then it will use default values specified in the StoreTSConstants.ps1 script located in the same folder. This is where you can customize the 25% threshold, for example, if it is not ideal for your environment:

   # The percentage of disk space for the EDB file at which we should start quarantining users.

   $PercentEdbFreeSpaceDefaultThreshold = 25

   # The percentage of disk space for the logs at which we should start quarantining users.

   $PercentLogFreeSpaceDefaultThreshold = 25

   # The percentage of disk space for the EDB file at which we are at alert levels.

   $PercentEdbFreeSpaceAlertThreshold = 16

   # The percentage of disk space for the EDB file at which we are at critical levels.

   $PercentEdbFreeSpaceCriticalThreshold = 8

   #The number of hours we can wait before running out of space.

   $HourDefaultThreshold = 12

In order for mailboxes to be quarantined, the –Quarantine parameter must be passed to the script, which the SCOM monitor uses by default. Because the Exchange Management Pack is sealed, you can’t change this...

So, if 25% is too high for your environment, you can change the value by updating the StoreTSConstants.ps1 script across all your mailbox servers or, ultimately, simply disable the SCOM monitors that run this script:

• KHI: Failed to execute Troubleshoot-DatabaseSpace.ps1

• KHI:The database copy is low on database volume space and continues to grow. The volume has reached critical levels 8% free.

• KHI:The database copy is low on database volume space and continues to grow. The volume has reached error levels under 16% free.

• KHI:The database copy is low on database volume space and continues to grow. The volume is under 25% free.

Resubmit Messages in Queues

There might come a time where you experience a problem with you Hub/Edge Transport servers, Mailbox servers or e-mail gateway and messages are stuck in Queues. Once you resolve the issue, you can either wait a few minutes for Exchange to resubmit the e-mails or you can manually resubmit them to the Submission queue for the categorizer to reprocess as long as they have the following status:

·         Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state;

·         Messages in the Unreachable queue that aren't in the Suspended state;

·         Messages in the poison message queue.

 

 

To manually resubmit messages, you can use the following methods (examples below):

·         Use the Retry-Queue cmdlet with the -Resubmit parameter;

·         Export the messages to .eml message files and resubmit them by placing them in the Replay directory;

·         Use Queue Viewer or the Resume-Message cmdlet to resubmit the messages in the poison message queue. You can’t use the Retry-Queue with the -Resubmit parameter cmdlet to resubmit messages in the Poison Queues.

 

 

By using the –Resubmit parameter, messages are forced to be resubmitted through the Categorizer for a new delivery attempt. If you do not use the –Resubmit parameter, the delivery queue will try to connect to the next hop immediately without resubmitting the messages through the Categorizer.

 

 

Let’s look at a few examples:

1. To export a copy of a message (so you can put it into the Replay directory) that has an InternalMessageID of 1234 that's located in the remote delivery queue for the domain MSExchange.org on the server HUB01 to the path C:\MSExchange Export\export.eml:

Export-Message HUB01\MSExchange.org\1234 -Path “C:\MSExchange Export\export.eml”

2. To resubmit all the messages in the 62306 delivery queue of the HUB01 server, use the following cmdlet (you can’t use the EMC):

Retry-Queue “HUB01\62306” -Resubmit $True

3. To resubmit all the messages in all delivery queues of server HUB01 that have a status of Retry (again, you can’t use the EMC):

Retry-Queue –Server “HUB01” -Filter {Status -eq "Retry"} -Resubmit $True

4. To resubmit all messages located in the Unreachable queue of server HUB01, use the following cmdlet (again, you can’t use the EMC):

Retry-Queue “HUB01\Unreachable” -Resubmit $True

5. Let’s force a connection attempt for all queues that are holding messages for the domain msexhange.org, have a status of Retry and are located on the server HUB01:

Retry-Queue –Server “HUB01” -Filter {NextHopDomain -eq “msexchange.org” -and Status -eq “Retry”}

 

6. To resubmit messages in the Poison Queues, you have to resume the messages. As I mentioned previously, the Poison Queue cannot be resubmitted by using the Retry-Queue cmdlet with the -Resubmit parameter.

Remember that the Poison Queue contains messages that are determined to be harmful to the Exchange system after a server failure. They may also be victims of a poorly written agent that crashed the Exchange server while it was processing them. If you're unsure of the safety of the messages in the poison message queue, you should export them to files so you can examine them.

 

Using the Exchange Management Console to resume messages in the Poison Queue:

1.       In the EMC click Toolbox;

2.       Open the Queue Viewer tool;

3.       In Queue Viewer, click the Queues tab;

4.       Click the Poison Queue and select View Messages;

5.       Select one or more messages from the list, right-click them and select Resume.

 

To use the Shell you must first determine the identity of the message to be resumed. This example will show the identity of all messages in the poison queue:

Get-Message -Queue “Poison” | Select Identity

 

Now you can use the identity to resume the message. For example, let’s resume the message with an identity value of 123:

Resume-Message 123

 

Exchange 2010 EventID 9320 and 9359

During the generation of your Offline Address Book [OAB] you might see the following warning logged in the Exchange server responsible for generating the OAB:

Log Name:      Application

Source:        MSExchangeSA

Date:          05/07/2012 05:02:35

Event ID:      9320

Task Category: (13)

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      SERVER.domain.com

Description:

OABGen could not generate full details for some entries in the offline address list for address list '\Global Address List'.  To see which entries are affected, set event logging for the offline address list generator to at least medium.

And a similar warning to the one below for many of your users:

Log Name:      Application

Source:        MSExchangeSA

Date:          05/07/2012 05:02:08

Event ID:      9359

Task Category: (13)

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      SERVER.domain.com

Description:

OALGen truncated or dropped properties for entry 'USERNAME' in address list '\Global Address List' because they exceeded the configured size limits for the version 4 offline address list.  The affected MAPI ids are:  8008. 

- \Default Offline Address List 

The possible affected MAPI IDs are:

• 0x8CD8000D = PR_EMS_AB_AUTH_ORIG

• 0x8008101F = PR_EMS_AB_IS_MEMBER_OF_DL_W

The example above with the 8008 ID is generated for each user in the OAB that is a member of a Distribution List [DL] and for each DL that has members.

This happened because the Active Directory attributes member and memberOf are not part of the truncated property list for regular groups. So when the OAB is being generated, this property is read but because Exchange can’t see it in the list, a 9359 event gets logged.

It looks like this is by design so, at the moment, there is no workaround or a way to suppress these warnings. The good news are that these warnings are expected, can be ignored and Microsoft has plans to address this!

Users do not receive quota warning messages

We all know that, for better or for worse, the way Exchange calculates and sends Quota Messages changed with Exchange 2010 SP1. We also know that this has caused nothing but confusion for many Administrators out there...

In this post I will try to give an overview of the new behaviour for normal mailboxes and, more important, explain when users will actually receive these messages.

Pre Exchange 2010 SP1

In Exchange environments previous to Exchange 2010 SP1, Exchange sends a quota message to mailbox owners when a:

1. Mailbox exceeds its IssueWarningQuota limit (the lowest storage quota);

2. Mailbox exceeds its ProhibitSendQuota limit (the middle storage quota);

3. Mailbox exceeds its ProhibitSendReceiveQuota limit (the highest storage quota).

Remember that:

• quota messages are sent to mailbox owners, so if a mailbox is owned by a security group (shared mailbox), quota messages are sent to the security group;

• quota messages are sent with high importance and are not subject to storage quotas, which means they are always delivered even if the recipient's mailbox is full;

• quotas can be configured at a mailbox or database level.

These quota messages are sent during the QuotaNotificationSchedule specified for each mailbox database, which would normally be something like every day from 4AM to 6AM:

Get-MailboxDatabase | Set-MailboxDatabase -QuotaNotificationSchedule “Mon.04:00-Mon.06:00, Tue.04:00-Tue.06:00, Wed.04:00-Wed.06:00, Thu.04:00-Thu.06:00, Fri.04:00-Fri.06:00, Sat.04:00-Sat.06:00, Sun.04:00-Sun.06:00”

During this period, Exchange goes through every mailbox in the database(s) and if any has exceeded the quota threshold, it sends the owner an e-mail. No matter if the schedule was 1h, 2h or 10h, as long as Exchange has enough time to go through every mailbox, everyone over quota receives one warning message.

Exchange 2010 SP1 Onwards

Now comes SP1 and all hell breaks loose... We still have:

• the same 3 levels of quotas;

• quotas configurable at the user or database level;

• quota messages sent during the QuotaNotificationSchedule.

BUT.... The way these messages are generated has changed... Now, every mailbox has a flag that controls whether it is checked to see if it has exceed a quota threshold. This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit! Unfortunately, this flag is a system property (part of the code) and therefore not visible using MFCMapi...

Let’s take an example and imagine a mailbox currently 450MB in size. This mailbox (or its database) has IssueWarningQuota set to 400MB and ProhibitSendQuota set to 1GB. We can see the mailbox is over its warning limit but because 450MB is not over 50% of the ProhibitSendQuota (500MB), it will not be checked and will not receive a quota warning message!

On top of this, once a mailbox has been checked during the QuotaNotificationSchedule, the flag is cleared and the mailbox will not be checked again until the flag is reset. Now, here’s the problem I found: according to Microsoft documentation, this flag is reset when “either a message is saved in the mailbox or a message is submitted”. When this happens, if the mailbox size is more than 50% of the ProhibitSendQuota, the flag is reset and the mailbox will be checked during the next QuotaNotificationSchedule.

But what exactly is a saved message?! I assumed that if a user drafted a message and saved it without sending it, the flag would be reset. However, from my tests this is not the case... So far, only sending e-mails from a mailbox seems to reset this flag. This means that if you have a mailbox that only receives e-mails, it will never receive the warning message. Again, this is what I am seeing in the environment I work at and from my tests!

You might be asking why I previously emphasised the “1” in “everyone over quota receives one warning message”. By default, with SP1 the QuotaNotificationSchedule is set to run for 15 minutes every day at 1AM. If you increase this to 2h, for example, your users might receive more than one message at a time! I had cases where I had this set to run over 3h for testing purposes, and some users received 3 quota messages...

Troubleshooting

If you would like to see if/which mailboxes are over quota or received a quota message, you have a few methods:

Increase the diagnostic logging on the mailbox server you want to check:

1. Open the Exchange Management Console;

2. Choose Server Configuration;

3. Select the the server name under Server Configuration for which you want to increase logging ;

4. Choose Manage Diagnostic Logging Properties... under the Actions pane;

5. Expand MSExchangeIS;

6. Expand 900 Private;

7. Choose Storage Limits;

8. Select the Expert radio button and click Configure;

9. You don’t need to restart the MSExchangeIS service or dismount and remount the database stores;

10. The next time the QuotaNotificationSchedule runs, look for the EventID 1077 in the Application log.

Use PowerShell to check mailbox statistics:

Get-MailboxStatistics -Database MDB01 | ? {$_.StorageLimitStatus -eq "IssueWarning" -OR $_.StorageLimitStatus -eq "ProhibitSend" -OR $_.StorageLimitStatus -eq "ProhibitSendReceive"} | Select DisplayName, Alias, StorageLimitStatus

Use PowerShell to see which users received a quota message:

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "08/08/2012" -MessageSubject "your mailbox is" –EventID DELIVER | Select TimeStamp, Recipients, MessageSubject

Exchange 2013

I have been doing some tests with Exchange 2013 to check if the behaviour is the same, but for some reason Exchange doesn’t seem to check my mailbox for quotas...

From the screenshot below, you will see that:

1. Database DB1 has ProhibitSendQuota set to 400MB and IssueWarningQuota to 200MB;

2. My mailbox is using the database’s quota defaults;

3. My mailbox is over the IssueWarningQuota limit with a size of 246MB

4. Exchange has not set the StorageLimitsStatus for my mailbox which should say IssueWarning (if it’s the same as 2007 and 2010).

It was only when I set quota limits at the mailbox level that I started to get warning messages, so I am still trying to understand exactly what is going on with Exchange 2013...

Conclusion

To reiterate, from Exchange 2010 SP1 onwards:

• Every mailbox has a flag to control if the mailbox’s quota is checked;

• This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit;
• If ProhibitSendQuota limit is not used, users will never receive a quota message; 

• If the flag is set, Exchange will send a quota message during the QuotaNotificationSchedule interval and then clear the flag;

• The flag is reset only when a message is sent from the mailbox;

Hope this helps clarifying the new behaviour regarding quota messages!

Exchange 2010 SP2 Update Rollup 4

"On August 13th 2012, the Exchange CXP team released Update Rollup 4 for Exchange Server 2010 SP2 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2706690 - Description of Update Rollup 4 for Exchange Server 2010 Service Pack 2 for more details."

Exchange 2007 SP3 Update Rollup 8

"On August 13th 2012, the Exchange CXP team released Update Rollup 8 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2734323 - Description of Update Rollup 8 for Exchange Server 2007 Service Pack 3 for more details."

DirSync Filtering

Introduction

If you subscribe to Microsoft Office 365 (with the exception of the Small Business Plan) and your company already has users in a local Active Directory [AD] environment, you can use the Microsoft Online Services Directory Synchronization [DirSync] tool to synchronize those users to your Office 365 directory.

By using DirSync, you can keep your local AD in constant synchronization with Office 365 so that any changes made to users such as contact updates for example, are propagated to Office 365.

This allows you not only to create synchronized versions of each user account and group, but also allows Global Address List [GAL] synchronization from your local Exchange environment to Exchange Online.

Synchronization

Until now, one of the problems of DirSync was that it would sync your entire AD to Office 365. This means that if you had 10,000 AD users and only wanted 500 in Office 365, you would have all 10,000 users listed in Office 365... There were a couple of methods of excluding certain objects, but none supported by Microsoft.

DirSync Filtering has been possible for early Office 365 for Education customers but now it is available to all customers, allowing you to easily exclude Organizational Units [OUs], for example, from being synchronized. Let’s have a look.

DirSync is simply a pre-configured Microsoft Identity Integration Server [MIIS] installation specific for Office 365 integration. What some administrators don’t know is that MIIS can be customized by using the MIIS Client located at:

• 32-bit: %SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell

• 64-bit: %SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell

WARNING: Before we proceed, please be very careful when using MIIS Client as it can cause harm to your office 365 environment if not used properly!

Filtering

At the time of writing of this post, there are 3 filtering options that can be applied to DirSync:

1. Organizational Units based, which allows you to select which OUs are to be synced to the cloud;

2. Domain based, allowing you to select which domains are synchronized to the cloud;

3. User attribute based, enabling you to control which objects shouldn’t be synchronized to the cloud based on their AD attributes.

NOTE: If you have already run DirSync and synced all your AD into Office 365, the objects that you now filter will no longer be synchronized and will be deleted from the cloud! If you excluded, and subsequently deleted objects because of a filtering error, you can easily re-create them in the cloud by removing the filter and then syncing the directories again.

Organizational Units Based Filtering

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Directory Partitions and then click Containers;

5. When prompted, enter domain credentials for your on-premises domain and then click OK;

6. In the Select Containers dialog box, clear the OUs that you don’t want to sync;

7. If you click in Advanced... you will be able to further control which OUs to include and exclude;

8. Click OK three times;

9. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

10. Once finished, you can check the results at the bottom left corner of the window.

Domain Based Filtering

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Directory Partitions and then select the domains that you want to synchronize. Because in my environment there is only one domain, I only get one domain listed. To exclude a domain simply clear its check box;

5. Click OK;

6. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

7. Once finished, you can check the results at the bottom left corner of the window.

User Attribute Based Filtering

As the name suggests, this third option can only be applied to user objects. It is possible to filter contacts and groups, but these use other and more complex filtering rules.

To exclude users from filtering, we can utilize around 114 AD attributes. For example, you can set extensionAttribute10 to “noOffice365” for all the users you don’t want to sync and then create a filter rule to exclude these from synchronization. After you configure in AD the attribute you want to look, here’s how you configure MIIS:

1. Log on to the computer that is running DirSync by using an account that is a member of the MIISAdmins local group;

2. Open MIIS by running miisclient.exe;

3. In Synchronization Service Manager, click Management Agents and then double-click SourceAD;

4. Click Configure Connector Filter;

5. Select user in the Data Source Object Type column. In here you can see some examples of accounts being excluded already such as Exchange System mailboxes or the MSOL_AD_Sync account used by DirSync;

6. Click New;

7. In Filter for user, on the Data Source attribute, select extensionAttribute10. For Operator select Equals and then type noOffice365 in the Value field. Click Add Condition and then click OK;

8. Click OK again;

9. On the Management Agent tab, right-click SourceAD, click Run, click Full Import Full Sync and then click OK to perform a full sync;

10. Once finished, you can check the results at the bottom left corner of the window.

Hope this helps!

Exchange Server 2013 Preview Installation

As promised, here are some more details of the brand new Exchange Server 2013 Preview! In this post, we will start by performing a simple installation of an “all-in-one” on a Windows Server 2012 virtual machine.

Roles

I will go into more details on this topic soon, but as a quick note in case you don’t know yet, Exchange 2013 Preview consists only of the following two server roles:

• Client Access server proxies connectivity for all clients (Outlook, OWA, mobile devices, POP and SMTP) and also accepts e-mail from and delivers e-mail to other mail hosts on the Internet;
• Mailbox server stores mailbox data, processes client connections proxied by the CAS and handles Unified Messaging requests. And yes, we still have DAGs   :)

Note that the Edge Transport server role isn't included with Exchange 2013 Preview. However, it supports the Exchange Server 2010 SP2 Edge Transport server role.

System Requirements

You can check the full System Requirements in the Exchange 2013 System Requirements technet page. In here, I will just provide a basic overview.

Coexistence

At this stage, Exchange 2013 Preview does not support coexistence with any other versions of Exchange... However, the RTM version is said to support coexistence starting with Exchange 2007 (not sure what Service Pack yet).

Active Directory

Your Active Directory must be at Windows Server 2003 forest functionality mode or higher, with at least one Global Catalog on Windows Server 2008.

IPv6 Support

IPv6 is supported only when IPv4 is also used. A pure IPv6 environment is still not supported...

Operating System

This one is really important, so I will mention all of them. For the Mailbox and Client Access server roles:

• Windows Server 2012

• Windows Server 2008 R2 Standard with SP1

• Windows Server 2008 R2 Enterprise with SP1

• Windows Server 2008 R2 Datacenter RTM or later

For the Management Tools:

• Windows Server 2012

• Windows Server 2008 R2 Standard with SP1

• Windows Server 2008 R2 Enterprise with SP1

• Windows Server 2008 R2 Datacenter RTM or later

• 64-bit edition of Windows 8 Release Preview

• 64-bit edition of Windows 7 with SP1

Supported Clients

Exchange 2013 Preview supports the following minimum versions of Microsoft Office Outlook and Microsoft Entourage for Mac:

• Outlook 2013 Preview

• Outlook 2010 SP1 with April 2012 Cumulative Update 

• Outlook 2007 SP3 with July 2012 Cumulative Update

• Entourage 2008 for Mac, Web Services Edition

• Outlook for Mac 2011

Virtualization

The following is supported:

• Windows Server 2012

• Windows Server 2008 R2 with Hyper-V technology

• Microsoft Hyper-V Server 2008 R2

• Any third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program.

Prerequisites

Again, you can check the full prerequisites in the Exchange 2013 Prerequisites technet page as I will just provide a basic overview and only how to install Exchange 2013 Preview on Windows Server 2012! Note that there are many more steps involved to install it on Windows Server 2008!

To install both Mailbox and CAS server roles in the same server follow these steps:

Open Windows PowerShell.

Run the following command to install the required Windows components:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

After you've installed the operating system roles and features, install the following software in this order:

• Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

• Microsoft Office 2010 Filter Pack 64 bit

• Microsoft Office 2010 Filter Pack SP1 64 bit

For the Preview edition, you must also uninstall Microsoft Visual C++ 11 Beta Redistributable (x64). This must be done after you've installed UCMA, but before you run Exchange 2013 Preview Setup! To uninstall Microsoft Visual C++ 11 Beta Redistributable (x64), do the following:

• Open Control Panel > Programs and Features.

• Select Visual C++ 11 Beta Redistributable (x64) - 11.0.50531 and then click Uninstall.

• In Microsoft Visual C++ 11 Beta setup, click Uninstall.

• When Microsoft Visual C++ 11 Beta is uninstalled, click Close.

Prepare Active Directory

Now the usual steps in order to prepare AD. From a Command Prompt window, run the following commands:

1. setup /PrepareSchema or setup /ps

2. setup /PrepareAD /OrganizationName:<organization name> or setup /p /on:<organization name>

Now run one of the following:

• Run setup /PrepareDomain or setup /pd to prepare the local domain. You don't need to run this in the domain where you ran Step 2. Running setup /PrepareAD prepares the local domain;

• Run setup /PrepareDomain:<FQDN of domain you want to prepare> to prepare a specific domain;

• Run setup /PrepareAllDomains or setup /pad to prepare all domains in your organization.

If you want to verify that AD has been successfully prepared:

• In the Schema naming context, verify that the rangeUpper property on ms-Exch-Schema-Verision-Pt is set to 15132;

• In the Configuration naming context, verify that the objectVersion property in the CN=<your organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container is set to 15448;

• In the Default naming context, verify that the objectVersion property in the Microsoft Exchange System Objects container under DC=<root domain> is set to 13236.

Install Exchange 2013 in Unattended Mode

The unattended mode is very similar to what it has been in the previous versions. The only differences so far seem to be the addition of the [/IAcceptExchangeServerLicenseTerms] parameter and the removal of [/AdamLdapPort:<port>], [/AdamSslPort:<port>], [/LanguagePack:<language pack bundle>] and [/Hosting]:

Setup.exe
[/Mode:"setup mode"]
[/IAcceptExchangeServerLicenseTerms]
[/Role:"server roles to install"]
[/InstallWindowsComponents]
[/OrganizationName:"name for the new Exchange organization"]
[/TargetDir:"target directory"]
[/SourceDir:"source directory"]
[/UpdatesDir:"directory from which to install updates"]
[/DomainController:"FQDN of domain controller"]
[/AnswerFile:"filename"]
[/DoNotStartTransport]
[/LegacyRoutingServer]
[/EnableErrorReporting]
[/NoSelfSignedCertificates]
[/AddUmLanguagePack:"UM language pack name"]
[/RemoveUmLanguagePack:"UM language pack name"]
[/NewProvisionedServer:"server"]
[/RemoveProvisionedServer:"server"]
[/MdbName:"mailbox database name"]
[/DbFilePath:"Edb file path"]
[/LogFolderPath:"log folder path"]
[/Upgrade]

For example:

Setup.exe /mode:Install /role:ClientAccess,Mailbox /OrganizationName:LetsExchange /IAcceptExchangeServerLicenseTerms

This command creates an Exchange 2013 Preview organization in Active Directory called LetsExchange, installs the Client Access server role, Mailbox server role and the management tools, and accepts the Exchange 2013 Preview licensing terms.

Setup.exe /mode:Install /role:ClientAccess,Mailbox /TargetDir:"C:\Exchange Server"

This command installs the Client Access server role, the Mailbox server role and the management tools to the "C:\Exchange Server" directory. This command assumes an Exchange 2013 Preview organization has already been prepared.

Install Exchange 2013 Using the Setup Wizard

1. Start Exchange 2013 Preview Setup by double-clicking Setup.exe;

2. On the Check for Updates page, choose whether you want Setup to connect to the Internet and download product and security updates for Exchange 2013 Preview. Click next to continue;

3. On the Copying File page, Setup copies files required for setup. When Setup is finished copying files and is ready to begin, click next;

4. The Introduction page begins the process of installing Exchange. Click next to continue;

5. On the License Agreement page, review the software license terms. Select I accept the terms in the license agreement and then click next;

6. On the Error Reporting page, select whether you want to enable or disable the Exchange Error Reporting feature, and then click next;

7. On the Checking Required Software page, Setup makes sure that you've installed the software required for setup to run. If any applications are listed, install them and then run Setup again. If all required software is found, click next to continue;

8. On the Server Role Selection page, choose whether you want to install the Mailbox role, the Client Access role, both roles or just the Management Tools (you can add additional server roles later if you choose not to install them during this installation). Click next to continue;

9. On the Installation Space and Location page, either accept the default installation location or click Browse to choose a new location. Make sure that you have enough disk space available in the location where you want to install Exchange. Click next to continue;

10. If this is the first Exchange server in your organization, on the Exchange Organization page, type a name for your Exchange organization;

11. If you want to use the Active Directory split permissions model, select Apply Active Directory split permission security model to the Exchange organization. Click next to continue;

12. If you're installing the Mailbox role, on the Malware Protection Settings page, choose whether you want to enable or disable malware scanning. If you disable malware scanning, it can be enabled in the future. Click next to continue;

13. If you're installing the Client Access server role, on the Configure Client Access Server external domain page, click This Client Access server will be Internet-facing if the Client Access server you're installing will be accessible from the Internet. Then, enter a domain name to use to configure your Client Access servers. If the Client Access server won't be Internet-facing, you can click next without configuring a domain name. Click next to continue;

14. On the Customer Experience Improvement Program page, choose the appropriate selections for your organization, and then click next to continue;

15. On the Readiness Checks page, view the status to determine if the organization and server role prerequisite checks completed successfully. If they haven't completed successfully, you must resolve any reported errors before you can install Exchange 2013 Preview. From the screenshots below you will see I was missing a few updates... If/when all readiness checks have completed successfully, click next to install Exchange 2013 Preview;

16. On the Completion page, click Finish;

17. Restart the computer after Exchange 2013 Preview has completed;

18. Complete your deployment by performing the tasks provided in Exchange 2013 Post-Installation Tasks.

Overview

As I mentioned before, this post is only about installing Exchange 2013 Preview. I will be posting more about this new version of Exchange, but in the mean time here are some screenshots to satisfy your curiosity:

Exchange Administration Center

Exchange Management Shell

Exchange Toolbox

OWA

Stay tuned for more on Exchange 2013!