Windows Media Services is an optional component in Windows Server 2003 family of operating systems. Being an optional component, Windows Media Services is not installed by default, but is easy to add by using the Add/Remove Windows Components feature in Control Panel. You should be aware that an expanded set of features is available for Windows Media Services in the Enterprise and Datacenter editions of Windows Server 2003, as the following table explains.
Feature | Windows Server 2003, Standard Edition | Windows Server 2003, Enterprise Edition | Windows Server 2003, Datacenter Edition |
Advertising server support |
|
|
|
Cache/proxy server support |
|
| |
Unicast content delivery |
|
|
|
Multicast content delivery |
|
| |
Control protocol support (MMS, HTTP, RTSP) |
|
|
|
Wireless streaming optimizations |
|
| |
Authorization methods (NTFS, ACL, IP Address) |
|
|
|
Internet authentication (Digest) |
|
| |
Intranet authentication (Negotiate authentication, Anonymous access) |
|
|
|
Playlist parser support (SMIL 2.0, Directory) |
|
|
|
Media parser support (Windows Media, MP3) |
|
|
|
Custom plug-in support |
|
| |
Event notification (WMI, SNMP) |
|
|
|
Event-based scripting support |
|
| |
Fast Cache |
|
|
|
Fast Start |
|
|
|
Fast Streaming |
|
|
|
Fast Reconnect |
|
|
|
Fast Recovery |
|
| |
RTSP streaming |
|
|
|
Internet Protocol version 6 (IPv6) support |
|
|
|
Server based content repacketization |
|
|
|
Cache and proxy servers are servers that run Windows Media Services and include a third-party cache/proxy plug-in. Because a single server can perform both caching and proxying, they are usually indicated as cache/proxy servers. Cache/proxy servers act as “middle men” to receive content from an origin server and pass it along to the clients that requested it.
Why are cache/proxy servers important? Because an Internet site that draws customers from around the country or across the globe cannot always service all requests from a central location. Bandwidth can be consumed rapidly with all requests feeding in to one server or server cluster, and data can be lost or bogged down when it has to travel long distances, especially over slower network segments.
As indicated by its name, a cache/proxy server has two functions: caching and proxying. Let’s begin with caching.
Caching is a way of temporarily storing frequently requested on-demand content in a place where it is easily accessible. For example, each time a user visits a favorite Web page, a copy of that Web page is saved on the user’s computer where it can be retrieved and displayed quickly. This is an efficient way of delivering data because it greatly reduces access time, which enables you to get the content to the user who requested it without delay.
Caching is also effective for streaming, especially for large enterprises with satellite offices, content delivery networks (CDNs), or Internet retailers with a national or international Web presence. These types of organizations usually maintain multiple servers that are scattered about the country or around the world. The location of these servers depends on where the users are. For example, a U.S. shipping company based in Los Angeles might have offices in New York, New Orleans, San Francisco, and Seattle. While the company does maintain a bank of Windows Media servers in the Los Angeles headquarters, it doesn’t make sense for employees in New York or New Orleans to access those servers when they need information. The distance from point A to point B is far enough that users might experience latency when attempting to access the content. And if multiple users are accessing the content at the same time then much of the interoffice bandwidth will be consumed.
Instead, our shipping company would place a server or set of servers in each of these locations, as close to the users as possible. These servers are often called “edge servers” because they are on the edge of the company’s network. Some data from the origin servers in Los Angeles, such as line-of-business applications, would then be replicated to the edge servers. Other data, such as a corporate training video, would be cached. The caching process might work like this:
A user at a remote location requests content from the closest edge server.
The edge server checks its cache to determine whether the requested content is there. If it is, and if it’s up to date, the content is delivered to the user. If it isn’t, the edge server contacts the origin server to request the content.
The origin server delivers the content to the edge server.
The edge server delivers the requested content to the user and saves a copy in its cache. The next user who requests the content will receive it from the cache, and no additional connections to the origin server are required. The content remains in the cache until its expiration date.
The other half of the cache/proxy story is the proxy server. A proxy server is used to request content from an origin server and deliver it to a client computer. The process is very similar to caching, except that the content can be live or on-demand, and no files are cached. When a client computer requests a live stream from the proxy server, the proxy determines whether it is already proxying the live content. If not, it contacts the origin server to request the stream and then proxies the stream to the client that requested it. When additional clients request the stream, the proxy server can split the stream for each client. In this way, there is only one connection between the cache/proxy server and the origin server.
Windows Media Services does not offer a cache/proxy solution out-of-the-box. Rather, it supports caching and proxying content through the use of third-party plug-ins. Developers can build custom cache/proxy solutions by using the Windows Media Services SDK.
Windows Media Services runs under the Network Service user account. This is a change from Windows Media Services version 4.1 in Windows 2000 Server. In that version, Windows Media Services created its own administrator account with administrator rights and permissions to access system resources.
The Network Service account is a predefined local account that first appeared in the Windows XP operating system. Services that are running under the Network Service account can access network resources by using the credentials of the computer account. The Network Service account has minimal privileges on the local computer. This prevents someone from using the account to gain access to protected resources on your system. The Network Service account does not have a password associated with it.
Because Windows Media Services uses the Network Service account credentials to respond to authentication requests from other resources, the Network Service account must have the appropriate permissions in the access control lists (ACLs) of any files, folders, data sources, or other items to which Windows Media Services will read and write data. For example, if you are going to write log file information to a network location that is different from the default location, you must grant the appropriate permissions to the Network Service account for that location for Windows Media Services to write log files successfully. The Network Service account has the appropriate permissions for the default folder, WMRoot.
Windows Media Services 9 Series is completely customizable. This customization is possible because of the plug-in architecture. A plug-in is an auxiliary software component that extends or enhances the features of other software, in this case the server. Many of the features of Windows Media Services are implemented through plug-ins, and you can enable or disable those plug-ins to establish the feature set that you want to use.
Plug-ins enable you to perform a wide range of tasks, including protocol handling, data parsing, authentication, authorization, and archiving. You can apply a plug-in to either an entire Windows Media server or to a specific publishing point on the server by enabling the plug-in at the appropriate level. You can also modify the plug-in settings for each server or publishing point you are managing.
Windows Media Services plug-ins are divided into categories by function. Each category contains several types of plug-ins. The table at the end of this chapter describes the plug-in categories.
Third-party or custom plug-ins, such as cache/proxy solutions discussed earlier, also extend the functionality of Windows Media Services. These plug-ins enable you to implement customized streaming solutions such as multiple streaming formats, customized logging applications, and specialized data storage. A list of third-party plug-ins for Windows Media Services is available on the Windows Media Partner Center page at the Microsoft Web site (http://www.microsoft.com/windowsmedia).
Plug-in category | Description |
Archiving | Used to archive content that is being streamed from a broadcast publishing point to a file. |
Authentication | Used to validate client credentials before any content is sent to the client. |
Authorization | Used to grant or deny client access to content. |
Cache/proxy management | Used to control cache and proxy policies on your computer. |
Control protocol | Used to control the data sent between clients and servers. |
Data source | Used to receive data from an encoder, file system, or network source. |
Event notification | Used to control and customize how the server responds to internal events. |
Logging | Used to record server and client activity. |
Media parser | Used to allow the server to translate different digital media file types or real-time streams. |
Multicast streaming | Used to control the delivery of content through multicast transmission. This plug-in must be configured for each publishing point that is going to use multicast delivery. |
Playlist parser | Used to allow the server to translate different playlist types. |
Playlist transforms | Used to change the manner in which content is streamed from a playlist or directory. |
Unicast streaming | Used to control the delivery of content through unicast transmission. |