We're on a hybrid setup (Exchange 2013 on-prem), and MRSproxy is enabled and working. We want to archive our user's mailbox when they leave the company. So we want to migrate those mailbox from the Office 365 back to our on premise server. I've been trying to create a leaving script, and the New-MoveRequest
cmdlet keeps on giving 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://webmail.blah.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'. --> 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'. --> The remote server returned an
error: (401) Unauthorized.
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemotePermanentException
+9,Microsoft.Exchange.Man
agement.Migration.MailboxReplication.MoveRequest.NewMoveRequest
+ PSComputerName : outlook.office365.com
So I tested with Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer webmail.blah.com -Credentials $UserName<#>
with the 3 following type of PSCredentials:
UserName1 : <domain>\<SamAccountName>
UserName2 : <SamAccountName>
UserName3 : <SamAccountName>@<domain> (UPN)
With UserName1
and UserName2
I get
RunspaceId : 3966b356-0f49-46c3-9373-e914827fc6ed
Result : Success
Message :
ConnectionSettings : <ExchangeConnectionSettings HasAdminPrivilege="True" HasAutodiscovery="False" HasMrsProxy="True" AutodiscoverUrl="" IncomingEmailAddress="" IncomingRPCProxyServer="webmail.blah.ccom"
IncomingExchangeServer="webmail.blah.com" IncomingNSPIServer="" IncomingDomain="" IncomingUserName="UserName<#>" EncryptedIncomingPassword="something"
IncomingAuthentication="Basic" ServerVersion="" TargetDomainName="" SourceMailboxLegDn="" PublicFolderDatabaseServerLegacyDN="" IsPublicFolderMailboxesMigrationSource="False" />
SupportsCutover : False
ErrorDetail :
IsValid : True
Identity :
ObjectState : New
but with UserName3
I get :
RunspaceId : 3966b356-0f49-46c3-9373-e914827fc6ed
Result : Failed
Message : The connection to the server 'webmail.blah.com' could not be completed.
ConnectionSettings :
SupportsCutover : False
ErrorDetail : Microsoft.Exchange.Migration.MigrationServerConnectionFailedException: The connection to the server 'webmail.blah.com' could not be completed. --->
Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: 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://webmail.blah.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'. --> 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'. --> The remote server returned an error: (401) Unauthorized. --->
Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The call to 'https://webmail.blah.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'. --> The remote server returned an error: (401) Unauthorized.. --->
Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from
the server was 'Negotiate,NTLM'. ---> Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The remote server returned an error: (401) Unauthorized.
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
at Microsoft.Exchange.MailboxReplicationService.MailboxReplicationServiceFault.<>c__DisplayClass97_0.<ReconstructAndThrow>b__0()
at Microsoft.Exchange.MailboxReplicationService.ExecutionContext.Execute(Action operation)
at Microsoft.Exchange.MailboxReplicationService.MailboxReplicationServiceFault.ReconstructAndThrow(String serverName, VersionInformation serverVersion)
at Microsoft.Exchange.MailboxReplicationService.WcfClientWithFaultHandling`2.<>c__DisplayClass7_0.<CallService>b__0()
at Microsoft.Exchange.Net.WcfClientBase`1.CallService(Action serviceCall, String context)
at Microsoft.Exchange.MailboxReplicationService.WcfClientWithFaultHandling`2.CallService(Action serviceCall, String context)
at Microsoft.Exchange.Migration.MigrationExchangeProxyRpcClient.CanConnectToMrsProxy(Fqdn serverName, Guid mbxGuid, NetworkCredential credentials, LocalizedException& error)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Migration.DataAccessLayer.ExchangeRemoteMoveEndpoint.VerifyConnectivity()
at Microsoft.Exchange.Management.Migration.MigrationService.Endpoint.TestMigrationServerAvailability.InternalProcessEndpoint(Boolean fromAutoDiscover)
IsValid : True
Identity :
ObjectState : New
Looking at the TechNet article for both New-MoveRequest
and Test-MigrationServer
the Credentials/RemoteCredential
parameter should accept UPN usernames.
Is this a limit with Exchange 2013? I can Remote-PSSession to the on premise Exchange server with the UPN username, and import the CMDlet, so I'm at a lost why it doesn't work with New-MoveRequest
and Test-MigrationServer
loaded from Office 365?
Best Answer
It could just be the implementation of the CMDLET and how it is negotiating the connection. Your endpoint is configured with Negotiate, so the client and server should decide if you are using kerberos or NTLM. In your failed attempt it did not detect either correctly, and tried to fall back to Basic Auth - which your server is not configured to support.
NTLM does not support the UPN format, and you did not have a kerberos ticket, so this could be the reason. You generally don't run into this with Windows clients/servers often as most applications seem to take care of reformatting the username reqeust. However if your samAccountName and UPN pre-fix are different then the credentials won't match.
I would be sure your samAccountName and UPN prefixes match on the account. If not, or if they still fail, you should be able to enable basic auth on EWS. This should allow it to fall back on the client side and be accepted on the server side. Since this is an O365 connection, I think we can assume safely your already using HTTPS - which of course is critical if your using Basic Auth as the credentials are sent in plan text.