What’s New in PowerShell for SharePoint 2013
As the saying goes, with great power comes great responsibilities, and with every great version of SharePoint comes a great set of PowerShell features. Okay, that’s a very cheesy joke, but on a serious note the PowerShell story with SharePoint 2013 just got better; a lot better! I remember when I first heard of using PowerShell to manage a SharePoint environment. That was back in 2009 while sitting in a session at the SharePoint Conference at which Microsoft first announced SharePoint 2010. Back in those days, people were using a command line tool called stsadm to manage their environments, and dinosaurs still walked the earth. The presenter had shown a demo in which an automated script using stsadm was creating 100,000 site collections. He had then compared the results with running the same type of logic, but this time using PowerShell. The results were just unbelievable: PowerShell was on average four times faster than the traditional command line way of doing things. With every major release since then, Microsoft just kept adding more and more new PowerShell methods to make our life as easy as possible.
Version 3.0 of PowerShell was released by Microsoft early fall 2012, and SharePoint 2013 has been made so that it can leverage its full power. Assuming that you have PowerShell version 3.0 installed on a SharePoint 2010 farm, you are still able to switch back to version 2.0 of the tool. SharePoint 2010 doesn’t work with PowerShell version 3.0, which is why you may need to switch back to version 2.0. With SharePoint 2013, tons of new methods have been introduced. You will discover these new methods and features throughout this book. The focus of the present chapter is to highlight some of the new features that have been made available with the venue of PowerShell version 3.0 for managing SharePoint 2013. You will get an overview of some of the major new improvements to the tool in this chapter. Further details will be given in later chapters of this book.
SharePoint 2013 Apps
With SharePoint 2013, Microsoft introduced a new type of building block for custom business solutions, called SharePoint apps. These apps represent pieces of functionality that can run alongside or outside the SharePoint environment. Because these are brand new with SharePoint 2013, Microsoft introduced a full set of new PowerShell methods to help to install, deploy, manage, upgrade, and uninstall these apps in the SharePoint environment. For more details on how PowerShell can help you manage SharePoint 2013 apps in your environment, please refer to Chapter 7. Figure 2-1 shows the newly added Apps section in the SharePoint 2013 central administration web interface.
Figure 2-1. The Apps feature set in Central Administration
Back in the 2010 version of SharePoint, Microsoft introduced a new concept called service applications. These include the Search Service application, the Visio Graphics Service, the secure store, and the Business Connectivity Services, to name a few. In SharePoint 2007, these were called Shared Services Providers (SSPs) and were limited in terms of scalability and flexibility. The concept behind service applications was that they could be exposed and reused by other SharePoint farms.
In SharePoint 2013, there are several new service applications that have been introduced (Work Management, App Management, etc.). Because these are entirely new pieces of the SharePoint ecosystem, Microsoft introduced a large set of new PowerShell methods to allow to the creation, configuration, and management of these new service applications. For more details on how to use PowerShell to manage SharePoint 2013 service applications, please refer to Chapters 7 and 8. Figure 2-2 shows how to use PowerShell to list all of the available service applications in a SharePoint environment.
Figure 2-2. Listing existing service applications in a SharePoint 2013 farm using PowerShell
In previous versions of SharePoint, managing end-users’ licenses has always been a real nightmare. With SharePoint 2013, it is now feasible for administrators to map users and security groups to specific licenses. It is now possible, for example, to assign basic SharePoint Server 2013 licenses to a certain set of users while assigning enterprise licenses to others. The type of license that is assigned to a user will decide what features the user is authorized to use and consume. Let’s take, for example, the Excel Services feature, which is an enterprise feature. Assume that I’m assigned an enterprise license and that I build a page that has various images and blocks of text but that uses an Excel Services web part to expose data. A user who’s only assigned a basic license comes to my page will be able to view the images and text; however, where the Excel Services web parts shows for me, the user will see an error message saying that a valid license to use this feature could not be found (see Figure 2-3). The set of new PowerShell features offered by SharePoint 2013 includes a dozen of user-license enforcement specific methods to help you manage the various types of licenses that you may have in your organization. To learn more about user-license enforcement, refer to Chapter 8 of this book.
Figure 2-3. Error message when trying to use a SharePoint 2013 component for which you are not granted a valid license
Although this is not a SharePoint 2013 specific feature, it is nice to know that PowerShell Web Access (PWA) is something that could easily be implemented to ease your job as a SharePoint administrator. With version 3.0 of PowerShell, Microsoft introduced this new feature. As the name would indicate, it is a mechanism by which administrators can set up a web portal on the SharePoint server to allow remote authenticated users to run PowerShell commands at a distance. This can prove very useful in certain scenarios in which administrators having to execute an emergency script only have access to the web interface of the SharePoint environment. Maybe they don’t have VPN support to instantiate a remote session on the server to allow them to run PowerShell on it directly. PowerShell Web Access would prove to be extremely useful in such scenarios. To learn more on how to properly install and deploy PowerShell Web Access within your environment, you can refer to Chapter 3 of this book. Figure 2-4 shows the main screen of a PowerShell Web Access session viewed through a web browser.
Figure 2-4. PowerShell Web Access main session window
Backups
The concept of backing up data and artifacts in SharePoint got a major overhaul in the 2010 version of the product. Microsoft continues to build on this very important aspect of SharePoint administration in their latest release of the product. They introduced the capability to back up the index generated by the newly redesigned Enterprise Search module. This can prove to be a valuable asset when dealing with multiple large indexes for your SharePoint Search environment. On top of this, Microsoft continues to offer to possibility to backup entire farms, site collections, and configuration databases using PowerShell (see Figure 2-5). To learn more about automating backups in SharePoint 2013 using PowerShell, refer to Chapter 8 of this book.
Figure 2-5. SharePoint 2013 Backup Options screen from Central Administration
A great new addition to the SharePoint 2013 family is the integration of Bing Maps as part of the geolocation field types. It is now possible in SharePoint 2013 to use a new type of field called Geolocation, which lets you specify coordinates for a specific location as input (see Figure 2-6). You can then use Bing Maps to visualize this location on the item view form. All of these features are available out-of-the-box, but you must use PowerShell to activate it. For more details on using the Geolocation field in SharePoint 2013, you can refer to Microsoft’s TechNet entry at http://msdn.microsoft.com/en-us/library/jj163135(v=office.15).aspx .
Figure 2-6. Entering a new item that uses the new Geolocation field in SharePoint 2013
Note For more information on how to integrate the Geolocation field with your SharePoint 2013 environment, you can refer to Microsoft’s article at http://msdn.microsoft.com/en-us/library/jj163135.aspx. Note, however, that in order for you to be able to visualize its data using Bing Maps, you’ll need to configure it with your own personal key. Instructions to do so are provided in the series of articles mentioned earlier in this chapter.
Search
I have already covered to a certain level the Search aspect of SharePoint. However, I strongly believe it is important to put emphasis on the fact that Microsoft really outdid themselves with SharePoint 2013 to try to expose to PowerShell as many features as possible from their new Search infrastructure. Just by looking at the list of new PowerShell commands for SharePoint 2013 that Microsoft released back in July 2012, that’s 51 new methods just for the search component. As you can see in Figure 2-7, this brings the total number of available PowerShell methods to manage search to close to 150 (depending on the platform version you are running). New methods are still being added every now and then as new cumulative updates to the product are released. Even though I won’t be covering these 51 methods in depth throughout this book, you can refer to Chapter 8 to learn more about how to deploy and configure the SharePoint 2013 Search modules using PowerShell.
Figure 2-7. Counting all available SharePoint 2013 search methods using PowerShell
Tenants
When Microsoft built SharePoint 2013, they had one thing in mind: to build a product that would work well for on-premises deployments, and that would work equally well on cloud scenarios. Back in 2009, when the software giant announced their upcoming release of what they then called SharePoint Online, which eventually became known as Office 365, SharePoint 2013 was already well into its development phase. They knew that in order to make their online vision become a reality, some major changes in the way they allowed administrators to manage tenants environment had to be done. When I talk about multitenancy, you can think of it as hosting services. This is a concept that was officially introduced back with SharePoint 2010, which allows organizations to share a singular SharePoint farm with several different other organizations or governing bodies. It allows an organization to manage its own data, sites, and services while having them coexist in a secure way with other organizations on the same set of hardware.
SharePoint 2013 continues to build on the multitenancy features that were introduced by SharePoint 2010 by continuing to add additional support for new services and features. Office 365 is one of the best examples. When you register for an account on Microsoft’s cloud platform, you are actually assigned SharePoint space on a server that cohosts several thousand other accounts. It wouldn’t make sense for Microsoft to have to maintain a SharePoint farm for each of its Office 365 users. With SharePoint 2013, you now have a way of managing some newly added service applications and to partition them across different tenants. These new PowerShell features are what allowed Microsoft to expose the Search Administration pieces in SharePoint 2013 Online (Office 365), which is something that they never managed to do when the online platform was still running SharePoint 2010. The concept of multitenancy can easily become a very complex topic, and I won’t be discussing it in this book. If you are interested, however, in getting more information on how you can use PowerShell to enable multitenancy in your on-premise SharePoint farms, you can refer to the following Microsoft TechNet article: http://technet.microsoft.com/en-us/library/ff652528(v=office.14).aspx. The content was released for SharePoint 2010, but the core of its content has not changed for SharePoint 2013. Figure 2-8 shows the administrative console of a SharePoint 2013 tenant site collection.
Figure 2-8. Tenant Administration site created by PowerShell
Office 365 was first released to the public back in 2011. At that time, users were given the option to create various site collections based on SharePoint 2010. At first, the administrative option to manage our online SharePoint environments were very limited, but with every product update, Microsoft slowly added more and more capabilities. As an example, the ability to use the Business Connectivity services were made available in October 2011, giving users the ability to connect to external business data sources and expose them via SharePoint on Office 365. Something was still missing, however, to allow administrators to be able to automate tasks, and give them additional features than what was exposed through the web interface.
In July 2012, when Microsoft first announced SharePoint 2013, they also launched a beta preview of the new Office 365 environment. SharePoint sites in this environment were now running on SharePoint 2013. At the same time as the beta program was launched, Microsoft also released a preview version of a set of tools called the SharePoint Online Management Shell. These allowed SharePoint administrators to connect remotely to their SharePoint Online sites using PowerShell and to interact with them using a subset of the available PowerShell methods for SharePoint. During the fall of the year 2012, the final version of these tools were finally launched to the public. Over the first six months of 2013, Microsoft upgraded the existing SharePoint Online sites still on 2010 to the latest 2013 version of the platform.
Office 365 users running on SharePoint 2013 are now able to manage their SharePoint online environment remotely using PowerShell. The SharePoint Online Management Shell requires users to run PowerShell version 3.0, and requires users that use it to be granted the global administrator role on the SharePoint online environment to which they are trying to connect. As mentioned earlier, you are only given a subset of the available PowerShell commands that are available on premises, when using the Online Management shell. Microsoft continues to build on the existing list of available online PowerShell methods with every new product upgrade now scheduled for every three months. The current set of available methods include ways to create and delete SharePoint site collections and webs, manage apps and users, as well as some methods to manage security groups. At the time of writing this book, the total count of available SharePoint-specific PowerShell methods that are available online is 30. However, if you take into account the methods that are made available to maintain your overall Office 365 environment (Exchange, Outlook, Licenses, etc.), that’s over 2,000 available methods to which you have access. To learn more about how you can use PowerShell to manage Office 365 accounts, please refer to Chapter 9 of this book. Figure 2-9 lists several PowerShell methods that are available with Office 365.
Figure 2-9. Listing available PowerShell cmdlets using the SharePoint Online Management Shell
If you had to upgrade a SharePoint 2007 environment to SharePoint 2010, you probably remember the concept of visual upgrade that was introduced by Microsoft to create a temporary preview of what an upgraded SharePoint 2007 site collection would look like using the 2010 interface. This process was basically taking the existing site collection and applying the new SharePoint 2010 master page on top of it and updating the UIVersion property of the collection from 3 to 4 (SharePoint Foundation is version 4, whereas in the 2007 days it was called Windows SharePoint Services 3.0). The upgrade process wasn’t always as straightforward as Microsoft had described it, and very often features that were working well when running on SharePoint 2007 were broken when upgrading to 2010, even if the 2007 look was still being applied. In SharePoint 2013, the story changed entirely.
Before I go further, I need to take a step back and discuss the internals of the platform. When you install SharePoint locally on a machine, it creates a folder hidden deep in the program files directory structure (normally at C:Program FilesCommon FilesMicrosoft SharedWeb Server Extension<SharePoint Version>). The cool kids normally refer to this folder as the “hive” (the 14 hive for SharePoint 2010 and the 15 hive for 2013). This folder is where SharePoint will store all of its goodies: features, web services, resources files, images, style sheets, master pages, and so on is stored in there. When you install SharePoint 2013, it actually created both hives, the 14 one and the 15 one. This ensures full fidelity for sites that run in SharePoint 2010, but on an infrastructure that is on SharePoint 2013. This means that you basically have both SharePoint 2010 and SharePoint 2013 installed in parallel and you are able to run both versions at the same time in your environment. When you create a new site collection in SharePoint 2013, you are even given the choice to create one using the SharePoint 2010 mode.
Because you have the two hives on our server, you can now be almost certain that you won’t break a SharePoint site by simply upgrading its platform to SharePoint 2013 in the back end. You may see issues, however, when you upgrade a site collection from SharePoint 2010 to SharePoint 2013. When viewing a SharePoint 2010 site that is hosted on a SharePoint 2013 environment, you will get a notification message telling you that you have the option to upgrade (see Figure 2-10).
Figure 2-10. Notification to upgrade a SharePoint 2010 site collection to SharePoint 2013
Assuming that you are ready to upgrade your site collection to SharePoint 2013, you have the ability to create what Microsoft calls an Upgrade Evaluation Site Collection. This is a temporary copy of an existing site collection, which will be upgraded to SharePoint 2013 and that will allow you to test you upgrade. Once you are satisfy with the end result, you can officially upgrade the existing site collection, at which point the evaluation site collection will be deleted permanently. PowerShell provides various methods to allow you to control how and when to create evaluation site collection. By interacting with the SharePoint timer jobs, you can force a preview site collection to be created on the fly instead of waiting in queue for several hours before being processed. You are also provided with methods to allow you to monitor site collection upgrades while they are happening, and you have the option of controlling the automated expiration of evaluation site collections in your environment. For more information on how to perform upgrades to SharePoint 2013 using PowerShell, please refer to Chapter 10 of this book.
Summary
In this chapter you’ve learned about several new features that have been introduced in PowerShell version 3 that allow you to better interact and manage your SharePoint 2013 environments as a SharePoint administrator. This chapter focused on the new material for SharePoint 2013. However, if you are not familiar with the concepts of managing your SharePoint environment that have been in existence since the first release of PowerShell, the next chapters will help you learn a great deal. Because Microsoft keeps updating the platform, especially its cloud version, it is very possible that new features not discussed in the present chapter will get introduced as time goes. In the next chapter I will go over the steps required to properly configure your environment to start using PowerShell to its full potential.