Tag Archives: Site Columns

Scripting Sites and Content Type Decisions (features vs. scripting vs. Manual)

15 Nov


Sites are easy to script, and having a small script to create these means when we upgrade to the full release of SharePoint I can just run the script again.

The sites that we will start out using are:

Root Web
It Support Site
Social/Fun Zone Site
— 2012
—— Course One
—— Course Two
— 2013
—— Course One
—— Course Two

This will change as we properly script the courses once we have a full list as well as have the template implemented. For now a few empty course sites will do for development.

  1. Run up SharePoint 2013 Management Shell
    You may get the below error, but this can be ignored as its a preview issue: This article here mentions this
    could not create a CmdletConfiguration for CmdletName Start-BulkOperation, Cmlde
    tClass , CmdletHelpFile C:\Program Files\Common Files\Microsoft Shared\Web Serv
    er Extensions\15\CONFIG\PowerShell\Help\Microsoft.Office.Education.Institution.d
    Cannot process argument because the value of argument “implementingType” is null
    . Change the value of argument “implementingType” to a non-null value.
  2. I have saved the following PowerShell into a file called CreateSites.ps1. I use NotePad++ for editing PowerShell. At this stage all sites will use the team site template.
    $webApp = “http://gisitportal&#8221; #<— Change thisNew-SPWeb -url ($webApp + “/support”) -Name “IT Support” -Template “STS#0”
    New-SPWeb -url ($webApp + “/fun”) -Name “Fun Zone” -Template “STS#0”
    New-SPWeb -url ($webApp + “/social”) -Name “Social Zone” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses”) -Name “Courses” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses/2012”) -Name “Courses – 2012” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses/2012/courseone”) -Name “Course One” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses/2012/coursetwo”) -Name “Course Two” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses/2013”) -Name “Courses – 2013” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses/2013/courseone”) -Name “Course One” -Template “STS#0”
    New-SPWeb -url ($webApp + “/courses/2013/coursetwo”) -Name “Course Two” -Template “STS#0”
  3. Go to All Site Contents (slightly different to normal….) Click on the cogg icon then View Site Contents, this is on the RIGHT TOP OF THE PAGE by the way.
    View Site Contents SP2013
  4. Now you will see your sites (scroll to the bottom past the “apps”). Done!
    Sub Sites SP2013

Content Types and Fields

I’ve always had issues deciding when to use features or scripted content types, or manual… They seem to fit into different situations, heres where I place them



— The content type won’t change over time
— The content type name and id must stay the same everywhere (for custom functionality relying on this)
— No one wants to run a script or create content types manually
— The user doesnt need to delete the content type

Feature Drawbacks

— Users cant delete content types
— Next time the feature is updated it either wont change anything (particularly fields at a list level), or it will override everything the user has changed
— Users may need to change content types, this means that a developer may have to keep the solution/feature content types up to date. When this is implemented into the clients environment, it can be risky in terms of whether new fields etc will be added properly, particularly at list level. Extra code can be written for a proper upgrade of the feature, but this is a bit of overhead if it isn’t normal practice.


— Easy one click deployment for the client depending where they want certain content types.
— Good for deploying content types that are hugely tied to functionality where the id’s and names, and even fields shouldn’t be changed. This also means the content type and fields are created on activation with the other relevant functionality.



— There aren’t a large amount of content types
— Content types will change heavily over time, so the user needs full control over them after implementation
— The content type may need to be deleted

Scripted Drawbacks

— Unless the client is using a content type hub, the script will need to be run against each site collection, and any new site collections in future. If the content types do change and there isnt a content type hub an admin or dev may have to keep this script up to date.


— Usually deploy once, and from there on a client can fully manage their own content types with no feature restrictions
— Can be re-used accross environments and site collections during initial deployment

Manually Create


— There aren’t many content types or fields on those content types
— There aren’t many site collections (if not using a content type hub)
— The id’s of the fields and content types don’t need to be the same, new content types and fields get a new GUID, so they would be different per site collection (if not using a content type hub)
— You don’t mind re-creating per environment (test, uat and prod)

Creating Drawbacks

— Obviously creating the same thing over and over can be time consuming
— Have to name everything the same and not make mistakes


— If there aren’t very many content types, only 1 or 2 environments and not many site collections… this would be less time consuming

Mention of the Content Type Hub…

A Content Type Hub, or Metadata Hub allows users to create content types and fields in one place. They can then publish these fields and content types out to all of the other webs/site collections so there is no need to deal with them at every level. This can be great for documents that are scared across an intranet where there may be multiple team site collections and they all share common document content types for example.

What to do???

For a start, we know what we want for content types and there aren’t many, we don’t need a content type hub, we only have one environment with no plans for more. The easiest thing we can do for this implementation is manually create the content types and fields. One thing to keep in mind, if we did want more environments, it would be best to grab the details of the existing content types and fields and re-create those using a feature or script in other environments. The same would apply for any new site collections.