Exchange Cmdlet Extension Agents

Cmdlet Extension Agents are Exchange components that are invoked by cmdlets when the cmdlets run. These agents are available on any server role and, as the name suggests, they extend the capabilities of cmdlets that invoke them by assisting in processing data or performing additional actions based on the requirements of the cmdlet. They can be used to modify, replace or extend functionality of any Exchange cmdlet. For example, they can override a value provided by a user, perform actions outside of the cmdlet workflow, provide a value for a required parameter that was not provided, etc.

An example of such functionality is when creating a new mailbox. If an administrator does not specify a mailbox database when creating a new mailbox with Exchange 2007, the process fails. However, in Exchange 2010 and 2013, the New-Mailbox cmdlet invokes the Mailbox Resources Management agent whenever it is run. If a database is not specified, this agent automatically determines a suitable database on which to create the new mailbox and inserts that value into the Database parameter.

Note that cmdlet extension agents can only be invoked by Exchange 2010 and 2013 cmdlets as they are a feature introduced in Exchange 2010. Scripts cannot invoke these agents directly but if they contain Exchange 2010/2013 cmdlets, those cmdlets continue to call the cmdlet extension agents.

Unfortunately, cmdlet extension agents are not a well-known feature and, therefore, are often overlooked or ignored. A good example is the requirement that many organizations have to customize things immediately after creating a mailbox. They often develop custom scripts or even buy 3rd-party applications to achieve this, when cmdlet extension agents can very well be used to achieve most, if not all, these requirements.

In this article I use a particular cmdlet extension agent, called Scripting agent, in order to customize the mailbox provisioning process. Specifically, when a new mailbox is created, the agent will automatically configure archiving, permissions, Single Item Recovery, ActiveSync, other user attributes such as country and city, and send a welcome e-mail to the user.

To continue reading, please check the Cmdlet Extension Agents article on MSExchange.org.

 

Hyper-V Replica with Exchange Supportability

If you are considering whether to use Hyper-V Replica with Exchange, remember that Exchange has its own disaster recovery and site awareness capabilities that should be used instead.

 

Hyper-V Replica is not needed and is not supported because of problems with Exchange roles being forced back in time in the event of an unplanned failover.

DirSync Error "Microsoft.Online.PasswordSynchronization.Cryptography.dll Could Not Be Loaded"

The Directory Synchronization Tool (DirSync) is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature introduced in the latest version will not function correctly if installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

When this is the case, you will receive the following error:

Password synchronization failed for domain: "your domain".
Details: System.IO.FileLoadException: A procedure imported by 'Microsoft.Online.PasswordSynchronization.Cryptography.dll' could not be loaded.

To resolve this issue, install the Directory Sync tool on a supported Windows Server OS.

eDiscovery During Exchange 2010/2013 Coexistence

When transitioning from Exchange 2010 to 2013, you should be aware of the following in regarding to the eDiscovery feature during the coexistence period.

 

Administrator audit logs and metadata for eDiscovery searches (not search results) are stored in a system (arbitration) mailbox name SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} with the display name of Microsoft Exchange.

 

For eDiscovery to work during the period while Exchange 2010 and 2013 coexist (and after the transition), you need to move this system mailbox to an Exchange 2013 server. You can do this using the EAC or through PowerShell:

Get-Mailbox -Arbitration "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" | New-MoveRequest -TargetDatabase “Exchange_2013_database”

When the move finishes, to check if everything went OK, run the following cmdlet and ensure the Server and Database values refer to Exchange 2013:

Get-Mailbox -Arbitration “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}” | FL ServerName, Database

If you do not move this system mailbox to Exchange 2013, the following issues will occur when Exchange 2010 and Exchange 2013 coexist in your Exchange organization:

• Exchange 2013 tasks are not saved to the administrator audit log. When you run the Search-AdminAuditLog cmdlet or try to export the administrator audit log in the EAC, you will receive an error that says you cannot create an administrator audit log search because this system mailbox is located on a server that is not running Exchange 2013. A Microsoft Exchange error with an Event ID of 5000 is also logged in the Windows Application log each time a command is run;
• You cannot run eDiscovery searches using the EAC or the Shell in Exchange 2013. Mailbox searches can be created and queued, but they cannot be started. An error with an Event ID of 6 is logged in the MsExchange Management log, stating that the Start-MailboxSearch cmdlet failed. However, you can search mailboxes using the Shell and the Exchange Control Panel in Exchange 2010.

Exchange 2013 “Please restart the Microsoft Information Store service”

With Exchange 2013 Cumulative Update 1, administrators will notice that every time a new database is added, they are prompted to restart the Information Store service. Although this was also true in Exchange 2013 RTM, the difference was that before administrators did not receive this restart warning.

 

As we saw previously, Exchange 2013 introduced the new Managed Store, which uses a different memory management model than previous editions of Exchange. With a Store Worker Process for each active and passive database present on a server, it is now required to restart the Information Store service because the Store only determines the amount of memory that it will use to manage each database when it starts (which happens when the server starts or when the Information Store service is restarted).

 

In previous editions, Exchange typically seizes as much memory as it is available on a server and uses that memory to cache Store data. In Exchange 2013 this approach was revised and it now calculates how much memory it should use and makes it available to worker processes (obviously active databases are assigned more memory than passive databases). However, this new memory management approach depends on knowing how many worker processes are in use. When databases are added from a server, the Store does not re-calculate the amount of RAM for each worker process dynamically. This does not mean that you cannot mount the new database – it means caching will not be as efficient as it should be until the next time the Store process restarts and memory use is adjusted.

This might be seen as a big drawback of Exchange 2013, and it might even change in the future, but adding or removing databases should not happen that often, so the impact should not be that massive.

Differences Between FOPE and EOP

When customers using Forefront Online Protection for Exchange (FOPE) are upgraded to Exchange Online Protection (EOP), including Exchange Online and FOPE-standalone customers, there are behavior changes and feature differences to take note of, such as:

 

Quarantine access - In FOPE, end users and administrators could access the FOPE quarantine. In EOP, only administrators can access the EOP quarantine in the Exchange admin center. However, end users can self-manage their own spam-quarantined messages via end-user spam notifications;

 

Deferral notifications - FOPE could be configured to notify an administrator if an inbound message was deferred by the service. EOP does not currently have deferral notifications;

 

Multiple domain support - In FOPE, you used virtual domains to configure policy rules to apply to a specific group and route messages to a specific site. In EOP, you can route messages to a specific site by using transport rules and connectors. For instance, you can create an Outbound connector with criteria based routing enabled to deliver messages to a specific site. You can select this connector for use in a transport rule that is triggered based on a particular attribute in the transport rule predicate, such as the City property type;

 

Directory synchronization - The Office 365 DirSync tool replaces the FOPE DirSync tool;

 

Directory-Based Edge Blocking - In FOPE, the Directory-Based Edge Blocking feature enables administrators to reject email going to non-existent users in their organization rather than accept the message and try to deliver it or send it to the spam quarantine. In EOP, Directory-Based Edge Blocking is currently not supported;

 

Partner and reseller administration - If you are a Microsoft partner or reseller, and you sell EOP to your customers, you can request permission to administer their account within the Office 365 admin center. This is known as delegated administration, and it allows you to configure their EOP settings as if you were an administrator within their organization. (In the new Office 365, there isn’t a separate user interface for company administration.);

 

Connection filter IP Allow list - In FOPE, the IP Allow list was respected end-to-end only for single IP addresses. EOP's IP Allow list is respected end-to-end for single IP addresses and CIDR ranges from /32 to /24. For example, 65.55.39.10/26;

 

FOPE connectors and spam filtering - When you created or edited a FOPE connector, you could make selections to bypass spam filtering and policy-rule filtering. In EOP, you can't configure a connector to bypass filtering. Instead, Microsoft recommends that you use the connection filter's IP Allow list to bypass all spam and policy filtering;

 

Disabling anti-malware protection - The FOPE Administration Center allowed you to disable malware filtering. In EOP, malware filtering is automatically enabled for all customers. There is no way to disable it;

 

Exchange Enterprise CAL with Services - If you are an Exchange Enterprise CAL with Services customer, and you use EOP to protect your on-premises mailboxes, two additional features are available to you: Data Loss Prevention (DLP) and Remote Windows PowerShell administration. DLP helps you identify, monitor, and protect sensitive information in your organization through deep content analysis. Using Remote Windows PowerShell, you can manage your cloud features by running scripts from the command line. There is more information about EECAL with Services licensing and its included features in the Exchange Online Protection Overview.

 

Source: Office 365 Community

 

Migrating Public Folders to Exchange 2013

Now that Exchange 2007 SP3 RU10, Exchange 2010 SP3 and Exchange 2013 CU1 have been released, administrators can start deploying Exchange 2013 in a coexistence scenario with these two previous versions of Exchange.

 

Part of many transitions from Exchange 2007/2010 to 2013 will include the migration of Public Folders (PFs). Because of all the major changes made to PFs, discussed in the Exchange 2013 Preview - Public Folders article, legacy Exchange mailboxes are unable to access the PF hierarchy on Exchange 2013 servers. However, mailboxes on Exchange 2013 can connect to legacy PFs.

 

Unlike migrating PFs between previous versions of Exchange, PFs on Exchange 2013 and legacy PFs cannot coexist in an Exchange organization, which means that migrating PFs to Exchange 2013 is a one-time cut-over process.

 

Because legacy mailboxes cannot access PFs in Exchange 2013, it is recommended that all mailboxes are first moved to Exchange 2013 and only then PFs migrated.

 

The high level process for migrating Public Folders from Exchange 2007/2010 is as follows:
   1. Migrate user mailboxes to Exchange 2013 before migrating PFs;
   2. Snapshot current PF environment for comparison when migration is complete (folders, sizes and permissions);
   3. Create CSV file, manually or using scripts (Export-PublicFolderStatistics.ps1 and PublicFolderToMailboxMapGenerator.ps1). End result is a CSV file mapping PFs to new PF mailboxes;
   4. Create PF mailboxes using New-Mailbox –PublicFolder cmdlet;
   5. Migrate PF content using New-PublicFolderMigrationRequest cmdlet;
   6. Lock down Exchange 2007/2010 PFs for final migration using the following cmdlets:
         a.      Set-OrganizationConfig –PublicFoldersLockedForMigration $True (Exchange 2010)

         b.      Set-OrganizationConfig –PublicFolderMigrationComplete $True (Exchange 2013)

         c.      Set-PublicFolderMigrationRequest <name> -PreventCompletion $False (Exchange 2013)

         d.      Resume-PublicFolderMigrationRequest <name> (Exchange 2013)

   7. Test new PFs;
   8. Snapshot Exchange 2013 PFs and compare with Exchange 2007/2010 PF snapshots;
   9. Roll back, if necessary, by running Set-OrganizationConfig –PublicFoldersLockedForMigration $False and Set-OrganizationConfig –PublicFolderMigrationComplete $False;
   10. Remove Exchange 2007/2010 PFs and PF databases.

For a detailed explanation, including step by step instructions, please check MSExchange.org and the Migrating Public Folders to Exchange 2013 article.

Update-MailboxDatabaseCopy in Exchange 2013 CU1

The Update-MailboxDatabaseCopy cmdlet is used to seed or reseed a mailbox database copy. Seeding is the process in which a copy of a mailbox database is added to another Mailbox server, thus becoming the database copy into which copied log files and data are replayed. This cmdlet can also be used to seed a content index catalog for a mailbox database copy.

In Exchange 2013 CU1 this cmdlet includes some new parameters that are designed to aid with automation of seeding operations. These parameters include:

• BeginSeed – this is useful for scripting reseeds. With this parameter, the task asynchronously starts the seeding operation and then exits the cmdlet;
• MaximumSeedsInParallel – this is used with the Server parameter to specify the maximum number of parallel seeding operations that should occur across the specified server during a full server reseed operation. The default value is 10;
• SafeDeleteExistingFiles – this is used to perform a seeding operation with a single copy redundancy pre-check prior to the seed. Because this parameter includes the redundancy safety check, it requires a lower level of permissions than the DeleteExistingFiles parameter, enabling a limited permission administrator to perform the seeding operation;
• Server – this is used as part of a full server reseed operation to reseed all database copies in a Failed and Suspended state. It can be used with the MaximumSeedsInParallel parameter to start reseeds of database copies in parallel across the specified server in batches of up to the value of the MaximumSeedsInParallel parameter copies at a time.

Remember that you must suspend a database copy before you can update it using the Update-MailboxDatabaseCopy cmdlet.

DirSync Password Synchronization

The latest version of the Windows Azure Active Directory (WAAD) Sync Tool, also known as DirSync, has just been released.

Besides supporting Windows Server 2012, this new version provides the much anticipated Password Sync feature, which enables users to log into their Azure Active Directory services (such as Office 365, InTune, CRM Online, etc.) using the same password as they use to log into their on-premises network.

However, this should not be seen as a replacement for ADFS. Rather, it is an alternative for organizations that find it sufficient to have users using the same password in Office 365 as in the on-premises Active Directory. ADFS provides many other features that this tool does not, one of them being Single-Sign On (SSO) where users only need to authenticate once when they are logged on to a domain-joined client machine. With this new tool, and without ADFS, users will get prompted for credentials when accessing Office 365 resources even if they are on a domain-joined machine. The advantage is that the username and passwords are the same, and when users update their credentials on Active Directory, the password will get synchronized to WAAD. This tool does not provide SSO because there is no token sharing/exchange in the Password Sync based process.

How Password Sync Works
The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to an on-premises network and it is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service. The actual data flow of the password synchronization process is similar to the synchronization of user data such as DisplayName or Email Addresses.

Passwords are synchronized more frequently than the standard Directory Sync window for other attributes. Passwords are synchronized on a per-user basis and are generally synchronized in chronological order. When a user’s password is synchronized from the on-premises AD to the cloud, the existing cloud password will be overwritten.

When the Password Sync feature is first enables in DirSync, it will perform an initial synchronization of the passwords of all in-scope users from the on-premises Active Directory to Azure Active Directory. You cannot explicitly define the set of users that will have their passwords synchronized to the cloud. Subsequently, when an on-premises user changes their password, the Password Sync feature will detect and synchronize the changed password, most often in a matter of minutes. The Password Sync feature will automatically retry failed user password syncs. If an error occurs during an attempt to synchronize a password the error is logged in event viewer.

The synchronization of a password has no impact on currently logged on users. If a user that is logged into a cloud service also changes their on-premise password, the cloud service session will continue uninterrupted. As soon as the cloud service session expires, the user has to re-authenticate using the new password.

Security Considerations
When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment.

Password Policy Considerations
There are 2 types of password policies that are affected by enabling password sync:

• Password Complexity Policy: when you enable password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users;
• Password Expiration Policy: if a user is in the scope of the password sync feature, the cloud account password is set to "Never Expire". This means that it is possible for a user's password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password. The cloud password will be updated the next time the user changes the password in the on-premises environment.

Enabling Password Sync
Password Sync is enabled when running the Directory Sync tool Configuration Wizard. When prompted by the Wizard, select the “Enable Password Sync” checkbox. This process will trigger a full synchronization which generally takes longer than other sync cycles to complete.

NOTE: DirSync is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature will not function correctly if DirSync is installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

 

The new version of DirSync (v1.0.6385.0012) can be downloaded from your respective Office 365 Admin portal or from here.

Exchange 2013 Management Pack

The Exchange team has just released the Exchange 2013 Management Pack! You can find the Management Pack here and the guide here. The guide walks through the details of deploying, configuring and using the Management Pack.

 

Prerequisites
Before you can import the management pack, verify that the following conditions are met:

  • You have one of the following versions of System Center Operations Manager deployed in your organization:

        o System Center Operations Manager 2012 RTM or later

        o System Center Operations Manager 2007 R2 or later

  • You have already deployed SCOM agents to your Exchange Servers. Show me how.

  • The SCOM agents on your Exchange Servers are running under the local system account. Show me how.

  • The SCOM agents on your Exchange Servers are configured to act as a proxy and discover managed objects on other computers. Show me how.

  • Your user account is a member of the Operations Manager Administrators role.

 

Management Pack Scope and Benefits
The Exchange team takes monitoring seriously, and they have created a pretty comprehensive Management Pack in terms of monitoring coverage, with the primary focus being reduced downtime for an Exchange environment.

 

The Management Pack contains about 75 monitors that cover Exchange component health (such as Hub Transport health), customer touch point health (such as “is OWA working”), clustered scenarios, as well as dependencies monitoring (“is Active Directory healthy”). Monitoring covers primarily availability and performance scenarios.

 

The Exchange 2013 product comes with monitoring “built in” (more on that below). This means that Exchange itself has means to detect and try to automatically recover from availability and performance issues, before an operator is notified. This means reduced alert noise, as well as reduced administrative overhead for the Exchange product itself. In concrete terms, an Exchange server may detect an issue, then try for some time to fix it automatically. Only after the automatic recovery attempts have failed is the operator notified via an alert.

 

What’s in the Management Pack?
The Management Pack is very simple. It contains a handful of classes, 3 views, and about 75 monitors described here. There are also some dependency monitors.

 

All the monitors are simple event-based monitors using events in the Microsoft-Exchange-ManagedAvailability/Monitoring event log, logged by each Exchange server. So, each Exchange server is responsible for monitoring itself and its health.

 

In terms of scalability, this means this Management Pack will have a low impact to your Operations Manager environment. You will not require a separate Management Group for this MP for scalability purposes.

 

Where are the monitors?

If you look at the Management Pack in some tool like MP Viewer, you will discover that there are not 75 monitors in the Management Pack. This is because the Management Pack has logic to dynamically determine the set of monitors by communicating with the built-in monitoring features of Exchange (more on that below). The way to see the monitors is by installing the Management Pack in an Operations Manager environment with monitored Exchange servers and using Health Explorer (you can also see them listed in the Management Pack Guide).

 

What’s not in the Management Pack?
If you are familiar with the Exchange 2010 Management Pack, you know that it had a service called the correlation engine that ran on the Root Management Server. It basically correlated health data from all monitored Exchange components. In the Exchange 2013 Management Pack, the correlation engine is no longer used. Each monitored Exchange server is responsible for monitoring its own health, and simply reports this via the Operations Manager agent. There is a little bit of roll-up going on, from Exchange server to Organization health. There are no special components running on the Operations Manager Management Servers.

 

The Exchange 2010 Management Pack had tens of classes, leading to a pretty complex health model and many object instances being created. The Exchange 2013 Management Pack is very simple. It has only a few classes and should have a very low impact on Operations Manager in terms of instance space.

 

There are no performance counters collected by this Management Pack (as mentioned above, the monitoring does cover performance scenarios). However, all Exchange PerfMon counters are still available. It should be simple to create your own performance collection rules, if you do require them.

 

This means that by default there is way less pressure on the Management Group compared to the Exchange 2010 Management Pack, since there are no performance counters to store. But, what about reporting? There are also no reports in this Management Pack. However, you can use some of the built-in Operations Manager reports (such as the Health report) to track organization availability, or define SLAs against the Organization.

 

How does the Management Pack work?
Exchange 2013 has a built in monitoring engine called Managed Availability. It runs on every Exchange server. It contains logic for how to determine Exchange health. It detects issues, automatically performs recoveries (Exchange calls these “responders”) and ultimately notifies operators of issues, if the recoveries were not successful. The purpose of this of course, is high availability. Managed Availability is explained in more detail here.

 

 

Notification/Alerting to Operations Manager is handled via events, so the Management Pack has a set of simple event monitors that trigger based on these events. Events are logged to the Microsoft-Exchange-ManagedAvailability/Monitoring event log.

 

  • Probes: these are sets of data collectors that measure various components. There are three distinct types of probes:

      o Synthetic transactions that measure synthetic end-to-end user operations and checks that measure actual traffic;

      o Checks that measure actual customer traffic;

      o Notifications that allow Exchange to take immediate action. A good example of this is the notification that is triggered when a certificate expires.
  • Monitors: the data collected by probes are passed on to monitors that analyze the data for specific conditions and depending on those conditions determine if the particular component is healthy or unhealthy;
  • Responders: if a monitor determines that a component is unhealthy, it will trigger a responder. If the problem is recoverable, the responder attempts to recover the component using the built-in logic. There are several responders available for each component, but the one responder that’s relevant for the Exchange 2013 Management Pack is the Escalate Responder. When the Escalate Responder is triggered, it generates an event that the Exchange 2013 Management Pack recognizes and feeds the appropriate information into that alert that provides administrators with the information necessary to address the problem.

Each component in Exchange 2013 uses a specific set of probes, monitors and responders to monitor itself. These collections of probes and monitors are referred to as health sets. For example, there are a number of probes that collect data about various aspects of the ActiveSync service. This data is processed by a designated set of monitors that trigger the appropriate responders to correct any issues that they detect in the ActiveSync service. Collectively, these components make up the ActiveSync health set.

How should I work with this Management Pack?
First of all, this Management Pack should be simple to implement from an Operations Manager perspective. There are no special components to install on Management Servers, you do not need to worry about the impact to the Management Group in terms of database size, instance space, Management Server workload etc. You should be fine just importing this MP into your existing environment also for large Exchange deployments (as usual, we do recommend gradual deployment just in case). The Management Pack Guide includes a chapter on deployment, as usual you will need to enable Agent Proxy when you install the Operations Manager agents on Exchange 2013 servers.

 

Also, the Exchange team has been using the same monitoring logic in the Office365 environment. Normally, few changes to the Management Pack should be required.

 

If you want to disable some monitor, you can just create an override in Operations Manager as usual.

 

If you want to change a threshold for some monitor, this is done in the Exchange Managed Availability engine via PowerShell cmdlets. This does not involve Operations Manager at all. The Exchange Management Pack Guide walks through this scenario in some detail here. Since this kind of override is a modification of Exchange behavior, this kind of override is most commonly done by the Exchange administrator.

 

Also, Exchange Cumulative Updates may contain new or updated monitoring logic. These should be reviewed to determine the impact of that updated logic.

 

In terms of interoperability, this Management Pack does not upgrade the Exchange 2010 Management Pack, this is a completely new MP. It is possible to run these Management Packs side-by-side as you upgrade your Exchange environment from 2010 to 2013.

 

What’s the update mechanism for this Management Pack?The Managed Availability feature is built in to Exchange 2013. It contains the logic for how to detect issues and how to recover from them. The results of that is then reported to the event log for Operations Manager to pick up via event monitors. This means that updates in terms of Managed Availability monitors are shipped with Exchange Cumulative Updates.

As mentioned previously, the Exchange 2013 Management Pack has functionality to automatically detect these changes, so typically no Management Pack update is required.

 

Sources

  • Microsoft Exchange Server 2013 Management Pack
  • MP Blog: Exchange 2013 Management Pack released
  • Exchange Server 2013 Management Pack Guide

Office 365 Generic MX Records Deprecated

Microsoft has changed how e-mail is routed to Office 365 in order to provide continuing improvements in performance and reliability, and to make e-mail routing more efficient. Now, each custom domain in Office 365 has its own unique Mail Exchange (MX) record value.

Up until recently, MX records for custom domains were “generic”, meaning everyone would point the MX record for their particular domain(s) to a generic MX record such as mail.global.frontbridge.com or something similar, without any reference to the organization. These generic MX records were deprecated on 1 January 2013 and support for these records will end on 1 July 2013. As such, organizations need to update their MX records to domain-specific MX records before July.

Please note that this does not affect P1 user plans, but all E plans.

You can find the specific value(s) for your domain(s) in the domain administration section of your Office 365 tenant admin page. The values are also listed in an e-mail your organization’s technical contact should have received from Microsoft.

Login to the Office 365 portal as an administrator, click on Domains under Management on the left hand side:

Select the domain you want to update the MX records for and click on View DNS settings:

Click on View DNS records:

Scroll down until Exchange Online. In here, look for the Points to address field for MX: 

This should be in the format of “company-domain”.mail.eo.outlook.com.


If you do not update all your generic MX records by 1 July 2013, you may not receive a future update, resulting in a mail flow disruption from people outside your organization. Microsoft cannot predict when or if such an update will occur. Even though generic records will be unsupported after this date, Microsoft will e-mail customers if they know of such an update in advance.

Exchange 2013 Managed Availability

In Exchange 2013, native, built-in monitoring and recovery actions are included in a feature called Managed Availability. Managed Availability is the integration of built-in, active monitoring and the Exchange 2013 high availability platform, allowing Exchange to make a determination on when to fail over a database based on service health.

To view the health of a server, you use the cmdlets Get-ServerHealth to retrieve the raw health data and Get-HealthReport that operates on the raw health data and provides a snapshot of the health.

This example returns the server health for server MBX1:

Get-ServerHealth MBX1

The following examples return a report on the health of the server. The second cmdlet narrows this report to the Store process:

Get-ServerHealth | Get-HealthReport
Get-ServerHealth | Where {$_.HealthSetName -eq “Store”} | Get-HealthReport

Exchange Online Service Description Updated

Yesterday (April 17th) Microsoft updated the Exchange Online Service Description and added the following new items:

• New Storage and Recipient Limits topic
• New standalone Exchange Online Plan 1 & 2 feature sections in all topics

Additionally, the latest customer feedback has also been incorporated throughout all the service description topics.

Exchange 2013 Help Files Updated for CU1

The Exchange 2013 Help files (.chm) have been updated on April 4th with updates for Cumulative Update 1.

 

Here you can download the help files for both Exchange Server 2013 Hybrid and On-Premise deployments.

Exporting Queue Messages

When exporting messages from a Queue, you need to use the AssembleMessage script. For example, if you want to export the message with message ID 6789 from the letsexchange.com queue on server MBX1, you need to run the following cmdlet:

Export-Message MBX1\letsexchange.com\6789 | AssembleMessage -Path "D:\Messages\Message6789.eml"

To export all messages from a Queue into individual .eml files, use the following script (which you can convert to a one-liner):

Get-Message -Queue "MBX1\letsexchange.com" | ForEach {
  # Build message path and filename with the Internet Message ID as the file name
  $Temp = "D:\Messages\" + $_.InternetMessageID + ".eml"
  $Temp = $Temp.Replace("<", "_")
  $Temp = $Temp.Replace(">", "_")
  
  # Export the message using
  Export-Message $_.Identity | AssembleMessage -Path $Temp
}

Exchange Online Inactive Mailboxes

In Office 365 “Wave 14”, you could not discover content in disabled mailboxes (which were removed after 30 days). In order to keep content discoverable, you had to leave the mailboxes enabled, which meant they would take up licenses.

 

In the new Office 365 “Wave 15”, Microsoft introduced the concept of Inactive Mailboxes, which allows you to place a mailbox in In-Place Hold and then delete the corresponding Office 365 user account. This makes it possible to preserve the contents of deleted mailboxes indefinitely and still be able to search its content using eDiscovery!

 

The advantages/characteristics of inactive mailboxes are:

• Inactive mailboxes are not removed as long as they are placed on hold;

• After a mailbox is made inactive (by placing it on hold and then removing it), you can search content in the mailbox using In-Place eDiscovery;

• Inactive mailboxes do not require a license;

• Inactive mailboxes cannot send/receive messages and will not show up in GAL;

• They do show up in In-Place Hold and In-Place eDiscovery interfaces.

 

Important: If a hold isn't placed on a mailbox before it's deleted, the contents of the mailbox will not be preserved or discoverable. The mailbox can be recovered within 30 days of deletion, but the mailbox and its contents will be permanently deleted after 30 days if it isn't recovered.

“Creating” an Inactive Mailbox

As mentioned before, creating an inactive mailbox involves two steps: first placing the mailbox on In-Place Hold and then deleting the mailbox or corresponding Office 365 user account. After the inactive mailbox is created, its contents are preserved until the In-Place Hold is removed.

Place a mailbox on In-Place Hold

Placing a mailbox on In-Place Hold preserves all contents that were in the mailbox before it was deleted. You can place the mailbox on indefinite hold or on a time-based hold.

In an indefinite hold, the inactive mailbox and all its contents will be preserved until the hold is removed. After the hold is removed (assuming that the mailbox was deleted more than 30 days ago), the inactive mailbox will be permanently deleted and the contents of the mailbox will no longer be preserved or discoverable.

In a time-based hold, you specify the duration of the hold. This duration is on a per-item basis and is calculated from the date a mailbox item was received or created. After the hold expires for a mailbox item, the item is permanently deleted from the inactive mailbox.

To use the Shell to put a mailbox on In-Place Hold, you can use the following cmdlet:

New-MailboxSearch “Hold-Nuno” -SourceMailboxes “nuno@letsexchange.com” -InPlaceHoldEnabled $True

If you don’t specify additional search parameters for an In-Place Hold, all items in the specified source mailboxes are placed on hold. If you don’t specify the ItemHoldPeriod parameter, items are placed on hold indefinitely or until the mailbox is either removed from hold or the hold is deleted.

Delete the mailbox

After the mailbox is placed on In-Place Hold to preserve its contents, it can be deleted. The best way to delete a mailbox is to delete the corresponding Office 365 user account in the Office 365 admin center. You can also delete the mailbox by using the Remove-Mailbox cmdlet through the Shell.

Access the contents of an inactive mailbox

After you enable an inactive mailbox by placing the mailbox on In-Place Hold and then deleting the corresponding Office 365 user account, you can access the contents of the inactive mailbox by using In-Place eDiscovery in the Exchange admin center (EAC). When you search an inactive mailbox, you can create a keyword search query to search for specific items or you can return the entire contents of the inactive mailbox. You can preview the search results, copy the search results to a discovery mailbox, or export the search results to an Outlook Data (PST) file. For step-by-step procedures for searching mailboxes, see Create an In-Place eDiscovery Search.

To run an eDiscovery search you can use the EAC, the SharePoint eDiscovery Center or the Shell. This example creates an In-Place eDiscovery search called “Discovery-Nuno” for items containing the keywords LetsExchange and ProjectX that also meet the following criteria:

• Start date: 1/1/2010

• End date: 12/31/2012

• Source mailbox: Nuno

• Target mailbox: Discovery Search Mailbox

• Message types: Email

• Log level: Full

New-MailboxSearch "Discovery-Nuno" -StartDate "1/1/2010" -EndDate "12/31/2012" -SourceMailboxes "Nuno" -TargetMailbox "Discovery Search Mailbox" -SearchQuery '"LetsExchange" AND "Project X"' -MessageTypes Email -IncludeUnsearchableItems -LogLevel Full

Important: If you don’t specify additional search parameters when running an In-Place eDiscovery search, all items in the specified source mailboxes are returned in the results. If you don’t specify mailboxes to search, all mailboxes are searched.

Permanently delete an inactive mailbox

If you no longer need to preserve the contents of an inactive mailbox, you can permanently delete the inactive mailbox by removing the In-Place Hold. If the mailbox was deleted more than 30 days ago, the mailbox will be permanently deleted after you remove the In-Place Hold, and mailbox items will become non-recoverable. If the mailbox was deleted within the last 30 days, you can still restore the mailbox after removing the hold.

Set-MailboxSearch "Hold-Nuno" -InPlaceHoldEnabled $false

Remove-MailboxSearch "Hold-Nuno"

What about On-Prem?

Well, if you think about it, licensing and costs is what mainly drove this change. With Exchange on-premise you are not paying a monthly subscription cost so this is not as relevant. If a user leaves, you can easily disable the AD account, hide the mailbox from the GAL, stop mailflow, etc., and basically get the same behavior.

To keep its content discoverable, all you need to do is keep the mailbox. As long as the mailbox is not accessed by the user, you do not require a license for it (just like resource, shared and journaling mailboxes).

Also, note that in on-premises you cannot remove mailboxes that are placed on hold.

Mailbox Documents Not Indexed

Ever wanted to check which documents Exchange Search couldn’t index? The Get-FailedContentIndexDocuments cmdlet gives you exactly this information: it will return a list of documents that couldn't be indexed including an error code and the reason for failure.

The most common cause for this is the lack of an available filter for that document type. For example, if the PDF filter is not available (which is not by default) and if an e-mail contains a PDF document, the document is marked as failed content indexing as Exchange can’t index it.

After a new filter is installed, only new messages with attachments of the type for which the filter is installed are indexed. If you want to index older messages for that document type, the mailbox has to be moved, which triggers Exchange to re-index the whole mailbox content.

Some examples of reasons for failure are:

• “The document format is not recognised by the filter”;

• “This is an encrypted document”;

• “Filter not found”.

To retrieve a list of items that couldn't be indexed by Exchange Search from the mailbox of user Nuno:

Get-FailedContentIndexDocuments Nuno

To retrieve a list of items that couldn't be indexed by Exchange Search from the mailbox database DB01:

Get-FailedContentIndexDocuments -MailboxDatabase DB01

Hope this helps!

Exchange Server Jetstress 2013 Tool

Exchange JetStress 2013 has just been released and is available for download here! The changes are listed below, but the main ones include improved reports with Lost Flush* detection (an ESE improvement made in Exchange 2010 was the introduction of the Lost Flush detection mechanism which takes care of logical corruption) and a new option to allow JetStress to continue running even if a disk fails (obviously assuming there are other disks which JetStress is using) in order to support the “Storage Burn-in” scenario.

 

Overview

“Use Jetstress to verify the performance and stability of a disk subsystem prior to putting an Exchange server into production. Jetstress helps verify disk performance by simulating Exchange disk Input/Output (I/O) load. Specifically, Jetstress simulates the Exchange database and log file loads produced by a specific number of users. You use Performance Monitor, Event Viewer, and ESEUTIL in conjunction with Jetstress to verify that your disk subsystem meets or exceeds the performance criteria you establish. After a successful completion of the Jetstress Disk Performance and Stress Tests in a non-production environment, you will have ensured that your Exchange disk subsystem is adequately sized (in terms of performance criteria you establish) for the user count and user profiles you have established. It is highly recommended that the Jetstress user read through the tool documentation before using the tool.”

Improvements

• “Event log is captured and logged to the test log. Shows up on the Jetstress UI as the test is progressing;
• The error is counted against the volume it occurred on. The final report shows the counts in a new sub-section;
• A single IO error anywhere will fail the test. In case of CRC errors, they might be remapped. A re-run of Jetstress should verify that they indeed were remapped;
• Detects -1018, 1019, -1021, -1022, -1119, hung IO, DbtimeTooNew, DbtimeTooOld;
• Threads which generate IO are now controlled at a global level. Instead of specifying Threads/DB, you now specify a global thread count which work against all databases. This improves the granularity of thread tuning and enables automatic tuning to work more effectively;
• Jetstress config files generated from an older version of Jetstress are no longer allowed.”

Requirements

• .NET Framework 4.5
• Exchange 2013 binaries: ESE.DLL, ESEPerf.dll, ESEPerf.ini, ESEPerf.hxx
• VC11 runtime (I believe this is installed automatically, haven’t had the chance to test it)

Exchange 2013 Maintenance Mode

UPDATE (11/03/2013): change made to the process of emptying the queues (please see below)

With Exchange 2013, Microsoft introduced many new features to further improve Database Availability Groups, or DAGs. One of these new features is called Maintenance Mode and it enables administrators to designate a server as in-service or out-of-service by using the Set-ServerComponentState cmdlet. With Exchange 2010, administrators had to use the StartDagServerMaintenance.ps1 script or manually prepare a DAG member for maintenance.

 

As with the script, Maintenance Mode is used to tell Exchange that a particular server should not be available to service clients. In a mailbox server, an administrator will typically perform a switchover to another server (if the server to be put in maintenance mode is hosting active database copies) and then use the Set-MailboxServer and Set-ServerComponentState cmdlet to put it into maintenance mode, preventing the active copies from being activated and disabling the Transport services.

 

Enabling Maintenance Mode on a Mailbox server role is straightforward. Let’s consider mailbox server MBX1. Before you can disable the Transport service, all active queues need to be drained first:

Set-ServerComponentState MBX1 -Component HubTransport -State Draining -Requester Maintenance

If the server is part of a DAG, you must run these cmdlets to switchover any active databases currently mounted on the server and prevent those copies from being activated:

Suspend-ClusterNode MBX1

Set-MailboxServer MBX1 -DatabaseCopyActivationDisabledAndMoveNow $True

Set-MailboxServer MBX1 -DatabaseCopyAutoActivationPolicy Blocked

Once the queues are empty, you can disable all components on the server:

Set-ServerComponentState MBX1 -Component ServerWideOffline -State Inactive -Requester Maintenance

UPDATE: if you script the process and use the Get-Queue cmdlet to check how many messages are still in all the queues of the server you are placing in maintenance mode, the script might take a long time to pass this stage because of the Poison and Shadow Redundancy queues... There are two alternatives. One is to update the Get-Queue cmdlet to exclude these queues from your script:

Get-Queue -Server MBX1 | ? {$_.Identity -notmatch "Poison" -AND $_.Identity -notmatch "Shadow"}

The other option is to use the Redirect-Message cmdlet to drain active messages from all the delivery queues on the server and transfer those messages to another Mailbox server:

Redirect-Message -Server MBX1 -Target MBX2

When a message queue is drained, the active messages in the queues on the source Mailbox server are routed to the target Mailbox server. After the messages are received and queued by the target Mailbox server, the messages are made redundant. Please also note that:

• Only active messages are drained. Shadow queues aren't drained;

• Messages in the poison message queue aren't drained;

• The source server won't accept new messages while the queues are drained.

 

To take MBX1 out of Maintenance Mode all you have to do is reverse these actions. First, reactive all components:

Set-ServerComponentState MBX1 -Component ServerWideOffline -State Active -Requester Maintenance

If the server is part of a DAG, resume the cluster node and remove the restriction on the database copies:

Resume-ClusterNode MBX1

Set-MailboxServer MBX1 -DatabaseCopyActivationDisabledAndMoveNow $False

Set-MailboxServer MBX1 -DatabaseCopyAutoActivationPolicy Unrestricted

And finally resume the transport queues:

Set-ServerComponentState MBX1 -Component HubTransport -State Active -Requester Maintenance

Sources: Brian Reid | C7 Solutions and Michael Van Horenbeeck

Creating a Custom Receive Connector in Exchange 2013

Receive Connectors are used to control the flow of inbound messages into Exchange. With Exchange 2013 they are configured on servers with the Transport service (all mailbox servers) or with the Front End Transport service (all Client Access servers).

This means we can configure a Receive Connector in two different places... However, the big difference is that the Front End Transport service does not queue any messages locally while the Transport service does! Therefore, if you want Exchange to queue e-mails received by a custom Receive Connector (for example, in case of a problem with the recipient’s mailbox) you have to create it on your Mailbox servers.

Obviously, all the Receive Connectors required for internal mail flow are automatically created when a Client Access server or Mailbox server is installed. While Exchange 2007/2010 Hub Transport servers were not configured out of the box to accept e-mails from the internet, the new Client Access server comes with a Receive Connector named “Default Frontend server_name” already configured to allow “Anonymous Users” to connect to it to allow inbound flow from the Internet.

But sometimes custom Receive Connectors are required for various reasons: to control which servers receive messages from a particular IP address; to configure special connector properties for messages received from a particular IP address such as allowing larger messages or more recipients per messages; or to allow servers, applications or devices such as printers to establish unauthenticated SMTP connections to Exchange in order to send e-mails.

To create Receive Connectors in Exchange 2013 we can use the Exchange Administration Center [EAC] or the Exchange Management Shell [EMS]. In this tip, we will be using the Shell to create a Receive Connector that:
• Is associated with the Mailbox server called MBX1;
• Listens for incoming SMTP connections on the IP address 10.10.1.1 and port 25;
• Accepts incoming SMTP connections only from the IP range of 192.168.1.1 to 192.168.1.10;
• Accepts e-mails of a size up to 50MB;

New-ReceiveConnector -Name “Application 1” –Server MBX1 -Usage Custom -Bindings 10.10.1.1:25 -RemoteIPRanges 192.168.1.1-192.168.1.10 -MaxMessageSize 50MB

But what if a server is multi-role and has the Client Access and Mailbox server roles? How does Exchange know which role to associate the Receive Connector with? For these situations we have the TransportRole parameter exactly to designate the server role associated with this connector. The valid types are FrontendTransport and HubTransport.

So our example would become:

New-ReceiveConnector -Name “Application 1” –Server MBX1 -Usage Custom -Bindings 10.10.1.1:25 -RemoteIPRanges 192.168.1.1-192.168.1.10 -MaxMessageSize 50MB –TransportRole HubTransport