Microsoft SharePoint is the most popular application of its type ever created. According to Microsoft, more than 65,000 companies manage a total of 125 million SharePoint licenses – and 67% of these customers have rolled out SharePoint to the entire organization.
It’s inevitable that SharePoint users will have questions as they learn how to take full advantage of its capabilities. We took a look back at the 2012 Rackspace SharePoint webinars, and asked our own team of SharePoint experts to weigh in here on the most common questions users ask about how best to develop, deploy and manage SharePoint sites and applications.
More than 65,000 companies manage a total of 125 million SharePoint licenses – and 67% of these customers have rolled out SharePoint to the entire organization.
It really boils down to one word: governance. If you don’t have a solid methodology for maintaining databases and application code, for example, a SharePoint deployment can quickly get out of control.
There are three related areas of concern for SharePoint developers and administrators:
Any IT project goes wrong sometimes. The real question is how quickly you can make it right.
Building an intranet requires technical know-how, but there’s a lot more to it than that. In fact, SharePoint works best as an intranet development tool when you anchor your development process with a strong focus on the people who will be using it:
SharePoint works best as an intranet development tool when you anchor your development process with a strong focus on the people who will be using it.
External SharePoint users present an interesting IT challenge. SharePoint almost always sits behind a firewall, and any extranet or public web site deployment must take this into consideration.
Here’s the key concept for giving external users access to a SharePoint server: separation. An IT organization should never deploy intranet and extranet/public applications from a single SharePoint server.
Separate SharePoint servers mean each instance of SharePoint (and the separate network segment on which each resides) can be optimized for a specific purpose. This includes secure local domain control and security for intranets and appropriate access rules (and firewall policies) for extranets.
Such an approach ensures that internal-and external-facing SharePoint applications will work and provide access as designed. And while licensing multiple SharePoint servers may sound like an expensive option, the long-term development, management and security cost savings will justify the investment.
An IT organization should never deploy intranet and extranet/public applications from a single SharePoint server.
The SharePoint architecture makes certain assumptions about the nature of the accounts logging into the system. As a result, users running on a domain managed by the Active Domain server responsible for the SharePoint server will have little trouble authenticating and logging into the SharePoint application. Administrators can assign inherited roles and permissions for these users, and they can easily establish single sign-in rules.
Accounts logging in from other domains, however, pose certain challenges for SharePoint administrators.
Here’s the crux of the problem: Users want single sign-in, and administrators want to give it to them. But SharePoint’s internal architecture isn’t designed to serve as a federating agent for multiple application component security structures.
If you don’t mind forcing users to sign in for each component, then there’s no real problem. Otherwise, you’ll have to rely on tools like web authentication and persistent cookies to simplify the application security process for users.
Web authentication and persistent cookies bring security consequences of their own, but they do illustrate one of SharePoint’s strengths: Its support for a variety of optional components and third-party plugins that extend the platform’s functionality.
SharePoint’s internal architecture isn’t designed to serve as a federating agent for multiple application component security structures.
Permissions play a major role in deciding which option to use here. SharePoint permissions originate with the top-level site and are then inherited down through sub-sites, libraries and lists. When these relationships get too complicated – especially with completely different groups of users requiring access to different libraries on a site – then it can make sense to build a separate SharePoint site.
At the same time, multiplying SharePoint sites and sub-sites can also create management, security and administration challenges. This is especially true when users have the ability to create new sub-sites on their own initiative – a situation that can create real problems for setting and managing permissions.
Some SharePoint administrators deal with this by creating “site manager” roles that have limited control over content and libraries, but that don’t have the ability to create new sub-sites. This gives a SharePoint administrator greater control, but it can also increase an admin’s workload – if these users can’t create their own sub-sites, they’ll ask you to do it for them.
In the long run, finding the right answer is really a balancing act, and it will depend in part upon your own organization’s unique requirements.
Creating “site manager” roles give a SharePoint administrator greater control, but it can also increase an admin’s workload.
InfoPath is a component of Office Professional Plus 2010. It can be a powerful and flexible tool for building forms that serve as a front end for enterprise workflow applications – including those deployed using SharePoint. Some developers also use InfoPath as a front end for custom code deployments.
Many experts, however, advise caution when using InfoPath as a front end for custom code. It’s possible to stack too many layers together and to build applications that are extremely difficult to test, maintain and administer. It is especially important to avoid this problem when building SharePoint-based intranets or extranets that rely on large and fast-growing datasets. As a result of these issues, experts advise that it’s generally most productive to use InfoPath primarily as a form-development and deployment system.
Many experts advise caution when using InfoPath as a front end for custom code.
Due to legacy storage issues, SharePoint databases were traditionally limited in size to 100 GB. At one time, this was a lot of storage; today, however, video and other media file formats can very quickly test these limits.
Media files and other unstructured data sources are also typically stored as Binary Large Objects (BLOBs). When this unstructured data is stored inline with structured medatdata – as it would be in a single SharePoint content database – it can create both size and performance issues.
There are two ways to work around this issue. The first option involves Remote BLOB Storage (RBS). This approach places the BLOB on a remote server; SharePoint accesses it via a service such as Filestream. RBS supports multi-terabyte files, and it can alleviate performance issues. It also has drawbacks, however, including limits on compression, encryption and mirroring capabilities; it performs best with stable data used mostly for read-only applications.
The second option involves storing the BLOB data on the same server or storage device as the content database while still keeping it virtually separate. This approach delivers much better performance than RBS, and it is ideal for smaller BLOBS and transactional read-write applications that will change or update the data.
RBS supports multi-terabyte files, and it can alleviate performance issues, but it also has some drawbacks.
SharePoint developers often work with large data sets, and they must address the question of how best to present this data to users.
The answer to this question depends first on technical limitations: It is possible to display up to 2,000 rows of information on a single SharePoint display form.
Yet this is also a matter of usability and sound design. Forcing a user to digest this much data on a single form is guaranteed to cause confusion and frustration.
Fortunately, SharePoint supports the ability to link an almost unlimited number of forms and processes. If, for example, you build an application that might actually deliver 2,000 rows of information, look for ways to break up this data into smaller, more logical groupings that you can display in separate forms. Your users will appreciate the results, the applications you build will deliver better value, and you’ll ensure that your intranet development efforts are successful.
Forcing a user to digest too much data on a single SharePoint display form can lead to confusion and frustration.
With new social networking features, mobile device support and other major changes, many organizations are already looking forward to the arrival of SharePoint 2013. Here are a few things to keep in mind as you prepare for the next upgrade cycle:
Rackspace® Hosting is the service leader in cloud computing and founder of OpenStackTM, an open source cloud platform. With the recent acquisition of SharePoint911 and the launch of Rackspace Services for SharePoint, Rackspace is the SharePoint authority. The San Antonio-based company provides Fanatical Support® to its customers, across a portfolio of IT services, including Managed Hosting and Cloud Computing. Rackspace has been recognized by Bloomberg BusinessWeek as a Top 100 Performing Technology Company and was featured on Fortune’s list of 100 Best Companies to Work For. The company was also positioned in the Leaders Quadrant by Gartner Inc. in the “2010 Magic Quadrant for Cloud Infrastructure as a Service and Web Hosting.” For more information, visit www.rackspace.com.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License