I recently ran into a language security error with a custom Sitecore security domain and have detailed the fix in this post. I have also provided links to a couple of other helpful resources for setting up new custom security domains.
Sitecore custom security domain documentation can be found here and covers most steps needed for creating a new domain.
The creation of a new domain triggers an update in the \App_Config\Security\Domains.config which will need to be propagated to all environments. Since this lives outside of the Sitecore node, you cannot patch new domains in with a Sitecore config override file but Kam Figy details a patch solution here.
This is all well and good but now when you log in with a non-admin user, this language security error appears:
“The security settings for the current language prevent you from seeing this item. To continue, select another language from the Language drop-down list on the Versions tab.”
Every domain in Sitecore has a build in “Everyone” role. All users in the domain inherit from this role but it cannot be managed like a regular role. It is only accessible from the security editor so access can be assigned but not from the regular roles manager.
When my new custom domain was created, an “Acme\Everyone” group was automatically created as expected. What was not expected is that this new role does not have language read and write access by default.
To fix this, go to the security editor and search for the everyone account for your domain.
Click on the columns icon and check “Language Read” and “Language Write”
Browse to the System/Languages folder and click Assign Security. You will notice that the sitecore\Everyone group has Language Read and Language Write access on this folder and descendants. Give your domain Everyone user the same access. Problem solved.
Of note: this post refers to Sitecore 9 update 1.
I’ve been perusing all of the super helpful blog posts around getting Sitecore 9 up and running locally. I started with Toby’s blog post on the prerequisites here followed by George’s installation post here.
I did however run into a couple more gotchas that I hadn’t seen listed and couldn’t come up with a solution for by searching which I’ll detail here in the hopes that it saves someone some time and aggravation.
Issue number 1 – “error_scriptdom_needed_for_sql_provider”. Fortunately for me another co-worker had run into this error earlier in the week. The fix was finding where we had the dll and putting it in the GAC. In my case running the following from a cmd prompt window fixed it:
Cd C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools
gacutil -i “C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\Smo\Microsoft.SqlServer.TransactSql.ScriptDom.dll”
Issue number 2: Install-SitecoreConfiguration : Failed to start service ‘Sitecore XConnect Search Indexer
When googling I found that a bunch of people had also run into this, however I didn’t see a solution. I finally figured out that I didn’t have our latest and greatest partner license and as soon as I replaced that, I was back in business and am now the proud new owner of a local Sitecore 9 site.
Update 5/31/18 –
The JRE version is critical – use JRE 8 (not JRE 10 – uninstall JRE 10 if you have it). And use SOLR 6.6.2 as it fixes a bug in 6.6.1.
And Brandon Bruno has a ton of helpful tips up here.
There are often times when we need to have what I would call super users in Sitecore environments – users that need access to pretty much everything without being logged in as a Sitecore admin.
Below is the list of roles a super user should be a member of along with Sitecore’s explanation of what each roles encompasses. Sitecore’s full documentation on the 82 different security roles is here,
- Analytics Advanced Testing
- Gives the user access to see additional tabs and controls in the Marketing Control Panel.
- You typically give this role to optimization experts, who need expanded rights when performing tests, traffic allocation, and so on.
- Analytics Maintaining
- Gives the user access to the Marketing Control Panel, the Engagement Plan Designer, and the Supervisor.
- The role gives the user permissions to create goal or page event messages and campaigns for messages.
- Analytics Management Reporting
- Gives the user access to view the management reports for optimization efforts.
- This role is typically given to users working with optimization, who wants to view management reports for the optimization efforts. The user can still perform tests, but this is not their main objective.
- Analytics Personalization
- Gives the user access to the personalization functionality in the Experience Editor and in the Content Editor.
- Members of this role can create and edit personalization rules. Users who are not members of this role can switch personalization variations.
- Analytics Reporting
- Gives the user access to the Marketing Control Panel, Experience Analytics, Experience Profile, Path Analyzer, and to the Engagement Plan Monitor.
- Gives the user access to content manipulation facilities in the Content Editor, plus all the design and authoring roles normally used by client authors and client designers. It also provides access to more functionality on the ribbon of the Content Editor to allow full development features for users assigned to this role.
- This role also has access to the Development Tools menu in the Sitecore menu, which gives the user access to further development tools, such as the Package Designer.
- Experience Explorer
- Gives the user access to the explore mode in the Experience Editor and to manage the Presets of the Explore mode in the Marketing Control Panel.
- The role is intended for marketers who set up campaigns and personalization.
Assume you have a scenario with two different websites for US travel and Canada travel (“US.travel.com” and “CA.travel.com”) that have different home nodes in a shared Sitecore instance. Marketing Control Panel content such as goals and campaigns is shared as well.
By default in session personalization works for each individual site. Identifying and merging contacts at the end of the session allows for post session personalization (assuming the contacts have been identified) but does nothing to address the user triggering a goal on the US site and then navigating to the CA site. Out of the box, no personalization on the CA site would kick in based on the goal triggered on the US site until after session end.
It turns out that you can share an analytics session assuming that the sites in question share a domain and you have a shared session database:
- Configure shared session cookies based on a domain by adding “ <httpCookies domain=”.travel.com”/>” (with your domain name of choice of course) in the system.web section of the web.config
- Configure a shared session state database (instructions for 8.2 are here)
If you want to add some diagnostics to view this real time, you can access the Tracker.Current.Session.Interaction data. You will see it contains the same ContactId and InteractionId for both websites and the pages collection including page visits and goals triggered are in sync across both sites as well.
Voila – personalization now works for both the US and CA sites exactly the same as it normally does for a single site.
I recently ran into an issue where in some of my client’s (more active) environments we were not seeing any recent interactions in the Experience Profile. After much back and forth with Sitecore support it was finally determined that this setting – <setting name=”ContentSearch.SearchMaxResults” value=”500″ /> – in the Sitecore.ContentSearch.config was the culprit. By default it is set to nothing, but when I implemented Solr I followed the instructions in here which specifically tells you to set this value.
Maximum Number of Search Results
This is a global setting found in the Sitecore.ContentSearch.config file.
This setting contains the maximum number of documents to retrieve on a single request if a limit has not been specified in the query, for example, Take(10). It is important to remember, for performance reasons, when querying how many results will be returned from the query being run and to handle them correctly, for example by using paging.
<setting name=”ContentSearch.SearchMaxResults” value=”500″ />
The problem comes in because the Experience Profile dashboard loads all contacts and then afterwards performs a sort operation. That behavior was identified as a bug as it can lead to performance issues when there are a lot of contacts.
Sitecore has given the bug the reference number 163186. The patch that fixes the issue can be downloaded at:
https://sitecore.box.com/s/xppd1ny9gcbduxjahi7dwyye4awl6w6g. Of note, the config file and the dll only need to be put on CM servers.
The Sitecore User Group Conference 2015 was a great event organized by the community for the community. In addition to everything I learn, Sitecore events also give me a chance to catch up with colleagues (present – former – future), vendors and friends, and I always leave with renewed vigor and focus. Below are a couple of quick takeaways from two of the sessions I attended.
Sitecore provides a tool called Hash Stored IPs that must be run when upgrading from 8.1 or earlier. I ran into a few gotchas/good to knows when running the tool.
1. ERROR: System.InvalidOperationException: Failed to validate database. —> System.Exception: Database exist but the following collections doesn’t: GeoIps
Initially the tool didn’t run at all because we were missing the GeoIps collection. If for some reason you do not have this you will need to create the collection manually for the tool to work. A bug has been reported for this – reference number 142192
2. If you have a large analytics database, this takes forever to run and has no mercy in regards to how much memory it consumes on the collection server.
Of note, we are running on much less RAM than recommended so I’m sure that is a contributor. In our case we had roughly 32 million Interactions and 10 million ClassificationMap entries. We had to stop the process after it ran for about 15 hours as it was causing memory issues in production. The good news is that it can be safely stopped and started as many times as necessary. Overall it probably took us around 20 hours to complete over several nights.
3. I was a bit alarmed when in rerunning the tool over several nights we kept having an increase the number of Interactions that were not hashed. It turns out that In 8.2 IPs are only hashed in the GeoIps and ClassificationsMap collections and Interactions that are collected post-upgrade are in slightly different format than those processed by the tool.
Hopefully this saves a few headaches for others.