DogFoodCon 2014 to feature dedicated PowerShell track!


For several years now, the IT conference slate in Central Ohio has been dominated by the ever popular Dog Food Conference. That trend will continue this year, when Columbus once again hosts the 2-day Microsoft Dog Food Conference on September 29th and 30th. Multiple technologies will be featured, including Windows PowerShell.

I will be presenting on Managing SharePoint Anywhere using PowerShell, alongside these nationally recognized PowerShell Experts:

The event will certainly be phenomenal once again, and I hope to see you there!

cloud

 

Advertisement

Using PowerShell to manage SharePoint Online


Anybody who knows me or has ever read a single post of mine knows I’m a big PowerShell geek. I like it, I love it and I always want some more of it. Bad song lyrics aside, I quite literally use PowerShell every day for one task or another. Over the past 6 months or so I’ve been quietly working on creating some Cmdlets/Functions that will allow me to run PowerShell against Office 365 SharePoint Online. This might sound easy – but spoiler alert – it’s not. That’s not to say it’s difficult, if you’re a developer who is comfortable with CSOM, you’ll be just fine. However, I didn’t have those skills when I took off on this adventure; so needless to say it’s been a bit of a learning experience, combined with a lot of trial & error.

There are really a few key steps which must be taken prior to getting SharePoint Online and PowerShell to talk to one another.

  1. Set up the SharePoint Online Management Shell Windows PowerShell environment
  2. Run Connect-SPOService to connect to a SharePoint Online Administration Center

Once you’ve completed those two simple tasks, you’ve got the baseline environmental requirements in place to start using PowerShell with SharePoint Online. However, if I was writing a blogpost to tell you how to run the 30 built-in cmdlets you get by loading the Microsoft.Online.SharePoint.PowerShell module; well, you’d be left wanting more.

To really start doing the fun developer stuff, you will want to make sure you load the Microsoft.SharePoint.Client and Microsoft.SharePoint.Client.Runtime assemblies into your session. I’ve written a nice little function for this, which looks like:

function Add-SPOAssemblies {
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime") | Out-Null
}

Then, to run it – just use:

Add-SPOAssemblies

Pretty simple, and it just loads those two assemblies so you can access all the goodies that come with them.

Once you’ve gotten there, you can start to do things like create ClientContext against an SPWeb:

$webUrl = "SPOWebUrl"
$ctx = New-Object Microsoft.SharePoint.Client.ClientContext($webUrl)
$creds = Get-Credential -Message "Please enter your Office 365 Administrative credentials"
$ctx.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($creds.UserName,$creds.Password)
$spoweb = $ctx.Web
$ctx.Load($spoweb)
$ctx.ExecuteQuery()

So that’s cool, but it hasn’t done anything yet! Well try this:

$spoweb.Title

Ohhhh… So now that’s cool! Once you’ve gotten this far, i’m sure you can start to see the possibilities.

In case you want to wrap that up into a nice function, here’s a simple example that I think works well:

function New-SPOServiceContext {
[CmdletBinding()]
Param(
[System.String]$EmailAddress,
[System.String]$SPOWebUrl
)
try {
$assemblies=Add-SPOAssemblies
}
catch {
Write-Error "Unable to load Microsoft.SharePoint.Client assemblies"
}
if($assemblies){
$ctx = New-Object Microsoft.SharePoint.Client.ClientContext($SPOWebUrl)
$creds = Get-Credential -Message "Please enter your Office 365 Administrative credentials" -UserName $EmailAddress
$ctx.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($creds.UserName,$creds.Password)
$spoweb = $ctx.Web
$ctx.Load($spoweb)
$ctx.ExecuteQuery()
}
}

And of course to run it, use:

New-SPOServiceContext -EmailAddress your.email@your-company.com -SPOWebUrl https://something.sharepoint.com

“But wait, at the beginning you said this was challenging – this was way too easy!?”

Well, I wasn’t used to having to create a context object, then a credential object, followed by a web variable, and then I have to load and execute a query?! All new to me, but again – I haven’t done very much (read: any) development on the client side.

I could share loads of other cool things I’ve done, but you’ll have to wait while I clean up and finish some of the functions I’ve been working on. Until then, happy PowerShelling!

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

Fix SharePoint Quick Launch Links using PowerShell


A lot of times when I’m working on an environment for a client, I come across a situation where I’m in need of a way to quickly update links – usually because people have entered them as an absolute URL (e.g. http://intranet/pages/somepage.aspx) instead of a relative URL (e.g. /pages/somepage.aspx).

Usually when I run across a problem like this, I actually get excited – because these are great opportunities to use our buddy PowerShell! Unfortunately, there aren’t many examples out there of how to use PowerShell to manipulate SharePoint Navigation objects. Hopefully this blog post will be helpful for someone looking to do the same thing I needed to do…

Here’s how it all comes together – and if you don’t want to understand how it works just skip to the end and copy/paste the code :).

Getting the Web Object

The first thing we have to do in order to even begin to work on SharePoint Navigation is to retrieve an SPWeb object. To do this, it’s pretty simple – just run the following code, which will store the Microsoft.SharePoint.SPWeb into the $SPWeb variable:

$SPWeb = Get-SPWeb $Web

Getting the Web.Navigation.QuickLaunch Object

After we’ve retrieved that object, if you use Get-Member to view the Methods and Properties, you’ll quickly notice that the Navigation Property has a QuickLaunch property within it. This is exactly what we want. We can now start to use the ForEach-Object cmdlet to actually show us everything beneath the SPWeb.Navigation.QuickLaunch. Or more specifically, we can use an IF statement to make sure we only grab the appropriate URLs – that is, only ones matching the string we want to replace. Here’s the code snippet:

$SPWeb.Navigation.QuickLaunch | ForEach-Object {
    if($_.Url -match $FindString){
        $linkUrl = $_.Url
        Write-Host "Updating $linkUrl with new URL"
        $_.Url = $_.Url.Replace($FindString,$ReplaceString)
        $_.Update()
    }

Pretty cool, so essentially we just say if the URL matches the string we’re looking for, then go ahead and tell us it’s working on it – then update it, replacing the value of the FindString variable with the value of the ReplaceString variable. Both of these variables are actually mandatory parameters, you’ll see that part at the end… Finally, run the Update() method on each one to actually commit the changes to the server.

All done right? No, we can’t forget about the children!

Fixing the Child links

So far the code we’ve seen will only touch the parent links, but each link also has a Children node. We can simply use the same code as before, except this time we’ll run it against the $_.Children property of each link node.

Here’s how that looks:

$_.Children | ForEach-Object {
        if($_.Url -match $FindString){
            $linkUrl = $_.Url
            Write-Host "Updating $linkUrl with new URL"
            $_.Url = $_.Url.Replace($FindString,$ReplaceString)
            $_.Update()
        }
    }

And now, if we put it all together, you’ll see that we have a nice, clean function to do a quick find and replace of navigation links on the quick launch of a single SharePoint Web. I’ve called the function Repair-SPLeftNavigation, and it has 3 required parameters – Web, FindString and ReplaceString:

function Repair-SPLeftNavigation {
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true)][System.String]$Web,
[Parameter(Mandatory=$true)][System.String]$FindString,
[Parameter(Mandatory=$true)][System.String]$ReplaceString
)
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$SPWeb = Get-SPWeb $Web
$SPWeb.Navigation.QuickLaunch | ForEach-Object {
    if($_.Url -match $FindString){
        $linkUrl = $_.Url
        Write-Host "Updating $linkUrl with new URL"
        $_.Url = $_.Url.Replace($FindString,$ReplaceString)
        $_.Update()
    }
    $_.Children | ForEach-Object {
        if($_.Url -match $FindString){
            $linkUrl = $_.Url
            Write-Host "Updating $linkUrl with new URL"
            $_.Url = $_.Url.Replace($FindString,$ReplaceString)
            $_.Update()
        }
    }
}
$SPWeb.Dispose()
}#endFunction

To run this bad boy, simply dot-source the function and then call it like a cmdlet – for example:

. .\Repair-SPLeftNavigation.ps1
Repair-SPLeftNavigation -Web http://sp2013 -FindString 'http://sp2010' -ReplaceString 'http://sp2013'

If you needed to run this on multiple site collections or even web applications, you could simply use the native ForEach-Object cmdlet in conjunction with this function to accomplish that goal.

Cheers!
RD