As I wrote on Monday, the decision to begin removing already deprecated code-based sandbox solutions on SharePoint Online took many people by surprise. Even though the news about the deprecation has been out there since 2014, the abrupt move – especially during a time when many people are on summer vacation – caused consternation for some. Others welcomed the move, in essence saying “good riddance” to a model that never really reached maturity.
But what if you manage a tenant on Office 365 that might have code-based sandbox solutions? Maybe you’ve used outside vendors to build solutions for you and you’re not sure what techniques they have used. Or maybe your own team built some things a few years back, you’ve had some turnover, and your source control isn’t so great. (Not so unusual, frankly.) How do you know what you have and what to do about it? You certainly don’t want functionality your users actually need to stop working unexpectedly. Some of these solutions could be InfoPath forms with code-behind, for example.
Vesa Juvonen (@vesajuvonen) – one of my true Microsoft heroes for what he has done with the Office 365 Developer Patterns & Practices (PnP) set of tools – has come to the rescue, apparently with some help from Karine Bosch (@kboske). They have released a PowerShell script today that promises to “Generate [sic] list of sandbox solutions from SharePoint Online tenant.” (Far be it from me to correct Vesa’s Finglish!)
This script can be used to generate a list of sandbox solutions in a SharePoint Online tenant. You will need to use a tenant administrator account to connect to SharePoint Online and the script will generate a list of sandbox solutions into a separate txt file, which can be imported to Excel for further analyses.
Note: This script is relatively simple and does not use multi-threading, so execution in larger tenants might take a while. We are looking at further enhancing the script with multi-threading support, if there’s demand for this. Also, community contributions on this site are more than welcome.
The output file has the following columns
- URL of the site collection
- Name of the sandbox solution
- Author field from the sandbox solution – who uploaded the file
- Created field from the sandbox solution – when solution was uploaded
- Status field – 1=Activated, 0=Not activated
What seems to be missing here – at least to me – is the “and this one contains code” indication, but it’s still going to be very useful. Maybe it’s not simple to tell which solutions contain code? If you have ideas about this, it’s an open source project, so head over there and enhance it!
The script requires – not surprisingly – that you have the SharePoint Online cmdlets installed. My bet is that there are plenty of Office 365 customers that have never really figured out how to download, install, and use PowerShell against Office 365. Many tenants are run by business users rather than technical types, as befits a powerful SaaS offering. In fact, in many cases, IT doesn’t need to be involved at all. That said, one would hope that those tenant administrators would know whether they have sandbox solutions installed. However, see my mention of possible situations above, even if IT was in charge.
Here’s a quick tutorial on how to install those cmdlets in case you need it. In writing this section, I’m stealing the TechNet article, Connect to Office 365 PowerShell. To do this, you have to be a tenant administrator. If you are, you’re probably the one wondering what you have in any case. It’s a pretty painless process, but if you haven’t used PowerShell – think batch files for servers – then it might be intimidating. I’m just copying the instructions from TechNet here, but I’ll add in some graphics and additional comments over the course of the day, so come back if you have questions. If you want to add any tips, please do so in the comments.
As Vesa always says: Sharing is Caring!
Step 1: Install required software
These steps are required once on your computer, not every time you connect. However, you’ll likely need to install newer versions of the software periodically.
- Install the 64-bit version of the Microsoft Online Services Sign-in Assistant: Microsoft Online Services Sign-in Assistant for IT Professionals RTW.
- Install the 64-bit version of the Windows Azure Active Directory Module for Windows PowerShell: Windows Azure Active Directory Module for Windows PowerShell (64-bit version).
Step 2: Open the Windows Azure Active Directory Module
- Find and open the Windows Azure Active Directory Module for Windows PowerShell by using one of the following methods based on your version of Windows:
In the results, select Windows Azure Active Directory Module for Windows PowerShell.
- Start menu: On the Start menu, enter Azure in the Search programs and files box.
- No Start menu: Search for Azure using any of these methods:
- On the Start screen, click an empty area, and type Azure.
- On the desktop or the Start screen, press the Windows key+Q. In the Search charm, type Azure.
- On the desktop or the Start screen, move your cursor to the upper-right corner, or swipe left from the right edge of the screen to show the charms. Select the Search charm, and enter Azure.
Step 3: Connect to your Office 365 subscription
- In the Windows Azure Active Directory Module for Windows PowerShell, run the following command.
$UserCredential = Get-Credential
In the Windows PowerShell Credential Request dialog box, type your Office 365 work or school account user name and password, and then click OK.
- Run the following command.
Connect-MsolService -Credential $UserCredential
How do you know this worked?
After Step 3, if you don’t receive any errors, you connected successfully. A quick test is to run an Office 365 cmdlet—for example, Get-MsolUser—and see the results.
If you receive errors, check the following requirements:
- A common problem is an incorrect password. Run Step 3 again. and pay close attention to the user name and password you enter.
- The Windows Azure Active Directory Module for Windows PowerShell requires that the Microsoft .NET Framework 3.5.x feature is enabled on your computer. It’s likely that your computer has a newer version installed (for example, 4 or 4.5.x), but backwards compatibility with older versions of the .NET Framework can be enabled or disabled. For more information, see the following topics:
- Your version of the Windows Azure Active Directory Module for Windows PowerShell might be out of date. To check, run the following command in Office 365 PowerShell or the Windows Azure Active Directory Module for Windows PowerShell:
If the version number returned is lower than the value 1.0.8070.2, uninstall the Windows Azure Active Directory Module for Windows PowerShell, and install the latest version from the link in Step 1.
You can find other great blogs by Marc, plus read his original post, here.