Determine SharePoint 2013 My Site Usage with PowerShell


As a SharePoint consultant, I frequently encounter situations where a client / customer has My Sites deployed. However, nearly as frequently I’ll come across situations where they’re really not sure how many they have, who is actually using them, or if anybody is using them. While there are certainly GUI approaches to determining usage, PowerShell is a great, quick way to analyze an environment. Using the SharePoint Server Object Model, we can easily obtain this information.

Without further ado, here is a quick and dirty PowerShell function which can be used to determine My Site usage. Note: this will only tell you about My Sites with documents, feel free to tweak it for your usage:

function Get-SPMySitesWithData {
[CmdletBinding()]
Param(
[Parameter(Mandatory)][System.String]$MySiteHostUrl
)
Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction stop;
[Object[]] $MySites = New-Object PSObject
$webapp = Get-SPWebApplication $MySiteHostUrl
$webapp.Sites | ForEach-Object {
$spweb = $_.RootWeb
$docsLib = $spweb.Lists["Documents"]
$siteSize = $spweb.Site.Usage.Storage/1MB
$siteSizeInMb = "{0:N2}" -f $siteSize
if($docsLib.Items.Count -gt 0)
{
[Object] $mysite = New-Object Management.Automation.PSObject;
$mysite | Add-Member -MemberType NoteProperty -Name SiteUrl -Value $spweb.Url
$mysite | Add-Member -MemberType NoteProperty -Name ItemCount -Value $docsLib.Items.Count.ToString()
$mysite | Add-Member -MemberType NoteProperty -Name "SiteSize(MB)" -Value $siteSizeInMb
$MySites += $mysite;
}
else
{
#Skipping my sites with 0 items, but if you wanted to do something with them here's where you'd do it!
}
$spweb.Dispose()
}
Write-Output $MySites
}

To run it, simply treat it like a normal SharePoint PowerShell Cmdlet:

Get-SPMySitesWithData -MySiteHostUrl http://my.contoso.com

And here’s what the object looks like once the function is complete:
GetSPMySitesWithData

Advertisements

Dog Food Conference 2014


Today I had the privilege of presenting on Managing SharePoint Anywhere with Windows PowerShell at Dog Food Conference, 2014!

My presentation was focused on leveraging the Microsoft.SharePoint.Client assembly to write Client Side Object Model (CSOM) code against SharePoint Online. However, the twist is that it’s all done in PowerShell 3.0 – and there is a set of PowerShell functions written specifically to handle automation in SharePoint Online.

While I have shared this topic a time or two at other events, this was the most refined version of the presentation.

Continue reading…

Return SPListItems using CSOM and PowerShell without writing CAML


I recently tweeted about my triumph when trying to accomplish returning all SharePoint List Items without the use of CAML or LINQ. The reason I wanted to do this might be strange, but I’ll try to explain my process and methodology and why I got to a point of wanting to make SharePoint do things it didn’t want to do. 🙂

As a very advanced SharePoint Scripter, I do a TON of PowerShell. If you’ve read this blog, follow me on Twitter or talk to me in person you probably knew that. Having said that, there are times when I want to iterate through all list items – either looking for a match or just to return all values. It’s not super common but it happens. Well it’s a very easy thing to do with server side code (read: PowerShell and the Microsoft.SharePoint.PowerShell snap-in).

Getting List Items using standard PowerShell

$web = Get-SPWeb http://someSiteUrl
$list = $web.Lists["SomeList"]
$list.Items #do something with them here

As you see on line 3, there is an Items collection property on the List object. This is great, end of story – IF you’re using server-side PowerShell code. However, I’ve been focusing a lot lately on integrating PowerShell into the CSOM space – specifically to manage SharePoint Online with PowerShell. If you’ve written any CSOM code, you know that things are done a little differently. Here’s an example of how to return a list item using PowerShell on the client-side – note that I’ve omitted about 12 lines of code that must take place before this to load the Microsoft.SharePoint.Client* assemblies, create ClientContext, get the SPWeb, etc.:

Getting a List Item using PowerShell Client-Side Code

$list = $GLOBAL:Web.Lists.GetByTitle("BigListLotsOfItems")
$item = $list.GetItemById(5)
$GLOBAL:Context.Load($item)
$GLOBAL:Context.ExecuteQuery()
$item["Title"]

That’s great, but if I wanted to return all items – the Client Object Model won’t give me List.Items. In reading MSDN, there are C# examples of how to write CAML queries to return all list items – but the whole point is that I don’t want to write CAML. Here’s the C# example – which I could have certainly translated to PowerShell if I wanted to do so:

Using C# to get all List Items

// Starting with ClientContext, the constructor requires a URL to the
// server running SharePoint.
ClientContext context = new ClientContext("http://SiteUrl");

// Assume the web has a list named "Announcements".
List announcementsList = context.Web.Lists.GetByTitle("Announcements");

// This creates a CamlQuery that has a RowLimit of 100, and also specifies Scope="RecursiveAll"
// so that it grabs all list items, regardless of the folder they are in.
CamlQuery query = CamlQuery.CreateAllItemsQuery(100);
ListItemCollection items = announcementsList.GetItems(query);

// Retrieve all items in the ListItemCollection from List.GetItems(Query).
context.Load(items);
context.ExecuteQuery();
foreach (ListItem listItem in items)
{
    // We have all the list item data. For example, Title.
    label1.Text = label1.Text + ", " + listItem["Title"];
}

So that’s great, but here’s how I went about getting all list items without writing CAML! I’ll break it down section by section, but if you’re impatient the whole solution is at the bottom. 🙂

Creating our Context

The first thing we need to do when working with SharePoint from the Client Side is create ClientContext. To do so using PowerShell, here is some example code:

$GLOBAL:Context = New-Object Microsoft.SharePoint.Client.ClientContext("http://someWebUrl")
$GLOBAL:Credentials = Get-Credential -UserName $EmailAddress -Message "Please enter your Office 365 Password"
$Context.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($Credentials.UserName,$Credentials.Password)
$GLOBAL:Web = $GLOBAL:Context.Web
$GLOBAL:Context.Load($GLOBAL:Web)
$GLOBAL:Context.ExecuteQuery()

Getting our SPWeb

Once we’ve created our ClientContext variable, we’ve already got the SPWeb. But just for transparency, here’s how you would/could access methods and properties of the SPWeb object:

$GLOBAL:Web.Title #returns Web.Title
$GLOBAL:Web.Description #returns Web.Description

Getting our SPList

Now, to get the List object – we’ll do the following:

$SPList = $GLOBAL:Web.Lists.GetByTitle("BigListLotsOfItems") #Note that BigListLotsOfItems is my List Title

Using the For loop to iterate through all items

And this is where the magic happens as they say. For anyone who has done any level of development or scripting, you know that the best way to loop while also allowing for modification of the array with which you’re looping is to use a For loop.

For ($i=0; $i -le $SPList.ItemCount; $i++)
{
}

This is a pretty standard implementation of the For loop, what I want to call out though is the use of Try/Catch/Finally. As a dabbling developer, I’m not sure if this is the intended use of Try/Catch/Finally – so if this is bad practice forgive me. 🙂

Essentially I start out by creating the ListItem variable, and then calling the Load method of the ClientContext variable. I do that before entering the Try/Catch/Finally. I then use Try {} to run the Context.ExecuteQuery method, and if that fails the loop will go into the Catch {} block – where I will increment the array by 1 ($i++) and then run the GetItemById(), Load() and ExecuteQuery() methods against the next $i in the loop.

$ListItem = $SPList.GetItemById($i)
$GLOBAL:Context.Load($ListItem)
    Try
    {
        $GLOBAL:Context.ExecuteQuery()
    }
    Catch
    {
        $i++
        $ListItem = $SPList.GetItemById($i)
        $GLOBAL:Context.Load($ListItem)
        $GLOBAL:Context.ExecuteQuery()
    }

Why did I do this? Well it’s really pretty simple. Since I have to use the GetItemById() method, I have to know the ListItemID of each ListItem. If someone has deleted an item, the ItemCount property won’t match the highest ID in the list – right? So if there are 5 items but someone deleted a few at one point or another – the highest ID might be 7 or 8, without incrementing by 1 on a failure, we’ll never get to 7 or 8…

And so now that we’ve discussed all of that, here’s the final example script.

The Final Solution

$GLOBAL:Context = New-Object Microsoft.SharePoint.Client.ClientContext("http://someWebUrl")
$GLOBAL:Credentials = Get-Credential -UserName $EmailAddress -Message "Please enter your Office 365 Password"
$Context.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($Credentials.UserName,$Credentials.Password)
$GLOBAL:Web = $GLOBAL:Context.Web
$GLOBAL:Context.Load($GLOBAL:Web)
$GLOBAL:Context.ExecuteQuery()
$SPList = $GLOBAL:Web.Lists.GetByTitle("BigListLotsOfItems")
For ($i=0; $i -le $SPList.ItemCount; $i++)
{
    $ListItem = $SPList.GetItemById($i)
    $GLOBAL:Context.Load($ListItem)
    Try
    {
        $GLOBAL:Context.ExecuteQuery()
    }
    Catch
    {
        $i++
        $ListItem = $SPList.GetItemById($i)
        $GLOBAL:Context.Load($ListItem)
        $GLOBAL:Context.ExecuteQuery()
    }
    Finally
    {
        #Return item here and do something with it.
    }
}

And that – my friends – is how you can get all List Items from a SharePoint list using PowerShell and CSOM. Hopefully this is helpful for someone else.

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!

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)!