Gary provides some general grouping categories and suggested uses for some of the SPO cmdlets.
So today I was doing some SharePoint 2013 app development against my Office 365 SharePoint 2013 tenant and I needed to view the HTTP traffic from the site in order to troubleshoot some issues I was having and I stumbled across something I found very interesting when I looked at the header details in Fiddler:
Today I was working on a deployment for a client which entailed activating a custom SharePoint Feature on about 1000 Site Collections. This Feature did a fair number of things and on average it takes about 10-15 minutes to complete in their test environment (which is pretty slow compared to their production environment which I’ve not yet deployed to but I expect close to a 5 minute run time per Site Collection once I go to production with it). You can obviously do the math and quickly see that it will take me somewhere around 10 days for this to complete if I did one Site Collection at a time. This is just unacceptable as I personally don’t want to be monitoring a Feature activation script for that long. What’s worse is that when I look at CPU and memory utilization on the servers I can see that they have plenty of resources so it’s not like the operation is actually taxing the system, they’re just slow operations. So the solution, for me, is pretty obvious: I need to activate these Features in parallel.
There was recently a twitter conversation between @cacallahan, @toddklindt, and @brianlala discussing provisioning Search on SharePoint Foundation and whether it was possible or not and somewhere during the conversation it was suggested that I might know how to do this (sorry guys for not responding immediately) – unfortunately I hadn’t actually done any work with SharePoint 2013 Foundation yet and so had not yet tried and thus didn’t know the answer (I knew there were issues and suspected a workaround was possible but I didn’t have a server built to test anything). Well, last night and today I managed to have some free time so I figured I’d take a look at the problem to see if my guess about a workaround was correct.
When SharePoint 2010 was released we had hundreds of cmdlets available for our on-premises deployments but when it came to Office365 we only had cmdlets available for manipulating our subscription details, users in AD, and Exchange Online (http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125002.aspx). With the release of SharePoint 2013 as part of the Office365 offering we now have the ability to use PowerShell to manipulate our SharePoint Site Collections in the cloud. The capabilities are somewhat limited in that our abilities are limited to manipulating Site Collections, but it’s a start. In this article I’ll walk through the available cmdlets and detail some examples of how to use them.
In a recent post I detailed all the PowerShell changes from SharePoint 2010 to SharePoint 2013 Public Preview (part 1, part 2) – well, apparently I should have held off a couple of weeks because I’m now running the RTM version of SharePoint 2013 and have found that they have made a ton more changes. I don’t want to go through all the 2010 to 2013 changes again so instead I’ll just detail what has changed since the Public Preview; these changes include new cmdlets, removed cmdlets, and renamed cmdlets. (Note that some of the removed and new cmdlets may actually just be renamed cmdlets – not worth the effort for to verify them all at this point).
Now that SharePoint 2013 has been released to manufacturing and will be available for download soon I figured I’d go ahead and put together a quick article pointing out some of my favorite PowerShell V3 enhancements that you can use to improve your command-line usage of PowerShell as well as your automation scripts.