How to obtain an Exchange Hybrid Edition product key

As a general description, Exchange Hybrid servers are used for hybrid deployment connectivity that seamlessly connects an on-premises Exchange and Exchange Online organizations.

 

To avoid the additional cost of an Exchange 2010 SP3 or Exchange 2013 server license for the hybrid server(s), organizations may qualify for a free Hybrid Edition product key. You can request a Hybrid Edition product key if all the following conditions apply:

• You have an existing, non-trial, Office 365 Enterprise subscription;
• You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization;
• You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key.

 

Note that Exchange 2013 includes native hybrid capabilities, so you can connect your Exchange 2013 organization to Exchange Online without a Hybrid Edition server. The Hybrid Edition is only for organizations running Exchange 2007 or 2010. Exchange 2010 customers can also continue to connect their organizations directly to Exchange Online without an additional Hybrid Edition server if they are updated to the latest Service Pack, or can choose to install an Exchange 2013 hybrid server. Exchange 2003 customers can continue to use Exchange 2010 Hybrid Edition servers to connect to Exchange Online with the latest Service Pack.

 

Up to this point, nothing new. However, while previously customers had to log a support case to request a hybrid key, this has now changed. To obtain a Hybrid Edition product key for your Exchange 2013 server or Exchange 2010 SP3 server, simply go to the Exchange hybrid product key distribution wizard.

Exchange Server 2013 SP1 Transport service stops and does not restart

When upgrading Exchange 20013 to Service Pack 1, if you have servers running both back-end and front-end roles and you run the front-end Microsoft Exchange Transport service on the server, you might experience the Microsoft Exchange Transport stopping and not restarting.

 

If you stop the Microsoft Exchange Transport service, you can start the front-end Microsoft Exchange Transport service. Then, when you try to start the Microsoft Exchange Transport service, that service does not start and the following events are logged in the Application log:

Source: MSExchangeTransport

Event ID: 1019

Task Category: SmtpReceive

Level: Error

Description: Failed to start listening (Error: 10048). Binding: 0.0.0.0:25.

Source: MSExchangeTransport

Event ID: 1018

Task Category: SmtpReceive

Level: Error

Description: The address is already in use. Binding: 0.0.0.0:25.

Source: MSExchangeTransport

Event ID: 1036

Task Category: SmtpReceive

Level: Error

Description: Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly.

Source: MSExchange Common

Event ID: 4999

Task Category: General

Level: Error

Description: Watson report about to be sent for process id: 19848, with parameters: E12IIS, c-RTL-AMD64, 15.00.0847.032, MSExchangeTransport, M.Exchange.Net, M.E.P.WorkerProcessManager.HandleWorkerExited, M.E.ProcessManager.WorkerProcessRequestedAbnormalTerminationException, 5e2b, 15.00.0847.030. ErrorReportingEnabled: False

Source: MSExchange TransportService

Event ID: 1046

Task Category: ProcessManager

Level: Warning

Description: Worker process with process ID 18420 requested the service to terminate with an unhandled exception.

This issue occurs if there is a receive connector of Transport type HubTransport that has the binding set to port 25 on the affected Exchange 2013 server. On an Exchange 2013 server that has both back-end and front-end roles, only the FrontendTransport server-type receive connector should have the binding set to port 25.

To fix this issue, run the following cmdlet to change the connector type from HubTransport to FrontendTransport:

Set-ReceiveConnector –Identity "Receive connector name" –TransportRole FrontendTransport

Alternatively, delete and re-create the receive connector and set its role to FrontendTransport.

Office 365 Multi-Factor Authentication

Microsoft has recently introduced Multi-Factor Authentication (MFA) for Office 365. This feature is now part of Office 365 Midsize Business, Enterprise plans, Academic plans, nonprofit plans and standalone Office 365 plans (including Exchange Online and SharePoint Online) at no additional cost.

 

MFA has actually been available for Office 365 administrative roles since June 2013, but it is now available to any Office 365 end user. There are also improvements to the capabilities available since last year, such as App Passwords for users so they can authenticate from Office desktop applications such as Outlook, Lync, Word, etc., as these do not yet natively support MFA.

 

MFA in Windows Azure and Office 365 provides several options for users as well as backup options in the event the user is not able to authenticate using their preferred method. These are:

• MFA apps are available for Windows Phone, Android and iOS devices. Users download the free app and activate it using a code provided during setup. When the user signs-in, a notification is pushed to the app on their mobile device and the user taps to approve or deny the authentication request. Once the app is installed it can operate in 2 different modes:

1. Notification: in this mode, the app prevents unauthorized access to accounts and stops fraudulent transactions. This is done using a push notification to the phone or registered device. The user checks the notification and if it is legitimate, he/she selects Verify. Otherwise, the user can chose to Cancel or even Cancel and Report Fraud if it is a fraudulent notification;
2. One-Time Password: in this mode, the Windows Azure MFA app is used as software token to generate an OATH passcode. This passcode is then entered along with the username and password to provide the second form of authentication.

• Automated phone calls can be placed by the MFA service to any phone, landline or mobile. The user simply answers the call and presses # on the phone keypad to complete their sign in;
• Text messages can be sent by the MFA service to any mobile phone. The text message contains a one-time six-digit passcode. The user is prompted to either reply to the text message with the passcode or enter the passcode into the sign in screen.

To continue reading, please check my Office 365 Multi-Factor Authentication article on MSExchange.org which explores MFA in Windows Azure Active Directory in general with a focus on MFA for Office 365.

 

Microsoft Exchange Web Services Managed API 2.2 Released

The Exchange Web Services (EWS) Managed API 2.2 provides a managed interface for developing client applications that use EWS. The EWS Managed API simplifies the implementation of applications that communicate with versions of Exchange starting with Exchange Server 2007 SP1. Built on the EWS SOAP protocol and Autodiscover, the EWS Managed API provides a .NET interface to EWS that is easy to learn, use, and maintain.

This release also includes the Exchange Server 2013 token validation library that we can use to build mail apps for Outlook that can be authenticated by the identity tokens issued by Exchange 2013.

You can download this latest release here.

Office 365 IMAP Migration From Different Domain

Office 365 IMAP Migration From Different Domain

Often I get asked if it is possible to perform an IMAP Migration from an e-mail system that is using a different domain than the one being used in Office 365. A typical scenario are those who want to migrate from Gmail (...@gmail.com) into Office 365, either using a custom domain or the Microsoft-provided one (...@domain.onmicrosoft.com).

Most of the times, the question comes to light when they try to perform exactly this but receive the following error message:

 

MigrationRecipientNotFoundException

Migration rate:

Error: MigrationRecipientNotFoundException: A recipient wasn‎'t found for ”user@gmail.com” on the target. Create a recipient of the appropriate type for this migration on the target and try again.

 

 

 

It is perfectly possible to use IMAP migration to migrate users who have different e-mail address suffix other than the domain which verified in Office 365!

The reason why we get this error, is simply because the CSV file used in the migration was not created properly. As a quick overview, the CSV file can contain up to 50,000 rows, one row for each user, and can be as large as 10MB. However, it is always a good idea to migrate users in smaller batches.

The required attributes for each user are as follows:

• EmailAddress specifies the e-mail address of the target mailbox in Exchange Online;
• UserName specifies the user logon name for the user's source mailbox on the IMAP server (in this example Gmail);
• Password is the password for the user's account in the IMAP messaging system.

The problem here is that sometimes administrators use the EmailAddress attribute to specify the e-mail address of the source mailbox, when it is actually used to match a source mailbox to its target mailbox. However, there is no need for a source e-mail address as no similar process to autodiscover is performed. Exchange will use the username and password specified, and try to connect to the source system using the connection settings for the migration batch:

 

 

As long as all these settings are correct, you should have no problems!

High Volume of Event ID 6941 during DirSync Runs

With Directory Sync tool v1.0.6385.0012 and higher, administrators may notice a large volume of Error-level entries in the event log during Sync runs. These entries have a Source of FIMSynchronizationService, an EventID of 6941 and a Description generally starting with “ECMA2 MA export run caused an error”.

This is expected behavior. In old versions of DirSync, these events were suppressed by the tool, but the new version of the synchronization engine now logs this information to the event log. This is the same set of information that is sent to the Technical Notification Contact via e-mail.

Office 365 Domain Limit

Microsoft has increased the maximum number of domains per tenant allowed in Office 365 by 50%, from 600 domains to 900 domains.

The increase is automatic, so administrators do not need to do anything to take advantage of this improvement. Up to 900 domains can be added from the Office 365 admin portal or via remote PowerShell.

Message Trace Extended for 90 Days in Exchange Online

The lack of Message Tracking Logs in Exchange Online has been a concern for some organizations in their adoption of Office 365. Although Message Trace provided a good source of data for investigations, it was limited to the last 7 days of e-mail traffic, meaning administrators would have to frequently extract this data so it could be used later if needed.

 

Not anymore! Exchange Online Protection (EOP) and Exchange Online administrators can now check message trace information for the last 90 days.

 

To access this feature, in the Exchange admin center, click Mail flow and then click on Message trace. When we search for a message sent in the past seven days, we can view the results immediately. However, when searching for older messages, we have to submit a request for an extended message trace. To do this, simply choose the custom date range option and specify any date range in the past 90 days:

 

 

When we create a new extended trace request, we opt to receive an e-mail notification when the trace has been completed by entering an e-mail address in the Notification email address field:

 

 

 We can also choose to receive a summary list report or a detailed message trace report:

• Summary list report displays basic information about the messages traced, such as time, whether it was delivered, its subject, number of bytes, and so on;
• Detailed message trace report provides more details about messages than the summary list. To get a detailed report, when creating a new trace request, select the Include message events and routing details with report check box. In a detailed trace, all key events with all details that are available in the message tracking logs are exposed, providing an excellent data source for detailed investigations.

 

Typically, trace requests are processed within hours. The list of submitted requests and their status is displayed on the pending or completed traces page in the Exchange admin center (by clicking on View pending or completed traces under message trace) making it easy to check if a request has been completed:

 

 

Once a message trace request has completed processing, you can click Download this report in the right-hand side to view the results in a downloadable CSV file.

Exchange 2013 Platform Options

For BDMs and architects, this model describes the available platform options for Exchange 2013. Customers can choose from Exchange Online with Office 365, Hybrid Exchange, Exchange Server on-premises and Hosted Exchange. The poster includes details of each architectural option, including the most ideal scenarios for each, the license requirements and IT Pro responsibilities.

Get the poster now on PDF or Visio format from the Download Center here.

 

 

Exchange Cmdlet History in Exchange 2010/2013

Having a list of all Exchange cmdlets we ran is always useful. Besides the usual methods of getting these from the PowerShell window history (by pressing the F7 key) or from the administrator audit logs, for example, the Event Log also has a list of these cmdlets!

Both in Exchange 2010 and 2013, most cmdlets are recorded under the Applications and Services Logs -> Microsoft -> MsExchange Management event log.

In here we have entries under the MSExchange CmdletLogs source and with an EventID of 1 (cmdlet ran successfully) and/or 6 (cmdlets that failed).

For example, by running the following cmdlet: Add-MailboxPermission Mota –User Nuno –AccessRights FullAccess –InheritanceType All

We get this entry in the event log: Cmdlet Add-MailboxPermission, parameters {Identity=Mota, User=Nuno, AccessRights={FullAccess}, InheritanceType=All}.

NOTE: cmdlets started with Get-* do not get logged.

Check Account Permissions to Mailboxes

If you want to check what permissions an Active Directory user account has on a specific mailbox, simply use the following cmdlet which will enumerate all the permissions the user has on that mailbox:

Get-Mailbox "mailbox" | Get-MailboxPermission -User "AD_user"

If, alternatively, you want to check which mailboxes that specific user has permissions to, you can update the cmdlet to:

Get-Mailbox -ResultSize Unlimited | Get-MailboxPermission -User "AD_user" | FT Identity, AccessRights, Deny

However, please be careful as this cmdlet will enumerate all mailboxes in the organization. If there are dozens of thousands, you might want to target only specific mailboxes.

Modifying a user’s group membership may impact Exchange hybrid

Many organizations are currently running an Exchange Hybrid deployment between their on-premises Exchange and Exchange Online in Office 365. In this scenario, as part of the synchronization configuration, users that are added to some AD security groups before the Exchange hybrid deployment configuration is successfully written back to the on-premises AD will not have access to those features until the procedure documented below is executed.

The affected security groups are:

   • Schema Admins;

   • Enterprise Admins;

   • Cert Publishers;

   • Domain Admins;

   • Account Operators;

   • Print Operators;

   • Administrators (domain local);

   • Server Operators;

   • Backup Operators.

To resolve this issue, you should use the dsacls tool to re-provision the MSOL_AD_Sync_RichCoexistence account permissions to the AdminSDHolder object in your local Active Directory forest.

To modify the AdminSDHolder container, download and install the Windows Server 2003 Service Pack 1 (SP1) Support Tools (dsacls.exe is available as part of the Windows Support Tools).

Next, run the following commands:

dsacls CN=AdminSDHolder,CN=System,DC="mydomain",DC=com /G MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"MSExchArchiveStatus"

dsacls CN=AdminSDHolder,CN=System,DC="domain",DC="com" /G MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"MSExchBlockedSendersHash" 

dsacls CN=AdminSDHolder,CN=System,DC="domain",DC="com" /G MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"MSExchSafeRecipientsHash" 

dsacls CN=AdminSDHolder,CN=System,DC="domain",DC="com" /G MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"MSExchSafeSendersHash" 

dsacls CN=AdminSDHolder,CN=System,DC="domain",DC="com" /G MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"MSExchUCVoiceMailSettings" 

dsacls CN=AdminSDHolder,CN=System,DC="domain",DC="com" /G MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"ProxyAddresses" 

Installing DirSync on a Domain Controller

The Active Directory Sync tool [DirSync] can now be installed on an Active Directory Domain Controller [DC] as long as you install version 6553.0002 or above.

The process of installing DirSync on a DC is mostly the same as for deploying it normally. However, the administrator installing the tool will need to log-off and log-on again after the Installation Wizard is complete and before the Configuration Wizard is run. This additional step of logging off and logging back in is necessary to ensure that the Directory Sync tool is installed using the least privileges possible on the DC.

If you forget to follow the above process, the Configuration Wizard will return an “Constraint Violation Error” error. If you face this error, simply log off and log in again and you will be able to proceed.

Note that the recommendation is still to deploy DirSync on a member server rather than a DC as it will install FIM 2010 R2 SP1 and SQL Server 2012 Express SP1 by default, which can add overhead to your DC.

Exchange Server 2013 SP1 Architecture Poster

The latest version of the architecture poster for Exchange 2013 has now been released, this time for SP1.

 

Previously made available at the Microsoft Exchange Conference [MEC], it is now available to everyone at the Download Center: Microsoft Exchange Server 2013 Service Pack 1 Architecture Overview.

Azure Active Directory Sync Services goes Beta

Microsoft Azure Active Directory Sync Services (AADSync) has been announced as Customer Technology Preview (CTP) and is available through the Connect site.

AADSync, which is the next iteration of FIM2010 and DirSync, is used to onboard an on-premises environment to Windows Azure Active Directory and Office 365 and continue to synchronize changes. This new version allows for more advanced scenarios where DirSync, targeted at organizations with a single-forest, does not provide support for. Although FIM addresses scenarios that DirSync does not, it is often too complex for most IT admins to configure. With AADSync Microsoft is making this configuration a lot easier and more predictive.

One example of such scenario is the “Fully mesh with optional GALSync”, which allows users and resources to be located in any forest (commonly there would be two-way trusts between the forests). If Exchange is present in more than one forest, there could optionally be a GALSync solution representing a user in one forest as a contact in each other forest.

 

In this picture, AADSync would join on the mail attribute so a user with a mailbox in one forest is joined with the contacts in the other forests. Distribution and security groups can be found in each forest and can contain a mix of users, contacts, and FSPs (Foreign Security Principals).

For more information, please visit www.aadsync.com. Note that the content on this site will be moved to TechNet once AADSync has been released.

Stay tuned for further details on AADSync!

Office 365 and Heartbleed

As most IT people already know by now, on April 8, 2014, security researchers announced a flaw in the OpenSSL encryption software library used by many websites to protect customers’ data. The vulnerability, known as “Heartbleed”, could potentially allow a cyber-attacker to access a website’s customer data along with traffic encryption keys.

The good news for Microsoft customers/users is that, after a thorough investigation, Microsoft determined that Microsoft Account, Microsoft Azure, Office 365, Yammer and Skype, along with most Microsoft Services, are not impacted by the OpenSSL “Heartbleed” vulnerability. Windows’ implementation of SSL/TLS is also not impacted. A few Services continue to be reviewed and updated with further protections.

Exchange Hybrid Migration Endpoints

A migration endpoint is a management object in Exchange Online that contains the connection settings and administrator credentials for the source server that hosts the mailboxes that we want to migrate to Exchange Online.

For certain migration types such as a cutover or staged migration, the migration endpoint also defines the number of mailboxes to migrate simultaneously during initial synchronization and the number of mailboxes to synchronize simultaneously during incremental synchronization, which occurs once every 24 hours. During incremental synchronization, on-premises and Exchange Online mailboxes are synchronized so that new e-mails sent to mailboxes on the source server are copied to the corresponding Exchange Online mailbox.

In this post, we are going to look at migration points for a Hybrid deployment. When moving mailboxes, Exchange will try to automatically determine the migration endpoint (MRS Proxy FQDN) to be used. If unsuccessful, we can enter it manually if we are using the EAC for example. After a migration endpoint is created, it will not be deleted so that Exchange can re-use it for further migrations.

It is always recommended to test the connection settings to the server that hosts the mailboxes that we want to migrate. The connection settings will be tested when we create a migration endpoint, but verifying the settings before creating an endpoint will give us an opportunity to troubleshoot any issues (note that the Credentials parameter specifies the logon credentials for an account that can access mailboxes on the target server):

$Credentials = Get-Credential
Test-MigrationServerAvailability -ExchangeRemoteMove -Autodiscover -EmailAddress "email address for on-premises admin account" -Credentials $Credentials

For onboarding and offboarding remote move migrations in an Exchange hybrid deployment, we have to create Exchange Remote migration endpoints. The migration endpoint contains the connection settings for a Client Access server in our on-premises Exchange organization. To allow this Client Access server to accept incoming remote move requests, we have to enable the MRS Proxy endpoint by running:

Set-WebServicesVirtualDirectory "EXCH-SERVER\EWS (Default Web Site)" -MRSProxyEnabled $True
or
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $True

Note: the same Exchange Remote migration endpoint can be used for moving on-premises mailboxes to Exchange Online or for moving Exchange Online mailboxes to your on-premises organization.

The following example creates an endpoint for remote moves by using the Autodiscover parameter to detect the required settings:

$Credentials = Get-Credential
New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint -Autodiscover -EmailAddress administrator@letsexchange.com -Credentials $Credentials

Alternatively, we can manually specify the FQDN of the server(s) we want to use (this is useful in a globally dispersed environment to ensure that mailboxes are moved using a local server):

$Credentials = Get-Credential
New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint - RemoteServer MRSserver.letsexchange.com -EmailAddress administrator@letsexchange.com -Credentials $Credentials

In this case, when moving mailboxes using New-MigrationBatch we can use the SourceEndpoint parameter to specify the endpoint we just created.

To verify that we have successfully created the Remote migration endpoint, simply run:

Get-MigrationEndpoint OnpremEndpoint | FL

DirSync and Azure Active Directory Object Limits

Since May 2012 that all customers of Azure Active Directory and Office 365 have a default object limit of 50,000 objects (users, mail-enabled contacts and groups) by default.

This limit determines how many objects can be created in a tenant using DirSync, PowerShell, the GRAPH API or manually.

What some administrators are not aware of, is that when the first domain is verified, this object limit is automatically increased to 300,000 objects (each tenant is only granted one increase).

As before, if you have verified a domain and need to synchronize more than 300,000 objects OR you do not have any domains to verify and need to synchronize more than 50,000 objects, you will need to contact Azure Active Directory Support to request an increase to your object quota limit.

Also, please note that objects that were once present in your on-premises Active Directory, synchronized to Azure AD via DirSync and then deleted, may still contribute towards your Azure AD object limit for a period of up to 30 days. If the sum of these deleted objects and the remaining active objects is greater than your object limit, you may continue to receive notifications informing you that you have exceeded your object limit even though the object no longer appears in the on-premises AD or in the Azure AD directory. You can clear these by running:

Get-MsolUser -ReturnDeletedUser -All | Remove-MsolUser -RemoveFromRecycleBin –Force

Despite this 300,000 object limit, it is still recommended to run DirSync on a full installation of SQL Server if you plan to synchronize more than 50,000 objects.

Exchange Through the Ages

Exchange 2013 Server Role Requirements Calculator v6.3

v6.3 of the Exchange 2013 Server Role Requirements Calculator has just been released.

To download it click here and for more information see the Exchange 2013 Server Role Requirements Calculator post on the Exchange Team's blog.

 

Changes to this version include:

• Revised Dispart.ps1 script to create database mount points consistent with JetStress performance counters;
• Added Calculator version number to record one field three of CSV export files;
• Changes in sizing guidance.

 

As you might already know, Exchange 2013 SP1 introduced the MAPI/HTTP protocol, which causes an increase in requests handled by the CAS role when compared to requests generated by clients using RPC/HTTP. As each connection has a measurable amount of processing overhead, this results in an overall increase to our CPU requirements on CAS, moving from a 1:4 ratio of CAS to Mailbox processor cores, to a 3:8 ratio (a 50% increase)...

 

Exchange Server 2013 Server Role Requirements Calculator v6.3 has been updated to take into account this guidance change.