Setting up a Commerce Server Site with PowerShell

Previously, PuP packages were the only way to create Commerce Server sites, add resources, and move data between environments. Now you can use a suite of PowerShell CmdLets to manage your sites. These CmdLets perform many tasks you would have had to do manually.

For example, previously to set up the Reference Storefront, you would need to:

Along with those steps, you would need to decide on the correct security permissions to apply for each application pool.

Now, using CmdLets, the process is more streamlined:

Things such as PuP packages, importing data, SQL files, database security, AzMan security, Web Service security, and DCOM security are no longer concerns. The new CmdLets take care of those tasks based on convention and best practices. You can override the default behavior by using optional parameters or more granular CmdLets, but the previous steps will work for the majority of non-production cases.

The Initialize-CSSite CmdLet works by scanning the Website folder for a file that contains a Commerce Server configuration section. It scans Website\App_Config\CommerceServer.Core.config first, followed by \Website\web.config. Once a configuration section is found, the CmdLet will analyze the configuration xml to see what the name of the Commerce Server site required is, and what resource(s) are needed. Once the requirements are determined, the CmdLet will scan for a Commerce Server site by that name. If a site does not exist, the CmdLet will create it. Then the CmdLet will loop over all of the required resources and create those resources if the site does not already have them.

With the required Commerce Server site and resources now created, the CmdLets will now try to import data and schema xml files for each subsystem. By default, the CmdLet will scan for a directory called \Website\SitecoreCommerce\Data\, and look inside that directory for directories that match the name of subsystems existing under the Commerce Server site. For each resource directory that exists, the CmdLet will import the data for that subsystem. This means that you can now use Sitecore packages to move your seed data along with your site. This works well for development or small demonstration sites, but would not work as well for scenarios where you have very large catalogs.

Once the Commerce Server site and resources have been created, and data has been imported, the CmdLet will try to secure the deployment. The CmdLet will grab the user name of the application pool that the Sitecore site is running under, and add that user to the appropriate database and DCOM roles determined by the resources being used by the site. By default, this user will be given management level permissions on whatever subsystems are available to the site. For example, this user will be allowed to edit items in the catalog.

The New-CSWebService CmdLet will create the requested subsystem web service for you in the specified IIS Site. Unlike previous releases, web services are set up using Visual Studio Web Deploy packages, which are available inside the Commerce Server install directory. If you have a remote IIS instance, such as in Azure, you could take the Web Deploy packages and deploy them manually into IIS without using the CmdLets.

This CmdLet will also take care of common web service tasks, such as turning on Windows Authentication and turning off Anonymous Authentication. The user id will also be added to the Administrator Azman role for each web service, so that as soon as the CmdLet is finished running you will have permission to use it. Finally, the application pool user for the catalog web service will be given write access to its AzMan file.

The New-CSWebService CmdLet does not apply database security for application pool users. You can do that by running Initialize-CSSite in the web service folder, or use one of the Grant-CS*ManagementPermissions CmdLets such as Grant-CSCatalogManagementPermissions.