Windows Media Services 2008 FAQ

Applies To: Windows Server 2008, Windows Server 2008 R2

This document provides answers to the following frequently asked questions about Microsoft® Windows Media® Services 2008.

What protocols can I use to stream to Windows Media Player?

Why can't Windows Media Player stream content from my server by using the MMS connection URL?

How do I configure Windows Media Services and IIS to use the HTTP protocol on the same server?

Can I stream content from a Web server?

What file formats can I stream using Windows Media Services?

How can I convert my digital media files into file formats that Windows Media Services can stream?

What is the difference between encoder push and encoder pull?

What is the difference between proxy and reverse proxy?

How do I configure a Windows Media server as a proxy?

How do I configure a Windows Media server as a reverse proxy?

Why can't clients stream some of my MP3 files?

How can I control access to my content?

How can I tell if clients are having difficulty accessing my content?

How can I tell if a client received all the streaming data?

Why do unicast clients buffer my streams?

Why do multicast clients buffer or drop frames from my streams?

How much network bandwidth will my Windows Media server use?

How can I modify my existing Windows Media network to deliver more streams?

What other optimizations can I perform on my Windows Media network to improve scale and performance?

Why should I use Windows Media Services on Server Core installations of Windows Server 2008?

Is there an SDK for Windows Media Services 2008?

Where can I get help with Windows Media Services?

What protocols can I use to stream to Windows Media Player?

The Windows Media protocol reference identifies which streaming protocols can be used to deliver digital media content, depending upon the version of Windows Media Player and the version of Windows Media Services that you are using.

Why can't Windows Media Player stream content from my server by using the MMS connection URL?

Windows Media Player may be unable to stream your content for one of the following reasons:

• The Player successfully selected a streaming protocol during protocol rollover, but the control protocol plug-in for the selected streaming protocol (either RTSP or HTTP) is not enabled in Windows Media Services. Note that the WMS HTTP Server Control Protocol plug-in that manages HTTP streaming is disabled by default in Windows Media Services.

• The Player successfully selected a streaming protocol during protocol rollover, but Windows Media Services cannot deliver the content through your firewall. For more information about how to open ports on your firewall for the streaming protocols that might be selected during protocol rollover (either RTSP or HTTP), see Firewall Reference for Windows Media Services 2008.

• The Player cannot use protocol rollover to select a streaming protocol because streaming protocols and proxy settings are not configured correctly on the Network tab in the Player. For more information, see Which protocols does Windows Media Player use for streaming?

• The Player is using the correct streaming protocol, such as HTTP, but the Windows Media server is configured to use a different, non-standard port for the protocol.

How do I configure Windows Media Services and IIS to use the HTTP protocol on the same server?

If you set up Windows Media Services to stream content by using HTTP on a Web server that is running Internet Information Services (IIS), both services will try to bind to port 80. You can avoid this conflict by changing the port that Windows Media Services uses for HTTP streaming.

As an alternative, you can create multiple IP addresses on a single network adapter and then assign separate port 80 addresses to these IP addresses. You must then configure Windows Media Services and IIS to bind to different IP address/port 80 combinations.

For more information, see Using HTTP for Streaming and Downloading from the same computer.

Can I stream content from a Web server?

A Web server is not designed specifically for streaming the file formats that are supported by Windows Media Services. When a client requests digital media from a Web server, the Web server downloads the content to the client as fast as the network will allow without monitoring the quality of the delivery and adjusting the bit rate for the client in the way that a Windows Media server does. A client can start to play the content as soon as enough data is downloaded to its Internet cache (this is referred to as "progressive downloading"). To compare the delivery methods and bandwidth-management capabilities of Windows Media and Web servers, see Windows Media server or Web server?

What file formats can I stream using Windows Media Services?

Windows Media Services can stream the following file types:

• Windows Media Audio (WMA)

• Windows Media Video (WMV)

• Advanced System Format (ASF)

• MP3

• Windows Media playlist (WSX)

You can also add JPEG-encoded images as interstitial advertisements in a Windows Media playlist for unicast streaming.

The content must meet the minimum supported content length of the Windows Media Player to ensure reliable playback. The minimum supported content length for Windows Media Player 9 Series or later or a player that uses the Windows Media Player 9 Series ActiveX control is 5 seconds. The minimum supported content length for earlier versions of Windows Media Player is 30 seconds.

How can I convert my digital media files into file formats that Windows Media Services can stream?

There are a wide variety of digital media file formats, but Windows Media Services cannot stream all of them. In certain cases, you may need to convert your digital media files into a compatible format before they can be streamed. Microsoft Expression Encoder is a powerful production tool that can convert prerecorded and live audio and video into Windows Media files or streams. You can use the encoder to capture audio or video from devices installed on your computer and then convert the captured content to a Windows Media file for distribution.

What is the difference between encoder push and encoder pull?

To accommodate the widest possible range of streaming conditions, Windows Media Services can receive content from an encoder by using two different methods: push and pull.

When an encoder "pushes" content to Windows Media Services, the encoder controls the Windows Media server and the broadcast stream. The encoder can also create a new publishing point on the server and set the publishing point to delete itself when the broadcast is finished. To use the encoder to push a broadcast to a Windows Media server, the encoder administrator must have the Windows Media server name, the server URL, and permissions to access the server. In addition, the WMS HTTP Server Control Protocol plug-in must be enabled on the server. Encoder push is useful for live encoding scenarios and in situations in which you must maintain control of the broadcast at the content source.

When Windows Media Services "pulls" the content from an encoder, the server connects to an encoder stream that is already in progress. Encoder pull is useful if a publishing point is set to start when the first client connects to it or if the Windows Media server is separated from the encoder by a firewall. In an encoder pull configuration, the encoder must already be started and encoding content before the Windows Media server can connect to it. The server publishing point must use the encoder URL as its content source.

What is the difference between proxy and reverse proxy?

A proxy (also called a "forward proxy" to distinguish it from a reverse-proxy) is a client-facing proxy that acts as an intermediary for outbound traffic from a Local Area Network (LAN) to the Internet. When clients request Windows Media-based content from the Internet, the proxy evaluates the request according to its filtering rules. If the request is validated by the filter, the proxy provides the resource by connecting to the relevant server and requesting the content on behalf of the client. If the proxy has cached a copy of the requested content, it can fulfill the client request without contacting the specified server. This reduces startup latency and saves bandwidth on the client's connection to the Internet.

By contrast, a reverse proxy is an Internet-facing proxy that manages inbound traffic to (typically) Windows Media servers in a Content Delivery Network (CDN). Requests from the Internet for content stored on one of the Windows Media servers are routed through the reverse proxy, which fulfills the request itself if it has cached a copy of the requested content. If the reverse proxy does not have a copy of the requested content, it passes the request to one of the Windows Media servers for fulfillment, and caches a copy of the content for subsequent requests. If the request from the Internet is for a live stream, the reverse proxy will connect to the originating Windows Media server and then "split" the live stream so that multiple clients can view it, even though only one connection is made back to the origin server.

In this way, the reverse proxy is used for load balancing the cluster of Windows Media servers in the network. You do not have to manually replicate on-demand content to each edge server or configure each edge server for a live stream.

The following table compares the capabilities of these two types of proxies.

Feature	Forward proxy	Reverse proxy
Client configuration required?	Yes	No
Can load balance proxies?	Yes	Yes
Can proxy to any Windows Media server?	Yes	No
Meant for corporate environments?	Yes	No
Meant for CDNs?	No	Yes

Windows Media Services 2008 includes a new WMS Cache/Proxy plug-in, which enables you to use your Windows Media server either as a cache/proxy server or as a reverse-proxy server that provides caching and proxy support to other Windows Media servers. For more information, see Caching and Proxying Content with Windows Media Services 2008.

How do I configure a Windows Media server as a proxy?

To use a Windows Media server as a proxy, you must enable the WMS Cache/Proxy plug-in in Windows Media Services Administrator, configure the plug-in properties to use the server as a proxy, and then configure clients on the LAN to funnel requests through the newly configured proxy.

To enable the WMS Cache/Proxy plug-in

1. In Windows Media Services Administrator, in the Contents pane, click the Windows Media Server name.

2. In the Details pane, click the Properties tab.

3. In Category, click Cache/Proxy Management.

4. In Plug-in, right-click WMS Cache/Proxy, and then click Enable.

To configure server proxy properties

1. In Windows Media Services Administrator, in the Contents pane, click the Windows Media Server name.

2. In the Details pane, click the Properties tab.

3. In Category, click Cache/Proxy Management.

4. In Plug-in, right-click WMS Cache/Proxy, and then click Properties.

5. In the WMS Cache/Proxy Properties dialog box, on the Proxy tab, select Proxy.

The following steps provide information about proxy settings that you can configure in Windows Media Player 12 for each streaming protocol. If you are using a previous version of the Player, consult the Player Help for instructions as the steps may differ slightly.

To configure proxy settings for the Player

1. If the Player is in Now Playing mode, click the Switch to Library button in the upper-right corner of the Player.

2. In the Player Library, click Organize, and then click Options.

3. Click the Network tab.

4. In Streaming proxy settings, under Protocol, click HTTP, and then click Configure.

5. In the Configure Protocol dialog box, select the option Use the following proxy server. Then specify the Windows Media proxy server that you want to use to connect to the Internet by providing its name or IP address (in Address) and port number (in Port). The default port number for HTTP is 80.

6. Repeat steps (4) and (5) for the RTSP protocol. The default port number for RTSP is 554.

For more information, see Which protocols does Windows Media Player use for streaming?

If your clients are joined to Active Directory, you can use Group Policy to configure Windows Media Player proxy settings on the client computers. The following steps provide information about proxy settings that you can configure for each streaming protocol by using Group Policy.

To configure proxy settings for the Player by using Group Policy

1. Start Local Group Policy Editor. To do this, click Start, click Run, and then type the following in the Run dialog box:

   gpedit.msc

2. In Local Group Policy Editor, navigate to the following location in the Contents pane:

   User Configuration > Administrative Templates > Windows Components > Windows Media Player > Networking

3. In the Details pane, right-click Configure HTTP Proxy, and then click Properties.

4. In the Configure HTTP Proxy Properties dialog box:

   • Select the option Enabled.

   • In Proxy type, select Custom.

   • In Proxy address, specify the Windows Media proxy server that you want clients to use to connect to the Internet by providing its name or IP address.

   • In Proxy port, specify the port to use. The default port number for HTTP is 80.

5. Repeat steps (3) and (4) for the RTSP protocol. The default port number for RTSP is 554.

For more information, see Windows Server Group Policy.

How do I configure a Windows Media server as a reverse proxy?

To use a Windows Media server as a reverse proxy, you must enable the WMS Cache/Proxy plug-in in Windows Media Services Administrator, and then configure the plug-in properties to use the server as a reverse proxy.

To enable the WMS Cache/Proxy plug-in

1. In Windows Media Services Administrator, in the Contents pane, click the Windows Media Server name.

2. In the Details pane, click the Properties tab.

3. In Category, click Cache/Proxy Management.

4. In Plug-in, right-click WMS Cache/Proxy, and then click Enable.

To configure server reverse-proxy properties

1. In Windows Media Services Administrator, in the Contents pane, click the Windows Media Server name.

2. In the Details pane, click the Properties tab.

3. In Category, click Cache/Proxy Management.

4. In Plug-in, right-click WMS Cache/Proxy, and then click Properties.

5. In the WMS Cache/Proxy Properties dialog box, on the Proxy tab, select Reverse Proxy.

6. In Content Server, specify the name of the origin Windows Media server by entering its name or IP address. Note that you can specify only one origin Windows Media server.

7. Repeat the previous steps to configure additional reverse proxies that source from the origin Windows Media server, if desired, to reduce the load on the origin server. You can configure a load balancer in front of multiple reverse proxies so that clients can connect to any one of them by using a single URL.

Why can't clients stream some of my MP3 files?

Windows Media Services cannot stream multiple-bit-rate (MBR) MP3 files. If the MP3 file was encoded by using a multiple bit rate profile, it will not play back as expected when it is streamed from a Windows Media server.

In addition, if the MP3 file content is too short, the server may not be able to stream the file to Windows Media Player. The content must meet the minimum supported content length of the Player to ensure reliable playback. The minimum supported content length for Windows Media Player 9 Series or later or a player that uses the Windows Media Player 9 Series ActiveX control is 5 seconds. The minimum supported content length for earlier versions of Windows Media Player is 30 seconds.

How can I control access to my content?

Windows Media Services includes authentication and authorization plug-ins that work together to grant clients access to unicast streams. Authentication plug-ins validate user credentials, and authorization plug-ins control access to the content. If you enable one of the authorization plug-ins but you do not enable one of the authentication plug-ins, unicast clients cannot connect to the server.

Clients do not connect to the server to receive a multicast stream; therefore, you cannot use the plug-ins to control access to a multicast. To control access to a multicast stream, you must place the multicast information file (a Windows Media metafile with an .nsc file name extension that contains information that the client needs to decode the stream) in a shared file location and then associate an access control list (ACL) with the multicast information file. If you use an announcement file to distribute the multicast information file, you can associate an ACL with the announcement file instead.

You can also control new connections to clients that are receiving content as a unicast stream from the publishing points on your server. For clients that are receiving content as a multicast stream, you can stop the broadcast publishing point to stop multicast transmission. For more information, see Controlling access to content.

How can I tell if clients are having difficulty accessing my content?

Logs are extremely valuable for determining the effectiveness of your broadcast. Whenever you create a publishing point, you should enable the appropriate logging plug-in so that you can analyze the successes and failures of your broadcast. A careful review of the logs after a broadcast can reveal not only what problems have occurred and when, but a possible solution.

The following logging fields are typically the most helpful when trying to identify a client-side problem:

x-duration. This is the amount of time that the client rendered the stream. If the time in this field is less than the overall length of the content, the client may have been dropped.

c-status. These are codes that describe the client connection status. Certain common connection problems appear in this field.

avgbandwidth. This is the average bandwidth of the connection. If it is lower than the bit rate of the stream from the server, the client may have experienced reduced bandwidth capacity.

c-bytes. This is the number of bytes received by the client. If this number differs from the number of bytes sent by the server (sc-bytes), then packet loss occurred.

c-pkts-lost-client. This is the number of packets that were not delivered to the client.

c-buffercount. This is the number of times the client buffered the stream. A high value may indicate bandwidth problems.

For more information about how to use log files to identify streaming problems, see Logging Model for Windows Media Services.

How can I tell if a client received all the streaming data?

When the client does not receive all the data streamed from the Windows Media server, the result is known as "packet loss." Packet loss can be caused by network congestion, router problems, and similar phenomena. Packets are also considered to be lost if they arrive too late for the client to play them on time.

You can monitor the log files to determine if any packets were lost, where the loss occurred, and if any of the lost packets were recovered. The following logging fields can help you determine if packet loss occurred:

s-pkts-sent. This is the number of content packets sent by the server to a connected client. This field contains a hyphen (-) in remote cache client logs from a cache/proxy server and in multicast log files.

c-pkts-received. This is the number of packets from the server that were received correctly by the client on the first try. Packets that are not received correctly on the first try can be recovered if they are resent through the UDP protocol. Packets that are not recovered through UDP resend are considered lost in the network.

c-pkts-lost-client. This is the number of lost packets that were not recovered at the client layer through error correction or at the network layer through UDP resends. These packets are sent by the Windows Media server but never played by the client.

c-pkts-lost-net. This is the number of packets lost at the network layer. The client may be able to recover these packets if error correction is enabled.

c-pkts-lost-cont-net. This is the maximum number of continuously lost packets at the network layer. A high value indicates bad network conditions with long periods of time during which the client received no packets.

c-resendreqs. This is the number of client requests for new packets. This field contains a zero unless the client is using UDP resend.

c-pkts-recovered-ECC. This is the number of packets lost at the network layer that were repaired and recovered at the client layer because error correction was enabled. Error correction is the only means of packet recovery for multicast streams. Packets repaired and recovered at the client layer are equal to the difference between c-pkts-lost-net and c-pkts-lost-client.

c-pkts-recovered-resent. This is the number of packets recovered because they were resent through UDP. This field contains a zero unless the client is using UDP resend.

Note that values for all logging fields do not include TCP or UDP packets.

Why do unicast clients buffer my streams?

If clients experience excessive buffering, the Windows Media server may be serving too many simultaneous connections. Due to hardware limitations, a Windows Media server can only transmit a limited number of streams at one time. Servers that are overloaded often lose data, interrupt transmissions, and drop clients. Alternatively, the server may be exceeding the bandwidth capacity of the network. The network may have a weak point or a failure, or it may not have been designed to transfer the amount of data that your clients require.

There are several ways to solve this problem. You can implement any or all of these solutions to ease the data-transfer load on your server or network:

Set limits on your server. You can configure the server to limit the number of client connections and the amount of bandwidth used so that the server and network capacities are not exceeded. For more information, see Limits.

Create a server cluster. You can use a server cluster to make a group of Windows Media servers work together to stream content. Although clients connect to the cluster by using a single URL, all of the servers share the streaming load to reduce the load on any individual server. For more information, see Clustering and load balancing.

Add distribution servers. You can disperse the streaming load over the entire network by using distribution servers at points in the network where streaming demand tends to be highest. This can dramatically improve streaming performance because the distance between the server and client is reduced.

Implement a cache/proxy system. You can configure the new WMS Cache/Proxy plug-in in Windows Media Services 2008 to provide cache and proxy support. Using a Windows Media server as a cache/proxy server is an easy way to conserve bandwidth, decrease network-imposed latency, and offset the load on the origin server. Network bandwidth is minimized because only one connection from the origin server is required to upload content to and receive information from the cache. Network latency is decreased because a client can receive content from a nearby cache/proxy server more quickly than it could if it had to traverse the network or the Internet to receive content from the origin server. Additionally, the load on the origin server is offset because fewer clients are connecting directly to the origin server. For more information, see Caching and Proxying Content with Windows Media Services 2008.

Modify your streaming media content. You can lower the bandwidth requirements of your content by encoding it using different settings.

Use multicast streaming. If you are on a corporate network with multicast-enabled routers, you can deliver your content as a multicast stream from a broadcast publishing point. With a multicast stream, the server streams content to a multicast IP address on the network, and all clients access the IP address to receive the stream instead of connecting to the server. This reduces the amount of bandwidth required on the network as the single stream is able to fulfill multiple client requests. For more information, see Delivering content as a multicast stream.

Note that if you want to test how your server performs when experiencing different client loads, download Windows Media Load Simulator.

Why do multicast clients buffer or drop frames from my streams?

Typically, the network hardware can handle the way that Windows Media Services delivers multicast packets on the network. However, in certain scenarios, the network hardware cannot handle the brief spikes in bandwidth that Windows Media Services delivers on the network and loses the packets that Windows Media Services delivers. For more information about how to fix this issue, see The video occasionally is rebuffered, or frames are dropped, when you try to stream a video through a multicast from Windows Media Services to Windows Media Player clients.

How much network bandwidth will my Windows Media server use?

You can estimate the required network capacity by using the following equation:

Required network capacity = Content bit rate x Audience volume

To estimate the average content bit rate, divide the size of the file that you are streaming by the playback time in seconds. For example, a 2 megabyte (MB) digital media file represents about 16,000,000 bits. If the content duration is about 90 seconds, the streamed content has an average bit rate of 180 kilobits-per-second (Kbps).

To estimate the audience volume, determine the highest number of concurrent users during a streaming event. For example, your company may plan to offer online training to all of its 10,000 employees over the local area network. Past training performance indicates that a maximum of five percent of the employees are likely to access the training at any given time. Therefore, the network must be capable of reliably delivering the content to 500 concurrent users, which would mean that your network must have bandwidth of approximately 9 megabits-per-second (Mbps) to adequately service your training needs.

For more information, see Capacity Planning.

How can I modify my existing Windows Media network to deliver more streams?

For large-scale deployments of Windows Media Services, try one or more of the following modifications to your streaming media system:

• Upgrade from a single-CPU server to a multiple-CPU server.

• Install additional network adapters, or upgrade the existing network adapter to support a higher bandwidth network connection.

• Add additional servers running Windows Media Services to your streaming media system and use Network Load Balancing to distribute the server load.

• Distribute cache/proxy servers throughout the network and implement a content replication program to distribute content closer to the clients and relieve some of the demand on the origin servers.

• Set the network switches that will be processing streaming media requests and transmissions to full duplex mode to maintain an uninterrupted information flow.

What other optimizations can I perform on my Windows Media network to improve scale and performance?

Optimizing Windows Media Services provides a technical overview of the scalability and performance of Windows Media Services. It describes common performance issues, limitations, and performance-monitoring techniques.

Although the article is based on a study conducted in a controlled lab environment on Windows Media Services 9 Series running on Windows Server 2003 Service Pack 1 (SP1), in general, you can assume that scalability increases linearly with increases in RAM and CPU. Scalability of Windows Media Services 2008 is more than double that of Windows Media Services 9 Series when used with the 64-bit edition of the Windows Server 2008 operating system or the Windows Server 2008 R2 operating system.

The performance results described in the article are based on specific hardware configurations that represent simplified versions of real-world scenarios. The actual capacity of your streaming media system depends on several factors, including network topology, client usage patterns, hardware configuration, and software configuration. Based on the guidelines and performance information in this article, you should be able to design, fine-tune, and maximize the capacity of your servers to achieve the best results for your individual situation.

Why should I use Windows Media Services on Server Core installations of Windows Server 2008?

If you install Windows Media Services 2008 using the Server Core installation option on any version of Windows Server 2008, you may see a 10 to 25 percent increase in scalability over the full installation option. In addition, by removing the user interface, client features, and managed code from the operating system, Server Core reduces the footprint on disk by two-thirds, and substantially reduces attack surface and servicing requirements. In effect, Server Core provides an embedded-appliance-like installation of Windows Server that is ideal for branch offices, lights-out locations, and server farms.

Is there an SDK for Windows Media Services 2008?

The Windows Media Services 9 Series Software Development Kit (SDK) can also be used to build custom applications for Windows Media Services 2008.

Where can I get help with Windows Media Services?

A good general resource, with links to product information, FAQs, tools, technical articles, and other resources is the Streaming Media Services TechCenter.

A good end-to-end planning resource is the Microsoft Windows Media Resource Kit, written by the Windows Media team to highlight "how-to" information and best practices for common deployment scenarios.

The Streaming Media Services Forum is a good starting point for getting assistance from other users. It provides opportunities to interact with Microsoft employees, experts, and your peers to share knowledge and news about Windows Media Services and related technologies.

For paid product support services from Microsoft, contact a support professional by e-mail, online, or by telephone.