Tuesday, August 16, 2016

RESOLVED: You can't create a rule containing the ApplyOME or RemoveOME action because IRM licensing is disabled.

Recently enabled Office Message Encryption (OME) through a transport rule for a tenant and found the following error:

"You can't create a rule containing the ApplyOME or RemoveOME action because IRM licensing is disabled."

After some research I discovered you need to enable the Information Rights Management (IRM) licensing as follows:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/  -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc

Import-RMSTrustedPublishingDomain -RMSOnline -name "RMS Online"
Set-IRMConfiguration -InternalLicensingEnabled $True

Test-IRMConfiguration -RMSOnline

Once this is complete, you will need to wait a few hours for it to be enabled and your transport rule should complete just fine.

Message encryption reference: https://blogs.office.com/2013/11/21/introducing-office-365-message-encryption-send-encrypted-emails-to-anyone/

Thursday, June 23, 2016

RESOLVED: The connection to the server "fqdn" could not be completed.

A customer recently established a hybrid relationship with Exchange Online and encountered an issue moving a mailbox to Office 365. If they attempted to move a mailbox to Office 365 using the Exchange Admin Console web UI, they would get to the "Migration Endpoint" page of the wizard and it would fail with the error "The connection to the server 'outlook.contoso.com' could not be completed.



As it turned out, they had the same problem migrating back once we solved the issue so the fix was to use PowerShell for the moves in both cases and here is how it was done...

First off, the customer had configured the OWA and ECP virtual directories to use Windows Integrated Authentication. This caused Kerberos to be used when authenticating against these vDir's which is ultimately what was causing the issue. Additionally, if we authenticated via ADFS forms authentication, the Web Application Proxy server was performing ADFS pre-authentication (Kerberos Constrained Delegation). Lastly, when attempting the move from PowerShell, I received the following error:

The Mailbox Replication Service was unable to connect to the remote server using the credentials provided. Please check the credentials and try again. The call to 'https://outlook.contoso.com/EWS/mrsproxy.svc' failed. Error details: The HTTP request is unauthorized with client authentication

scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM,Basic realm="outlook.contoso.com"'. --> The remote server

returned an error: (401) Unauthorized.. --> The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM,Basic realm="outlook.contoso.com"'. --> The remote server returned an error: (401) Unauthorized.

+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemotePermanentException

+ FullyQualifiedErrorId : [Server=BY2PR02MB025,RequestId=fd31e252-987b-4504-b130-d7c6da62e36f,TimeStamp=6/23/2016 9:34:37 PM] [FailureCategory

=Cmdlet-RemotePermanentException] 62C7F80,Microsoft.Exchange.Management.Migration.MailboxReplication.MoveRequest.NewMoveRequest

+ PSComputerName : ps.outlook.com
 
 



To resolve the issue I had to specify the username in the pre-Windows 2000 format of "CONTOSO\Jason.Shave" and not the UPN. When you authenticate via ADFS, you must use the UPN so this made authenticating inside or out without the UPN impossible when using the web UI. At least PowerShell gives us the option of scripting whatever we want. Here is an example of the code I used to move the mailbox:

First we connect to on premises Exchange 2013 called 'exch01.contoso.local':

$credential = get-credential 'contoso\jason.shave'

$sessionOption = New-PSSessionOption -SkipRevocationCheck

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exch01.contoso.local/powershell/ -SessionOption $sessionOption -Authentication Kerberos

Import-PSSession $session

Next we connect to the Office 365 tenant:

$exoCreds = Get-Credential some.admin.id@contoso99.onmicrosoft.com

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $exoCreds -Authentication Basic -AllowRedirection

Import-PSSession $session -AllowClobber

Lastly, we move the mailbox but note we use the pre-Windows 2000 format:

$onPremCreds = Get-Credential CONTOSO\jason.shave

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $exoCreds -Authentication Basic -AllowRedirection

Import-PSSession $session -AllowClobber

Connect-MsolService -Credential $exoCreds

New-MoveRequest -Identity jason.shave@contoso.com -Remote -RemoteHostName outlook.contoso.com -TargetDeliveryDomain contoso99.onmicrosoft.com -RemoteCredential $onPremCreds -BadItemLimit 1000


The move should start and succeed!

The process for moving back on-prem is as follows:

$exoCreds = Get-Credential some.admin.id@contoso99.onmicrosoft.com

$onPremCreds = Get-Credential CONTOSO\jason.shave

New-MoveRequest -Identity Jason.shave@contoso.com -OutBound -RemoteTargetDatabase DB01 -RemoteHostName outlook.contoso.com -RemoteCredential $onPremCreds -TargetDeliveryDomain contoso.com