Yet another Sitecore 9.2 Install Blog

Setting up a developer VM got much easier with 9.2. I'm sure lots of these "how to" posts are going up; here's mine (as much for my own reference as anything else).

I'm assuming you're using a "bare" Azure VM with Server 2016, but the steps shouldn't be much different for other hosting scenarios. I use a DS4 v3. I take liberties with security best practices, since this is a dev box.

Installing SQL

Install en_sql_server_2017_standard_x64_dvd_11294407.iso.

• Instance ID: MSSQLSERVER
• Mixed Mode authentication
• Assign a SA password
• Add your machine account as an admin.

Install management tools 8.1

• Installer: https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-2017 

Create a service account

• sitecore/sitecore 
• Enforce password policy off 
• Server Roles > sysadmin 

Enable "contained database authentication"

• Run the SQL script:  EXEC sp_configure 'contained', 1; RECONFIGURE;

Install Solr 7.5

• Install JRE using https://download.oracle.com/otn/java/jdk/8u171-b11/512cd62ec5174c3487ac17c61aaa89e8/jdk-8u171-windows-x64.exe  

• There's lots of good Solr installation scripts. I used this one: https://github.com/Sitecore/Sitecore.HabitatHome.Utilities/blob/master/XP/install/Solr/install-solr.ps1 to C:\Setup\solr\
• Setup the variables at the top as desired: 

[string]$solrVersion = "7.5.0", 
[string]$installFolder = "C:\solr",
[string]$solrPort = "8983", 
[string]$solrHost = "solr750.local", 
[bool]$solrSSL = $TRUE, 
[string]$nssmVersion = "2.24", 
[string]$keystoreSecret = "secret", 
[string]$KeystoreFile = 'solr-ssl.keystore.jks', 
[string]$SolrDomain = 'solr750.local', 
[switch]$Clobber 

• Run powershell as admin in C:\Setup\Solr 
• .\Install-Solr.ps1 
• Test https://solr750.local:8983/solr/#/ 

IIS

• IIS 10, using Server Manager > Roles and Features > Tasks > Add Roles and Features > Web Server 
• .NET Core 2.1.7 Windows Hosting Module https://dotnet.microsoft.com/download/thank-you/dotnet-runtime-2.1.7-windows-hosting-bundle-installer  

Sitecore

Install SIF 

• Register-PSRepository -Name SitecoreGallery -SourceLocation https://sitecore.myget.org/F/sc-powershell/api/v2 
• Update-Module SitecoreInstallFramework 
• Validate: Get-Module SitecoreInstallFramework –ListAvailable 

Install Sitecore 

• Use “Graphical setup package for XP Single” https://dev.sitecore.net/~/media/1C1D7C4CBC934A6AA36825974A18A72E.ashx  

SXA

https://dev.sitecore.net/Downloads/Sitecore_Experience_Accelerator/19/Sitecore_Experience_Accelerator_190.aspx 

• [Correction 7/29/18] SXA 1.9 requires Sitecore Powershell Extensions 5.1. As of this writing, that version is not available on the Marketplace. You can download SPE 5.1 from https://github.com/SitecorePowerShell/Console/releases/tag/5.1.
  Install Sitecore Powershell Extensions 5.0 full from https://marketplace.sitecore.net/Modules/Sitecore_PowerShell_console.aspx 

• Download “Sitecore Experience Accelerator for 9.2” from https://dev.sitecore.net/~/media/FB62D25D54C945999FE05C0E22B29622.ashx  

• Follow instructions in the Installation Guide https://dev.sitecore.net/~/media/870D6095010241668E83E16C8DB2C850.ashx
  (be sure to create and populate cores, rebuild indexes) 

JSS

https://dev.sitecore.net/Downloads/Sitecore_JavaScript_Services/120/Sitecore_JavaScript_Services_1200.aspx 

• Install the latest Node.js https://nodejs.org/en/ 
• Download server components https://dev.sitecore.net/~/media/21E55AD5AEA145C2903E1FB3A25B079E.ashx 
• Install package Sitecore JavaScript Services Server for Sitecore 9.2 XP 

Understanding Sitecore SXA: Why SXA?

Traditional Sitecore implementations have always been a “custom build” proposition. And with each custom build often comes a different approach and methodology. How can organizations overcome the cost, time and stress involved with a fully custom build?

Once regarded as a “small site” tool, SXA has evolved into an enterprise-class framework. 

Organizations can embark on projects large and small, secure in the knowledge that best practices are already baked into the solution.

When leveraged to its fullest, SXA allows organizations to redefine the process for building and maintaining sites, in a way that shortens timelines, reduces reliance on development, and promotes team collaboration. Projects are accelerated by utilizing a toolbox of pre-built components, and by embracing a compressed project cadence that promotes collaboration and brings the work of many teams into a more parallel arrangement.

Your New Development Process

With SXA, Sitecore itself becomes central to solution development as well as content development, bringing together the visual and UX designers, content creators, back-end and front-end developers.

Serving as the wireframing tool, SXA allows content creators to develop content and construct pages in a wireframe mode, as designers and front-end developers style the site in parallel. These “themes” are applied iteratively to content being created in flight.

Improved Time-To-Value

With development and content being developed in parallel, project timelines are shortened. Unexpected conflicts are uncovered as design meets real world content, allowing adjustments to be made sooner, with a less regressive remediation cycle.

In a multi-site environment, content and presentation can be shared across sites, streamlining development as additional sites are added.

Lower TCO

Much of the classic development cost for a typical site can be avoided, by leveraging the impressive set of components that ship with SXA. Many tasks once relegated to developers and requiring code deployments are now accomplished in the Sitecore UI and simply published.

Page editors have more control over the styling and composition of common presentation components, freeing developers to focus on domain-specific custom features.

SXA’s framework, with strong separation of presentation from design, promotes multi-site development with heavy re-use of components, further lowering development cost.

Reduced Organizational Stress

SXA allows organizations to start with a strong foundation, using a fully supported and tested framework that makes the entire process more reliable and reduces rework. Solution structure is consistent across sites, making development more predictable and allowing developers to switch between projects with less ramp-up time.

Developers are relieved from mundane tasks, allowing them to focus on more interesting challenges, while content creators are freed from reliance on development to achieve commonplace requirements. Having fewer code deployments reduces friction and removes barriers to content publishing.

Upgrades become more approachable, because less coding means fewer regression issues to remediate.

Next: What is SXA?

Home: Understanding Sitecore SXA

Understanding Sitecore SXA: What is SXA?

Previous: What is SXA?

Marketers and technologists often struggle with complex implementations. Faced with a dazzling array of new technologies, organizations everywhere are trying to develop a roadmap that fits the right technologies with their business objectives. But as many have learned, the road to success is often bumpier than expected.

SXA delivers key features out-of-the-box, shifts development away from coding and into UI, and provides a reliable framework for execution.

Projects can now start with a fully-baked scaffolding, that puts mobile first, separates presentation from content, and already contains a host of presentation components. In addition, key features like url management and search are already incorporated, and the execution methodology is clear and well understood.

For Marketers

• Best practices (“Helix”) baked in
  Consistent structure of content reduces guesswork. Start with a stable solution that is poised to grow as needed.
• Extensive component suite
  Most of the commonly needed components are ready to go, right out of the box.
• Search
  No need to invest in a separate search technology for many common search requirements.
• Multi tenant and siteHost multiple sites in a single infrastructure, with selectively shared content and cross-site link management.
• Layout and rendering flexibility
  Content editors have more control of layout and appearance. Renderings can be tweaked, extended or created without having to wait for development.
• Parallel development and content load
  Content pages can be developed in a wireframe mode, and style can be applied is it becomes available.

For Technologists

• Best practices (“Habitat”) baked inAvoid costly strategic errors in new projects. Coders are immediately familiar with existing projects.
• Extensive component suiteNo need to develop commonly used components. All pre-built components can be styled, extended or replaced as needed.
• Search
  Fewer technologies to maintain, fewer integration points to fail.
• Multi tenant and site
  Less infrastructure to maintain, better re-use of code, and consistent deployment strategy.
• Layout and rendering flexibility
  Developers focus on new features and capabilities, rather than tweaks to existing artifacts. Fewer regression bugs.
• Parallel development and content load
  Front end developers can see real-world instances of their design by switching completed pages into their custom theme.

Next: Rapid Start, Smooth Execution

Home: Understanding Sitecore SXA

Understanding Sitecore SXA: Which Way to Go?

Previous: Changes to Roles and Processes

When is SXA the right course for a project, and when is a conventional build the right way to go? The answer is, “it depends”.

For smaller projects, where a conventional Sitecore build was too large an undertaking, SXA changes the equation by reducing the build time and technical burden. Customers building smaller sites can now reap the benefits of Sitecore’s engagement and marketing automation capabilities, instead of limiting themselves to a less capable CMS tool.

For large enterprises that face a range of challenges, the choice between SXA and a conventional build becomes more nuanced. In a development-lead culture, or where heavy functional functionality is required, a conventional build may be best. But SXA is a viable, even desirable, choice for organizations experiencing a digital transformation and orienting to a marketing- and business-forward approach.

Organizations with a large amount of web presence can use SXA to “pace layer” their solutions into more manageable groupings that develop at different rates and have different orientations. SXA reduces the friction for building smaller, more nimble projects. An enterprise might have a classic build for portal or corporate sites, and an SXA model for brand sites, location sites, and campaign sites. This allows nimble execution for time-critical marketing demands, alongside a more rigorous model for times when fidelity and precision are crucial.

For battle-scarred managers who have survived painful and expensive builds, SXA is a welcome relief. Those who’ve survived those rocky projects in the past would gladly embrace a more prescriptive process that starts with “best practices”.

Read the full series on SXA: Understanding Sitecore SXA

Understanding Sitecore SXA: Changes to Roles and Processes

Previous: Prescriptive, Yet Flexible


Two of SXA’s key benefits are improved project cadence and less reliance on development. Achieving these goals often means changes in roles and responsibilities.

Development doesn’t necessarily mean coding

With SXA, some of the implementation work that would otherwise be done in back-end code is now done in the Sitecore UI. That doesn’t mean that code is written in a Sitecore UI, but it does mean that some things that would have otherwise required code are now either done in, or supplemented by, activities in the Sitecore UI.

Once upon a time, the Sitecore UI largely insulated the person in the chair from technical “stuff”. Now, quite a bit of that technical stuff is managed in UI. Structuring components was once done entirely in code, now this is done largely in Sitecore. You’ll find yourself declaring element tags and CSS classes, creating data queries and using substitution tokens, and structuring things akin to models and markup. But just because it’s managed in UI doesn’t mean it doesn’t require a technical thinker.

Although much of the methodology shifts from code to configuration, developing functionality in SXA is conceptually more akin to development than content management. Just like in coding, an understanding of what can be done and how things work, leads to effective solutioning. Your technical staff is going to change where and how they do a lot of this work, and the big benefit is that many things that would otherwise have required a code deployment now just require a publish.

This will require a shift in thinking for both I.T. and Marketing. In the early days of CMS it was often hard for I.T. to accept that content management was now a production activity; now they must accept that more things that have been traditionally subjected to development protocols are now becoming production activities as well.

Front-End in the loop

The role of the front end developer isn’t just coding, and it isn’t just design. It’s some of both and other things besides. Since SXA is a framework that manages the methodology for developing both structure and style, the front-end developer’s work becomes part of the SXA flow.

Changes to HTML structure are done directly in SXA (or at times, in back-end code). This may be driven by the need for new renderings, or by imperatives the styling process. As wireframes and content are developed, the entire site (or portions of it) are exported to a ZIP file, where designers and front-end developers extend CSS and JavaScript and apply styling using their preferred tools. Sitecore’s Creative Exchange re-imports this zip file, detects changes to styling, and applies them to the system. The styling methodology is constrained by how the SXA framework operates (for example HTML structure and content can’t be modified, and existing class cannot be removed), and  SXA injects comments into the HTML to direct developers as appropriate.

If desired, teams can use “Creative Exchange Live” to fully automate the export/import loop. Creative Exchange can be triggered by a Continuous Integration server, integrating code changes into the main branch, and to test changes early and often.

Next: Which Way to Go?
Home: Understanding Sitecore SXA

Understanding Sitecore SXA: Prescriptive, Yet Flexible

Previous: Improved Project Cadence

Many marketers and technologists have found that their perspective on a large project can change rapidly, as the level of effort and learning curve become increasingly clear. The envisioned scope, schedule and budget are all threatened, as the imagined methodology and cadence meet reality.

SXA tackles this dilemma by providing a proven structure, framework, and methodology. The aim is to simplify processes, increase collaboration, shorten timelines, and smooth the path to success. Naturally, the maximum benefit is gained by a comprehensive adoption, but SXA can be used in an opt-in fashion, utilizing some of its features and replacing others with more conventional approaches.

By embracing all of SXA, organizations achieve the maximum benefit that they seek from a prescriptive, out-of-the-box framework. For many organizations, however, there are aspects to the architecture or build process that need a more custom approach.

Going All In

Adopting SXA to its fullest doesn’t mean giving up customization. Design customization is an essential part of an SXA build. Customizing CSS, building multiple themes, and extending the client-side structure are all common activities in an SXA build.

Page structure are actually more flexible with SXA than a typical conventional build. Content editors are able to drag-and-drop renderings, choose from more focused data sources, and adjust column widths. Also common is the use of Rendering Variants, to change the structure and appearance of components — without requiring code deployments!

SXA’s preferred project cadence solves a common pitfall. When design collides with content, it often becomes necessary to adjust, when styling designed for best casecontent collides with real world content. In the SXA model, these collisions are detected earlier, and remediated faster than with a conventional build.

In an all-out SXA implementation, the design/style/construct process is shortened, but changes from conventional expectations.

Wireframes are developed directly in Sitecore. They are exported as packages with HTML, CSS and script, organized in an orderly layered stack based on themes. Designers and front-end developers then style these wireframes, by extending and modifying the CSS and script (for the most part, without changing the HTML). Their work is imported back into Sitecore, where their theme(s) are applied to the site(s) that have already begun to take on content and structure.

This process can be iterative and branched. The export/style/import process can iterate, without necessitating radical changes to the existing work. In fact, Sitecore SXA provides “Creative Exchange Live”, that uses the gulp toolkit to bring design into a dev-ops model for continuous integration. Content editors continue to develop content and construct pages while the styling process iterates, shortening the project timeline and providing more real-world content to help refine the styling.

Multiple themes can be developed within or across sites, allowing the same components and structures to be presented differently simply by selecting from the different themes. The compounded power of reusable components with customizable themes and development-free customization, creates a force multiplier that can dramatically improves time-to-value.

Deep customization when needed

SXA ships with an impressive set of components that cover most of what the core of any site will need, and through the use of “rendering variants”, new renderings can be created without requiring coding.

Using these components out-of-the-box means (for the most part) working with the HTML as provided and styling entirely with CSS and script. An implementation can replace the HTML of all or some of these components and add new ones, but this requires requires a back-end development process more akin to a conventional build. Custom HTML is cut up and used as prototypes for c# developers to create new views, which replace default views or are registered in SXA as new components. Changes to the HTML require code deployments after a round trip through this back-end development process, which can slow concurrent content development.



Next: Changes to Roles and Processes

Home: Understanding Sitecore SXA

Understanding Sitecore SXA: Rapid Start, Smooth Execution

Previous: What is SXA?

Today’s marketing technology landscape has become a “field of dreams,” offering a dizzying array of platforms, technologies, and strategies. Marketers are eager to make their own dreams a reality, utilizing these tools to achieve the promise of true customer engagement.

Two things become quickly apparent.

• Actually living that dream means changing business as usual.
• Understanding how to execute is the difference between a dream and a nightmare.

Adopting a powerful technology like Sitecore can be overwhelming. A knowledgeable partner knows the landscape can guide a successful implementation, but a complex implementation can be a long and trying process.

By combining a suite of pre-built components and user-friendly tools that smooth the learning curve, SXA gets projects off to the right start and streamlines execution.

Throughout and beyond the initial project build, much of the work of modifying layout and even building new features is shifted to the Sitecore administrative interface, meaning many things that have historically relied on cumbersome code deployment processes can not be achieved with a mere publish.

Time-to-value is reduced, and concurrent team collaboration becomes a force multiplier rather than a series of tactical waves.

Next: Improved Project Cadence

Home: Understanding Sitecore SXA