MSExchangeRepl 2147 / MSExchangeRepl 2104 / MSExchangeRepl 2127 occurring on Windows 2008 or Windows 2008 R2 with Exchange 2007 Cluster Continuous Replication (CCR)

As i ran into this issue this week,I’ve stumbled upon this thread: http://social.technet.microsoft.com/Forums/en-US/exchangesoftwareupdate/thread/eca3bbf7-ee9f-41bd-89e8-47a81780292b

Seems the cause for these errors, are because SMBv2 introduces status caching into the LanManWorkstation service…read more at SMB2 Client Redirector Cache

So to fix it I’ve added these registry keys under :

HKLMSystemCurrentControlSetServicesLanmanworkstationParameters
FileInfoCacheLifetime [DWORD] = 0
FileNotFoundCacheLifetime [DWORD] = 0
DirectoryCacheLifetime [DWORD] = 0

My errors on the server were:

Event ID : 2147
Raw Event ID : 2147
Source : MSExchangeRepl
Type : Error
Machine : SERVER
Message : There was a problem with ‘ActiveNode’, which is an alternate name for ‘ActiveNode’. The list of aliases is now ‘ActiveNode’, and the alias ‘was’ removed from the list. The specific problem is ‘CreateFile(
\ActiveNodeStorageGroupGuid$LogFile.log) = 2′.

ID:       2127
Level:    Information
Provider: MSExchangeRepl
Machine:  SERVER
Message:  The system has detected a change in the available replication networks.  The system is now using network ‘ActiveNode’ instead of network ‘ActiveNode’ for log copying from node ActiveNode.

Thanks a lot for JR on sharing this, check out Tim McMichael with more info on this:

http://blogs.technet.com/b/timmcmic/archive/2010/07/11/msexchangerepl-2147-msexchangerepl-2104-msexchangerepl-2127-occurring-on-windows-2008-or-windows-2008-r2-with-exchange-2007-cluster-continuous-replication-ccr.aspx

How to Use Telnet to Send SMTP Email to Exchange 2007 and 2010

Thanks to Jeff – The EXPTA {blog}, you can have full how-to ” use telnet to send SMTP email” for some basic testing and such.

I’ve ran into A lot of issues when migrating to Exchange 2007 / Exchange 2010 , due to the strict RFC compliance that Microsoft has implemented with the new transport (SMTP) stack.

anyways, enjoy this fine how-to:

http://www.expta.com/2010/03/how-to-use-telnet-to-send-smtp-email-to.html

How to publish Exchange 2003 and Exchange 2010 with ISA 2006

Hi,

First Step-By-Step !

This guide will show you how to configure ISA 2006 for coexistence of Exchange 2003 with Exchange 2010 remote connectivity services, including:

  • Outlook Web Access & Outlook WebApp
  • Microsoft ActiveSync
  • RPCoverHTTP – Outlook Anywhere
  • Publishing Exchange 2010 FARM – two client access servers

This guide assumes that:

  • ISA 2006 is configured to publish OWA 2003 and all additional services
  • SSL is configured for the Exchange 2003 server
  • Windows Integrated Authentication is enabled on the ActiveSync Vdir in the Exchange 2003 Back-End server ( http://support.microsoft.com/?kbid=937031 )
  • RPC-over-HTTP was working for for 2003 mailboxes, and the 2003 back-end is configured as an RPC-over-HTTP
  • The current configuration works 😉
  • This guide will not cover scenarios when exchange is directly exposed to the internet. which I personally do not recommend in generally….

Okay here we go:

  1. Configure redirection for Exchange 2003 OWA:
    Exchange 2010 will redirect a user that holds a mailbox in exchange 2003, this will be possible when the following cmdlet will be run on the Exchange 2010 Client Access server:
    Get-OwaVirtualDirectory -server cas01-2010 | Set-OwaVirtualDirectory -Exchange2003Url https://owa.ext.com/exchange
  2. Publish Exchange 2010 client access web farm with ISA 2006, OWA first:

New OWA 2010 Publishing Rule Outlook Web Access Publishing

– Notice ISA 2006 does not provide a wizard (or the new form) for OWA 2010 – for that you need TMG

– Now we need to create the Web Farm and select it as the target for the publishing rule

– Configure the web listener and authentication delegation option

– The web listener should be already configured for Form Authentication and a valid SSL certificate

– The publishing rule for the Web Farm is now complete.

– Two additional configurations are now required:

    1. Edit the new “exchange2010” Rule:
      Remove the legacy virtual directory’s – /Exchange, /Exchweb and /Public they will continue to be published to your original 2003 rule.
      Add /ecp/* as this is the new “options” applications for users, and a powerful administration web console with Exchange 2010.
    2. Edit the original OWA 2003 publishing rule and remove Microsoft-Server-ActiveSync path, we will next create ActiveSync publishing rule for Exchange 2010.

Now we have three last steps to finish our Exchange 2010 publishing:

  1. Create a new Exchange Web Client Access rule – and select ActiveSync – Repeat most of part 1 except we select ActiveSync, publish the webfarm, enter the same info, and select the same listener.
  2. Now as same for ActiveSync, we need to move the RPCoverHTTP (Outlook Anywhere) from the 2003 publishing rule to 2010 publishing rule. Delete the existing rule. Next you we will create a new publishing rule for Outlook Anywhere based on Exchange 2010.
  3. Create a new Exchange Web Client Access rule – and select Outlook Anywhere – Repeat most of part 1 except we select Outlook Anywhere, publish the webfarm, enter the same info, and select the same listener.

That’s it 🙂

if you kept up with all the requirements, all should be fine and you are now able to migrate your 2003 users to 2010 with ease, while both systems are allowed for external connectivity.

Enjoy!

More relevant links on the subject:

Upgrading Outlook Web App to Exchange 2010

Transitioning Client Access to Exchange Server 2010

Prevent Outlook Anywhere (aka RPC over HTTP) from being automatically configured in Exchange 2007 with autodiscover

Update #2 – July 28th 2014 –

Removing the EXPR while Autodiscover is being utilized (which is probably the case in most deployments) will achieve preventing Outlook Anywhere from being used.

With that being said, a few commentators stated that they would like to continue using Outlook Anywhere and with Autodiscover enabled and the EXPR removed this will result in constant “removal” of the Outlook Anywhere settings that were statically configured.

If you want only specific users to be able to use Outlook Anywhere while others don’t I would advice considering the Set-CasMailbox -MAPIBlockOutlookRpcHttp:$true cmdlet to allow/block specific users.

UpdateJune 29th 2013 –

If you’re going to deploy Exchange 2013 anytime soon – work your way to adapt autodiscover, and bring back the EXPR value. See Exchange 2013 Outlook Anywhere Considerations for more.

This is an unsupported method, use at your own risk!

Once “Outlook Anywhere” is configured on a client access server an EXPR entry is created. Then the autodiscover application picks up the change and publish it, along with the url’s for OAB,EWS & Availability.
This basically “force” the automatic propagation of settings into the profile, including the checkbox for “Connect to Microsoft Exchange using HTTP” and filling the information for the HTTP proxy and authentication methods.

Microsoft documented Deployment Considerations for the Autodiscover Service in:

http://technet.microsoft.com/en-us/library/aa997633(EXCHG.80).aspx – Where only Site Affinity is can be configured.

The Outlook provider setting and autodiscover relation are referenced quite good in the Exchange team blog:

http://msexchangeteam.com/archive/2008/09/26/449908.aspx

A client of mine needed the possibility to disable the automatic propagation of the  “Connect to Microsoft Exchange using HTTP” setting in an Exchange 2007 environment .
he did of course wanted to keep the ability to connect using “Outlook Anywhere”  if desired when configuring that manually.

Because autodiscover was made to auto-configure clients that are inside & outside the corporate network disabling this feature disables the ability for external outlook clients, that not domain joined to automatically connect using “Outlook Anywhere” . it does, however does not affect the configuration of a profile.

Within the exchange shell:
Get-outlookprovider –identity EXPR | remove-outlookprovider
Once this is done, recycle the application pool of AutoDiscover in IIS.

This solution will keep the outlook clients from automatically propagate the settings for “Outlook Anywhere” , but retains the possibility for configuring it manually.
All web services and autodiscover information other then the proxy information itself are intact.

Updates (Thanks for all commentators)

New-OutlookProvider -Name:EXPR

I have done the required testing to make sure this solution works.

This is an unsupported method, use at your own risk!