You can avoid the penalties of a cold transfer by using Common Internet File System (CIFS) and HTTP prepopulation to warm the SteelHead with data not yet requested by end users. Prepopulation is fully integrated into RiOS 7.0 or later.

The prepopulation of data is extremely beneficial for end users who know of data crossing the WAN: for example, operating system patch updates, antivirus update files, a video training session posted on an internal file server for offline viewing, or a directory of a user share located at the data center.

You configure prepopulation only on the client-side SteelHead. You must configure and connect the client-side SteelHead primary interface properly for prepopulation to work. The primary interface must be able to establish connection with the server.

The primary interface of the SteelHead acts as a client and requests data from the share you want to use to warm the RiOS data store. To warm both SteelHeads, data flows from the server, passes the server-side SteelHead, and ends at the client SteelHead.

The traffic leaves the primary interface and it must traverse a client-side in-path connection (for example, LAN0_0/WAN0_0 for an inline deployment, or WAN0_0 for a logical in-path deployment) before reaching the server-side SteelHead. Prepopulation does not work if the primary interface bypasses client-side optimization first.

This chapter includes the following sections:

CIFS prepopulation uses a flexible scheduler to prepopulate the RiOS data store. When a client on the remote LAN requests data again, only new or modified data is sent over the WAN, which dramatically increases the rate of data transfers. Unlike with Proxy File Service (PFS), the client-side SteelHead drops the actual data files it has received, but it maintains SDR data in the RiOS data store.

Because CIFS prepopulation uses the CIFS/SMB protocol, you can use a Windows machine, or any other CIFS/SMB capable NAS filer, for the file server.

In RiOS 7.0 or later, CIFS shares that require SMB signing are fully supported. Depending on the file server configuration, the authentication for SMB signing can be NTLM or Kerberos, but both methods are supported by CIFS prepopulation. To populate SMB signed CIFS shares, you must join the SteelHead to the domain in which the shares are published or to a trusted domain.

If the file server authentication is NTLM, then you must configure NTLM transparent mode on the server-side SteelHead. If the file server authentication is Kerberos, then you must configure the AD environment that the server-side SteelHead has joined (by creating a replication user account) and configure the server-side SteelHead to support Kerberos.

For more information, see Encrypted MAPI Optimization and Kerberos. For more information about SMB signing, see .

When you create a share using CIFS prepopulation, the SteelHead attempts to connect to the destination server on port 139. You must enable NetBIOS over TCP/IP on a Microsoft Windows machine (server or client) to accept the connection on port 139. On a Windows server, enter the following command to see if it is listening on port 139:

If you do not see similar output with the correct host IP, NetBIOS over TCP/IP is not enabled on the interface. You can enable it on the relevant interface from the WINS tab in the Advanced TCP/IP settings.

In RiOS 8.5 or later, you can create policies and rules for a higher level of control over which files the system transfers to warm the RiOS data store. A policy is a group of rules that select particular files to prepopulate; for example, you can create a policy that selects all PDF files larger than 300 MB created since January 1st of 2013.

Share synchronization begins, based on the parameters you entered.

You can create synchronization policies in RiOS 8.5 or later. Synchronization polices enable you to define granular synchronization using filters for inclusion and exclusion specific data types.

For more information about the CIFS prepopulation CLI commands and configuration, see the Riverbed Command-Line Interface Reference Manual.

This section describes several design considerations.

Prewarming the RiOS data store during off-hours helps to reduce WAN bandwidth consumption during peak hours. When you configure CIFS prepopulation, it tries to use all available bandwidth. If you want to control bandwidth usage with CIFS prepopulation, you can configure QoS so that only a portion of the bandwidth is used for CIFS prepopulation.

For more information about QoS, see the SteelHead Deployment Guide.

In RiOS 7.0 or later, clients can authenticate to servers requiring signing and synchronizing transparently from a Windows 2003 server DFS share.

In RiOS 7.0 or later, you can set the length of time a CIFS prepopulation command is to run. The time is reflected in seconds. You can run a test report on the client-side SteelHead to view the expected changes to be synchronized. A sample report follows:

RiOS 8.5 or later enhances CIFS prepopulation with a new policy-based system available in the CLI and the SteelHead Management Console. You can create specific policies and associate them with the CIFS prepopulation shares previously created.

The use of policies is a function of the client-side SteelHead. When you use policies, you can synchronize files:

An example policy creation follows:

You can delete a complete policy directly or delete a specific rule within a policy with the following command.

HTTP prepopulation, in RiOS 7.0 or later, is an enhanced HTTP-based data delivery method. HTTP prepopulation delivers data to the remote site by using the HTTP protocol to prewarm your RiOS data store. HTTP prepopulation uses the HTTP protocol to read and deliver data. The feature delivers any data content residing on a web server, including on-demand video streams at remote site. Remote users can have an enhanced viewing experience. For more information about video optimization, see the SteelHead Deployment Guide.

HTTP prepopulation requires that you configure and connect the primary interface for full functionality. HTTP prepopulation is only available through the command line. Configuration is only on the client-side SteelHead.

To configure HTTP prepopulation you create a list composed of URLs that contain the data you want optimized. You can configure up to 100 lists, and you can include an unlimited number of URLs within each list.

For example, you can combine URL links to multiple Human Resource training videos in one list named HRvideos. The URL link must reference a filename with an extension in the URL link such as http://www.example.com/video/example.mp4, and not reference a general URL link such as http://www.youtube.com/videoexample.

Figure: Web Server Directory Listing shows a web server directory listing. The HTTP prepopulation functionality recursively downloads the entire folder content.

The following example shows how to configure HTTP prepopulation with the list name HRvideos. List names are case sensitive.

HTTP prepopulation time varies, depending on transfer time. If you want to maintain access to the CLI, Riverbed recommends that you use the job command to run the transfer at a specified time to run the transfer during off hours.

An example of the job command is as follows:

Additional various supporting commands follow:

For more information about HTTP prepopulation commands, see Microsoft Silverlight, Apple HLS, and Adobe Flash and the Riverbed Command-Line Interface Reference Manual.

In RiOS 7.0 and later, the SteelHead supports prepopulation for Microsoft Silverlight On-demand streaming content. In RiOS 8.5 and later, the SteelHead supports prepopulation for Microsoft Silverlight Video, Apple HLS, and Adobe Flash.

To prepopulate video, you must specify the manifest URL containing the manifest file. The manifest file includes information about the different bit rates available, the timeline markers, and so on. Manifest files are generally produced by video encoding software that supports their related format: for example, the Microsoft expressions encoder for Microsoft Silverlight is MP4.

In RiOS 8.5 and later, you can specify a URL (as opposed to specifically referencing the manifest file in the URL link as in previous RiOS versions). RiOS 8.5 and later automatically:

You need a browser plug-in on the client machine to play and watch the video. For example, Microsoft Silverlight is compatible with Internet Explorer, Firefox, and Safari.

The Microsoft Silverlight manifest file is an XML file, with a .ISM extension, that describes the live or on-demand video presentation. The Apple HLS manifest file is a text-based manifest file with a .M3U8 or .M3U extension that directs the player to additional manifest files for each of the encoded streams. The Adobe HTTP Dynamic Streaming manifest file has a .F4M extension.

To configure HTTP prepopulation, use the following commands on the client-side SteelHead: