Update 10/25/2017: This article originally appeared on ITUnity.com but as that site has been decommissioned I’ve republished it here.
In the article, Introduction to the SharePoint Online Management Shell, you learned about the SharePoint Online Management Shell and you saw how to use it to connect to your SharePoint Online tenant. This article will continue that discussion by further detailing what cmdlets are available along with a few key points about some of the less frequently used cmdlets. In a later article you will delve much deeper into the more commonly used cmdlets.
As was noted in the Introduction to the SharePoint Online Management Shell article, the SharePoint Online cmdlet nouns all start with SPO. As shown in Figure 1, you can see the full list of all SharePoint Online cmdlets by passing the Microsoft.Online.SharePoint.PowerShell module name to the Get-Command cmdlet.
Figure 1: Use a Get-Command to get the names of the cmdlets available in SharePoint Online.
If you run the command you’ll see that only 30 cmdlets are available compared with the over 800 cmdlets available to a SharePoint on-premises installation. As you can see in the list below, the bulk of the cmdlets available are focused on Site Collection, User and Application management.
You can categorize these cmdlets into six general categories as seen below:
The first three categories (Site Groups, Users and Site Collections) are what I believe people will use the most, as I believe most people will want to use PowerShell to manage their Site Collections and associated security. One thing I found interesting when I first saw what cmdlets SharePoint Online provided was that you have cmdlets for managing Site Collection security groups in addition to users. However, in SharePoint on-premises you only have cmdlets for working with users and not groups. So, it’s definitely nice to see that Microsoft gave us this ability using nice and simple cmdlets. (You can manage groups in SharePoint on-premises, but it requires that you know the SharePoint API to do so.)
The group and user cmdlets are pretty self-explanatory given their names, as are most of the Site Collection cmdlets, which are covered in the Working with the SharePoint Online Site Collection Cmdlets
article. However, I want to briefly explain a couple cmdlets here as they are not covered in that separate article.
The Repair-SPOSitecmdlet and the Test-SPOSite cmdlet both relate to Site Collection specific health check rules. These are the same types of rules that you may be familiar with seeing in the Central Administration site if you have an on-premises installation. Test-SPOSite tells SharePoint Online to go ahead and evaluate any Site Collection specific rules against the specified Site Collection, and Repair-SPOSite will run any applicable repair code to address failed health check rules. Of course, not every failed rule has the ability to repair the issue, but many do.
With the exception of the Connect-SPOService and Disconnect-SPOService cmdlets, you will likely use the cmdlets in the next three categories (Tenants, Apps and Connections) very infrequently, though they can be useful for monitoring and troubleshooting errors. Regarding the tenant-specific cmdlets, the Get-SPOTenant cmdlet (figure 2) simply provides general information about your tenant, such as quota usage and site creation mode; this information is all available via the browser from your portal administration site.
Figure 2: Use the Get-SPOTenantLogEntry cmdlet, together with a correlation ID to see the log entries associated with the ID
The Set-SPOTenant cmdlet allows you to alter some of the properties that you can see when you run the Get-SPOTenant cmdlet. The remaining tenant cmdlets are all about viewing logs. The Get-SPOTenantLogLastAvailableTimeInUtc cmdlet does exactly what its rather verbose name suggests: It returns the most recent time when the logs were collected and available for querying. You can then use this information when working with the Get-SPOTenantLogEntry cmdlet to see one or more log entries. However, you will probably not need this as it’s usually safe to assume the log entries are available and you’ll be more likely to simply filter by correlation ID and a date range. In the example in figure 3, I’m providing a correlation ID to see the log entries associated with the ID.
Figure 3: Use the Get-SPOTenantLogEntry cmdlet, together with a correlation ID to see the log entries associated with the ID.
Note that I’m not providing a start and end time, but I recommend you do so when you run the cmdlet against your tenant.
When I first saw the Get-SPOAppInfo cmdlet I thought it would be a great governance tool to help me quickly see all the SharePoint Apps that have been installed throughout my various Site Collections. Unfortunately, I was disappointed to discover that the cmdlet requires you to provide a specific App Name or Product ID, and it then simply returns back the App Name, Product ID and Source as seen in the figure 4.
Figure 4: The results from the Get-SPOAppInfo cmdlet are probably not that useful.
So, while being able to get the Product ID given the name is useful when I need to call the Get-SPOAppErrors cmdlet, which only accepts a Product ID, it’s not all that useful if I don’t know what Apps are even in use within my Site Collections. For this reason, I don’t expect either of the two App-related cmdlets to be used very often.
SPO Object Members
If you’re familiar with the objects returned by SharePoint on-premises cmdlets, then you know that those objects are complex types that allow you to drill down into the object to get to child objects, or to call methods that perform some sort of action against the object or its children. If you look at the SharePoint Online objects returned by the various cmdlets, however, you’ll see that all of them are simple types containing only properties and no methods. All of the properties will be simple data types, such as string, integer or Boolean (figure 5). Though some of the properties are not read-only, changing the value of a property will have no effect on the actual object as there’s no way to commit the property change.
Figure 5: Most of the SharePoint Online cmdlets contain only properties as simple data types.
In this article you were introduced to the cmdlets that are provided as part of the SharePoint Online Management Shell. It’s obvious from the limited set of cmdlets that are available that you’re not going to be doing anything earth shattering but it is important to know what is available out of the box and when you’re going to have to look elsewhere to get the job done. However, before you look elsewhere, you want to make sure that you definitely understand how to use these cmdlets. To that end, the Working with the SharePoint Online Site Collection Cmdlets
article walks you through using the Site Collection related cmdlets to create, delete and secure your Site Collections.