Exclude Robots functionality issues

As for now, there are three known issues related to the Exclude Robots functionality.

149102 - IP ranges in Exclude Robots don't support IPv6

This means that if you add an IPv4 range to the Sitecore.Analytics.ExcludeRobots.config file:

<excludedIPAddresses>
  127.0.0.1 - 128.0.0.1
</excludedIPAddresses>

and then visit a site with an IPv6 IP address, you will face the following exception:

[InvalidOperationException: rangeBegin.AddressFamily != address.AddressFamily]
   Sitecore.Web.IPAddresses.IPRange.Contains(IPAddress address) +262
   Sitecore.Web.IPAddresses.IPList.Contains(IPAddress address) +381
   Sitecore.Analytics.Configuration.ExcludeList.ContainsIpAddress(String addressString) +99
   Sitecore.Analytics.Pipelines.ExcludeRobots.CheckIpAddress.Process(ExcludeRobotsArgs args) +202
   (Object , Object[] ) +83
   Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) +365
   Sitecore.Analytics.DefaultTracker.ExcludeRequest() +28
   Sitecore.Analytics.DefaultTracker.StartTracking() +267
   Sitecore.Analytics.Pipelines.StartAnalytics.StartTracking.Process(PipelineArgs args) +95
   (Object , Object[] ) +83
   Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) +365
  Sitecore.Mvc.Analytics.Pipelines.MvcEvents.RequestBegin.StartTracking.Process(RequestBeginArgs

The same behavior, if you specify an IPv6 range and then visit a site with a usual IPv4 address.

150102 - Sometimes IP ranges identify the occurrence of IP not correctly

There is a known issue in the method which should determine whether an IP address belongs to the IP range. For example, if you specify the 127.0.0.1 - 128.0.0.1 range, the 127.0.0.10 IP address will be considered as a not belonging one.

149113 (379609) - Exclude Robots does not take the Analytics.ForwardedRequestHttpHeader setting into account

There is a knowledge base article regarding this issue - https://kb.sitecore.net/articles/454115

FIX

The patch which fixes all the three issues can be found - https://github.com/SitecoreSupport/Sitecore.Support.149113.149102.150102

Unable to cast object of type 'System.String' to type 'Sitecore.Analytics.Reporting.ReportDataProvider'

Sitecore + WFFM

You can face the following exception:
Exception: System.InvalidCastException
Message: Unable to cast object of type 'System.String' to type 'Sitecore.Analytics.Reporting.ReportDataProviderBase'.
Source: Sitecore.Forms.Core
   at Sitecore.Forms.Core.Dependencies.DefaultImplFactoryObjectsProvider.CreateObject[T](String configPath, Boolean assert)
   at Sitecore.WFFM.Analytics.Dependencies.ReportDataProviderWrapper.GetReportDataProviderBase(Boolean assert)
   at Sitecore.WFFM.Analytics.Providers.AnalyticsFormsDataProvider..ctor(ReportDataProviderWrapper reportDataProviderWrapper, ILogger logger, IAnalyticsTracker analyticsTracker, ISettings settings)

If it's a CD + CM server, you should remove the highlighted node from the App_Config\Include\Z.SwitchMasterToWeb\SwitchMasterToWeb.config file:

<reporting>
  <dataProvider>
<datasources>
 <add key="item">
<FiltersFactory>
 <param desc="definitionDatabaseName">web</param>
</FiltersFactory>
 </add>
 <add key="collection">
<FiltersFactory>
 <param desc="definitionDatabaseName">web</param>
</FiltersFactory>
 </add>
 <add key="reporting">
<FiltersFactory>
 <param desc="definitionDatabaseName">web</param>
</FiltersFactory>
 </add>
</datasources>
  </dataProvider>
</reporting>

This is fixed in Sitecore 8.1 Update-1 (bug number - 96933).

If it's a CD server, please comment out the whole <reporting> node because it's trying to patch the Sitecore.Analytics.Reporting.config file which has to be disabled on a CD server.

The Analytics.ClusterName and Analytics.HostName settings

I will try to explain the purpose of each setting.

Very short

The Hostname setting is important only for multi-clustered environments. For the environments, which are not multi-clustered the setting is not important. But, there is a known issue with multi-site environments when the setting isn't empty. Therefore, you just need to keep the setting empty. It shouldn't be empty only in a multi-clustered environment with an only one site.

The Clustername setting is also used in multi-clustered environments (each cluster must have its own value of the setting). But, it's important for non-clustered environments too. It should be set to the domain name. This is related to both servers CM and CD. If it is empty, there is another known issue.

Details

The main purpose is scaling ability. The main idea of these settings is the following.
For example, you have 40 geographically distributed CD servers:

• 10 in Australia;
• 10 in Asia;
• 10 in Europe;
• 10 in the USA.

There is a sense to group them into 4 CD clusters. Each cluster will have its own session and shared session databases. But here we need a mechanism which will not allow a situation when the first request will be served by one cluster and the second request from the same user will be served by another cluster. Therefore, each of our clusters will have its own Analytics.Clustername setting, for example:

• cluster1.site.com
• cluster2.site.com
• cluster3.site.com
• cluster4.site.com

When the first visit of a visitor comes to cluster3.site.com, for example, this cluster will get (or create) a contact in the Mongo Analytics database and add the { "Lease.Owner.Identifier": "cluster3.site.com" } field to the contact. Which means that this cluster has locked this user. If the second request from the same client comes to another cluster, it will be redirected back to cluster3.site.com because this cluster serves the client and this cluster's session databases have the actual session data of the client. But even in a non-clustered environment, this setting is used to lock the contacts. Therefore, it's important to set it to the correct hostname on both CM and CD servers. Also, this host should be accessible from the CM.

Hostname setting, in this case, should be set to the main domain name - site.com which is under a load balancer. If the setting is not empty, Sitecore doesn't allow the first request in session to be made directly to a cluster. The first request is expected to be made to the host whose name is specified in Analytics.HostName setting which is under the load balancer that will redirect the first request to the most geographically appropriate cluster. But there is a known issue with multisite solutions since any site will be redirected to Hostname.