The Easier Way to Sitecore XP 9

This article was originally posted in its entirety on the Paragon Blog here:

You’ve either arrived because you made it through the full series or a quick google landed you here as you where looking for a quick and easy Sitecore XP 9 install.

Most of the following was taken from the Sitecore Installation Guide but is a little buried in all the documentation, so this will be a long term refernece for myself, my teams, and now you!


The Steps

  1. Install MS SQL 2016 SP1 or later
  2. Install Web Deploy 3.6 for Hosting Servers (done via the Web Platform Installer)
  3. Install Url Rewrite 2.1 (done via the Web Platform Installer)
  4. Install Microsoft SQL Server Data-Tier Application Framework (DacFx) version 2016
  5. To support DacFx, the target SQL server needs to allow users and logins at the DB level, this can be configured/confirmed by running the following SQL script
    sp_configure 'contained database authentication', 1;
  6. Extract the contents of Sitecore 9.0.1 rev. 171219 (WDP XP0 packages).zip to a working directory. You should see the following
    • Sitecore 9.0.1 rev. 171219 (OnPrem)
    • Sitecore 9.0.1 rev. 171219 (OnPrem)
    • XP0 Configuration Files 9.0.1 rev
  7. Extract the contents of XP0 Configuration Files 9.0.1 rev, and you should have the following JSON configuration files, this should be the same directory as the WDP packages in step 6:
    • sitecore-solr.json
    • sitecore-XP0.json
    • xconnect-createcert.json
    • xconnect-solr.json
    • xconnect-xp0.json

    At this point the working directory should look like this:
    Sitecore Easy Install - Working Directory

  8. Open a PowerShell Command prompt as Admin
  9. Change directory to your Working Directory as defined in step 7
  10. Download the install script from Sitecore Easy Install Gist by running the following
    (Invoke-WebRequest | Out-File "SitecoreEasyInstall.ps1"
  11. Open SitecoreEasyInstall.ps1 in your favorite editor (my recommendation is to open the entire working directory in Visual Studio Code).
  12. The first section of the file are global parameters that will define how your environment is configured and installed so update accordingly based on the instructions. At a minimum all values in the ‘CUSTOM TO THE ENVIRONMENT’ section should be completed.
    Sitecore Easy Install - Install Parameters
  13. From the PowerShell prompt run
  14. Grab some coffee (or beer, I won’t judge) while it runs. (On my machine I was up and runninng in about 10 minutes.)
  15. Enjoy Sitecore Experience Platform 9!!!



Getting Ready for Security in Sitecore XP 9

Security in Sitecore 9 Experience Cloud

The next step towards installing Sitecore Experience Platform 9 is making sure we can easily handle the creation of locally signed certificates.


Sitecore 9 by default is meant to run as a secure application. To help with managing these new security needs, the good (and smart) people at Sitecore have provided some PowerShell scripts to help. These scripts are found as part of the Sitecore Fundamentals module, which can be installed manually via a download from Sitecore, or through a custom MyGet Feed as shown here.

Sitecore Fundamentals Install

As I prefer to script for repeatability and ease of sharing with my dev team, this guide will be based on installing Sitecore Fundamentals via the MyGet feed approach.

Setup PowerShell to interact with the Sitecore MyGet feed

  1. Open a PowerShell command prompt, ensure you are running it as Admin
  2. Register the connection to MyGet feed, at the prompt enter (Note: if you have followed my SIF Install skip to step 3.)
    Register-PSRepository -Name SitecoreGallery -SourceLocation

    Sitecore Fundamentals - Register Sitecore Gallery

  3. Install the Sitecore Fundamentals module, at the prompt enter
     Install-Module SitecoreFundamentals
  4. PowerShell will ask if untrusted scripts can be ran, enter ‘A’ and hit Enter. (Note: If you have already set this value during SIF Install won’t apply to you.)Sitecore Fundamentals - Accept Untrusted Scripts
  5. Before performing any other steps, and each time before you use the module, you will want to perform a check and update of the module via
     Update-Module SitecoreFundamentals
  6. Confirming everything installed correctly is as easy as running the following command, at time of writing the current version is 1.1.0
    Get-Module SitecoreFundamentals -ListAvailable

    Sitecore Fundamentals - Available Versions

You should now be ready leverage Sitecore Fundamentals as needed in maintaining and installing Sitecore.

Planning for Cache in Sitecore

This is a follow-up to my Unofficial Sitecore Planning Checklist, where I try to consolidate as much information as I can find on Sitecore’s built in caching.

One of the easiest ways to improve a visitor’s perceived impression of any website visit is through a well-tuned cache. A cache which has been properly tuned will be able to server of requested content quicker, sometimes magnitudes faster than rebuilding the HTML for a page on each request.

Sophisticated caching scenarios can be configured through third-party tools and applications, but even for the most highly trafficked site properly tuning Sitecore’s different cache options should provide the desired performance gains. As site cache is configured and tuned, be aware the need for vertical or horizontal scaling may become necessary. (For details on scaling Sitecore checkout Scalability)

Determine the cache limits required

The general practice for Sitecore caching tuning is to turn all cache limits off via the following simple cache patch config:

<configuration xmlns:patch="">
      <setting name="Caching.DisableCacheSizeLimits">
    <patch:attribute name="value">true</patch:attribute>

With the cache limits now disabled, Sitecore will try to manage based on current traffic and available resources to cache as much as possible. By performing well structured load test or allowing the site to run in this manner, the team should monitor both server resource utilization as well as the Sitecore cache levels to determine areas that should be manually limited to maximize performance.

To monitor what Sitecore has cached you can use the Sitecore admin page, http://&lt; your domain >/Sitecore/admin/cache.aspx, or leverage the Sitecore Marketplace module Caching Manager,

Cache Manager Options

After data collection has occurred you are ready to begin to evaluate which caches need their limits adjusted from the default level. For more information on the different cache limits that can be set see Sitecore CMS 7.0 – 7.2 CMS Performance Tuning Guide.pdf and Sitecore CMS 6.6 or later Cache Configuration Reference.pdf.

Configuring HTML Cache of Components

The first level of caching to configure to is review each rendering that is created and set the appropriate HTML level caching on it.

Rendering Cache Option

To turn HTML cache on for the rendering, select the first option Cacheable. From here you can customize the how different variations of the control should be cached via the different ‘Vary By’ options. Finally, you can mark that all cache be cleared when the search index is updated via the ‘Clear on Index Update’ selection.

The following fuller description of each cache option is taken from Chapter 4: Output Caching in Sitecore CMS 7.0 or later Presentation Component Reference.pdf.

Clear on Index Update

The Clear on Index Update property controls whether or not a control clears its cache when an item that is associated with the control is updated in the index. This is useful for any control that uses the new Search API to populate its data sources. For example:

  • You have a control that returns all the products that are on special offer from the index.
  • The Clear on Index Update property for this control is set to True.
  • The price of each product is stored in the index.

If someone updates the price of one of the products on special offer, the Clear on Index Update property will the trigger the control to clear its cache because something has been updated in the index that is bound to the control.


The VaryByData property controls whether or not output caching varies based on the data source of the presentation component.

Set the VaryByData property:

  • To False for components that do not generate different output when used with different data sources.
  • To True for components that generate different output when used with different data sources.


The VaryByDevice property controls whether or not caching varies based on the name of the context device.

Set the VaryByDevice property:

  • To False for components that do not generate different output when used with different devices.
  • To True for components that generate different output when used with different devices.


The VaryByLogin property controls whether or not output caching varies based on whether or not the user has authenticated. For caching configuration involving the VaryByLogin property, the layout engine treats all anonymous users as a single authenticated user.

Set the VaryByLogin property:

  • To False for components that do not generate different output for authenticated than for unauthenticated visitors.
  • To True for components that generate different output for authenticated than for unauthenticated visitors.


The VaryByParm property controls whether or not output caching varies based on rendering parameters passed to the presentation component. Solutions built with earlier versions of Sitecore may have used the token VaryByParam instead of VaryByParm. Update any instances of VaryByParam to VaryByParm.

Developers set the VaryByParm property:

  • To False for components that do not generate different output when passed different rendering parameters.
  • To True for components that generate different output when passed different parameters.


The VaryByQueryString property controls whether or not output caching varies based on query string parameters passed in the URL. The VaryByParm property causes output caching to vary based on rendering parameter values passed by the developer. The VaryByQueryString property causes output caching to vary based on parameters passed in the URL query string.

Developers set the VaryByQueryString property:

  • To True for components that generate different output when supplied different query string parameters.
  • To False for components that do not generate different output when supplied different query string parameters.


The VaryByUser property controls whether or not output caching varies by the domain and username of the context user.

Developers set the VaryByUser property:

  • To False for components that do not generate different output for different users.
  • To True for components that generate different output for different users, when the number of active users between publishing operations is relatively small. The VaryByUser treats all anonymous users as a single authenticated user.

To avoid excess memory consumption, avoid using the VaryByUser property except in solutions with relatively small numbers of users, or monitor cache utilization closely. The VaryByLogin property causes Sitecore to generate different output depending based on whether or not a user has authenticated, differentiating anonymous users from authenticated users. The VaryByUser property causes Sitecore to generate different output for each user

Other Caches

Sitecore contains a number of other caches that help to lower the number of calls required to the database for item information and indexes. These are best described in a post from the Sitecore Tactics blog entitled How Sitecore caching work.

Additional Helpful references

One Final Note

Starting in Sitecore 8.2, the Cache APIs where refactored, creating breaking changes to any custom cache providers used in previous versions. Be sure to check out the change list,


Solr and Sitecore Upgrade Cocktail

There is nothing worse than getting half-way to three quarters of the way through a Sitecore upgrade, just to be hit in the face with a strange error related to Solr. In the recent months, my team and I have seen an increase interest in Sitecore upgrades involving Solr implementations. In my latest post Sitecore Upgrades Mixed with Solr, I review some of the hurdles we’ve faced to help you on your path.

Early to Plan and Early to Test Makes an Upgrade

…Intuitive, Effective, and Calm.

On Wednesday, November 17th I had the opportunity to speak to the Fort Wayne SharePoint User Group. This was the first time I have spoken to a use group, and feel over all it was a successful presentation. The title of the presentation was “Early to Plan and Early to Test, Makes an Upgrade Intuitive, Effective, and Calm.” During the presentation I spoke about the different approaches and steps to upgrading a SharePoint 2007 farm to SharePoint 2010, as a number of those in attendance are looking to begin upgrade projects during the first quarter next year.

I told those attending that I would be posting my notes and slides. I tried to format everything to include in the body of this post, but I couldn’t find a nice way to do it without hand editing a lot of HTML. (Any suggestions for a good blog editor for Word Press, I’m currently using Windows Live Writer.) Here is a link to download everything as a docx file:


Creative Commons License
Early to Plan and early to Test makes an Upgrade intuitive, effective, and calm by Scott Gillis is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at
Permissions beyond the scope of this license may be available at

Installing SharePoint 2010 with Local User Accounts

This morning I awoke early to a lovely fall-esque morning, bright sun, clear sky, and just a little chill to the air…you never would have thought it was mid-August.

So a beautiful morning, mixed with a delightful cup of coffee (Wegman’s Cinnamon Nut coffee blend) seemed like the perfect fit to write an article on how to install SharePoint 2010 on a local virtual machine with domain connections for development.

So gather you cup of choose beverage ( I recommend a Bell’s Double Creamy Stout for an evening session of install, but I’ll leave that for you to decide) grab the machine of choice and let us begin.

I can’t claim to know it all, and have borrowed the notes made by Neil ‘The Doc’ Hodgkinson in his article from October 19, 2009 found at,

My first time attempt at performing an advance install of SharePoint 2010 on a single machine, I ended up with the following error message:


(For the search engine: The specified user <local user> is a local account. Local accounts should only be used in stand alone mode.)

So reading this message, I then uninstalled and tied again, but this time using the Stand Alone option given at install time. Well, this worked…BUT you end up with a special SQL Express version installed on your machine, and no control over what user accounts are performing what actions. This was not ideal for me, nor did it give me the additional practice of SharePoint farm installation that I was seeking.

So enough of the small talk…onto the How To!

  1. The first step is to plan out the appropriate user accounts that will be needed throughout the installation process.
    • Based on guidance found in MSDN and the SharePoint Getting Started Guide ( there area number of different user accounts that can be created and assigned to different tasks, in general I would recommend creating the following three accounts.
    • SQL Server Service Account
      • Purpose: Default account used to run the SQL Server services
    • Setup User Account
      • Purpose: Runs the Setup, SharePoint Products Configuration Wizard
      • Specific Requirements: Must be part of the Administrators group, and have read/write access to the SQL server. In addition this account should have db_owner rights in SQL so that PowerShell can be leveraged to get around the noted local account issue.
    • Server Farm and Database Access Account
      • Purpose: Configure and manage the server farm and acts as the app pool identitiy for Central Administration.
  2. Place the DVD into your system or mount the ISO you have. The following opening screen shall come up. Click Install software prerequisites to begin with to confirm all the needed items are installed.
    • clip_image004
  3. This is the opening screen to the prerequisite checker.
    • clip_image006
    • Click Next
    • This will run for about 10 minutes depending on what will need to be downloaded and installed. It is possible to pre-download the above items and install before running the pre-requisite checker.
  4. Click Finish. You will be returned to the opening screen.
    • Click Install SharePoint Server
  5. Enter your Product Key and click Continue.
  6. You are now prompted to either perform a standalone or a server farm install.
    • clip_image008
    • Select Server Farm. Stand alone will create the local SQL version, etc…
  7. Under the Server Type options, you should select Complete as it provides the ability to properly customize the installation.
    • clip_image010
    • Click Install Now
  8. Once the installation completes, you will be asked to launch the Configuration Wizard. DO NOT just blindly click Close. Uncheck the box that says "Run the SharePoint Products Configuration Wizard now." If you don’t the local user account error message will be displayed.
    • clip_image012
  9. Exist out of the Install screen by clicking Exit.
  10.   Now the product is installed, but nothing has been setup and configured. Why? Because we have delayed the running of PSConfig so that we could use local user accounts, instead of being attached to a domain controller.
    • This is were Neil’s blog article comes into play. His article can be found at
    • SharePoint 2010 has been integrated into PowerShell with a collection of administration cmdlets, more on this in future posts, some of which we are use to seeing as part of STSADM, and even some new ones.
    • For our issue we will need to use New-SPConfigurationDatabase cdmlet. This cmdlet creates a new configuration database on the designated SQL server, for a SharePoint Farm.
  11.   From the start menu open SharePoint Management Shell running it as Administrator this is required even if you are logged as a local administrator….this is a PowerShell prompt, with the SharePoint modules included, and enter New-SPConfigurationDatabase at the prompt and hit enter.
  12.   You will then be asked to enter the required information for a configuration database.
    • clip_image014
    • When prompted for the Farm Credentials make sure to include your machine name as the domain for the account and to enter the password. Passphrase is the password used of the login account.
    • If you receive any error messages, close out of the PowerShell console, delete the Admin and the configuration databases, if they exist, and try again. It does seem to take a few minutes for the process to complete.
  13. Once this succeeds launch the SharePoint Products Configuration Wizard. You will not get the normal opening screen, as we have already created the farm information via the above PowerShell cmdlet.
    • clip_image016
  14. Since the farm has already been created you will be shown the current farm settings. Make sure "Do not disconnect from this server farm." and click Next
    • clip_image018
  15. You will now be asked to configure the necessary settings for the Central Administration Web application for the new farm. Feel free to assign a new port or accept the default, just make sure to take note of what it is. As we will be using local user accounts through out this setup, NTLM is the preferred security setting.
    • clip_image020
  16.   After clicking Next, you will be given a chance to review the settings for the farm. If everything looks correct, click Next.
    • clip_image022
  17. Configuration will now begin, the green processing bar will fill back and forth completing the 9 tasks of SharePoint configuration. Upon completion of the 9 configuration tasks, you should see the "Configuration Successful" screen. Click Finish and the CA should appear.
    • clip_image024