PermanentlyClearPreviousMailboxInfo WARNING: The command completed successfully but no settings of 'user' have been modified.

 I'm going to take one for the team on this...

So you have hybrid Exchange and Office 365 and for some reason you wind up with an account with a local Exchange Mailbox and an Office 365 mailbox.  After years of just delete the whole Office 365 account to fix the issue Microsoft finally gave us this:

Permanently Clear Previous Mailbox Info: https://blogs.technet.microsoft.com/exchange/2018/01/17/permanently-clear-previous-mailbox-info/

Great!  That's awesome!  I have a user right now that I need to fix.  Wonderful.  Glad I remember seeing that somewhere along the way.

{The actual command most people would use would be Set-User, but I use the O365 prefix to my Office 365 powershell commands so as to not clobber my local AD and Exchange powershell commands. -ED}
PS C:\Scripts\Exchange 2013> Set-O365User user@contoso.com -PermanentlyClearPreviousMailboxInfo

WARNING: The command completed successfully but no settings of 'user' have been modified.

What?  Why not?

Why is Google only telling me of other people who are seeing this same error but now resolution?

Open support ticket.  DELAY DELAY DELAY

Oh wait that user has an Exchange online license. Let's unselect that.

PS C:\Scripts\Exchange 2013> Set-O365User user@contoso.com -PermanentlyClearPreviousMailboxInfo


PS C:\Scripts\Exchange 2013>

Uhhhhhhhhhh...  Genius!  Well DUH!  So there you are.  I'm admitting that I made a pretty stupid mistake so you can read this and then not have to admit to anyone else that you did.

Hybrid Exchange mrsproxy.svc connection closed

I'm getting this error:  The connection to the server 'ews.contoso.com' could not be completed. --->  Microsoft.Exchange.MailboxReplicationService.RemoteTransientException: The call to 'https://ews.contoso.com/EWS/mrsproxy.svc' failed. Error details: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. --> The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.. ---> Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. ---> Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

Nothing on Google helps at all!  I put in a call to Office 365 support and the tech was actually worse than not helpful about this issue.  At the start he mentioned that I would likely need to pay for a support ticket to get Exchange support.  He then gave me 'best effort' support which included telling me to change all of my EWS virtual directory authentication to basic from Integrated Windows authentication, which of course Exchange warns will break Outlook Anywhere.  That didn't fix it.  His suggestion was to export to PST, delete the whole AD account for the user, create a new AD account with all the same user information, create a new local mailbox, and finally import the PST.

I have Exchange 2013 and Exchange 2016 in my org.  They are behind a hardware load balancer.  I have recreated the Migration Endpoint in Office 365 to no avail.  Migrations were fine earlier this week.  They are now broken.  I have put the HLB into maintenance mode for two servers and I am only using one server to connect with for EWS hoping that would eliminate any persistence issues.  I changed the timeout value from the working fine before 60 seconds to now still not working 600 seconds.

I now have an open paid Exchange support ticket with Microsoft.  I will update this with findings/results.

On Prem Exchange support said it was an Office 365 issue.  After a week migrations just started working again.  No changes were made by me.

Exchange contact NDR IMCEAEX NT5 00000000000000000000000000000000

Another bare bones post here.  I wish I actually understood WHY this happens.  What I do know is this does happen and here is my fix.

If you get a contact from another org you might end up seeing NDR errors that look like the following:

IMCEAEX-_o=NT5_ou=00000000000000000000000000000000_cn=...

When you get the NDR back it looks like the correct address is filled in in the message headers.  Only when you put your cursor over the person's name does the IMCEAEX address pop out.  This is what it looks like:

Delivery has failed to these recipients or groups:
LastName, FirstName
The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues, please contact your helpdesk.


Diagnostic information for administrators:
Generating server: mail.contoso.com
IMCEAEX-_o=NT5_ou=00000000000000000000000000000000_cn={32 char number}@mail.contoso.com
Remote Server returned '550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found'
Original message headers: ...

I don't know why, but appearntly it has something to do with a bad LegacyExchangeDN?

To fix it I run this command daily against my OU that the contacts are in:
Get-MailContact -OrganizationalUnit "OU=MailContacts,OU=OffSite,DC=ad,DC=mydomain,DC=com" | Update-Recipient



You may need to rebuild the OAB after doing this to solve the problem *right now* but I don't know.

mrsproxy.svc authentication scheme 'Negotiate' (403) Forbidden

The call to 'https://server.contoso.com/EWS/mrsproxy.svc' failed. Error details: The HTTP request was forbidden with client a
uthentication scheme 'Negotiate'. --> The remote server returned an error: (403) Forbidden..
    + CategoryInfo          : NotSpecified: (:) [New-MoveRequest], RemoteTransientException
    + FullyQualifiedErrorId : [Server=BL2PR02MB2129,RequestId=cd8a2403-0b3c-4fee-ad2c-a27305435b36,TimeStamp=4/20/2016
    8:51:30 PM] [FailureCategory=Cmdlet-RemoteTransientException] 8E22672D,Microsoft.Exchange.Management.Migration.Ma
  ilboxReplication.MoveRequest.NewMoveRequest
    + PSComputerName        : ps.outlook.com


Run:
Get-WebServicesVirtualDirectory |FL

Compare the URL listed above with the URLs in ExternalUrl and InternalUrl and adjust accordingly.  Create a new migration endpoint in Office 365 that uses the new name.

It's been a very long day.  I'll try to give a proper update once I have had some downtime.

[Edit below]
So in the planning for going from Exchange 2010 to Exchange 2013 I did a lot of research on load balancing and namespaces.  I decided to go for the each service has its own namespace model so that if for some reason the address book was down that owa would still show as alive.  Well I got a lesson in things you still don't know about Exchange so you're gonna learn today.

On 2010 everything was accessed via one namespace like mail.contoso.com.  So in our hybrid environment with Office 365 the migration endpoint mapping pointed to mail.contoso.com.  When I cut over the namespaces to 2013 I left mail.contoso.com for the friendly owa name and broke out all the other names.  I started getting errors in my scripts that I made to migrate mailboxes to Office 365.  The error listed above.  Of course it wasn't much help to determine what the actual problem was.

After lots of digging and hair pulling I finally stumbled upon the suggestion to use Get-WebServicesVirtualDirectory |FL and look for something else that was useless.  However I did note that the URL was not mail.contoso.com that was in there.  Not trusting that observation I changed the authentication and got the same error.  After that I removed and remade the migration endpoint mapping.  It tried to autodiscover the setting and failed.  I then put in ews.contoso.com and it was happy and my scripts were happy.

Edge transport doesn't talk to 2013 but works just fine with 2010

I could not get my Exchange 2010 Edge Transport to talk to my new Exchange 2013 server.  The Edge Transport continued to function just fine with Exchange 2010.  All the mail from my new 2013 box that was supposed to be going through the Edge Transport was just sitting in the mail queue.  I could see MSExchange EdgeSync 1032 errors in the logs.  I was also getting MSexchangeTransport 12023 errors in the event logs.  These two issues are related but I didn't know it last week when I found out that I was queuing mail.  I had to make a workaround to get mail flowing.  It wasn't until today that I fixed one and that lead me to a useful error of MSExchange EdgeSync 1033 that gave a certificate error.

I had to run
Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services SMTP
to clear MSexchangeTransport 12023 error.  Using the ECP to set the "already set" SMTP flag did not work and no error or information was shown.  Running that command from EMS asked if I wanted to replace the default SMTP certificate. I answered yes and it told me there was an Edge Transport problem and to resubscribe.  Below is a partial screenshot.

I did the resubscription and all is good now.  Now I just have to tear down my workaround. 

Site to Zone Assignment list and IEHarden

I am going to apologize for knowingly posting something incomplete on here.  Was at work late working on this issue and I'm in zombie mode today.

If your Site to Zone Assignment list via GPO seems not to be working, and especially if it is working for some users and not other users it could be a registry setting.  If a user profile is made before changing the IE Enhanced Security Mode it will inherit the registry setting.  Then you change the setting for users via Server Manger -> "Configure IE ESC" new profiles are created without the registry setting.

I connected via remote registry and under the user section for my user sid I went to
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
and found the value IEHarden set to 1.  If I set it to 0 and restarted IE it would do what I needed it to and expected it to.

I used this to solve my problems with the error of "an add-on for this website failed to run" and wouldn't start Java for a particular set of allowed sites.

Upgrading Dirsync to Azure Active Directory Connect (AADC) a cautionary tale

I usually try to be pretty thorough about things when I post.  I wasn't planning on posting a here's how you upgrade post so I have no screen shots or errors. Basically the upgrade is next next next.  The one problem that I had was that I needed to change the schedule for the sync process.  This is now a scheduled task that is automagically setup in AADC.

When you change the schedule DO NOT JUST CHANGE THE PASSWORD ON THE CREATED SERVICE ACCOUNT.  Make a new service account, or use another account to edit the scheduled task and run it.  If you want to change the password on the created service account it will mess up the encryption keys in AADC and you will have to jump through some hoops.  It is not a huge deal, but it takes way way less time to just make or use another account to run the task.  Just save yourself some time.