This one is a doozie, I tell ya. I was firing up Experience Profile in a client’s Production environment, and it was empty. Which was not accurate. Trust me, it shouldn’t have been empty. So a quick peek at the network traffic showed this:

So yeah. Lemme call up that administrator.

Me: Hello Me?

Also Me: Yes?

Me: I need to talk to you about an error. Apparently something went wrong…

Also Me: I’m aware.

So that was fun. Should do it again sometime. At any rate, time to check some Application Insights for a “real” error message. Not that that nugget of ‘wrongness’ wasn’t helpful (Narrator: It wasn’t)

Well, something helpful DID come from App Insights!

The Stacktrace was somewhat…what? IndexReaderDisabled?

System.NotSupportedException:
   at Sitecore.Xdb.Collection.Indexing.IndexReaderDisabled.SearchContacts (Sitecore.Xdb.Collection, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null)
   at Sitecore.Xdb.Collection.Repository+<SearchContacts>d__11.MoveNext (Sitecore.Xdb.Collection, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at Sitecore.Xdb.Collection.RepositoryCountersDecorator+<SearchContacts>d__8.MoveNext (Sitecore.Xdb.Collection, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089)
   at Sitecore.XConnect.Service.RepositorySearchInvoker+<Execute>d__7.MoveNext (Sitecore.XConnect.Service, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null)

Time to head over to the code and figure out what’s inside there:

Something sure as hell isn’t right here.

Ok, so why is this happening? Hitting the google, there were a couple posts out there about how my connection strings were pointing to the wrong service. Looking at the connection strings file, I could confirm that they were actually pointing to where they should:

Alright, now what? Well, back to the google. I found this pretty epic Stack Exchange Post by Pete Navarra that detailed how to work with the Contact Search, which had good note on the configuration of how it connected with the XConnect Client. Looking at THAT code, it was more clear how the configuration of the endpoints worked:

BACK to the Showconfig!

So yeah, even though the connection strings were right, the client configuration was wrong. I noticed that node didn’t have a patch:source in it, which means that was out of the box! I’ve been hoodwinked! How did this happen???

First thing I did was pop open the XP1 scaled install and check out the Sitecore.XConnect.Client.config. It looked pretty good:

<clientconfig type="Sitecore.XConnect.Client.Configuration.SitecoreXConnectClientConfiguration,Sitecore.XConnect.Client.Configuration"
     singleInstance="true" 
     role:require="Standalone or ContentManagement">
        <param desc="clientModel" ref="xconnect/runtime"/>
        <param desc="collectionConnectionStringName">xconnect.collection</param>
        <param desc="searchConnectionStringName">xconnect.search</param>
        <param desc="configurationConnectionStringName">xconnect.collection</param>
</clientconfig>

Ok, so what gives here??? For the pure entertainment value, I popped open the XP0 install to see if he matched. He should right? Nah. He didn’t:

<clientconfig type="Sitecore.XConnect.Client.Configuration.SitecoreXConnectClientConfiguration,Sitecore.XConnect.Client.Configuration"
     singleInstance="true"
     role:require="Standalone or ContentManagement">
        <param desc="clientModel" ref="xconnect/runtime" />
        <param desc="collectionConnectionStringName">xconnect.collection</param>
        <param desc="searchConnectionStringName">xconnect.collection</param>
        <param desc="configurationConnectionStringName">xconnect.collection</param>
</clientconfig>

Oh boy. So yeah, that means that by default, there’s an issue. Womp womp. That’s fine in the Standalone scenario, as the Search and Collection URLs are the same XConnect instance. When you scale out your topology, that doesn’t work.

The great news is two-fold:

1. If you update that value to point to the xconnect.search Connection String, you should start seeing results like you expect!
2. It looks like they fixed this in SC10.

Note: Before everyone jumps on the “They’re different installs, you should expect different config files!” train..stop. Aside from AppInsights, this is literally the only configuration file that is different between XP0 and XP1-CM