Deploying Sandboxed Solutions to an Office 365 Public Site… well, maybe
Deploying Sandboxed Solutions to an Office 365 Public Site… well, maybe.
So, a couple of months ago, I set up a new Office 365 site where I could test out some of the things that I’ve been working on in an environment that was stable, controlled, and most importantly, not administered by myself. I previously had an instance of the SharePoint 2010 BPOS (Business Productivity Online Suite) where I deployed a couple of sandboxed solutions, dropped some blog posts, and all was good. Let’s just do that same thing again, shouldn’t be hard, right? Yeah, not so much…
Office 365 Public Site
SharePoint Online is the SharePoint component of the Office 365 package. For what I was looking for, I didn’t have a need for the full Exchange/Lync integration that the Office 365 Business Plans have to offer. Nothing more was needed than the SharePoint component of the package. As part of the configuration, I added a custom domain (cribtoso.com) to the plan, honestly, to make it a little easier to log in instead of using the cribtoso.onmicrosoft.com login I was given by default. Adding the custom domain to the plan is pretty straightforward. From the Office 365 administration dashboard, click the Domains menu option and the wizard will walk you through the rest. During this process, be sure to select that the domain will be used for public Office 365 website. Seem like the obvious choice in this situation but with the Small Business and Enterprise Office 365 plans, there’s the option to use the domain for Exchange and Lync. In that scenario, you could use your root domain to be used for Exchange and Lync then configured a custom sub domain to be used for the public site.
Figure 1: Public Site Domain Name Settings
With each of the SharePoint Online packages that are available, they include a site collection dedicated as the public site collection. In order to make this site collection a little easier to get to, I added a custom sub domain and mapped that to the public site collection of the plan. As part of a work around as directed by Microsoft to allow the use of the same domain for both authentication and the public site URL, I simply created a www subdomain on the cribtoso domain and using a little DNS magic with Hover, I was able to add and configure the domain for the public site on www.cribtoso.com with DNS pushing every variation on that address on to the www subdomain of cribtoso.com.
Deploying the Solution
All right, the public SharePoint site is there and ready to go. Just a quick click into the Site Settings, select Solutions…. (record scratch)… wait, where did the Solutions go? Here’s where things get a little hokey. Checking out the Site Settings page for the public site collection, you’ll notice it’s paired down quite a bit. Check out the differences in the following screen shots.
Figure 2: Office 365 Public Site Settings
Figure 3: Office 365 Intranet Site Settings
You can see that not only is the Site Collection Administration section severely reduced, so are the Search and Web Designer Galleries groups. All references to Site Collection and Site Features have been removed and looking a little closer to the Web Designer Galleries, you can see that there is almost no support for web parts at all. It’s almost as if Microsoft doesn’t want them to be used at all within a public site. So Sandboxed Solutions and custom web parts have been removed for the settings… Let’s ponder a moment as to why this would be.
- Without Sandboxed solutions, there is no way to add a custom web part to the site. The Web Part Gallery link is gone so you can’t upload a custom web part definition. Even if you could, the web part would have to be just a variation of an out of the box web part with, perhaps some predefined settings. Without solutions, there’s no need to monkey with the existing web parts.
- Sandboxed solutions are resource throttled. I can see why Microsoft would remove the use of Sandboxed solutions due to throttling capabilities. In a public site scenario, anonymous users can access the site. If your web site has a certain functionality that will cease to execute after a throttle threshold has been hit, it’s conceivable to think that a form of attack could be done by an anonymous user to force the site to hit the throttle threshold on a daily basis. Upping the throttle level only delays the inevitable while removing the throttle opens the door to unnecessary load on the system as a whole. Nixing the whole sandboxed solutions from the start fixes the problem completely.
- Anything that a web part can do, a SharePoint App can do. With the addition of the SharePoint App Store, the need for custom web parts has diminished. Additionally, with the App store, the functionality of the apps can be offloaded to other servers which hosts the app thus reducing the strain on the Office 365 front end servers. These front end servers can focus on doing what they’re fine tuned to do, serve web pages without balancing resources for executing the custom business logic of the sandboxed solutions.
So Now What?
Basically, it’s time to stop using Sandboxed Solutions for customization and functionality enhancements and it’s time to start embracing the development of SharePoint Apps as a means of providing this custom functionality. Plain and simple.
But I thought this was about deploying Sandboxed Solutions?
After all this, if you’re still bent on installing that Sandboxed Solution to your public Office 365 SharePoint site, fear not, there are some options hacks. At the time of this article, though the O365 team cleverly removed the link to the Solution library from the Site Settings page, it doesn’t necessarily mean that the functionality is ACTUALLY gone. By directly navigating to the library, you could be able to upload and Activate your solution. To access the library directly, use the following URL:
Here, you will see the Solutions library that you’ve grown to love. Feel free to upload the solution and activate it at will while keeping in mind the resource throttling issue mentioned earlier.
Ooooooo, what else does this work for?
Now that we know that some links are simply removed from sight and the functionality is not pulled, what other links should be available? Let’s see if we can find some of the relevant ones…
- Web Part Gallery – https://<yourdomainname>-public.sharepoint.com/_catalogs/wp – Accessible – You can also still select New from the Ribbon, find a whole slew of additional web parts and populate them to your site.
- Site Content Types – No Access
- Site Collection Features – No Access
- Site Features – No Access
- List Templates – https://<yourdomainname>-public.sharepoint.com/_catalogs/lt – Accessible
To insert the necessary legal blurb in here, I hope you realize that we take no standing as to whether these links will or will not work, whether the functionality will or will not be available or anything to the liking. Microsoft has the full capability to remove this functionality and likely will in the near future much the same as they have done with the Site and Site Collection Feature management pages. It’s on you to figure out if this is a viable solution for your needs as well as to appropriately plan for the migration of your existing Sandboxed Solutions to the App framework.
In the end…
Microsoft and SharePoint are moving more and more to the App model for their products and it’s time to start embracing it with open arms. From the looks of it, if we’re going to continue to use the SharePoint public site as a viable web site platform, we need to figure a way around the limitations of a public site without the use of Sandboxed Solutions.