*
Windows Media Player 9 Series*
Results by Bing
|Windows Media Worldwide

Sourcing Content from Remote Storage

Bill Birney and Rob Van Schooneveld
Microsoft Corporation
September 2003


Introduction

The default location for storing content that you want to host on a Windows Media server is the local hard drive of the server computer. To make content available for streaming to users, a folder or file on the drive is mapped to an on-demand publishing point. This method of storing content works for many streaming media sites. However, local storage has its drawbacks if a streaming site does one or more of the following:
  • Hosts many concurrent connections. In addition to processing many concurrent streaming requests, the server must handle basic hard disk I/O operations and other operating system tasks. This can lead to high memory and CPU usage, and result in a slow response to client requests or even dropped connections.
 
Abstract
You can save Windows Media content on a file server or storage device and then host the content on a Windows Media server. By using basic folder and file sharing, you can store content remotely in order to help manage and administer content. This article describes different remote storage solutions and how to configure them.
  • Hosts many large files. The local hard disk may simply not be large enough for the number and size of source files. With one local drive handling all server tasks there may also be no provision for fault tolerance. If the drive fails, so does the server, operating system, and all the content.


  • Draws content from many sources. In many scenarios, the volume of users accessing content may be low to moderate, but administering one centralized server may not be the most efficient way to manage content.
In a heavy streaming scenario, there are a number of drawbacks to local storage. Solutions that use SCSI devices, such as external RAID arrays, work fine to a point. However, a number of very high volume Internet sites have turned to network attached storage (NAS) and Storage Area Network (SAN) solutions to provide the scale they need to handle the volume now and in the future.

This article describes three remote storage solutions (remote file servers, NAS appliances, and SAN systems), and how to configure Windows Media Services to host content stored on a remote device. We will also briefly compare the devices. For a complete comparison and information about using and configuring the devices, consult the documentation for a specific hardware device or system.

This article contains the following topics: Back to the top of this page Back to the top


Sourcing from a Share

When a Windows Media server streams on-demand content, the WMS File Data Source plug-in is used to access the file. As far as the operation of the server goes, the location of the file does not matter as long as the data source plug-in can access the data and the other plug-ins can read the data and output a continuous real-time stream. The server can access and stream files from the local NTFS file system just as easily as a share on a remote server. The main difference between hosting from local and remote shares is how the two are configured. Setup can be more difficult because you must also consider security over a network and how to connect between a Windows operating system and another device, which may be running on an operating system with an incompatible security model.

Unlike an external SCSI drive, remote storage systems access data over a network, sometimes the same network that the server uses to deliver content to users. The network can be shared by multiple users in a domain or workgroup, or it can be a private network that consists of storage devices and a front-end server. Regardless of where the file is, you configure publishing points on a Windows Media server to source from a remote storage device using a Universal Naming Convention (UNC) path or drive path. The main disadvantage of remote storage over a SCSI device is access speed. However, in many situations the advantages of remote storage far outweigh those of SCSI devices, such as the ability to easily scale to multiple devices capable of storing terabytes of data, and to share data between multiple servers.

The three main types of remote storage solutions that are appropriate for streaming with Windows Media Services are:
  • Remote file server. Typically, a computer running Windows 2000 Server or Windows Server 2003. However, other operating systems that have compatible authorization systems, such as Windows XP Professional, can be used. One advantage of using this method for storing files is that the computer can be used to run other services. For example, a file server in an enterprise could be used to host Windows Media files for a remote Windows Media server as well as a department intranet Web site.


  • NAS appliance or device. This device is essentially a file server that has been built into a dedicated appliance. A NAS device does not run Web services or host domains, but it connects to a network the same as a computer running Windows. Because NAS devices are dedicated, they typically handle the hosting of files more efficiently. The devices are often capable of scaling to several terabytes of storage capacity.


  • SAN system. A SAN is a system of components connected through a private high-speed fiber network, which uses the Fibre Channel (FC) protocol to route data between storage devices and servers. Most SANs are highly scalable and extensible, enabling the sharing of data among multiple devices. The distance between devices in a SAN is limited by properties of the fiber network.
If you are investigating all possible remote storage solutions, you should also consider the distribution method and cache/proxy plug-ins. With both methods, content is sourced from a remote Windows Media server. For more information, see Windows Media Services Help.

Back to the top of this page Back to the top


Remote Storage Scenarios

To help you understand remote storage, we will look at two scenarios: a distributed enterprise and high-volume commercial site. Figure 1 shows the topology of the distributed enterprise scenario.

Topology for distributed enterprise
Figure 1. Topology for the distributed enterprise scenario

In this scenario, remote servers in the marketing, training, and media production departments of an enterprise connect to publishing points on a centralized Windows Media server located in a perimeter network (also known as a DMZ). The server is connected through a firewall to the Internet, enabling remote retail, training, and branch office users to stream content.

Assuming the server receives low to moderate concurrent connections, it is possible to use one server computer with a modestly-powered CPU and comparatively small hard disk because most of the content is stored remotely on file servers. Content management can easily be handled locally in the departments, rather than having to synchronize and maintain files on the centralized server. In a large corporation, administrative access to the central server may be restricted to users in the IT department, but content can still be managed by users in the remote departments.

In this scenario, the remote file servers are computers running a Microsoft Windows operating system, such as Windows 2003 or Windows XP Professional. However, one or more remote devices could just as easily be NAS appliances. To a Windows Media server, a share on a NAS device is no different than a share on a computer. The initial configuration of security options on a NAS device can be more complicated if it runs on an incompatible operating system. However, a particular model may offer features that would give it the advantage over a file server in high-volume scenarios.

An advantage of a remote device or server over a local or external SCSI hard drive is distance. A SCSI system is limited by the length of the cabling and number of devices in the chain. A remote device, on the other hand, can be located any place that is reachable by an Ethernet cable. Also, with a SCSI device the server computer must be able to handle disk I/O operations in addition to running the operating system, services, and all the related tasks. By using a NAS device or file server, all disk and file hosting operations are handled outside the server.

The other scenario uses a SAN system. A SAN has many of the advantages of a SCSI system because the storage is connected through a dedicated, high-speed network. However, one disadvantage is that there is a distance limit of 10 kilometers. Figure 2 shows the topology of the high-volume commercial site.

Topology for high-volume commercial site
Figure 2. Topology for the high-volume commercial site scenario

Three Windows Media servers are connected by using Network Load Balancing (NLB), which offers load balancing, and enhanced availability and reliability. The servers are connected through a firewall to the Internet, and to a SAN. The SAN can provide high-speed access to large numbers of large files. The SAN is secure because it is a private network, and the storage device or devices can contain many terabytes of data in configurations that provide a high degree of fault tolerance.

Solutions Summary
A file server, running on Windows Server 2003 for example, can host a good deal of content and provide you the advantage of being able to run additional services, such as Internet Information Services (IIS), on the same computer. Such a system is appropriate if you anticipate low to moderate demand.

A NAS device does not enable you to run additional services, but because it is a dedicated appliance, it can provide better performance and more storage for hosting files. NAS devices connect to a network in the same way as a Windows Server computer, and offer a variety of configuration options.

Although NAS devices and file servers can be set up on a network fairly quickly and easily, a SAN is typically more costly and requires more time and expertise to configure. The advantage is that a SAN is more like a local hard disk in that content is accessed at the data block level. Content on a NAS and file server is accessed at the file level.

NAS devices and file servers deliver data to clients; SAN systems deliver data to servers. NAS grew out of a need for a larger, faster, and more reliable file server solution; SANs grew out of a need for a larger, faster, and more reliable storage solution. In many ways, the goals of both technologies are the same. They just approach the problem in different ways. A NAS is often thought of as an entry-level storage device, but a SAN is traditionally thought of as a large, expensive, advanced, centralized system. There may be some validity to these categorizations, however, NAS devices are becoming more powerful and SAN systems are becoming less centralized and complicated to work with. Many believe that the future for remote storage is a hybrid NAS/SAN system that consists of a NAS front-end for file handling and a SAN back-end for managing storage.

These scenarios are also used to describe how to use remote storage with IIS in the white paper "Deploying and Configuring Internet Information Services (IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices." This paper provides details about configuring and tuning IIS servers, and can provide additional help when configuring Windows Media Services.

Back to the top of this page Back to the top


Configuring Remote Storage

In order to host remote content on a Windows Media server publishing point, you need to configure the following areas on the remote device and server: Security
Understanding how authentication and authorization works between a Windows Media server and a file server or remote storage device can help you quickly and correctly configure the system. Typically, after you initially configure security, you should not have to do it again.

The process that Windows Media Services uses for authentication and authorization takes place in the following two steps, regardless of where the content is located:
  1. The Windows Media server uses impersonation to log the user on to a folder or file with the WMS NTFS ACL Authorization plug-in.
  2. If the user is authenticated, the Windows Media server logs on by using a local account (NETWORK SERVICE) to access the content.
This process works by default when the content is stored locally. However, when the content is stored remotely, two changes need to be made: ACL authorization must be disabled, and permissions must be set on the remote share. The following topics describe these tasks.

Disable ACL Authorization
To disable ACL authorization, you must first disable the WMS NTFS ACL Authorization plug-in, which is enabled by default at the server level. Then enable the plug-in on each on-demand publishing point that does not source from a remote share. The NTFS ACL plug-in is not used when sourcing from other Web or Windows Media servers using the HTTP or RTSP protocols. The plug-in is also not used by broadcast publishing points, even if the source is a file or folder on a remote storage device. Therefore, if you are using a Windows Media server, for example, to distribute content from a remote Windows Media server, or as a cache/proxy server, or to host content stored locally, or to host content stored remotely through a broadcast publishing point, you do not need to disable the NTFS ACL Authorization plug-in.

When the NTFS Authorization plug-in is enabled, Windows Media Services attempts to use the credentials of the requesting client to authenticate the client on the remote content share. Some authentication methods, such as NTLM, do not support delegation. Therefore, attempts to authenticate clients using these methods will fail. This can result in a user being prompted repeatedly for credentials, even though valid credentials have been entered. With the plug-in disabled, the server does not attempt to authenticate the users on the remote share. Therefore, all users can access remote content through the publishing point.

If you want to restrict access to the content, you can enable the Publishing Point ACL plug-in, IP Authorization plug-in, or a custom authorization plug-in (supported on computers running on Windows 2003 Server, Enterprise Edition) the publishing points that source from the share.

Set permissions on the remote share
If the server and remote device are in the same domain, the preferred method is to add the Windows Media server computer account (for example, WmServer01) to the remote share and give it read permission. With this method, any service or process running under the NETWORK SERVICE account on the server will have access to the remote share. However, users logged on to the server will not be able to access the share directly, unless they too are given permission.

If the server or remote device or both are in a workgroup, the preferred method is to create new local user accounts with the same name and password on both devices. Configure Windows Media Services to run under the new account, and give the account read permissions on the remote share. The Network Service account, which Windows Media Services runs under by default, cannot be used in this way because it is a special built-in local account.

Caching
When streaming from a file on the local hard disk, the file system cache manager buffers blocks of the file in memory. This helps improve performance and latency by reducing the need to access the hard disk. However, when accessing content on a remote share, file system caching will not always occur, because Windows Media Services opens files in sharing mode by default. Sharing mode allows other applications to read, modify, and delete files while the files are in use by the server. This makes it easy to update files, for example. However, in many cases, the increase in performance provided by caching can outweigh the advantage of being able to update files at any time.

In sharing mode, the server caches only a number of the most requested files. You can configure the server to cache all files by disabling sharing mode. You do this by adding a property and value to the servernamespace file. After sharing is disabled, other applications cannot modify or delete a file as long as it is being accessed by the server. For example, you must wait until no users are streaming a file before you can update it.

Note: Caching requires that a server computer has adequate CPU speed and memory to handle buffering large amounts of data. Before enabling caching, make sure you determine the effects on overall server performance and the user experience.

Back to the top of this page Back to the top


How to configure security

This section describes the basic processes that you can use to configure security for remote storage on a number of devices and in various network environments. Setup procedures will vary depending on the model of storage device or system, and the network configuration. After security has been configured properly, the publishing point can stream from the remote server or device. This section provides procedures for the following two scenarios: Server and Remote Device in the Same Domain
The following procedure describes how to configure security, if the server and remote device are authenticated on the same domain:
  1. On the remote device, open properties for the shared folder.
  2. In permissions for the share, add the name of the Windows Media server computer object (such as WmServer01), and give the computer read access only. Remove any other computers, users, and groups that do not require access to the share.
  3. On the server, open the Windows Media Services snap-in, and connect to the Windows Media server.
  4. On the Properties tab for the server, disable the WMS NTFS ACL Authorization plug-in.
  5. Add an on-demand publishing point, and enter the remote share as the source by using a UNC path, such as \\RemServer\RemShare.
  6. In Properties for the publishing point, enable the WMS Publishing Point ACL Authorization plug-in, and set permissions for access to the publishing point.
  7. Enable the WMS NTFS ACL Authorization plug-in individually on all other publishing points that do not source from a remote share.
Server, Remote Device, or Both in Workgroups
The following procedure describes how to configure security, if the server and remote device are authenticated in a workgroup:
  1. On the remote device and Windows Media server identify or create a user or group account that is common on both computers, such as WMServer. Give the common account the same password on both computers.
  2. On the remote device, open properties for the shared folder.
  3. In permissions for the share, add the user, WMServer, and give the user read access only. Remove any other computers, users, and groups that do not require access to the share.
  4. On the server, open the Services MMC snap-in, and then open Properties for Windows Media Services.
  5. On the Log On tab, change the account that Windows Media Services runs under to the common user, WMServer.
  6. Give the common user appropriate permissions on folders, services, registry keys, and processes that Windows Media Services logs on to, including the following:
    • Read permission on the sources of all on-demand publishing points, including the default folder WMPub.
    • Read permission on the following registry key, in order for anonymous username, distribution, and proxy credentials to be read:
      HKLM\Software\Microsoft\Windows Media\Server\Namespace\Storage
    • Write and modify permissions on the folder and subfolders of: %windir%\system32\windows media\server.
    • If logging is enabled, write and modify permissions on the folder: %windir%\system32\LogFiles\WMS.
    • If archiving is enabled, write and modify permissions on the folder: %systemdrive%\wmpub\WMArchive.
  7. Restart Windows Media Services.
  8. Open the Windows Media Services snap-in, and connect to the Windows Media server.
  9. On the Properties tab, click the Authorization category, and then disable the WMS NTFS ACL Authorization plug-in.
  10. Add an on-demand publishing point, and enter the remote share as the source by using a UNC path, such as \\RemServer\RemShare.
  11. In Properties for the publishing point, enable the WMS Publishing Point ACL Authorization plug-in, and set permissions for access to the publishing point.
  12. Enable the WMS NTFS ACL Authorization plug-in on all other publishing points that do not source from a remote share.
Back to the top of this page Back to the top


How to Configure Caching on the Remote Share

To improve performance, you can disable sharing mode on the remote share, which enables the Windows Media server to cache content in local memory. The following procedure describes how to disable sharing mode on the server:
  1. Open the Windows Media Services snap-in, click the server name, and then on the Action menu, click Stop.
  2. Locate the namespace file for Windows Media Services, ServerNamespace.xml, and open it in a text editor such as Microsoft Notepad. The default location is %SystemRoot%\system32\windows media\server\.
  3. Locate the WMS File Data Source node in the namespace, and then expand the Properties node.
  4. Add the following line to the Properties sub-node:
<node name="Only File Read Share" opcode="create" type="int32" value="0x1" />
  1. Save and close the file.
  2. Open the Windows Media Services snap-in, click the server name, and then on the Action menu, click Start.
Warning: Before you edit the namespace file, verify that you have a backup copy of the original that can be used to restore the server to its previous condition if a problem occurs with the new configuration. If you edit the namespace file incorrectly, you can cause serious problems that may require you to reinstall any product that uses the namespace. Microsoft cannot guarantee that the problems that result if you incorrectly edit the namespace can be resolved. Edit the namespace at your own risk.

Back to the top of this page Back to the top


For More Information

Back to the top of this page Back to the top


Legal Notice

Portions, Copyright © 1994-2000 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved. http://www.w3.org/

Back to the top of this page Back to the top



© 2014 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy Statement
Microsoft