Most companies that use SharePoint as their Intranet or collaboration platform have (or should have) multiple SharePoint environments so they can stage their solution before they go in production. Most companies usually have to go through 3 steps before going in production, for example Dev -> QA -> Staging -> Production.

This is a great practice and makes all production environments more stable. However, as a SharePoint admin, I often have the problem where I can’t run the same PowerShell script in QA as I do in staging because URL’s usually change, some file paths usually change. So every time, I move a script from DEV up to production, I find myself modifying the script every time, and create a chance of error.

In this blog post, I will show you how to use environment variables in order to make your SharePoint PowerShell scripts universal and be able to use them in each of your environments without ever changing your script.

First of all, what exactly is an environment variable?

Environment variables are, in short, variables that describe the environment in which programs run in. They are used by all kinds of programs and scripts to answer questions like: What is the name of the computer where I am installed? What is the name of the user running me? What is my current working directory? Where is Windows installed? Where are temporary files stored?

You could say it works a bit the same way as SharePoint admins use cliconfg to set an alias for the SQL instance when they install SharePoint. Furthermore, similar to the SQL alias, you will need to set it on all the SharePoint servers you want to run the script on.

There are two sorts of environment variables: User and Computer. User Environment variables only apply to the logged in users, while Computer variables apply to everyone that runs a script on that server. In this article we will use environment variables as sometimes, you will run PowerShell scripts under a service account in a scheduled task for example, so you don’t want your variables to be locked in to your user.

Let’s create a very simple SharePoint script that you need to run in all your environments. First, let’s see how it would be done the “old way”:

$web = Get-SPWeb -Identity
Enable-SPFeature -identity “MyCustom” -URL $web

In this very simple script, every time you go from Dev, to QA, to UAT to Production, you have to open it up and change it. In this case it’s not bad, because if the SPweb does not exist, your PowerShell will fail, so you will be aware of the error .However, in other cases such as for example adding a navigation item, the script will run, but if you forget to change the parameters in the script, your production environment can point to DEV.
Now, let’s see how we can use Environment Variables to run the same PowerShell script in all the environments, without changing one thing. First, let’s create our environment variable.

1.    Press start, and right click on Computer.  From there, choose the Properties Option

Properties Option

2.    Click on the Advanced System Settings button

Advanced System Settings Button

Environment Variables

4.    Under System Variables, click on New

Under System Variables

5. Name the variable “Intranet_URL” and give it the value of an existing webapp on your SharePoint farm.

New System Variable

You now have an environment variable called Intranet_URL with the value of http://demosite . But how do we call it in PowerShell?
$web = ((Get-ChildItem Env:Intranet_URL).Value)

Here is the result:

The Result

In order for this to work, you would have to create the variable Intranet URL in all your environments, but with different values! Once this is in place, you will never have to edit your PowerShell scripts again when going from Dev, all the way to prod!

Getting Everthing You Ever Wanted Out Od Share Point (via Power Shell)

Vlad Catrinescu

About the author Vlad Catrinescu: Vlad is a SharePoint Consultant with more than 5 years in IT specializing in analyzing and deploying your perfect SharePoint Infrastructure. He also specializes into designing and implementing High Availability and Disaster Recovery SharePoint solutions as well as hybrid scenarios between SharePoint and Office 365 and deployment automation using Microsoft TFS. Vlad is a Microsoft Most Valuable Professional (MVP) in SharePoint since 2013 and is known in the community for his technical abilities and for founding the biggest and most active SharePoint Community that you can find at www.SharePoint-Community.net. Vlad also has his own blog at http://www.absolute-sharepoint.com and he often shares his knowledge by speaking at local conferences and community events.

Check out the 2016 European SharePoint Conference video: