Use PowerShell to create a whole bunch of SharePoint content


This post is one that came out of a conversation with another SharePoint buddy of mine. We were discussing how to evenly place SharePoint Site Collections into multiple content databases, and how it’s sort of a nice, relatively unknown ‘feature’ of SharePoint that it will use a round-robin approach of placing them into all available content databases for a web application. While it’s very common to place individual SharePoint Site Collections into their own content database, and that’s certainly a good approach – it is certainly a good option to pre-create several content databases and allow SharePoint to handle the balancing act, as it were…

Having said that, here is what I did to prove it out for the purposes of this blog post. I already had an empty web application at http://testtest.adventureworks.com with no content databases from some other testing I’ve done recently:

1. Store the Web Application in a variable

$wa = Get-SPWebApplication http://testtest.adventureworks.com

2. Create 10 Content Databases – note the 1..10 that I’m piping to the ForEach-Object cmdlet. This is a great shorthand way to quickly create a number of ‘things’ in PowerShell.

1..10 | ForEach-Object {
$name = “SPContent_”+$_
New-SPContentDatabase –Name $name –WebApplication $wa
}

3. Create 100 Site Collections – note again the use of 1..100. Also, these will all be team sites under the /sites managed path.

1..100 | ForEach-Object {
$url = “http://testtest.adventureworks.com/sites/”+$_
New-SPSite –Url $url –Template "STS#0" –Name $_ -OwnerAlias domain\user
}

And once all of that is done, you should be able to see a nicely balanced web application with 100 site collections evenly distributed across 10 content databases:
ContentDBs

Happy SharePointing (and PowerShelling)!

Advertisements

SharePoint Saturday Columbus 2013


Today I spoke in front of a hometown crowd at SPS Columbus, which was a great event filled with an absolutely incredible lineup of speakers!

The presentation was about InfoPath – which was interesting considering how little it’s changed in 2013. The high-level gist of the presentation is to talk about how InfoPath can streamline forms development and data entry in SharePoint 2013, although all of it is relevant with SharePoint 2010 as well. I have used this presentation before, although I adapted it quite a bit to add relevance both to SharePoint 2013 on-prem and Office 365.

Below is a description of the topic itself along with PowerPoint Slides:

Funnel your Info down a new Path

​InfoPath provides business users with a familiar, feature rich means of creating dynamic, powerful electronic forms. While it has been around since the 2003 release of Microsoft Office, InfoPath 2013 combined with SharePoint 2013, is a match made in heaven. InfoPath is heavily integrated into SharePoint 2013, and users can now create engaging forms within minutes and without writing a single line of code.

This presentation will show you how you can start leveraging InfoPath to funnel your business information down a new path. Demos, gotchas, tips & tricks will all be a part of this 10,000 foot view of Microsoft InfoPath as it relates to SharePoint 2013.

Here are my slides:

And finally, if you want more information on the workflow I used to create the SPWebs upon gaining approval – here is my separate blog post on that topic.

Run all SharePoint Health Analyzer Jobs with PowerShell


Today I had a need to run all health analyzer jobs to make sure everything was good after a clean install of SharePoint 2010. Of course I knew there had to be a quick PowerShell approach to this. I did a quick search and found a few different variations of the same basic code, so I took what I liked and made it into a simple function that I will store in the profile on my SP machines going forward.

The blog that had exactly what I wanted, both in the body and the comments was Matthew McDermott’s blog – here. Matthew has a more structured approach using a foreach loop to iterate through each job in the collection, and then he calls the RunNow() method to start the jobs. Gary LaPointe commented and provided a one-liner, which I’m going to use – although I am putting that one-liner into a function…

By making a simple function, I can just run the function like a cmdlet – so it makes it very easy to run going forward.

Here is the function:

function Start-SPHealthTimerJobs {Get-SPTimerJob | Where-Object {$_.Title -like “*Health Analysis Job*”} | Start-SPTimerJob}

And to run it, I simply type:

Start-SPHealthTimerJobs

Customizing the SharePoint 2013 Suite Bar Branding using PowerShell


I recently stumbled across a great blog post by Wictor Wilen on how to customize the Suite Bar Branding Element HTML on the Central Administration Web Application in SharePoint 2013. If you’re not familiar with this, we’re basically talking about the area at the top left of the SharePoint 2013 user interface:

SuiteBarOOTB

By default, it will just say “SharePoint”. While that’s fine for out of the box folks, this can be a great spot for a little customization. It’s also possible to do this on content web applications, not just Central Administration – and I think this could be a good place to provide a description of the web application. It could also serve as a good place for a hyperlink to always allow the user to get back to the root site – sort of like the Portal Site Connection functionality…

While Wictor’s code was great as a starter point, I thought it would be cool to tweak this a little bit by making it a reusable function and also by allowing the HTML to include a hyperlink to the root site collection in the web application. I simply took his code and modified it to make it a little more reusable, and to also allow for the hyperlink functionality. I also included a custom CSS class name on the A tag to allow for easy branding in your custom solutions.

As for how it works, I’ve provided 3 parameters – 2 of which are required. The required parameters are WebAppUrl and Text; meaning you must provide the link to the web application you want to modify and you must provide the text value you want to replace the out of the box value with. Optionally, you can include a third switch parameter for SetTextAsHyperlink. By including this, you’re sipmly telling the PowerShell function to also make the text a hyperlink to the URL of the web application you are modifying.

Here is the PowerShell function:

function Set-SPSuiteBarBrandingElement {
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true)][System.String]$WebAppUrl,
[Parameter(Mandatory=$true)][System.String]$Text,
[Parameter(Mandatory=$false)][Switch]$SetTextAsHyperlink
)
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$webApp = Get-SPWebApplication $WebAppUrl
if($SetTextAsHyperLink)
{
    $html = "<div class='ms-core-brandingText'><a class='customSuiteLink' href='$WebAppUrl'>"+$Text+"</a></div>"
}
else
{
    $html = "<div class='ms-core-brandingText'>"+$Text+"</div>"
}
$webApp.SuiteBarBrandingElementHtml = $html
$webApp.Update()
}

To run it, first dot-source the function and then run it like so – example provided below is for my local VM:

Set-SPSuiteBarBrandingElement -WebAppUrl http://sp2013.intranet.adventureworks.com -Text 'AdventureWorks Intranet'

This should give you something like this:
SuiteBar1

Optionally, to make the text a hyperlink – run it like so. Notice that when hovering over it’s now a link – pretty cool!

Set-SPSuiteBarBrandingElement -WebAppUrl http://sp2013.intranet.adventureworks.com -Text 'AdventureWorks Intranet' -SetTextAsHyperlink

SuiteBar2

One last thing I wanted to mention is that in the function above, I’m setting the class of the Anchor tag to “customSuiteLink”. This means if you’re using custom branding, you can reference this CSS class to apply different branding to the link.

Thanks again to Wictor for sharing this!

RD