A Use Case for Running Sitecore Powershell Extensions (SPE) locally only

We don’t install Sitecore Powershell Extensions (SPE) in our Production environment. Why? Because it adds a potentially dangerous attack vector if someone got a hold of an admin login. Yes, we argued this back and forth over time, but in the end came to a workable compromise.

The compromise was to run SPE locally, adding an extra connection string to point at the “master” database in the environment you want to target. We did this on an as-needed basis, and would receive a temporary user/pass combo for the duration of the work. This kept the scope of SPE use localized to just the developer’s machine being used, and as it was inside a corporate network, made it much safer than out in the wild.

Here are the two files to update to add a new “target” database:

  1. /App_Config/ConnectionStrings.config
    1. Add an new node and name it uniquely (eg. “remote_master”)
    2. You will use this unique name in the other file
  2. /App_Config/Sitecore.config
    1. Copy the whole <database id=”master” /> node and rename the “id” property to what you used in the previous step (e.g. “remote_master”).
  3. After IIS recycles, you’ll have an additional target you can reference in your  Powershell script with a prefix: “remote_master:/some/path”:

For SPE in general, as with any powerful tool, there is still the “use it responsibly and test, test, test locally first” approach, but having this compromise has saved us a few times. If you haven’t heard of SPE, check it out (https://marketplace.sitecore.net/en/Modules/Sitecore_PowerShell_console.aspx). It’s worth getting familiar with if only to add another tool in your belt.