How to Create SharePoint Web Applications with PowerShell

 

This post talks about creating SharePoint web applications with PowerShell. Though the concept is pretty simple, there are always a few things that I forget to do when I'm in a hurry – like adding the object cache accounts to my web application after it is created. The sample script I'm providing takes care of all the basic things that I repeatedly have to do but usually forget to do.

Background

 

I just rebuilt my work machine using Windows 8 and Hyper-V. While doing that, I figured it would be as good of time as any to toss my old virtual machines and start over with clean environments. Part of that process was to create several web applications. Though it would have been relatively easy to just create 5 or 6 web applications, I knew I would forget a few things if I had to do it manually – and I know I'll probably have to do this again sometime soon anyhow.

Approach

 

The Approach in this case was pretty simple.

  • Check to see if a web application with the current specified URL is already in use – exit if it is
  • Check to see if an application pool with the name already exists. If so use it, otherwise create one
  • Create a web application based on the parameters specified
  • Assign the object cache properties to the new web application
  • Create policies for the object cache users to the web application

Solution

 

As I mentioned above, there really are only a handful of steps involved, and most are straightforward. For the first step, checking to see if a web application already exists, we can use Get-SPWebApplication. If this returns an object, the URL for the web application is already in use by SharePoint.

Once we've determined that the web application URL is available, we can check to see if the application pool name selection is available. This becomes a little more complicated – and probably the cause for 90% of my headaches while preparing this script. The obvious way to go about determining if the application pool name is available is to use Get-SPServiceApplicationPool.

 

This Cmdlet covers most scenarios, however it doesn't account for any application pools somebody might make that are not associated with SharePoint. Such as the DefaultAppPool. Personally I'd recommend to use servers that are dedicated to SharePoint as your web front-end servers, however that's not always under your control. For that we need to use the Test-Path Cmdlet. Using Test-Path against IIS objects will require you to import the WebAdministration module, but is also relatively straight forward.

The challenge in my case was working out the correct logic to make this work for my intended purpose – luckily now we won't have to again. Now that if the application exists, we can choose whether we're going to use the existing application pool or create a new application pool. We've already addressed how to use Get-SPServiceApplicationPool, so let's look at New-SPServiceApplicationPool

Asides from a few cosmetic options in the script, we're just about ready to create the web application. We do this using New-SPWebApplication.

After the web application is created, I simply create web application policies and assign properties for the SharePoint Object Cache accounts. There is a significant amount of error checking in the sample script provided; however not all error checking is performed. Any error checking not included in the script will not be suppressed during execution. This can be easily demonstrated by specifying a content database which is already used by SharePoint, or a database which is not usable by SharePoint which exists on the SharePoint database server.

You can download the Web Application Creation script from this location: Download CreateWebApplication.ps1 (zipped)

Usage

 

Simply log into the server using an account which has sufficient privileges to create SharePoint web applications. Modify the script to suit the needs of your environment. Keep in mind that object cache accounts may be claims users as opposed to classic users. Ensure that the object cache user accounts are configured to match your deployment.

Feedback

 

As always, if you have any questions or feedback, let me know. If you have any ideas to optimize the script, I'd like to hear that too. Thanks for reading!

You can also follow me on Twitter:

 RCormier_MSFT