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.
Just a quick note for myself…Licensing Microsoft SharePoint Server 2013. Spells out common licensing scenarios. Also: http://technet.microsoft.com/en-us/library/jj219627.aspx for managing license assignments by user/group.
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.
SharePoint 2010 support for mobile devices have been limited. Simple mobile views of lists and libraries were supported by mobile browsers using a mobile redirection feature. SharePoint 2013 steps up the support for mobile devices with features to support page design, content creation and remote API improvements.