Wednesday, September 10, 2014

Managed Availability Failed by Design Error

If you navigate to the Exchange’s ProbeResult Crimson Channel under ActiveMonitoring, you will likely find the following error event logged:


EventID: 2
Channel: Microsoft-Exchange-ActiveMonitoring/ProbeResult
ResultId: 479968430
ServiceName: Monitoring
ResultName: HealthManagerHeartbeatProbe
Error:  Failed by design.
Exception: System.Exception: Failed by design. at Microsoft.Office.Datacenter.ActiveMonitoring.TestActiveMonitoringProbe.DoWork(CancellationToken cancellationToken) at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem.Execute(CancellationToken joinedToken) at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem. c__DisplayClass2.startexecuting b__0() at System.Threading.Tasks.Task.Execute()

So why is something failing by design?! Basically this probe is testing the Managed Availability framework, including that it can run responders. More specifically, a probe that will test that monitors can become unhealthy and execute null responders.

Bottom line, nothing to worry about :)

Tuesday, September 9, 2014

Clean-MailboxDatabase in Exchange 2013

In Exchange 2007 and 2010 we had the Clean-MailboxDatabase cmdlet to get disconnected mailboxes visible in the GUI without having to wait for the maintenance schedule.

However, in Exchange 2013 this cmdlet no longer exists but the same problem persists: disconnected mailboxes are not visible immediately after being removed or disabled.... Clean-MailboxDatabase has been replaced by Update-StoreMailboxState, which forces the mailbox store state in the Exchange store to be synchronized with Active Directory.

Its syntax is as follows:
Update-StoreMailboxState -Database “DatabaseIdParameter” -Identity “StoreMailboxIdParameter” [-Confirm [SwitchParameter]] [-WhatIf [SwitchParameter]]

Both the –Database and –Identity parameters are required, meaning we need to know the identity of the mailbox (mailbox GUID) that we want to update the store state for. To do so, we can run the following cmdlet for example:
Get-MailboxDatabase | Get-MailboxStatistics | Format-List DisplayName, MailboxGuid, Database, DisconnectReason, DisconnectDate

Once we know the mailbox’s GUID and in which database it was located, we can update its mailbox state by running:
Update-StoreMailboxState -Database “db_name” -Identity “mailbox_guid”

If we want to update the mailbox state for all mailboxes on a particular database, we can adapt the cmdlet to:
Get-MailboxStatistics -Database “db_name” | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

Finally, if we want to just update the mailbox state for all disconnected mailboxes on a particular database:
Get-MailboxStatistics -Database “db_name” | Where {$_.DisconnectReason -ne $null } | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

To be honest, I am not sure why this change from Clean-MailboxDatabase to Update-StoreMailboxState. The only reason I can think of is to give administrators the possibility to just update the state of a single mailbox instead of having to update an entire database.

Thursday, August 28, 2014

Get-LogonStatistics in Exchange 2013

The Get-LogonStatistics cmdlet is used to retrieve logon statistics about currently active sessions such as user name, logon time, last access time and client version for example.
 
As you can see from the next screenshot, the Get-LogonStatistics cmdlet is still present in Exchange 2013 all the way to the latest CU5:

 
However, if you actually try to use it, you will get an error similar to the following:
 
 
The specified mailbox "DB01" doesn't exist.
  + CategoryInfo          : NotSpecified: (:) [Get-LogonStatistics], ManagementObjectNotFoundException
  + FullyQualifiedErrorId : [Server=EXAIO,RequestId=361f29b3-6474-4aad-a43e-111fe3af86b2,TimeStamp=07/08/2014 14:42:08] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 83C28CB1,Microsoft.Exchange.Management.MapiTasks.GetLogonStatistics
  + PSComputerName        : exaio.letsexchange.com



Cannot find LogonStatistics objects from the root 'DB01'. Please make sure that you specified the correct search root and that you have the correct permissions to perform the search.
  + CategoryInfo          : NotSpecified: (:) [Get-LogonStatistics], MapiOperationException
  + FullyQualifiedErrorId : [Server=EXAIO,RequestId=ebda72ad-ce19-443e-95bf-6b417cd14d7e,TimeStamp=07/08/2014 14:42:18] [FailureCategory=Cmdlet-MapiOperationException] 3962F04B,Microsoft.Exchange.Management.MapiTasks.GetLogonStatistics
  + PSComputerName        : exaio.letsexchange.com


The reason for this error is that this cmdlet has been deprecated in Exchange 2013 since RTM! According to Microsoft, “Get-LogonStatistics is no longer supported by Exchange 2013. The cmdlet and documentation will eventually be removed.”
 
The documentation mentioned above refers to a couple of TechNet articles that still mentioned the cmdlet. However, these now seem to have been removed.

Wednesday, August 27, 2014

Exchange 2013 Loose Truncation

Loose Truncation is a new feature that was introduced in Exchange 2013 Service Pack 1. Its purpose is to prevent possible disk space issues that can occur in environments with DAGs when one or more copies of a database is offline for an extended period of time. When enabled, loose truncation changes the “normal” truncation behavior. Each database copy tracks its own free disk space and starts to truncate transaction log files independently if the available disk space falls behind a set threshold configurable by the administrator.

To continue reading, please check the full Exchange 2013 Loose Truncation article at MSExchange.org.

Friday, July 25, 2014

How to manually force a Directory Synchronization with the new DirSync tool

In the latest release of the Windows Azure Directory Synchronization tool (aka DirSync), the way we manually force a directory synchronization has changed.

In previous versions, we had to navigate to the location where DirSync was installed, launch DirSyncConfigShell.psc1 (PowerShell Console) and then run the Start-OnlineCoexistenceSync cmdlet:
 
 
However, in this latest version this console file does not exist anymore:
 
 
So how do we manually force a directory synchronization now?! Well, DirSync cmdlets are now part of a PowerShell module named DirSync. As such, simply lunch a PowerShell console with administrative rights, import this module and run the usual Start-OnlineCoexistenceSync cmdlet. Simple as that!
 
This change, however, will obviously break any scripts you might have developed, but it shouldn’t be hard to update them.


As expected, if you try to import this module in an older version of DirSync, you will get the following error as the module does not exist:
 
 
If we try to list all the cmdlets available in this module, we actually don’t receive anything back:
 
 
So where are all the DirSync PowerShell cmdlets we had in previous versions?! Not to worry. The DirSync module is actually just a wrapper which calls “%programfiles% \Windows Azure Active Directory Sync\DirSync\DirSync.psd1”. As such, if we want to list all the cmdlets, we have to check the Microsoft.Online.Coexistence.PS.Config module instead:
 
 
Unfortunately not all of these cmdlets are fully documented yet, but we can guess what most of them do based on their name anyway.
 
 
In my opinion, this change is more than welcomed as it makes life a lot easier!

Monday, July 21, 2014

Exchange 2013 with Rights Management Connector

Windows Rights Management Services (also known as Rights Management Services, Active Directory Rights Management Services or simply RMS) is a form of Information Rights Management used on Microsoft Windows that uses encryption and a form of selective functionality denial in order to limit access to information, such as e-mails or Word documents for example, and enforce what operations authorized users can perform on them.
Users can use this technology to encrypt information stored in such document formats, and through policies embedded in these, prevent the protected content from being decrypted except by specified people or groups, under certain conditions, and even for certain periods of time. Specific operations such as printing, copying, editing, forwarding and deleting can be allowed or disallowed by the author.
 
Rights Management Server first debuted in 2005 as an add-on to Windows Server 2003, with client API libraries made available for Windows XP and Windows 2000. With Windows Server 2008, it was renamed to Active Directory Rights Management Services [ADRMS], reflecting its higher level of integration with AD.

The next big “upgrade” was in July 2013 when Microsoft released a preview of Azure Rights Management which allows organizations to protect their data in Office 365. Azure RMS is included with E3, E4, A3 and A4 plans at no additional cost, or it can be purchased as a standalone subscription.
 
For organizations that are in the process of migrating to Office 365 there is a feature called RMS Connector that enables protected content to work with an organization’s online services as well as on-premises servers.
 
RMS connector lets administrators enable existing on-premises servers, such as Exchange, SharePoint or even file servers running Windows Server to use their Information Rights Management [IRM] functionality with the cloud-based RMS. With this functionality, IT and users can easily protect information both inside and outside the organization, without having to install additional infrastructure or establish trust relationships with other organizations.

The RMS connector is a small-footprint service that is installed on-premises on servers that run Windows Server 2008 R2, 2012 or 2012 R2. After installed and configured, it acts as a communications interface (a relay) between the on-premises IRM-enabled servers and the cloud service.

To read the entire article, please check Exchange 2013 with Rights Management Connector on MSExchange.org.
 
 

Monday, July 14, 2014

AssociatedItemCount versus ItemCount in Exchange

When running the Get-MailboxStatistics cmdlet, two of the attributes returned are AssociatedItemCount and ItemCount. But what exactly are the differences between the two?!
 
As one would expect, ItemCount is the total number of e-mails, contacts, etc. items available and visible to the end-user on the mailbox. Basically, everything the users sees.
 
On the other hand, AssociatedItemCount are special messages in the Associated Table of a folder. They are most often rules and other special messages like the MRM FAI message. Basically, things that are “associated” with a folder, usually other file-like objects not visible to users such as IPM.Configuration.RssRule, IPM.Configuration.AutoComplete, Outlook Rules Organizer or IPM.Microsoft.MigrationStatus.
 
These are not visible to the user, only through MFCMapi for example (right-click a folder and select Open Associated Contents table).
 
Folder Associated Information (FAI) is a collection of message objects that are stored in a folder object and are typically hidden from view by e-mail applications. An FAI Message object is used to store a variety of settings and auxiliary data, including forms, views, calendar options, favorites and category lists.

Thursday, July 10, 2014

Database Availability Group Failover during a Mailbox Move

During a mailbox move operation if the active database becomes unavailable then the Mailbox Replication Service [MRS] contacts the active manager to see which copy will take over. MRS then logs on to the mailbox on the new database and continues with the move process from where it left off. This as long as the DataMoveReplicationConstraint setting for the database is set to something else other than None and as long as the database was not down for longer than 30 minutes (or there is another copy satisfying the constraint).
 
Let us assume the database has 3 copies. It is entirely possible that MRS will just continue working after a failover even if the original server is down.
 
If DataMoveReplicationConstraint is set to None then MRS will try to connect to the same database every 30 seconds for the next 30 minutes. The 30 minute is from the maximum retry of 60 times every 30 seconds. This value can be changed in the in the msExchMailboxReplication.exe.config file.
 
The DataMoveReplicationConstraint parameter specifies the throttling behavior for high availability mailbox moves. The possible values are:
  • None: moves should not be throttled to ensure high availability. Use this setting if the database is not part of a DAG;
  • SecondCopy (default): at least one passive mailbox database copy must have the most recent changes synchronized. Use this setting to indicate that the database is replicated to one or more mailbox database copies;
  • SecondDatacenter: at least one passive mailbox database copy in another AD site must have the most recent changes replicated. Use this setting to indicate that the database is replicated to database copies in multiple AD sites;
  • AllDatacenters: at least one passive mailbox database copy in each AD site must have the most recent changes replicated. Use this setting to indicate that the database is replicated to database copies in multiple AD sites;
  • AllCopies: all copies of the database must have the most recent changes replicated. Use this setting to indicate that the database is replicated to one or more mailbox database copies.
 Note: any value other than None enables MRS to coordinate with Active Manager.

Monday, July 7, 2014

Exchange server has failed to heartbeat error after uninstalling Exchange

When you uninstall Exchange 2013, you might encounter the following error in the Event Log regarding the Managed Availability’s monitoring agent complaining that the server you uninstalled is not available:
Log Name: Microsoft-Exchange-ManagedAvailability/Monitoring
Source: Microsoft-Exchange-ManagedAvailability
Event ID: 4
Task Category: Monitoring
Level: Error
Description: Machine “uninstalled_server” has failed to heartbeat since “unistalled_date_and_time”, as observed by machine “some_other_server”. Restarting the Exchange Health Manager service did not fix the problem.

The problem is that the old server continues to be present under the following registry key for all other Exchange Servers:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Subjects

This causes the error above in the Event Log or SCOM alerts. If this happens, the workaround is to simply delete the old server(s) from the registry key mentioned above on the remaining servers.

Microsoft says that this bug was previously closed as Won’t Fix but that they have re-opened it for re-triage.

Thursday, July 3, 2014

Managing Lync Online and Exchange Online from the same PowerShell session

When working with Office 365, administrators often need to resort to PowerShell in order to perform certain configuration tasks or reporting. One “issue” is that Lync Online and Exchange Online do not share the same URI, nor do they use the same connection method. This implies that administrators need to use separate sessions to manage both Lync and Exchange Online.

But is this really true? No! It is perfectly possible to manage both products from the same instance of PowerShell. To begin with, start PowerShell and connect to Lync Online (remember that you will need Windows PowerShell Module for Lync Online):
$O365cred = Get-Credential user@domain.onmicrosoft.com
$lyncSession = New-CsOnlineSession -Credential $O365cred



Next, use a similar process to connect to Exchange Online (you do not need to create a new Credentials object):
$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $O365cred -Authentication Basic -AllowRedirection



At this point, you should have two separate remote sessions running on your computer. To verify this, type the following command at the PowerShell prompt:
Get-PSSession



You now have a pair of remote sessions that can be imported into your local session of Windows PowerShell. To do that, run these two commands:
Import-PSSession $lyncSession
Import-PSSession $exchangeSession


At this point, you will have both the Lync Online and the Exchange Online cmdlets available for use. To verify this, use the Get-CsOnlineUser and the Get-Mailbox cmdlets, for example, and make sure that you get back user information:


When you want to end your management session, make sure that you close both remote sessions:
Remove-PSSession $lyncSession
Remove-PSSession $exchangeSession

Monday, June 23, 2014

List Users' Shared Calendars

If you need to see a list of the URLs for a user's calendar that has been published for Internet access the specified calendar, you can use the following cmdlet:
Get-MailboxCalendarFolder “user”:\Calendar

This cmdlet, available in on-premises Exchange Server 2010, 2013 and Exchange Online, retrieves the publishing or sharing settings for a specified mailbox calendar. This information includes the calendar name, whether it is currently published or shared, the start and end range of calendar days published, the level of details published for the calendar, whether the published URL of the calendar can be searched on the web, and the published URL for the calendar.

 

Safe and Blocked Senders list in OWA 2013 and Office 365

It is very straightforward for end user to configure their Safe Senders and Blocked Senders list in OWA both for Exchange 2013 and in Exchange Online.

On the main page of OWA, select the gear icon at the top right of the page and select Options:

 
From the left hand pane of the Options panel, select block or allow:
 
In this page, users can add the desired sender(s) or domain(s) to the Safe Senders or Blocked Senders list by typing the e-mail address or domain name and selecting the add icon. Once all of the entries are added, scroll down to the bottom of the page and select save.

Friday, June 20, 2014

Netwrix Auditor Product Review

Netwrix is a US software company that specializes in auditing solutions for IT systems and applications. Its flagship product is Netwrix Auditor, previously known as Change Reporter Suite. Netwrix Auditor collects data on changes made to an IT infrastructure, such as Exchange, Active Directory, EMC storage, SharePoint, SQL, VMware and more. It generates reports showing the before and after values for who changed what, when and where in a human-readable format, with the possibility of long-term data archiving.
 
Netwrix Auditor is a great product that provides, in one place and in a readable format, all the auditing reports any Exchange administrator can want, something currently lacking out there. Its customizable capacities together with its reporting power, make this a great product for any type of organization where auditing is a must, from SMBs to Enterprises.
 
To continue reading, please check Netwrix Auditor Product Review at MSExchange.org.
 
 

Monday, June 16, 2014

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.

Friday, June 13, 2014

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.

Thursday, June 5, 2014

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.

Wednesday, June 4, 2014

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!

Wednesday, May 28, 2014

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.