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.

What are the biggest challenges for SharePoint administrators?

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:

• Performance. A successful SharePoint application can gather new data the way oak trees gather Spanish moss. Proper governance will go a long way toward making sure that content databases don’t grow out of hand, and that content databases and BLOBs are stored efficiently.
• Stability. Nothing makes users abandon an intranet faster than systems that aren’t reliable. If you pay attention to change management you can avoid the sort of add-on components that can steer your business processes off into the weeds.
• Reliability. Any IT project goes wrong sometimes. The real question is how quickly you can make it right. A proper governance program will set up the processes and component inventory to allow more rapid and complete recovery and continuity for critical SharePoint-based applications.

Any IT project goes wrong sometimes. The real question is how quickly you can make it right.

What are some best practices for building a successful SharePoint intranet?

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:

• Understand how knowledge flows within your organization today. Identify gaps and areas for improvement, talk to users about their day-to-day needs, and create a coherent vision for an ideal knowledge flow. Then ask how SharePoint can deliver the capabilities you need to achieve this vision.
• Make education and training part of your intranet development process. SharePoint is a powerful platform. It will empower users with new and better ways to share information, but it can also confuse and intimidate them. Anticipate these changes, and give users the training they need to take advantage of their new tools.
• Get buy-in for your SharePoint development effort. Departments and workgroups place great value upon their ability to control key information and to follow carefully defined business processes. These stakeholders need to be involved from the very beginning of any SharePoint intranet initiative – and the lessons IT organizations learn from this sort of cooperation can extend to other projects,

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.

How do I manage SharePoint access for users working outside our corporate firewall?

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.

I need to present SharePoint 2010 collaboration sites to users who aren’t part of a shared domain. Is there a simple way to do this without forcing them to go through multiple authentication processes?

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.

Why is it better to create pages and document libraries instead of new SharePoint sites?

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.

What is InfoPath and how is it used with SharePoint?

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.

I need to serve very large media files as part of a SharePoint deployment. What are my options?

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.

How much data can I show on a SharePoint display?

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.

How should we prepare for SharePoint 2013?

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:

• Analyze your needs. You won’t really know what code you need until you know which processes and data your business requires. A new SharePoint version is the perfect opportunity to talk with users, engage multiple departments and get real input on how new applications should work.
• Establish governance. Know how you’re going to account for all the changes you’ll make during the upgrade process and decide who will take ownership of these projects. Also ensure that your change management and version control systems are in place and up to date.
• Clean up your act. Weed out unused site collections, and take stock of your content database sizes: For performance sake you don’t want to let databases grow north of 7 gigs. All of this is basic SharePoint hygiene, but if you don’t take care of it beforehand, it will make things much, much more difficult when you migrate.
• Take inventory. Know what you have before you start to bring in the new components. It’s far too easy to dive into development only to realize that you’ve just re-invented a component you already had, or that a stray existing component is fighting against something you just wrote.

 DISCLAIMER
Rackspace® Hosting is the service leader in cloud computing and founder of OpenStack^TM, 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.