Digital asset library topology and architecture (SharePoint Server 2010)


Applies to: SharePoint Server 2010

Topic Last Modified: 2011-09-26

This article discusses logical architecture and topology decisions that are related to deploying digital asset libraries. For information about managing digital assets, see Managing digital assets overview (SharePoint Server 2010).

The Microsoft SharePoint Server 2010 asset library, which is a kind of document library, is a collection of media files — such as image, audio, and video files — that are shared with other site users. Because the asset library is nothing more than a SharePoint Server library with specialized content types for digital assets, the overall architecture and topology is minimally affected. The factors that can potentially influence logical architecture and topology decisions include the following:

  • The placement of digital asset libraries in the overall site structure.

  • The relationship between digital asset libraries and content databases in the logical architecture.

  • Optimizing a server farm with a binary large object (BLOB) cache or with Bit Rate Throttling.

  • Scaling out a server farm with dedicated databases or server hardware for digital assets, if it is necessary, to accommodate a large volume of digital assets.

In this article:

The core element of managing digital assets in SharePoint Server 2010 is the asset library. You can add the asset library to any site, at any level within your solution. However, if you will be storing a large total volume of data, such as thousands to tens of thousands of files in an asset library, or audio or video files that in total require hundreds of gigabytes of storage space, you must carefully plan for the location in which the asset library is created and in which assets will be stored.

For example, if you have a collaboration site in which multiple individual teams each have their own sites but have to use a shared set of media, you might create an asset library at the top-level site to store the assets that will be used by the individual teams. In this scenario, the content database is shared by all sites within the site collection, so the quantity and size of the files that are stored in the asset library might be significantly smaller than in the previous example.

The following figure shows an example of the logical architecture for when an asset library is put at the root of a site collection and shares a content database that has other sites in the site collection.

Single site collection

As another example, for a large corporate training site which will contain training videos used by internal employees, you might place the asset library in the top-level site of a site collection that uses its own content database, and that has no other sites under it in the site hierarchy. By doing this, you can ensure that there is sufficient storage space for the files that will be uploaded to the asset library. This also lets you plan for future expansion, because the content database is already isolated by itself, and does not share content with any other sites in your solution.

The following figure shows an example of the logical architecture for when an asset library is put in a separate site collection with a content database that is separate from the rest of the sites:

Two separate site collections

The following table summarizes these two approaches. Note that you can implement a combination of these two approaches.


Area Single site collection Separate site collection


A digital asset library is contained within the same site collection as other content. Multiple digital asset libraries can be created within the site structure.

A separate site collection is deployed to host a digital asset library.


Teams can add digital asset libraries to their team sites or use the library contained at the top-level site.

Teams add and use media files from the centrally managed digital asset library.

When using a publishing site, the URL for an asset library in a separate site can be added to the Suggested Content Browser Locations list for the publishing site. This will enable content creators to access the asset library when they insert assets into Web pages within SharePoint Server 2010, or within Microsoft Office 2010 suite applications, such as Microsoft Word.


Teams manage their own libraries. Media files are managed in the same manner as all other content in the site collection.

Because media files reside in a separate database, this content can be managed separately and according to a different service level agreement.

Performance and capacity

A large total volume of media files can affect the overall performance of sites. If site collections approach or exceed database size limits, it is more difficult to scale out the overall server farm.

Because media files reside in a separate database, the database can be scaled out to dedicated hardware, if it is necessary, to reduce the performance effect this contact has on the rest of the server farm.

When you plan to incorporate the management of digital assets into your solution, you should carefully consider the quantity and size of the files that will be stored and also how they will be used. This will help you design your site architecture when you determine where the asset library should be located.

Digital asset library topologies use the same elements as any standard SharePoint topology, such as Web servers, application servers, and database servers. Components that are specific to managing digital assets are put in certain locations within the topology, but they do not change the overall structure of the topology. The following are components about which you must make configuration decisions for your digital asset library topology:

  • BLOB cache   The disk-based BLOB cache controls the caching for binary large objects (BLOBs), such as frequently used image, audio, and video files, and other files that are used to display Web pages, such as .css and .js files. The BLOB cache should always be enabled if your solution will include asset libraries, and is enabled on every front-end Web server in a server farm.

  • Bit Rate Throttling   Bit Rate Throttling is an Internet Information Services (IIS) 7.0 extension that meters the download speeds of media file types and data between a server and a client computer. Bit Rate Throttling can be enabled on every front-end Web server in a server farm, and it should always be enabled if your solution will include audio or video files in asset libraries. For more information, see Bit Rate Throttling (

  • Maximum file upload size   The maximum upload file size is a setting that is used by the SharePoint Server 2010 Web application that specifies the maximum size of a file that a user can upload to the server. The maximum file upload size is configured for every Web application on the server that hosts Central Administration, and should be adjusted to accommodate the size of files that will be uploaded to asset libraries.

For more information, see Plan for caching and performance (SharePoint Server 2010).

If your digital asset library solution will be used to store a very large amount of content, you should consider using Remote Blob Storage (RBS) to move the storage of large binary data (BLOBs) from Microsoft SQL Server 2008 to an external storage solution. RBS is not a feature of SharePoint Server 2010 or Internet Information Services (IIS) 7.0. For more information, see Overview of RBS (SharePoint Server 2010).

This section shows components that can affect the overall server farm topology.

Digital asset libraries work well with any server farm topology that is supported by SharePoint Server 2010. The server farm can be a single server, a small server farm, or a large server farm.

When you decide to deploy BLOB cache or Bit Rate Throttling, you must deploy them to Web servers:

  • BLOB cache is enabled in IIS 7.0 and stored on every front-end Web server.

  • If Bit Rate Throttling is used, it must be installed and configured in IIS 7.0 on every front-end Web server.

Additionally, the server that hosts the Central Administration Web site is used to configure the maximum file upload size for each Web application it contains.

Depending on the size of your server farm and the kind of solution that you are implementing, you might have additional servers that are designated for specific roles, such as Search databases, or query and index servers.

The following illustration shows a typical three-tier server farm topology with components added for a digital asset library topology:

Basic farm topology for digital asset management


Callout Element


Front-end Web servers, each with their own BLOB cache and Bit Rate Throttling enabled (if applicable).


Application server that runs Central Administration. The maximum file upload size is specified for each Web application in Central Administration.


Database servers that contain one or more content databases.

When planning and scaling a solution that includes digital asset libraries, the two main factors that you must consider are capacity planning and performance. Because video and audio files can be much larger than images or other kinds of files, you will potentially reach storage capacity more quickly with them than you would without them. And depending on the number of users who must access these files at any time, the rate at which requests for the files are made to the server and then sent to the client browser will affect network performance.

For example, if you plan to use an asset library for storing training videos, you must consider the average size of each video, and the estimated total number of videos that will be needed for your organization. You must also consider the number of users who will view the videos, and which videos are likely to be requested most frequently.

For each main component in a digital asset library topology, consider the following issues:

  • Database storage   Is there sufficient storage capacity on the content database servers for all the files that users will upload? It is important to understand the average size of the files and the number of files that you expect the users will upload to the server.

  • BLOB Cache storage   Is there sufficient storage capacity on the front-end Web servers for the files that will be cached?

  • Remote BLOB storage (RBS)   If you will have large volumes of content, you should consider using RBS to move storage of BLOBs out of the content database and into an external storage solution. For more information, see Overview of RBS (SharePoint Server 2010).

The logical architecture of your digital asset library plan will influence options for scaling out a server farm. If a digital asset library is contained in a dedicated site collection, you can easily move the database to a dedicated server, if it is necessary, to improve capacity and performance.