Home » How to Install and Configure SharePoint using Windows Powershell

How to Install and Configure SharePoint using Windows Powershell

Summary:

Several sites already explain how to install and configure SharePoint using Windows PowerShell (see “Related Articles“). But anyone wanting to customize their environment or learn PowerShell will benefit from separately installing SharePoint, its application pools, its service applications, etc.

Requirements:

  • Three servers (ours are virtualized) running Windows Server 2008 R2: A database server with SQL Server 2008 R2, a “primary” application server, and secondary application server(s).
  • SPModule extracted to the desktop of each application server. Download SPModule.
  • SharePoint installation folder on the desktop of each application server. Download a trial version of SharePoint.
  • Office Web Apps extracted to the desktop of each application server. Download Office Web Apps. (Sorry, but you’ll need an MSDN subscription)
  • Cumulative Updates, saved to the desktop of each application server. Check for the most recent cumulative update. As of this posting the most recent CU is October 2011 (Caution: Test your CUs thoroughly before using in production and only install these if you need a particular fix. I assume if you’re following these steps, you’re working from scratch in a development environment anyway):
    1. Download SharePoint Foundation 2010 Cumulative update (but don’t install it yet).
    2. Download SharePoint Server 2010 Cumulative update (don’t install it yet).
  • An alias from the App servers to the database server. Ideally, you’ll also change the port SQL is listening on. Our alias is called “SharePoint_alias”. Instructions for setting up an alias are here.
  • Hotfixes not included in your Cumulative Updates. Any Hotfixes that were previously part of this process are included in the October Cumulative Update.
  • Finally, you must be logged into both/all application servers as “SP-SETUP” (a domain account that must be a local administrator on all app servers that you plan to install SharePoint onto). Also, “SP-SETUP” (sometimes people name it “SP-ADMIN”) must have the following “Login roles” on the DB Server (set these via SQL Management Studio): dbcreator, public, and securityadmin.

Preparation: Set up application server desktops

Having downloaded everything… make sure the desktop of each app server looks like this image:

Preview of desktop prior to install
Must have SharePoint, Office Web Apps, SPModule, and Cumulative Updates downloaded to the desktop

Step-by-step SharePoint Install

Install SharePoint: Run on the main Application Servers

Run this script in Windows Powershell as an administrator, and on all application servers.

Create Configuration Database: Run only on the main Application Server

Run this script in Windows Powershell as an administrator.

Join other servers to the farm: Run on all other Application Servers

Run this script in Windows Powershell as an administrator, and on all other application servers.

Create Managed Accounts:

You will need to add these accounts to active directory first. Run this script in Windows Powershell as an administrator.

Create Web Applications

We’re creating three: one for our web front-end applications, one for MySites, and one for the company intranet.

“SharePoint Front End Web Application” Web Application and Application Pool

“SharePoint Intranet Web Application” Web Application and Application Pool

“SharePoint My Sites Web Application” Web Application and Application Pool

Get Web Applications

Create Application Pools

How many application pools should you create? Which accounts should you assign to the application pools? Check Harbar.net: More on SharePoint Application pools to see what the application pools look like after a default SharePoint install (i.e., one configured with the “Farm Configuration Wizard”). It will help you choose which service accounts to use and what application pools to create. I’m using several pools. In most small or medium environments, they can share one. Run this script in Windows Powershell as an administrator.

# Create “SharePoint Office Web Apps Application Pool” Application Pool

# Create “SharePoint Managed Metadata Application Pool” Application Pool

Create “SharePoint User Profiles Application Pool” Application Pool

# Create “SharePoint Web Services Default Application Pool” Application Pool

# Get Application Pools

Set up Office Web Apps

Related:

Office Web Apps (OWA) allows you to work on Excel, PowerPoint, and Word files in a browser. This requires cache, which is stored inside a special OWA site collection called “Office_Viewing_Service_Cache.” A cron job automatically creates it inside each Web Application in your farm. But here’s the thing: look for that site collection and you’ll see that it shares its content database with every other site collection in the Web Application. That’s right: inside any Web Application, Team sites, publishing sites, and OWA will, by default, share the same content database.

As you continue reading, keep in mind that Microsoft discourages letting content databases get larger than 200 GB and that OWA Cache can be very large — up to 100 GB. Also, since it’s cache, it doesn’t contain anything that can’t be lost. So that’s potentially 100GB of space on your content database that’s being unnecessarily used (and unnecessarily backed up). Given that this potentially eats up half of your allotted space on the content database, it is best to separate out OWA and give it its own content database. That way, you can exclude it from backups and forever ignore it. And as long as we’re doing that, we might was well put it in its own, separate managed path. Therefore, the basic steps are to:

  1. Remove all existing managed paths inside each web application (e.g., “/sites”)
  2. Add new managed paths (e.g., “/owa/cache”)
  3. Install OWA
  4. Turn OWA on (on each server)
  5. Wait 5 minutes for the cron jobs to run and install “Office_Viewing_Service_Cache”
  6. Create new content databases for OWA cache and Link “Office_Viewing_Service_Cache” sites collections to those new content database
  7. Re-create managed paths (e.g. “/sites”) (this is done in the next section, after iisrestart and other stuff)

Remove all existing managed paths

The code snippet below removes the “/sites” managed path on each Web Application. If we don’t do this, Office Web Apps — once installed — will automatically install site collections there (one on each Web Application). Run these scripts in Windows Powershell as an administrator. (I’ve separated them because they require user input.)

Add new managed paths

Let’s give OWA a new path to use: “/owa/cache”. Run this script in Windows Powershell as an administrator.

Install OWA: You’ll need the PIDKY-PIDKY-PIDKY-PIDKY-PIDKY

Just use the installer on the desktop and when it’s done, run the PSConfig script. That is necessary. Repeat both the install and the PSConfig script on every ‘application’ (not db) server in the farm. Say “Yes” when it asks if you want to make SP better. Cancel when it prompts you to run the farm configuration wizard.

Turn OWA on

Wait 5 minutes

During this time, a SharePoint cron job runs. It automatically creates a site collection for Office Web Apps. This site collection is created in the first place that it finds a wildcard managed path (that is, a non-explicit path). Since we deleted all the managed paths in each web application and left only “/owa/cache”, the cron job is forced to put its site collection inside that path. (Comment 79 discusses this.) To see when the OWA Site Collection has been created, go to http://www.contoso.com/_admin/SiteCollections.aspx. You will know the cron job has done its thing when you see “/sps/cache/Office_Viewing_Service_Cache” in the list. Click on it. Off to the right you will see it is using the default content database. We’ll need to change that in the next step.

Create new content databases for OWA cache

Here’s what this script does:

  1. It cycles through each Web Application in your farm
  2. It comes up with a name for the new content database: “SP2010_OWACache_WebApplicationNameWithoutSpaces”
  3. It checks whether a content database by that name already exists
    • if a content database for the cache already exists, it moves the cache to that content database;
    • If one does not exist, it creates a new content database

This script has been changed so that it loops through and makes this change on each Web Application (here’s a version that runs only on a URL you specify). Be sure to save this to C:Scripts (say as “C:ScriptsOWAConfigCache.ps1”) and then run it from Powershell ISE as an administrator. E.g., from the prompt, PS C:Scripts > .OWAConfigCache.ps1

Grant the office web apps service account access to content databases

# iisreset

Install Cumulative Updates and Required Hotfixes

Cumulative Updates

Check for the most recent cumulative update and install whatever version is appropriate. As of this posting the most recent CU is October 2011. Note: Always install SharePoint Foundation 2010 patches before you install SharePoint Server 2010 patches. And don’t get clever trying to install one right after the other without restarting or running PSConfig. This might ruin your installation. (I just did this. I restarted, but did not run PSConfig, between installing Foundation CU and SharePoint CU. It worked out Ok.) Install Foundation CU. Restart. Rinse and repeat on all other app servers. Run PSConfig. Install SharePoint CU. Restart. Rinse and repeat on all other app servers. Run PSConfig.

  1. Download SharePoint Foundation 2010 Cumulative update (Install this first)
  2. Download SharePoint Server 2010 Cumulative update (Install this second)

Hotfixes

Check that required Hotfixes were installed as part of the CU; if not, install them now. Any Hotfixes that were previously part of this process are included in the October Cumulative Update.

Create Managed Paths

At this point, you will probably want to think about your environment and whether it will use managed paths or host-names. Here are two Technet articles to help you (a) plan for host-named site collections (SharePoint Server 2010) and (b) define managed paths(SharePoint Server 2010). Run this script in Windows Powershell as an administrator.

Get managed Paths

Create Default Managed Paths (Basically, add the “/sites” path that we took out before)

Remove Managed Paths (if necessary)

Install Service Applications

Create Managed Metadata Service Application

Start Managed Metadata Services

Thanks to Eric Schrader for code:

Usage and Health

Start Search Service Instance

This code is lifted pretty much directly. I recommend installing it line-by-line to address possible errors. One error I get is that write-host $QueryTopo.State returns “Inactive.” Update: It returns “Inactive” because it fails: “Another topology activation is in progress. Please wait until it is finished and try again.” Simply wait 10 minutes and try that line (line 10) again.

Note: If it returns “Inactive” it is because it fails. It fails because “another topology activation is in progress.” Solution: Wait 10 minutes before running this last command.

Business data

State Service

Install Site Collections

New SP Site

Create”My Sites Host” site collection

Remove SP Site (So you know how)

Provision UPS

Several questions: In which application pool should this service application run? A separate “SharePoint User Profile” application pool? Or the “SharePoint Web Services Default”? At least one tutorial uses a separate “SharePoint User Profile” application pool. That same tutorial uses a separate application pool for Managed Metadata. But Microsoft’s Technet, Troubleshoot User Profile Synchronization Service start issues, uses the “SharePoint Web Services Default.” I chose to use a separate pool.

Helpful Articles about UPS:

So. Onto the procedure…

Add farm account to local administrators group

Yes, add SP-Farm to the local administrators. You will remove it again when the process is complete. Do this with the server manager. No powershell needed.

Restart

Grant Replicate Directory Changes permission on a domain to the SP-UPS account

Try to install UPS using Powershell

Note: I’ve been having trouble setting up UPS using Powershell. I’m still trying to figure out what the deal is. Ideally, you would run this script in Windows Powershell ISE as an administrator, remembering to change the variables… and, IDEALLY, this would work. Alas, it does NOT work.

I’m still testing possible solutions for this and am documenting what I try in another post: How to configure the UPS with Powershell. What I’ve found is that provisioning UPS with PowerShell does not work due to a bug in SharePoint. When running these Powershell scripts, the provisioning is done as a setup account. But UPS must be provisioned with the Farm account. Therefore, if you try to provision UPS using Powershell, it will seem to work, but it will not have proper permissions to start itself up and will simply say “Starting” or “stopped” when you try. Getting around this requires knowing how to run the Powershell UPS Provisioning script as another user — in this case the farm account user. This page (and the above code) allegedly offers a way to do this, but it hasn’t worked for me. Therefore, I recommend creating the UPS manually — that is, through the GUI. This site has a good tutorial: Configuring the User Profile Service in SharePoint 2010. When a solution is found, this page will be updated.

Follow SharePoint George and do this through GUI

Start UPS and UPSS

Enable NetBIOS domain names on UP Service Application:

Remove SP-Farm from local administrators:


15 comments

  1. Thanks for all the updates, theres a lot changing!

    I noticed you have " in your code snipets now. Is there a way to replace these on your blog? Just wondering.

    I have been looking over the older version of your post and ran into issues at the OWA stage, but looks like there are a lot of updates so I will update my scripts and give it a shot. Running 2 WFE and 2 app servers to a single DB server.

    I also noticed you dont pre-fill the credential username. you can call Get-Credential with the following,
    get-credential -credential Administrator or get-credential -credential DOMAINAdministrator. That way users dont have to figure out which service account they just put in, as its a little confusing to get 5 authentication prompts that are blank with no prompt.

    I also ran Set-SPDiagnosticConfig -LogLocation “C:Logs” on each WFE and app server to set my logs to a shorter path.

    Great post. Not too many places have this (a lot of it was old beta 2 stuff and confusing).

    Looking forward to getting UPS and Search configured through PS also.

  2. For the OWA wildcard managed path, after you delete sites, can you create OWA wildcard, cache explicit under that, then recreate Sites wilcard before configuring OWA? Not sure what you mean by “1st wildcard manged path it finds”. My OWA failed to configure Word and PowerPoint, but Excel succeeded. I was wondering if my developers could create sites wildcard again and configure OWA again another time.

    • smallcity says:

      Prior to configuring OWA, two managed paths exist: “/” (explicit) and “/sites” (wildcard). I advocate removing “/sites” before configuring OWA. If you do not, a cron job will run when the OWA is configured and it will install an OWA site collection under that path, leaving you with “/sites/Office_Viewing_Service_Cache”. I don’t like that. So I remove “/sites” and create a new managed path (“/owa/cache”). Having only “/” and “owa/cache” seems to force the cron job to create the OWA site collection under that new, isolated, managed path. It looks nicer and is easily ignored.

      By the way, notice it does not install the site collection on the explicit path at the root (“/”). That is what I meant by my comment, “1st wildcard managed path.” Still, it’s only a hypothesis based on observation. My guess (and it is only that) is that the cron job actively looks for the “/sites” path first. Then, if it doesn’t find it, it looks for another “wildcard” managed path. I don’t think it will install the site collection under any “explicit” path. I have not tried leaving only explicit paths and seeing where the cron job puts the site collection. My guess is that it won’t create it or it will create it at the root (“/”), neither of which is desirable.

      Now, as you know, the managed path is one thing and the content database is another. And the more important thing is to isolate the OWA site collection’s content database. The script that does this can be found under “Configure Office Web Apps Cache database,” which was lifted from this blog . But I may decide to replace it with this Technet code or with this similar code.

      As for the services failing… that happened to me once (but not regularly) and I simply manually turned them on.

  3. You can also do write-output “Please enter SP Farm account” etc. There is also write-host, and you can do cool things like write-host -fore green “This text is green”, but the text will only be placed on the screen (not pipable to another command, just something to keep in mind if you try to manipulate the text)

  4. In Usage and Health, $Usage.provision(), should that be $usageApplicationProxy.provision()?

    When this ran, for some reason $usageApplicationProxy was null, but I re-ran it and I was getting back the service app proxy

  5. Start Managed Meta Data Services-

    #Start the Managed Meta Data Web Service
    $mmdservice = Get-SPServiceInstance | Where-Object { $_.TypeName -ilike “Managed Metadata Web Service”}
    start-spserviceInstance $mmdservice.ID

    • smallcity says:

      Thanks, Eric. As there’s one per server, I went with:
      $appserver1 = “servername1”
      $mmserviceID = $(Get-SPServiceInstance | where {$_.TypeName -ilike “Managed Metadata Web Service”} | where {$_.Server -match “SPServer Name=$appserver1”}).ID
      Start-SPServiceInstance $mmserviceID

Comments are closed.