During the SharePoint Evolution Conference in London, I was asked, so what’s the purpose of Live Publish for Word and SharePoint? A perfectly legitimate question given we’re relatively unknown in the SharePoint space and that our app has been in the Office Store all of few weeks. I guess this is precisely the reason for me travelling half way around the world (from Perth) - to get the message out regarding apps for Office and SharePoint and to tell folks what we’ve been doing in this space.
It all starts with web content management (WCM) and the basic assumption that it’s all just a little too difficult to create web content in SharePoint. Perhaps it’s the experience of using the browser as an editing tool, perhaps it’s the challenges in managing HTML mark-up or perhaps it having to upload and manage images separately from the written content – perhaps it’s all these things. Whatever the cause, Live Publish sets about to help solve the problem of getting written content into SharePoint Publishing pages easily and more efficiently by using MS Word as the editor and publishing tool.
So how big is the issue of creating publishing pages in SharePoint via the browser experience? It’s hard to say, however, experience tells me that 80% of web content created and managed via SharePoint publishing pages (e.g. Intranet-based content), is essentially informational written content. The purpose of the content is to detail how or what users need to know; this may take the form of policies and procedures as an example.
Qualitem Live Publish is a product to help manage informational content in SharePoint (whether that is intranet, extranet or internet based content), it's important to understand exactly where Qualitem Live Publish can help. The best way to answer this is to look at the following issues you might experience with the SharePoint content publishing process:
When users look to create new content for their internet or intranet site, they know what they want to say but the process of getting it into SharePoint is not simple and not intuitive; certainly not as simple as using an editor like Microsoft Word.
In my experience, irrespective of the browser editing experience, users tend to draft content in MS Word before publishing web content. Using MS Word, content is cut-n-pasted into a publishing page (via Notepad on-the-through to strip out any control characters). Time is taken to ensure the content is grammatically correct and that there are no spelling errors. The reviewing of the written content by others is also done in MS Word. Once reviewed in MS Word and ready for publishing, it’s migrated out of MS Word in to a publishing page and submitted it for approval.
So it makes sense to integrate the two; initially editing content in MS Word with the Publishing of HTML to a SharePoint publishing pages. Qualitem Live Publisher achieves this using the app model. It’s a Word app loaded in the right-hand task pane that communicates to SharePoint to publish the MS Word document to the server or Office 365 environment.
In addition to the written content making up the publishing page, images are used. To view these images in-line within the web pages, the images are pre-downloaded (either purchased, downloaded from a camera or downloaded from a file share) and uploaded into SharePoint. Links to the images are then added to the publishing page to allow the images to view in the web page.
By using MS Word as our edit for web content, the user simply adds images and photos to the MS Word document – in-line. This is very straightforward and intuitive. There’s no need to separately uploading images and create links, users simply bring the images directly into the Word document and Qualitem Live Publish takes care of managing the upload.
We also manage the image sizes. Most user will not give consideration to the image size they are using. When images are downloaded from a camera to be incorporated in to a web page, they are typically not optimised for web and can be unnecessarily larger than needed. This slows down the web page load time as the entire non-optimized image is loaded. Live Publish will optimize the image as it saves to SharePoint; cropping and optimizing the image to assist with page load performance.
Live Publish solves this problem as it allows users to stay in MS Word as their content editor. Using our app, content is moved directly from the drafted MS Word document, to the SharePoint publishing page. Users can publish documents in-line directly from within the Word document, and preview the document once saved to SharePoint; this provides a seamless experience between MS Word and SharePoint with the user never having to leave MS Word to see the published document.
Saving the MS Word document to PDF format, is not a particularly difficult task to perform. However, it’s made easier using Qualitem Live Publisher. The reason it’s easier is that the user can navigate SharePoint document libraries within the Word app task pane. This is a nice inclusion that would otherwise be performed using a “save as” process.
What else? Opening and editing existing publishing pages In addition to creating web content and saving as PDF, probably the coolest thing about Qualitem Live Publish, is that you can open an existing published page to edit in MS Word, directly from within the app. This instantiates a new instance of MS Word to allow the user to edit the APSX content in MS Word and re-publish it out via the Qualitem Live Publish app.
Qualitem Live Publish supports opening the page within a currently open MS Word document, what this means is that whilst editing within Word, you can simultaneously open another publish page in a new instance of MS Word. The Qualitem Live Publish engine will load the task pane in the new instance of MS Word and import/convert the HTML content from the ASPX publishing page in to the MS Word document.
The Qualitem Live Publish Word and SharePoint app helps simplify the process of creating and publishing content to SharePoint Publishing pages. As a fully integrated experience, the user never has to leave the MS Word edit experience to publish their content to SharePoint, whether this is as a web page (HTML), DOCX and as PDF document. Qualitem Live Publish is available for trial from the Microsoft Office Store
Many web sites and corporate intranets suffer from content being out-of-date or stale and when this occurs, user adoption is low and user retention usually drops off. In addition to content being fresh and relevant, it needs to be presented nicely to give a good impression and wow the user in coming back.
There are some key initiatives you can consider in trying to drive user adoption and increase user retention, and this article covers two main strategies:
Keeping content current and relevant in SharePoint will help drive user adoption and retain users for longer. This is an obvious statement but unless you implement strategies to keep content current, it's difficult to achieve through day-to-day updates. Many of our clients use external feed content from news and social media providers as a strategy for keeping content current. This is a sound strategy as most of the external content is updated frequently (with a certain amount of reliability) and at little to no cost.
The concept of using external content providers is analogous to how newspapers are created. Of course Newspaper providers have their own journalist that generate content, but a large portion of any newspapers consists of bought syndicated content from other news providers. In fact, there’s more news content than they can fit into the newspaper (usually) and the articles that make it to print are ones targeted to the local audience (based on relevance and demographic). Consuming feeds within you site is no different, except, for the most part, feed content is free. If you adopt a strategy of keeping content fresh and relevant, you will retain and have better adoption of SharePoint (assuming relevance to the target audience is high). The other thing to note about feeds, is that they are usually just a snapshot view (an excerpt, sometimes with images). To receive the full content, you will be required to click-through to the provider.
The great thing about using feed content to keep your web site or intranet fresh, current and relevant, is that most feed content from news sites, social media sources and search engines is FREE! You can't get any cheaper than free and the approach to using free content as a strategy for maintaining a high level of user adoption is a sound one, as long as the content is relevant. As well as being free, there's an abundance of feed content that you possibly could consume, the content is global and made readily available from some of the most trusted sources in the world. BBC world news, CNN world news, Yahoo weather, etc. Relevance goes hand-in-glove with frequency of updates when it comes to maintaining a high level of user adoption. If content is not relevant, why consume it? It's like eating food, you wouldn’t eat something you didn’t like. If is relevant and attractive to consume, you’ll consume it without leaving an awful taste in your mouth.
Also, we eat with our eyes way before we take a bite; consuming content is no different when it comes to satisfying our appetite for knowledge and information. So the key is to make it look attractive to consume, this might mean that the feeds contain images or that the site has a responsive design to allow feed content to be displayed on smaller form-factor devices.
Some of our customers buy feed content that is very specific to their industry sector. An example of this is the finance and banking sector. There are specific content feed providers that deliver content that is very relevant and attractive to the finance and banking sector. As an example, these providers publish security bulletins relating to the finance and banking sector. The same can be said for other industries, like Health Care, Aged Care, Automotive, Oil and Gas, Mining; the list goes one.
Ensuring adoption is high within SharePoint is more than making sure content is fresh, current and relevant. The content needs to look good and often not enough importance is placed on how it should look in SharePoint. Whenever we've re-branded an intranet, we've found very positive feedback within the customer. This involves nothing more than re-skinning SharePoint to look a little bit cleaner, shinier and more in line with the customer's branding guidelines.
The branding of the intranet is always extremely subjective and follows the fashion of the day. We're in a period where straight lines, pointed corners (non-rounded) are in and shadows a definitely out. In the Microsoft world, this look is not allowed to be called “Metro”. Transparency (with varying degrees) seems to rule many good UI designs at the moment and simple colour and often single colours with varying shades are being selected.
A great example of a really cool SharePoint site is http://www.connectedsystems.com
This site is not only attractive to the eye but responsive in design, meaning it will automatically cater for different devices without the need for re-directing links.
So look-n-feel is as important as content freshness and relevancy; take time to ensure the look is in line with you branding guidelines and current fashions as this will naturally retain and attract users to your web site or intranet.
In attending several conference as an exhibitor (for Qualitem), the question I get asked the most is "what do you guys do?" It's a great question because Qualitem has a lot of great products for the SharePoint platform. The product that has the focus at the moment, is Feed Manager.
Most people don't know what Feed Manager is by the title and although we've tried to make it simple, folks get us confused with Twitter or Yammer. We're neither of these things and no we don't compete with Sitrion either. Our product is very different, in fact, we use the data available via all feed content systems (whether it be syndicated News feeds or Social Media site feeds). Qualitem Feed Manager will cache these into SharePoint for you and updates the content based on an update frequency setting per feed.
Having worked in and around software development most of my life, I’ve seen a lot and I’ve been responsible for a lot. Some I’ve been very proud to be responsible for and some not so proud. One of the things that we all strive for, but is not always achieved because of the pressures brought about by delivering solutions quickly or under unrealistic timeframes, is QUALITY! In this article, I’ve coined the phrase “Absolute Quality” and from a software development perspective, Absolute Quality is key to how we tackle software development.
In mentioning the term “Absolute Quality” to my staff, many mentioned the Six Sigma processes. I’d obviously heard of Six Sigma and its relevance in the manufacturing sector but I honestly never thought to look into its principles for software development. I’m not sure why; after all, as software engineers we’re simply manufacturing software solutions. But I think there’s a fundamental difference in my meaning to “Absolute Quality”, and it relates to cultural and behavioural changes in how we develop software, and not just process improvement during the manufacturing process.
I realised a long time ago that nothing is perfect, and certainly software has bugs. Perfection is not the outcome of thinking “Absolute Quality” and to me setting the quality bar at “perfect” is unrealistic. Absolute Quality is about raising the bar; raising it to heights you never expected you could reach. Implementing a way of thinking and working that dismisses the concept of “path of least resistance” and aims for “going above and beyond”.
Absolute Quality is at risk though, and I see it every day. Especially under strict deadlines and unrealistic and meaningless timeframes that are arbitrarily set to make people feeling as though they are achieving results, when all they are really doing is setting things up to fail. I worked for a very clear man once who ran a wedding function business (when I was much younger, earning extra money after hours), he said something to me that was very profound. He was constantly under pressure to reduce his price as weddings are an expensive and emotive business. He used to say, “Do you want a cheap wedding, or a good wedding, because you can’t have both.” This resonated with me because software development solutions are a bit the same. My point is, quickly delivered software solutions very rarely result in good software solutions. The principle of Absolutely Quality means we focus on what needs to be done, in the right order, not setting end dates we’ll never achieve and by setting these unrealistic end dates we’re just cheating on quality.
My product development software business, Qualitem, builds SharePoint software products. Although Qualitem is a new venture, our SharePoint products have been in the market since 2007 (via Connected Systems). Throughout the journey of building SharePoint products (or any software for the matter) it’s obvious that quality must be the highest tenant within the company – quality products must be what we deliver, whether it’s through Qualitem or Connected Systems our services business. Although this is a simple and obvious statement, what I’m really talking about is encapsulated in the phase – “Absolute Quality”.
The reason I’m speaking about quality is because it’s the one thing we tend to let drift, especially when we’re under pressure to deliver. Quality is more than just good code, it’s an attitude and something that takes adjusting to, especially if you’ve had the need cut corners to get it done on time. Too often I hear within a project, “we’re finished”, with the reality not matching the expectations of those that just don’t get what “Absolute Quality” is all about.
When I worked for Microsoft Consulting Services in the early 2000’s, it taught me a lot about what was important and how to approach software development. Tools like Microsoft Solutions Framework were extremely helpful to me and helped me understand the importance of doing the right things in the right order. This is where I learnt that quality can never be compromised. This is the diagram that encapsulated software development best.
This simple but elegant diagram taught me that no matter which of the 3 sides changed (time, features and resources/money), quality was at the centre and it never changed (it should always be at the highest level) and should never be compromised. This diagram represents our approach to software delivery. If features were fixed then time and resources had to change to accommodate the features changes. Similarly, if resources were fixed then features or resources had to change etc.
Absolute Quality means we decide to do things that make NO assumptions. We do the right things in the right order and we should not be driven by deadlines that are unachievable. An example of this is implementing support for verbose logging in our software. It’s not good enough to just cater for exception handling of errors (of course we do this), however, we must log what’s happening and even support a tracing mechanism so we can understand where the issues lie. Absolute Quality is needed with everything we do, whether it be software development, business development, marketing, support or administration, everyone must take ownership for achieving Absolute Quality.
And remember, when you’re under pressure to deliver something quickly, ask yourself (and the customer), do you want a quality systems or one delivered quickly, because chance are, you cannot get both.
Large List support is something that many organisations struggle with in SharePoint. If you're wondering what I'm talking about, here's an overview of what is Large List support and why is it important.
When we start out using SharePoint, our intentions are fairly modest. The last thing we're focused on is having SharePoint tell us we've exceeded the number of list items or documents in a library. In fact, Microsoft tell us in their marketing of SharePoint that it support millions of list items and documents. Strictly speaking it can, however, it's never straightforward and there are boundaries set by Microsoft to ensure the performance of SharePoint is not impacted by users not understanding the impact of having very large lists. As IT folks, it happens all the time with SharePoint. We provision the site, then we provision the list, then we provision the document library and we hand it off to the user with very little governance. Sometime down the track we get the phone call - the user has uploaded the entire file share and suddenly SharePoint stops working – sound familiar?
Typically when the user gets the error that they have exceeded the maximum number of list items, it usually sounds alarm bells around the organisation because the list is rendered useless using the out-of-box SharePoint list view. SharePoint restricts the number of items that can be retrieved for a list or library. The reason it does this is performance. Imagine SharePoint returning 10's of thousands of items without this consideration – it may cause SharePoint to perform slowly. To combat the issue of having lists views too large, Microsoft implemented list threshold settings. The setting that manages the size of the list is called "list throttling" and its purpose is to ensure that large lists view request don't give the impression that SharePoint is slow or not working.
There are some out-of-the-box activities within SharePoint to manage the large lists and these are normally used after-the-fact. The point of this article is to raise awareness regarding the planning of list/library content and to critically ask yourself whether you've done an appropriate amount of planning of your SharePoint content. There are many good articles from Microsoft and others on some of the pitfalls and remediation steps with supporting large lists in SharePoint. Try and plan for this now if you haven't already and if you have, ensure your strategy for large list support is sound and meets the requirements of users. When I talk about strategies, what I'm really getting at here is "Are the solutions outlined in this article (under the heading 'Rendering Large List') really going to suit your users?"
There are many out-of-the-box solutions to the issue of managing large list in SharePoint and there may be one that suits your situation. In most cases (from my experience), customers just increase the list threshold settings temporarily to give them a bit of breathing space whilst they figure out the best long term solution. I do support this approach as a short-term tactical solution but long term, increasing the list threshold is not sustainable and performance will be an issue very quickly. The reason I say this is because temporarily increasing the threshold limits is not addressing the problem; the real problem relates to the viewing of the data.
The reason that threshold limits even exist in SharePoint is related to querying and rendering the list/library results set. Microsoft don't want you thinking SharePoint is slow or broken just because you're trying to query and render 10,000 items.
When we think about what's involved in solving the issue of large list, there's really two things to think about.
So if increasing the limit to tie you over is just delaying the issue (albeit an attractive solution as it fixes an immediate problem), what should the limit be set to? How much is enough and when will you hit this limit again?
So think about this, is increasing it by a 1,000 going to be enough, or 10,000? Why not just remove the limit? If we consider removing the limit for lists and libraries, it means we need to have alternate and more performant ways of displaying the results from SharePoint lists and libraries. If a list has 10,000 items, it's just not practical to bring back the entire set and expect SharePoint to be lightning fast.
We need to find alternate ways to limit our results sets or just render what we care about, a page at a time. Fixing the rendering issues caused by supporting large lists is the key to solving this problem. We know that SharePoint can support 50 million items; and if you've chosen to use it to manage tens-of-thousands of items, that's fine, however, you'll need to find alternate way to search, filter, find and display the items you're looking for.
There are some simple methods within SharePoint that will give you some immediate solutions, these include:
I'm not looking to re-purpose the main reference for this article (http://office.microsoft.com/en-in/sharepoint-server-help/manage-lists-and-libraries-with-many-items-HA102771361.aspx#_Toc346115854) where it explains these in detail, however, what I would recommend is to keep it simple.
I support most of these options however there's three that really resinate with me:
As a SharePoint vendor we endeavour to make the management and use of SharePoint easier for customers. Qualitem has taken a solution approach to this problem and through our solution we allow administrators to more easily manage lists thresholds (per list) and solve the displaying of the content issue.
We tackle the issue in two ways:
For more information on our solution, please contact us at sales @ qualtiem.com.
You say building a Publishing toolset for SharePoint Foundation is a little crazy, maybe you’re right. Regardless, we did it and it’s in and working for many customers globally.
This is the 2nd article of a two part series covering the Qualitem Web Publisher, why and how. Please refer to “Web Publishing For SharePoint Foundation - Why?” - for background information on why we did it.
Our customer needed to create content on the Staging farm and have it migrate to the Production internet farm, whilst retaining the ability to publish content (for example set the welcome page, master pages, custom layouts, access the editing toolbar, and run approval workflows). The alternative was for them to buy SharePoint Server for their 190,000 employees; this was never going to happen and simply cost prohibitive even for this extremely large organisation.
This article will start to address the how, albeit at a fairly high-level to start with, essentially:
So we set about writing a SharePoint Publishing feature that worked in SharePoint Foundation; so how did we do it?
Consider this scenario – 2 farms, the Extranet farm running SharePoint Foundation and the Intranet Farm running SharePoint Server Standard. The destination Extranet server is therefore running a sub-set of SharePoint functionality currently available in the Intranet SharePoint Server Standard environment. It was imperative to reduce/remove the dependencies on SharePoint Server Standard components without losing the SharePoint Publishing functionality.
An example of this is the Content Publishing features of SharePoint Server Standard. These features are key to how content is managed on the Intranet, however, how can we simulate these on the Extranet without imposing a SharePoint Server licensing cost. This was important to the customer as it was cost prohibitive to buy SharePoint Server for their subsidiary business users. It is also possible to deliver similar Content Publishing components without imposing a licensing overhead (like Content Query web part). We achieve this through development and customisation; specifically replacing Microsoft built-in components with “freeware” components built within the SharePoint community.
Bringing the SharePoint Server Enterprise Intranet back to a “lowest common denominator” (and not using the Publishing feature) facilitates a simpler content migration path. In effect, we simulate and replace as many features as possible without using SharePoint Enterprise features.In fact, we have a situation now where SharePoint Server would be in question as needed for their Intranet except for the fact that Forms Services and People Search are required.
The following components are required to be replaced or augmented in Intranet for a possible synchronisation of content with the SharePoint Foundation Extranet site.
We needed to align features across the SharePoint Server Intranet and SharePoint Foundation Extranet as much as possible. Most content migration issues relate to there being a mismatch in “features” between the source site template and the destination site template. When the base or underlying site templates are different or have different features installed, it is likely that the migration will fail. All features installed and activated are to be the same across the SharePoint Server Intranet site and the Extranet site, these include:
The Content Publishing features of the SharePoint Server Intranet supports the ability for pages to be created and moderated. When pages are created, users have the option of selecting a custom layout (which defines content placeholder areas). It is imperative to simulate the multiple layout support and custom master page support for the Extranet. This will ensure pages are supported and can load without error. The synchronisation of the custom layouts and custom master pages is a customisation as SharePoint Foundationv3 doesn’t support Content Publishing out-of-the-box.
Our aim with the Content Publishing feature was to minimise the usability impact of implementing a replacement publishing feature. Our Ribbon buttons resembled the ribbon in SharePoint Server and apart from some styling attributes most seasoned SharePoint Server users would find it difficult to pick the difference. Don’t under estimate the necessity of the ribbon, given it drives the editing process, it, along with the selection of layouts and master pages, they are the “killer” features of content publishing.
So now we had a Publishing feature across two farms, how do we get the content from Staging to Production? The client wanted a solution where they could opt-in particular content and this was managed on a page-by-page basis. As with most things, there is always more than one way to achieve the same result. SharePoint Server and SharePoint Foundation has a very rich content deployment and migration application programming interface (API). There are many built-in options using this API to make content migration and deployment easy for SharePoint Server administrators.
SharePoint Server has various content migration features built-in as part of the Content Publishing and Management features. However, when looking to synchronised content with a separate SharePoint Foundation farm, most of the built-in options either do not work or impose a licensing overhead. The built-in content migration services as part of SharePoint Server attracts a license overhead – this is why we couldn’t use it. The other issue with this is that the destination or Extranet SharePoint Foundation needs to accept the “right to receive” content from a source SharePoint Server and this is not supported in SharePoint Foundation. Finally, using this method, the entire site collection is replicated – this does not allow for an opt-in, only replicate tagged content model.
Using standard SharePoint (out-of-the-box) tools, there are three other methods of getting content from one farm to another, these include:
The Custom Approval workflow is the preferred content synchronisation option. These workflows are customisation to SharePoint that action any business rule built into the workflow (via source code). Content can be opted in or out using metadata and migrated optionally on approval or without approval if needed. It leverages the SharePoint Content Deployment and Migration API which is an extremely rich and functional API.
In conclusion, the undertaking of creating a set of publishing tools for the SharePoint platform was huge. Our customer needed to create content on the Staging farm and have it migrate to the Production internet farm, whilst retaining the ability to publish content. It was not an option for them to buy SharePoint Server (it was cost prohibitive for their 190,000 employees), so we set about creating a Publishing and content migration feature for SharePoint Foundation.
You might ask, "Are you crazy? Why?"
SharePoint Server already has web publishing, right?
That’s’ right! But what about SharePoint Foundation clients? There’s no way for SharePoint Foundation clients to publish web content easily and efficiently. You might be thinking (and I certainly hope not), what is SharePoint Foundation? For more information on SharePoint Foundation, please refer to my article on “The Power behind SharePoint Server”. This will outline the SharePoint Foundation product and why it’s the heart and lungs and nervous system of SharePoint Server.
This is a great question and one that can be answered quite simply; some customers want it!
Not every customer that wants the functionality of SharePoint Server can afford to buy the SharePoint licenses. Many opt to install SharePoint Foundation and use the out-of-box features to their best ability. These customers I’m referring to not always small or mid-sized customers, some of the customers we’ve helped and implement Qualitem solutions on SharePoint Foundation into are multi-billion dollar organisations. Using tools like SharePoint Designer, customers can extend SharePoint Foundation. But there’s still a gap between SharePoint Server and what tools like Designer can do.
So why did we bother when Microsoft already did it? Like most products, it started as a customer problem.
This was a very bold undertaking by any measure, after all, SharePoint Server 2010 has a working publishing feature. Many might say that this is actually something that only Microsoft would attempt. It’s actually the type of solution Microsoft asks of all its ISV partners, that is, take the Microsoft platform and build compelling solutions that add value above the stack.
So we did just that. Moreover, this is exactly what SharePoint Server Stand and Enterprise is; a set of solutions (or WSPs) installed on the SharePoint Foundation platform, it’s just that Microsoft call is SharePoint Server (Std and Ent) and sell it with different SKUs based on deployment scenarios.
Qualitem Web Publishing solves the problem of building and managing web content on SharePoint Foundation. The customer we originally built this for has 190,000 employees; implementing SharePoint Server Standard with its Client Access License (CAL) model for licensing, was never going to fly. Our customer was never going to license that many users and SharePoint as a platform was at risk of being thrown out – it was simply too cost prohibitive for our client at the time to purchase 190,000 SharePoint CALs (as they were not on an Enterprise Agreement).
The customer was publishing content that was going to be accessible across their group of companies (and potentially 190,000 users). This meant that a SharePoint Server Standard CAL would be needed for every user. They also needed to move content from a Staging farm, which was SharePoint Standard (this was where the content was maintained), to a SharePoint farm in the DMZ (accessible by potentially all 190,000 employees) and across a firewall.
They needed to create content on the Staging farm (SharePoint Server Standard), have it migrate to the Production internet farm (SharePoint Foundation), whilst retaining the goodness of publishing (like welcome page, master pages, custom layouts, editing toolbar, and approval workflow). So we set about writing a SharePoint Publishing-like feature that worked in SharePoint Foundation and could also work on the SharePoint Standard SKU. We knew that if we could get it working on SharePoint Foundation, it would also work in SharePoint Server Standard product.
Our customer’s business is structured as a federated set of businesses; the “Corporate Office” sits above a set of subsidiary businesses, each runs autonomously.
The “Corporate Office” has a SharePoint Server Standard intranet to service their employees (“Intranet”). They also have a requirement to host a central web site for the subsidiaries businesses (“Extranet”) to reference information from the parent company’s corporate functions (e.g. group treasury, group risk etc). Content is authored by corporate office users in the Intranet with the option to publish the content to the Extranet via a custom workflow. None of the SharePoint Server Standard Publishing features could be used as they would obviously not work on SharePoint Foundation.
Using SharePoint Server Standard as their Extranet (accessible by their subsidiary businesses) was cost prohibitive. Under the current Microsoft Product Use Rights (PUR) (for a product like SharePoint Server Standard), any subsidiary business employee accessing a SharePoint Server Standard web site requires a SharePoint CAL.
Please note: Anonymous access is NO way of getting around the PUR conditions in this scenario.
In costing this out, the “Corporate Office” determined that a SharePoint Server Standard Extranet was cost prohibitive as it would have to purchase for ALL subsidiary business employees - combined number is over 190,000 employees. The Internet Connector license is not applicable in this situation as the “Extranet” is on the internal network and servicing subsidiary businesses, not on the Internet.
We needed a way to allow the small corporate office to utilise SharePoint Server Standard internally (Intranet), whilst having the ability to easily publish to a separate anonymous Extranet (SharePoint Foundation). The customer needed to seamlessly synchronise and publish content from the Intranet (SharePoint Server Standard) server to the Extranet server (SharePoint Foundation) via workflow and tagging content as “Extranet Applicable”.
Turning the SharePoint Server Publishing feature on and publishing these pages to SharePoint Foundation would not work.
The challenge was to have an environment where Intranet users could publish information in SharePoint Server Standard (just like the out-of-box Publishing features), tag it as “extranet ready” and for this content to be available on the Extranet portal in an automated way. We wanted the newly created Publishing feature to map as closely as possible to the SharePoint Server Standard out-of-the-box features, as this would minimise the training impact for users already using SharePoint Server Standard Publishing.
In addition to mirroring the SharePoint Server Publishing features, the requirements for the Extranet were as follows:
In summary, our ambitious plan to build a “fit-for-purpose” web publishing feature for this customer paid off. The Qualitem CMS is now a robust and proven option for customers all over the world that have opted for SharePoint Foundation as their Web Content Management platform.
Everyone knows that SharePoint is NOT free, or is it?
If you do a search on Google or Bing for "The SharePoint Alternative to Open Source" you get hundreds of results back for "Alternative to SharePoint". In reading through many of these articles the usual suspects keep coming up as valid "free" replacements for SharePoint Server. Many of the alternatives to SharePoint Server are very mature and good products in their own right.
These products cover workloads like:
However, most people don’t look right under their noses, and for most of us, when we think free, we think it’s not very feature rich, but this couldn’t be any further from the truth when we consider SharePoint Foundation.
During my investigation into why people are looking for SharePoint Server alternatives, I came across numerous reasons why people are looking for SharePoint-like alternatives. Some of the discussion out there is based on the thread that, SharePoint Server is:
Whatever the reason, there's one product that does not get a mention as a viable SharePoint Server replacement; I guess that's because everyone is looking at non-Microsoft products.
SharePoint Foundation is “The SharePoint Alternative to Open Source”.
Here’s why? If you own a Windows Server 2008 and above, you might already know that SharePoint Foundation is a free option, this also applies to Windows Vista, 7 and 8 because SharePoint Foundation 2010 (not 2013, this requires Server) can be run on these platforms as well as Windows Server.
I'm not saying SharePoint Foundation 2010 solutions are completely free (as you need to have a base Microsoft Windows operating systems), but for those who own any of these operating systems already (and that's most of us), SharePoint Foundation 2010 doesn’t cost a penny.
Whether you’re looking to use SharePoint to host your internet site, storage and manage you document, as a collaboration platform for team content or a portal environment for your staff intranet, it’s all there in one form or another with SharePoint Foundation.
At the start of this article, I mentioned the four main workloads that open source vendors compete with SharePoint; I will use the Web Content Management workload to describe what I mean by my statement “the core is all there!”
When I speak to clients about their requirements regarding web content management, it’s clear that Foundation really doesn’t help them out-of-the-box; however the core of what they need is all there (assuming you like to get dirty with SharePoint), it’s just not as easy as using the SharePoint Publishing features. There are 3 types of web content pages you can build in SharePoint Foundation, these include:
So building HTML web content is possible. The question regarding branding your web site, is for another discussion (and branding your SharePoint site would be done regardless of the SharePoint SKU), but using various techniques, CSS and scripting languages, SharePoint Foundation is a viable platform for web content management – after all, as it’s free (for anonymous sites).
When you break down the requirements of publishing web sites in SharePoint, the key elements are:
Microsoft has incorporated the Publishing Features as part of SharePoint Server Standard and although Foundation doesn’t contain these features, many of these settings are in Foundation (just hard to get at) either using some free tools to expose the settings that the Server Publishing Feature leverages, or by investing in a 3rd party add-on that brings Foundation up to the same level as the Server product (like the Qualitem Web Publishing feature).
SharePoint Foundation as a SharePoint Alternative to Open Source is an extremely viable solution. With the additions of 3rd party add-ons (free and commercially supported), you’ll find that SharePoint Foundation can meet the needs of your client, whether it’s web publishing, document management, collaboration team site or as a portal platform for you staff intranet, SharePoint Foundation is worth investigating as a low cost entry in to SharePoint – forget Open Source!
First of all, I want to apologise to all those folks reading this that totally understand what SharePoint Foundation is. This article is not for you, I’ll explain further on if you care to continue reading. Our company, Qualitem, recently exhibited at the SPC14 in Las Vegas (http://www.sharepointconference.com/). This was our first conference as an exhibitor. Qualitem is a SharePoint product company (http://www.qualitem.com), and like the other 200 vendors at the conference, our product adds value to the SharePoint platform. There is one main difference with Qualitem though, we market ourselves as a SharePoint Foundation solution provider. This is not to say our features don’t work on Standard or Enterprise (because they do), we’re simply highlighting the point that if it works on SharePoint Foundation, it will work on the Standard and Enterprise products. In light of the fact that we market ourselves as a SharePoint Foundation solution provider, one of the many questions that was asked of us at the conference was, “What is SharePoint Foundation?” This absolutely flabbergasted us as an exhibitor; to think, there were SharePoint folks out there that hadn’t heard of or didn’t know what SharePoint Foundation was or understand its role in the scheme of SharePoint Server (Standard and Enterprise), was something that we found hard to believe. The question, “What is SharePoint Foundation?” has prompted this article.
Before I outline the answer to the question “What is SharePoint Foundation?” I first need to get across the concept of the “Microsoft Stack” in the context of SharePoint. Having worked at Microsoft previously, this term is used internally a lot to relay the message that Microsoft is a platform, not a single instance solution. This idea that implementing Microsoft allows you to build on a very strong foundation, many Microsoft layers (or the “Microsoft Stack”), is a very compelling value proposition for most organisations.
The second reason for this article is to answer the question, “What is SharePoint Foundation?” Microsoft define SharePoint Foundation as - The underlying technology for all SharePoint sites. SharePoint Foundation is available for free on premises deployment—in previous versions it was called Windows SharePoint Services. You can use SharePoint Foundation to quickly create many types of sites where you can collaborate on Web pages, documents, lists, calendars, and data. (http://office.microsoft.com/en-au/sharepoint-foundation-help/what-is-sharepoint-HA010378184.aspx)SharePoint is a hugely successful collaboration platform for Microsoft and this is obvious when you attend the SharePoint Conferences. Not too many of the other Microsoft server products have a dedicated conference, and none are as well attended as the SharePoint Conference. There is consistently in excess of 10,000 delegates each time Microsoft hold their global SharePoint Conference and more than 200 vendors exhibiting their products for SharePoint. These exhibitor (just like Qualitem) is trying to carve out their niche in the world of SharePoint value-added products. In attending the recent SharePoint Conference 2014 in Las Vegas, it was evident that the SharePoint vendor market is extremely mature. There are many vendors for SharePoint and many of them have been in the market for considerable time (since 2007). This is a great story for customers looking for value-added solutions for SharePoint. But not many of them talk about SharePoint Foundation, why is that? My guess is that so many large organisations have SharePoint Server as part of their volume licensing agreements. This means SharePoint Server licensing is not an impediment or barrier to deployment. This is great news for Microsoft and SharePoint as a platform for collaboration. I think the reason that SharePoint Foundation is the forgotten product (or not that well-known), is because folks discount it as they think it can’t be a serious product if it’s free. Or, they think it simply doesn’t deliver the features they need. Maybe it doesn’t; my point is, understand where it does fall short and see whether there a 3rd party solution out there to fill the gap. I believe SharePoint Foundation does have a place in the corporate sector – it’s there now! There are many workloads that can be satisfied with the SharePoint Foundation features, for example, an extranet scenarios where collaboration with JVs or partner organizations is more cost effective with SharePoint Foundation. SharePoint Foundation is also (with a few 3rd party vendor solutions) considered a great compete strategy against all the Open Source vendors. So if you’re looking to compete against the Open Source solutions, or even non-Microsoft vendors, remember that SharePoint Foundation is an excellent solution and a very affordable option for your organisation or customer(s).
In the context of SharePoint Server, SharePoint Foundation is the heart and lungs and nervous system for the Standard and Enterprise features that Microsoft have built above SharePoint Foundation (these features/components have been packaged up and sold as SharePoint Standard and Enterprise Server). SharePoint Server doesn’t exists without the SharePoint Foundation product and therefore, SharePoint Foundation is “The Power behind SharePoint Server”.
info @ qualitem.com
+61 8 9227 0416
81 Edward Street, Perth