The Exchange Management Shell helps us discover the amazing capabilities of PowerShell.  One way it does this is by displaying a tip of the day so that we are introduced to concepts and topics that inevitably will come in handy one day!

The other Exchange 2013 tips of the day posts can be found here:

Exchange 2013 Tip Of The Day – 26 To 50

Exchange 2013 Tip Of The Day – 51 To 75

Exchange 2013 Tip of The Day – 76 To 93

Exchange 2010 tips can be found here and the  Exchange 2007 Tips are listed on TechNet.

To retrieve the tips listed in this post, this PowerShell code was used to retrieve them:

$Int = 1;While ($Int -le 25){Get-Tip $Int;  Write-Host; $Int+=1}

Please refer to the Exchange 2010 tips post for a more verbose version of the PowerShell code.

Just like the Exchange 2010 tips, the first four Exchange 2013 tips are also duplicated, though since they are randomly displayed it goes un-noticed!

Tip of the day #1:

Did you know that the Identity parameter is a "positional parameter"? That means you can use:

Get-Mailbox "user" instead of: Get-Mailbox -Identity "user"

It's a neat usability shortcut!

Tip of the day #2:

Did you know that the Identity parameter is a "positional parameter"? That means you can use:

Get-Mailbox "user" instead of: Get-Mailbox -Identity "user"

It's a neat usability shortcut!

Tip of the day #3:

Did you know that the Identity parameter is a "positional parameter"? That means you can use:

Get-Mailbox "user" instead of: Get-Mailbox -Identity "user"

It's a neat usability shortcut!

Tip of the day #4:

Did you know that the Identity parameter is a "positional parameter"? That means you can use:

Get-Mailbox "user" instead of: Get-Mailbox -Identity "user"

It's a neat usability shortcut!

Tip of the day #5:

Tired of typing a long command every time that you want to do something? Alias it! Type:

Set-Alias GetMre Get-ManagementRoleEntry

For all the current aliases, type:

Get-Alias

Tip of the day #6:

Want to see the members of a dynamic distribution group that has a custom filter? Just use the Get-Recipient cmdlet. Type:

$DDG = Get-DynamicDistributionGroup "Contoso Marketing Managers"    
Get-Recipient -RecipientPreviewFilter $DDG.RecipientFilter

Tip of the day #7:

The Exchange Management Shell is a calculator, too! Try it directly at a command prompt:

1.2343+3123 or (23/435)*2

Tip of the day #8:

Command line SOS! Do you need help? Type:

Help <cmdlet-name>  or  <cmdlet-name> -?

You can choose what information to return when you view Help by using the Detailed, Full, and Examples switches:

Help Get-Mailbox –Detailed

Tip of the day #9:

Want to look at Help for a cmdlet but don't want to read through pages and pages of text in the Shell window? Just use the Online switch with the Get-Help cmdlet. The Online switch tells the Shell to open the online version of the cmdlet's Help topic in your default browser. Type:

Get-Help <cmdlet> –Online

Tip of the day #10:

The tilde character (~) should be familiar to Unix users. It represents the shortcut to your root directory. To see what it's evaluated to by default, type:

Dir ~

You can use it as a useful shortcut:

Cp SomeFile "~\My Documents"

Tip of the day #11:

CTRL+C is the equivalent of the hard-break command in the Exchange Management Shell. If a command is taking too long to run or you want to cancel an operation quickly, press CTRL+C to stop execution.

Tip of the day #12:

Pushd and Popd work the same way in the Exchange Management Shell as they do in cmd.exe. Type:

Pushd <location>

Tip of the day #13:

XML over everything! The Exchange Management Shell treats XML as a native type, so that you can do interesting things like:

$Sample = [XML](Get-Content SomeXMLFile.xml)

This command assigns $Sample to the actual XML object. To see it, type:

$Sample

To navigate, type:

$Sample.Prop1.Prop2

No need for text parsing when you want to load XML data!

Tip of the day #14:

Cmdlets that end in "Config" manage singleton configuration, either one per server or organization. For these tasks, you don't have to specify an identity because there is only one instance of the configuration. You may have to specify the Server parameter if the configuration is per server.

Tip of the day #15:

To get a list of all users on an Exchange 2013 server who aren't Unified Messaging-enabled, type:

$Mailboxes = Get-Mailbox    
$Mailboxes | ForEach { If($_.UmEnabled -Eq $False){$_.Name}}

Tip of the day #16:

To get a list of all users on an Exchange 2013 server who are Unified Messaging-enabled, type:

$Mailboxes = Get-Mailbox    
$Mailboxes = | ForEach { If($_.UmEnabled -Eq $True){$_.Name}}

Tip of the day #17:

To display the user's alias formatted in a table together with the user's Exchange 2013 server name and telephone extension, type:

Get-Mailbox | Format-Table ServerName,@{e={$_.SamAccountName};Label="User Alias"},@{Expression="Extensions";Label="Telephone numbers"}

Tip of the day #18:

To display the list of UM IP gateway server names disabled for outbound calling and hunt groups associated with a UM IP gateway server, type:

$Gateways = Get-UMIPGateway    
$Gateways | ForEach {If($_.OutCallsAllowed -Eq $False){ "Gateway Name = " +$_.Name;ForEach ($HuntGroup In $_.Huntgroups ){"Huntgroups " + $Huntgroup}}}

Tip of the day #19:

If you want to test all IP Block List providers, you just have to pipe the Get-IpBlockListProvider cmdlet to the Test-IpBlockListProvider cmdlet:

Get-IpBlockListProvider | Test-IpBlockListProvider -IpAddress 192.168.0.1

Tip of the day #20:

Before you remove an object by using the Remove verb, use the WhatIf parameter to verify the results are what you expect
 

Tip of the day #21:

Sometimes it's useful to convert the output of a cmdlet to a string to interoperate with native cmdlets. For example, type:

Get-Mailbox | Out-String | Findstr "Administrator"

Tip of the day #22:

Get all Win32 WMI information, such as Perfmon counters and local computer configurations. For example, type:

Get-WMIObject Win32_PerfRawData_PerfOS_Memory

Tip of the day #23:

Who isn't tired of spam? You can configure real-time block list (RBL) providers with the Exchange Management Shell by running the following two commands:

Set-IPBlockListProvidersConfig -Enabled $True -ExternalMailEnabled $True

and then

Add-IPBlockListProvider -Name <Name of RBL Provider> -LookupDomain <FQDN of RBL Provider> -AnyMatch $True

Tip of the day #24:

Access the event log from the Exchange Management Shell. To retrieve the whole event log, type:

Get-EventLog Application | Format-List

To retrieve all Exchange-related events, type:

Get-EventLog Application | Where { $_.Source -Ilike "*Exchange*" }

Tip of the day #25:

One benefit of the Exchange Management Shell is that cmdlets can output objects to the console. You can then manipulate this output and organize it in interesting ways. For example, to get a quick view in tabular format, use Format-Table:

Get-Mailbox | Format-Table Name,Database,RulesQuota

Cheers,

Rhoderick

When doing some recent customer work for Exchange 2013, I ran into an annoying issue in one of my labs.  Outlook 2013 refused to connect to Exchange 2013.   A witch hunt then ensued to ensure that all of my Outlook Anywhere, Autodiscover and authentication settings were correct.  Well it turns out that they were, and this was just a client side issue.  Legacy IIS permissions when coexisting with Exchange 2013 are covered here for example. 

The symptom was that Outlook would not connect using an existing profile, and was unable to create a net new profile.  When creating a new profile the error received was “The action cannot be completed.  The connection to Microsoft Exchange is unavailable.  Your Network Adapter does not have a default gateway”. 

Since this entire lab exists on a single flat subnet ( 10.0.0.0/8 ) I foolishly, ignored the default gateway bit of the error message and focussed on client connectivity.   Why would it want a default gateway when all machines are on a single subnet, the network is a private Hyper-V switch and all machines resolve names perfectly……

Let’s look at what was going on and then remediate manually and how to automate the fix. 

Running Outlook  Auto Account Setup

Trying to create a new Outlook 2013 profile with pre Outlook 2013 SP1 and then Outlook 2013 SP1 both resulted in the same issue.

Firing up Outlook initiated the Auto Account setup.  As expected we hit up AD to get the SMTP address and then query AD for the Autodiscover SCP endpoints.  For details on Autodiscover please see this post.   

All normal so far.  We issued the LDAP query to AD, did the Autodiscover SCP query, and start to process the Autodiscover response. 

Then the wheels fall off the wagon……

Clicking OK, shows the below dialogue box. 

Couple of things to mention about the content of the above window.  Note that the Exchange server field does not state the name of any of the Exchange servers.  Is this something to be worried about? The answer is no.  This was a deliberate design change in Exchange 2013 to provide a single consistent identity that Outlook could store.  The intent was to minimise the occurrences of “Your administrator has made a change that requires you to restart Outlook”.  We can talk more about that with MAPI/HTTP. 

You will note that the information specified in the Exchange server name is the ExchangeGUID of the mailbox.  This can be seen below:

Get-Mailbox Administrator | Select Name, *GUID*

You will note that the ExchangeGUID does not show up in the ADDS cmdlet:

Get-ADUser Administrator | Select Name, *GUID*

Going back to the error screen again…..

Clicking Check Name again, just shows the previous error – The connection to Microsoft Exchange is unavailable.  Your network does not have a default gateway.

What’s up with this? 

Correcting The Issue By Disabling Outlook Connection Optimisation

In this case we are using a pretty rare scenario.  All of these test machines exist on an isolated segment with no other network access whatsoever.  Typical client machines have a default gateway configured to allow IP traffic to flow correctly in the environment.  Outlook 2007 will typically look for a machine to have a default gateway set so they can perform some more advanced connection optimisation compared to Outlook 2003.  In this case it this which is getting in the way.  As described in KB 913843, this is disabled in the registry.  The registry keys and values to set will depend upon the version of Outlook that you have installed.    The registry keys are:

Which contains a  REG_DWORD called  DefConnectOpts  = 0

Note that the RPC key may not currently exist.  If it does not you can manually create it or use the automated solution below in this post. 

This registry data disables the new Outlook 2007 connection logic and forces Outlook 2007 to use the same connection logic available in Outlook 2003.  One check that gets disabled is  the step to validate if a default gateway is present. 

Please note that there are multiple reasons Outlook 2013 may not want to connect to Exchange 2013.  This is just one of them.  A couple of the other recent ones that I have see are:

KB 2264398 Outlook Unable to perform a Check Name or connect to an Exchange mailbox may get these errors:

KB 2934750 Outlook 2013 cannot connect after an Exchange Server 2010 mailbox is moved to Exchange Server 2013

If you want to automate this via a script, logon script or just don’t want to have to browse the registry, we can use the venerable reg.exe tool. 

To Set The Outlook 2013 DefConnectOpts  Registry Value

Reg.exe Add HKEY_CURRENT_User\Software\Microsoft\Office\15.0\Outlook\RPC  /T REG_DWORD  /V DefConnectOpts  /D "0"

To Check For The Outlook 2013 DefConnectOpts  Registry Value

Reg.exe Query HKEY_CURRENT_User\Software\Microsoft\Office\15.0\Outlook\RPC /V DefConnectOpts

Funnily enough, after the fact I remembered that I’d seen this previously, about 5 years ago.  Those who forget the past certainly do repeat the same mistakes!

Cheers,

Rhoderick

When writing Exchange PowerShell scripts it is very useful to target specific machines to either query or set their properties.  Thus the ability to generate a query that effectively targets the correct machines is a very good thing to have!

The reason I'm posting this is that I see a lot of people manually specify a list of servers, and then iterate through the list which typically looks like this:

$ExchangeServers = “Exch-1”, “Exch-2”, “Exch-3”

ForEach ($Server In $ExchangeServers)

{

# The code to do something goes here…..

#  I would indent these lines if Live Writer would allow it….

# Oh well, it’s not a perfect world….

}

This is all good and fine if you have three servers.  What if you have three hundred? Man, that would be a gargantuan sized variable and really horrible to maintain!

In those cases we want to work the server list out on the fly, and then iterate through the collection.  Let’s look at some sample code that allows us to focus upon certain types and locations of servers.

Select Only Specific Roles

Starting with  simple example, let’s pull in a list of all the CAS servers in the organisation.  Then for the remaining Exchange 2010/2007 roles.  You will note that we have built in cmdlets for discovering each of these roles in  a nice easy fashion:

Show CAS Servers

Get-ClientAccessServer

Show HUB Transport Servers

Get-TransportServer

Show Mailbox Servers

Get-MailboxServer

Show Unified Messaging Servers

Get-UMServer

Well, that was  good start!  But let’s say that we want to then filter this list further.  What if we want to then get a specific version of CAS?

Select Only Exchange 2010 CAS

In the previous example we successfully used the Get-ClientAccessServer cmdlet to retrieve a list of all CAS servers.  So it should be simple to then just add the version information to this cmdlet as Get-Member does show us that there is a version parameter.  For more information on Get-Member and other PowerShell fundamentals please check this series of articles out.

Oh, smeg!  All of the versions are the same.  What to do??

To be able to see the version information of a server, we need to use the Get-ExchangeServer cmdlet.  There are other reasons for using this as well that we will get into at the end of the post.

In this example let’s select only Exchange 2010 CAS Servers.  To do this we need to check that they are Version 14 (Exchange 2010 is E14).  We shall save the Name parameter into the $CASServers variable, and sort it.  Note that we are using Get-ExchangeServer as we can see the AD site information with that cmdlet.  Get-ClientAccessServer does not return site information.
 
This collection will be only CAS servers.  Note though that, depending upon your requirements, you have to filter this more as it will include every CAS from every corner of your Exchange organisation.  We shall address that concern later in the post!

$CASServers = Get-ExchangeServer | Where-Object {$_.IsClientAccessServer -Eq $true -and $_.AdminDisplayVersion -Match "^Version 14" }  |  Select Name | Sort-Object

In the above PowerShell code we are using the –Match operator.  You will note that the “^” symbol is within the string that is being searched for.  The ^ character indicates that this is the location where the string begins.  This is part of regular expression searches, and you can read more about this here. 

My personal preference is to always sort these collections so when reviewing output, since the data is then in a predictable order and that makes it much quicker and easier to analyse.

One other thing to note when looking at the Exchange 2007 and 2010 version strings.  They will not increment when a RU is installed.  Only an Exchange 2007 and Exchange 2010 Service Pack is designed to advance the build number.  Exchange 2013 will increment the build number for each CU that is installed.  This is discussed in great detail here.

Select Only Exchange 2007 CAS

Taking the previous example, it is a simple task to then change this so that we look for the Exchange 2007 version information which is “8.”.  At this time all of your Exchange 2007 servers must be on Service Pack 3, with an up to date rollup as well.  We could then hard code the search to look for only SP3 builds of Exchange 2007 which would be “8.3”, but let’s leave it open to search all versions.

$CASServers = Get-ExchangeServer | Where-Object {$_.IsClientAccessServer -Eq $true -and $_.AdminDisplayVersion -Match "^Version 8" }  |  Select Name | Sort-Object

Select Only Exchange 2010 HUB Transport

$E14HUBServers = Get-ExchangeServer | Where-Object {$_.IsHubTransportServer -Eq $true -and $_.AdminDisplayVersion -Match "^Version 14" }  |  Select Name | Sort-Object

Select Only Exchange 2010 Mailbox

$E14MailboxServers = Get-ExchangeServer | Where-Object {$_.IsMailboxServer -Eq $true -and $_.AdminDisplayVersion -Match "^Version 14" }  |  Select Name | Sort-Object

Let’s now switch this up a little and make some more complicated queries!

Select Only Exchange 2010 CAS In A Specific AD Site

As mentioned above, there will be times that you do not want to get every single CAS server in the organisation.  Sometimes you only want those is  a particular AD site.  Remember that all CAS in a site should be configured the same, as you cannot control to what CAS a particular user is referred to and thus the configuration needs to be  the same to ensure a consistent user experience. 

In this example we want to get a collection of just the Exchange 2010 servers that exist in a specific AD site called Edinburgh.

$E14CASServers = Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -match "^Version 14" -and $_.ServerRole -Match "ClientAccess" -and ($_.Site -match "Edinburgh") } | Sort Name

The trick as you see here, is the multiple “-And” statements.  This makes sure that each of the elements must evaluate to $True for it to be considered as part of the collection.  Should any part of a given server evaluate to $False then it will not be present in the collection.

Select Only Exchange 2010 CAS In Multiple AD Sites

In the above example we leverage multiple  “-And” statements to generate the required logic.  In the example here we then add to this by using an “-OR” statement.  For a server to be included in the collection it could be in AD SiteA or AD SiteB.  In the example below the sites are called Edinburgh and Aberlour.  Please ensure that this does not wrap:

$E14CASServers = Get-ExchangeServer | ?{$_.AdminDisplayVersion -match "^Version 14" -and $_.ServerRole -Match "ClientAccess" -and ($_.Site -match "Edinburgh" -or $_.Site -match "Aberlour") } | Sort Name

 

 

Select Only Exchange 2003 Servers

This will be a very handy command to ensure that all of your Exchange 2003 servers have been removed by the 8th of April 2014!

$Exchange2003Servers = Get-ExchangeServer  | where {$_.AdminDisplayVersion -match "6.5"}

  For this and the other examples we can get a count of the servers in a couple of ways.

$Exchange2003Servers  | Measure-Object

 

$Exchange2003Servers.Count

 

Select Specific Mailbox Databases

If you have a few hundred mailbox databases, then you will have developed a naming scheme for them to indicate which DAG, continent and mailboxes are contained therein. 

To see databases that contain a particular string we can use our familiar wildcard search character:

Get-MailboxDatabase *04*

This is shown in the above example.  We want to see databases that contain the phrase “04”.  The same can be done for many other objects in Exchange. 

Select Specific Mailboxes

For mailbox filtering examples, this is covered in great detail in this previous post.

Cheers,

Rhoderick

Wow, time has certainly flown and its now only two weeks until MEC 2014 happens down in sunny Austin, Texas!

My MEC Profile is here.  Currently looking at all the sessions and planning that out!

I’m really pumped and am looking forward to meeting a load of virtual friends from a wide range of countries from Sweden, Australia and the UK to name just a few!  Having so many community members in a single place is simply outstanding!

What can we look forward to?  Lots, including:

• Plenty great sessions
• Interesting speakers

The MEC site also has some of the MEC 2012 videos for your viewing pleasure .

The theme for MEC 2012 was the lost conference.  I wonder what fun has been cooked up for this one!

If you are also at MEC, please do come and say hello!

Cheers,

Rhoderick

Since we are still in the early stages of the year, and Exchange 2013 SP1 is now available, we will see lots of migrations to Exchange 2013.  Exchange 2013 can be deployed into an existing Exchange organisation where Exchange 2007 SP3 RU10 + and/or Exchange 2010 SP3 exists.

Let's look at an issue that can arise in an Outlook Anywhere co-existence scenario with Exchange 2007 and 2013.  After walking through the scenario we will see what can be done about it and review  a couple of other issues that will probably crop up, for example IIS permissions.

Update 27-3-2014:   Added link to TechEd 2013 Outlook Anywhere session.  Tightened up client auth wording. 

Update 12-11-2014: Updated reference to OA traffic flow from Gavin's feedback.

Update 12-11-2014: Updated reference for disabling IPv6

Since some customers may not already have Outlook Anywhere enabled, and are lighting it up to permit co-existence with Exchange 2013, they may run into issues if the required OS bits are not deployed on the older versions of Exchange.  You may receive EventID 2003 stating that the RPC over HTTP proxy component is not installed of is not configured correctly. 

It is possible to install Exchange 2007 and enable Outlook Anywhere without installing the required underlying OS component.  This is the RPC/HTTP proxy component that was introduced in Windows 2003 and allowed for the introduction of RPC/HTTPS.  Since Exchange 2007’s Outlook Anywhere requires the RPC/HTTP component, it will not work without it.  Funny that, eh?

Install Exchange 2007 Sans RPC/HTTP

We start this scenario with a base Windows 2008 R2 SP1 Installation.  The telnet client is installed, and nothing else just to prove that the Get-WindowsFeature cmdlet is working. :

Since we are using Exchange 2007 on Windows Server 2008 R2 SP1, we will not be prompted to download and install additional hotfixes. So let’s focus on installing Exchange!  

Slapping in the CD, and the splash screen launches. 

The familiar Exchange 2007 introduction screen appears, and after reading it fully we move on to the next screen:

And we choose the typical installation type.  There is a reason for not splitting the roles, and we shall get to that at the end of the post!   Then we click Next.

As expected since this is a base OS, the Exchange readiness check fails as we are missing IIS and other OS bits.

To install the missing OS bits, we can grab the pre-canned OS requirement commands from TechNet. Since we are installing a server with CAS, Mailbox and HUB these OS bits must be installed:

ServerManagerCmd -i Web-Server

ServerManagerCmd -i Web-ISAPI-Ext

ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console

ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Digest-Auth

ServerManagerCmd -i Web-Windows-Auth

ServerManagerCmd -i Web-Dyn-Compression

If the server will support Outlook Anywhere clients, install the RPC over HTTP proxy feature by running the following command:

ServerManagerCmd -i RPC-over-HTTP-proxy

For ease we will typically use something like the below which is one line.  Please beware that it does not wrap:

ServerManagerCmd -i Web-Server, Web-ISAPI-Ext, Web-Metabase, Web-Lgcy-Mgmt-Console, Web-Basic-Auth, Web-Digest-Auth, Web-Windows-Auth, Web-Dyn-Compression, RPC-over-HTTP-proxy

Since folks may copy the above to install a server, the command is complete and includes the RPC/HTTP proxy component.  However note that in the below example I have deliberately omitted the RPC/HTTP proxy Windows component, else our scenario will not play out!

Groovy, so we have the OS bits installed, and after a swift reboot we can then go and resume our Exchange installation.  Again choosing the same options as before, the readiness check now passes.  Green ticky-ticky all around!

Note that the RPC/HTTP proxy component is not installed.  This can be verified by the Get-WindowsFeature output in the background. 

One Exchange installation completes, the server should be restarted, and the latest RU installed.  At the time of writing this was Exchange 2007 SP3 RU13. 

As you saw, it is possible to install Exchange 2007 CAS role, without installing the RPC/HTTP proxy.  Let’s move on to enabling Outlook Anywhere on the server, and see what happens!

Enabling Outlook Anywhere Sans RPC/HTTP

Exchange 2007 will not check that the RPC/HTTP proxy component has been installed prior to enabling Outlook Anywhere. 

Thus after Exchange 2007 is installed, we can enable Outlook Anywhere on this server, even without the RPC/HTTP component being installed:

Impact of Enabling Outlook Anywhere Sans RPC/HTTPS

In a nutshell, it is not good! 

Exchange does not have a mechanism to convert the HTTPS traffic to RPC, so Outlook Anywhere will not work at all on this server. 

If you are monitoring the event logs (as you should be) Exchange does detect that something is not right. Exchange will check and realises the RPC/HTTP component is not present.  This generates the error 2003 stating that the RPC over HTTP component is not installed or is not configured correctly. 

If you do open up Exchange Management Shell and look for the Outlook Anywhere settings, you will see that the Get-OutlookAnywhere cmdlet discovers that the /RPC virtual directory is not present since the RPC/HTTP component is not installed.  For details on checks (and the time taken) made to virtual directories when running cmdlets, please also see this post. 

Exchange 2013 CAS will also detect that something is amiss and write an error to its application event log.  This will manifest itself as error 3005 from MSExchange Front End HTTP Proxy stating which server that it found an issue with.  There are a few variants of this, with errors ranging from 404 to other HTTP error codes depending upon the issue at hand.  In this case the error is a 404 since the RPCProxy.dll is not present. 

Note that the error string states that this is a Client Access 2010 server, but in fact this is an Exchange 2007 box.  Don't let that confuse you! 

One other thing that you may notice for Exchange 2013’s proxy and redirection behaviour is the URL that is used to connect to legacy Exchange servers.  Exchange 2013 will build a URL to match the FQDN of the server in question.  I’ll save the details on that for a later post as it would add too much here.

Exchange 2007 & 2010 Required IIS Permissions

When configuring Exchange 2007 Outlook Anywhere or Exchange 2010 Outlook Anywhere using the Exchange Management Console there are  options to enable either basic or NTLM authentication. 

The one originally chosen when deploying those servers depended upon your design which was in turn influenced by factors like client authentication requirements and NTLM support (or rather lack of) on any device that publishes Outlook Anywhere to the Internet. 

If you configured Exchange 2007 Outlook Anywhere to use Basic auth, then you will see this in PowerShell: 

Note that this is a separate server.  This one is imaginatively called E2K7-2.  If NTLM was used:

Note the two different authentication settings that are listed.  ClientAuthenticationMethod and IISAuthenticationMethods.   For the detail oriented people out there, you saw that one was plural and the other singular.

When you configure OA for Basic auth, then the ClientAuthenticationMethod and IISAuthenticationMethods are both set to Basic.  The same is true for when OA is set to NTLM auth.  In that case ClientAuthenticationMethod and IISAuthenticationMethods are both set to use NTLM. 

When co-existing Exchange 2007 and 2010 with Exchange 2013, we need to ensure that the correct authentication settings are in place.  There are two things that we need to pay attention to.  Authentication at the IIS layer and authentication at the client layer.  This is the IISAuthenticationMethods and   ClientAuthenticationMethod  properties respectively. 

As specified in the Exchange Server Deployment Assistant, to allow CAS 2013 to redirect Outlook Anywhere connections to Exchange 2010 and 2007, Outlook Anywhere must be enabled and properly configured on Exchange 2007 and 2010.  If Outlook Anywhere was previously deployed, then ensure that their configuration will support Exchange 2013.   The follow permission considerations need to be addressed:

• Client authentication, which is used to allow clients like Outlook 2013 to authenticate with Exchange is properly configured.  The same consistent OA client authentication scheme should be deployed on legacy CAS and CAS 2013. 
• Internet Information Services (IIS) authentication, which is used to allow Exchange servers to communicate must include NTLM auth.

As an example to set basic client auth on Exchange 2007.  The required permissions on Exchange 2007 and 2010 can be set using Set-OutlookAnywhere:

Set-OutlookAnywhere -Identity 'ServerName\Rpc (Default Web Site)' -ClientAuthenticationMethod Basic -SSLOffloading $False –ExternalHostName <Exchange2013HostName> -IISAuthenticationMethods NTLM, Basic

Setting multiple permissions on the IISAuthenticationMethods is probably a bit of a change compared to how we were previously configuring Outlook Anywhere.  There have also been some interesting discussions on this topic in the past. 

Permissions for Outlook Anywhere coexistence were also discussed by Greg Taylor, in a style that only Gregg manages to get away with, at Tech Ready 2013 NA in session OUC-B313.   We should shoot who names these sessions…..   The video, PowerPoint and podcast for this and all the other available Exchange TechEd 2013 sessions are here. 

Without getting into the entire CAS namespace discussion, if you want all Outlook Anywhere traffic to flow via CAS 2013 a critical point is that the Exchange 2007 Outlook Anywhere external URL is set to the external hostname of the Exchange 2013 server.  This is discussed in great detail in this post on EHLO by Ross. 

Disabling IPv6 On Exchange 2007

Before you install Exchange 2013, you might need to disable IPv6 on some of your Exchange 2007 servers. Some connections between Exchange 2007 and Exchange 2013 don't work correctly when IPv6 is enabled and an Exchange 2007 server has both the Mailbox and Client Access server roles installed.

If you have Exchange 2007 servers that have both the Mailbox and Client Access server roles installed, complete the following steps on each of those servers to disable IPv6 on them.  To do so

1. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
2. If the DisabledComponentsentry doesn’t exist, do the following to create it:
   1. In the Edit menu, click New, and then click DWORD (32-bit) Value.
   2. Type DisabledComponents and then press enter.

3. Double-click DisabledComponents.
4. In the Value data field, enter 0xFF

Note that the recommendation is not to use 0xFFFFFFFF nowadays, and 0xFF should be used instead.  Please see this post on disabling IPv6.

Alternatively, if you want to automate this, you can use something like the following. 

To Set The DisabledComponents Registry Key

Reg.exe Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /T REG_DWORD  /V DisabledComponents  /D "0xFF"

To Check For The DisabledComponents Registry Key

Reg.exe Query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /V DisabledComponents

This issue is discussed in the Exchange Deployment Assistant and also KB 2794253. 

Cheers,

Rhoderick