Best Practices for Windows Media Technologies

  • Article

Operating System

Abstract

This paper discusses the best practices for implementing Microsoft® Windows Media™ Technologies. It covers protocols, encoder configuration and techniques, server configuration and tuning, enabling multicast distribution, and logging.

On This Page

Introduction Introduction
The Microsoft Media Service Protocol The Microsoft Media Service Protocol
The Windows Media Encoder The Windows Media Encoder
Encoding Techniques Encoding Techniques
The Windows Media Server The Windows Media Server
Server Security Issues Server Security Issues
Logging and Server Performance Information Logging and Server Performance Information
Windows Media Performance Tool Windows Media Performance Tool
Windows Media Load Simulator Windows Media Load Simulator
Multicasting Multicasting
Load Balancing Load Balancing
WIndows Media Player HTTP Error messages WIndows Media Player HTTP Error messages
More Information More Information

Introduction

Microsoft® Windows Media™ Technologies is distributed as part of the Microsoft Windows® 2000 operating system. It allows you to create, distribute, and play streaming media files. For the IT professional, it is important to understand how both Windows 2000 Professional and Windows 2000 Server should be configured to optimize performance, and how the files can be distributed over the network.

Figure 1, below, shows the components used for transmitting streaming media:

Figure 1: Components of Windows Media Technologies transmission

This paper discusses the components related to encoding, serving, and transmitting streaming media over a network. It includes information on the following:

  • The Microsoft Media Server (MMS) protocol

  • Configuring and using encoders

  • Configuring and tuning servers

  • Logging, authentication, and load balancing

  • Using and troubleshooting multicast

  • Windows Media Player error codes

The paper assumes a basic familiarity with WMT, and with networking protocols.

The Microsoft Media Service Protocol

Windows Media Technologies uses an application-level protocol called Microsoft Media Server (MMS) to send Active Streaming Format (ASF) files across the Internet and intranet. A URL that points to a streaming ASF file includes MMS as its protocol, as shown in the following example:

mms://servername/filename.asf

The MMS protocol automatically looks for the optimal transport to stream media, in the following order:

  • UDP (User Datagram Protocol)

  • TCP (Transmission Control Protocol)

  • HTTP (Hypertext Transfer Protocol)

The UDP protocol is a connectionless, transport-layer protocol that is ideal for real-time media because it doesn't guarantee delivery. Although this sounds like a drawback rather than an advantage, it is a characteristic particularly suited for streaming media. Unlike data such as files or e-mail, which must be delivered in their entirety no matter how long the transmission time, the value of streaming media data is constrained by time. If a frame of video is lost it is worthless because it won't arrive within the correct time frame. Transmitting it again is a waste of bandwidth. It is possible to specify that only UDP should be used as the transport protocol. To do this, use the following syntax:

mmsu://servername/filename.asf

The drawback to UDP is that it may not be able to pass through a corporation's firewall. For information about configuring firewalls to accept streaming ASF files over UDP, see:

https://www.microsoft.com/ntserver/techresources/streaming/default.asp

The next choice, TCP, is the dominant Internet transport protocol. The drawbacks to TCP are that it will try to retransmit data and that it too may be unable to pass through a corporation's firewall (see the previously mentioned article for information about TCP and firewalls). The syntax specifying that only TCP should be used as the transport protocol is: mmst://servername/filename.asf

The last choice is HTTP. Although it is an application-layer protocol rather than a transport-layer protocol, and although it is not designed for streaming media, HTTP can pass through firewalls. Anyone who can browse the Web can receive streaming files via HTTP. The syntax specifying that only HTTP should be used is: https://servername/filename.asf.

Using ASX Files

An ASX file links Web pages to ASF files. Unless every client accessing the Web site is running Microsoft Internet Explorer, never reference MMS paths directly in an HTML page. This is because other browsers don't understand the protocol and ignore it when they encounter it. Instead, reference an ASX file that points to the streaming media file.

A simple ASX file might look like this:

<ASX version="3.0">
<Entry>
<ref HREF=" mms://servernane/filename.asf "/>
</Entry>
</ASX>

After creating the ASX file, host it on an HTTP or network server. To link to the ASX file, use a standard <A HREF> tag in the HTML page:

<a href="https://servername/path/asxname.asx">Description</a>

When the user selects a link to an ASX file, the browser downloads it (ASX files are small). The system looks for the ASX extension in the file association table and launches the Windows Media Player. In turn, the Windows Media Player looks in the ASX file for the location of the ASF file, and starts the stream. For more information about writing ASX files, see the documentation on the MSDN Online Web Workshop https://msdn.microsoft.com/workshop/imedia/windowsmedia/.

The Windows Media Encoder

The Windows Media Encoder compresses digitized media files that can be in the AVI, MP3, or WAV format, and converts them to the ASF format used by the Windows Media Player. The encoder can be used either for real-time events or stored files. Because encoding is a CPU-intensive activity, it is recommended that the encoder be on a separate computer from the one running the Windows Media service. This section discusses the following issues related to using the encoder:

  • Computer hardware configurations

  • Encoding multiple streams

  • Automated encoding

Computer Hardware Configurations

There is no single configuration that will satisfy every situation. Before purchasing new hardware, first decide if you will be recording high-motion or low-motion video. An example of low-motion is a talking head, which requires very little processing power. An example of high-motion is something with many rapid changes, such as a music video. This requires more processing power.

Selecting a CPU

In general, a single Pentium II processor can perform real-time encoding for any video with a bandwidth of up to 300 kilobits per second (Kbps), and probably 500 Kbps. A Pentium III, or equivalent, should be used for up to 1 megabits per second (Mbps). For higher bit rates, (Microsoft CODECs can scale up to 5 Mbps for real-time encoding), use a second processor. As a rule, if you are buying new equipment, get a Pentium III, or equivalent, computer. Even if you don't need the processing power now, you will probably need it in the future.

Adding Memory

Typically, 64 megabytes (MB) of memory is the optimal amount for encoding. Large amounts of memory are unnecessary because no buffering occurs and only the operating system and the application need to be loaded. Use the Performance tool to make sure the system isn't paging to disk, which will adversely affect performance. (To access the Performance tool, point to Programs on the Start menu, point to Administrative Tools, and click Performance.)

To check for available memory, add the Memory\Available Bytes counter. To check how much paging is occurring, add the Memory\Pages/sec counter. Both of these are under the Memory heading. Figure 2 below shows an example of adding a counter:

Figure 2: Adding the Pages/sec counter

Figure 3 below shows these counters as well as the amount of processor time that is being used:

Figure 3: Example of the Performance Monitor

The Memory\Available Bytes counter indicates how many bytes of memory are currently available for use by processes. This number should stay above 4 MB. The Memory\Pages/sec counter indicates the number of pages that were either retrieved from disk because of page faults or written to disk to free up space. For more information about the Performance tool, see the appropriate Help files.

Adding Disk Drives

Disk drives can be a bottleneck because they must be able to capture and store the data as fast as it's coming in. If the drive's data transfer rate is too slow, then data will be lost and the stream's quality will suffer. For encoding speeds of 300 Kbps to 500 Kbps, use SCSI drives. For faster rates, consider using RAID Level 0 disk arrays.

Selecting an Operating System

Although the Windows Media Encoder can run on both Windows 2000 Professional and Windows 2000 Server, it is recommended to use Professional because it gives priority to foreground applications.

Selecting a Video Capture Card

To find a list of video capture cards that are compatible with Windows Media Technologies, consult the "Windows Media Hardware Providers" Web page at:

https://www.microsoft.com/windows/windowsmedia/forpros/service_provider/hardware/default.aspx

It is important to use this list rather than a list of cards that are compatible only with the Windows 2000 operating system because only a subset of video cards is compatible with them both. One of the most popular video capture cards is the Osprey 100 from Viewcast.com. Although this card will not capture audio, no problems have been reported synchronizing the Osprey 100 with sound cards. For more information, go to:

https://www.viewcast.com/products/osprey/osprey100.html

Selecting a Sound Card

For encoding a single audio stream, select a stereo sound card such as Soundblaster Live. The Soundblaster16, or a compatible card, is minimally acceptable. Consult the Windows Hardware Compatibility List to see the sound cards that have been approved for the Windows 2000 family of operating systems (any sound card that is compatible with Windows 2000 is compatible with Windows Media Technologies). The hardware list is at:

https://support.microsoft.com/kb/131900

Encoding Techniques

This section discusses techniques for encoding audio and video and for setting up automated encoding. Other than the obvious distinctions, one difference between encoding audio and video is that a video file can include multiple bit rates while an audio file cannot. Multiple bit rates allow the Windows Media Player to adapt to changing network conditions by selecting the bit rate most appropriate for the quality and speed of the user's network connection. This cannot be done with an audio file because the ear is much more discerning than the eye and would more readily detect bandwidth changes in the audio stream than the eye would for video streams.

Encoding Multiple Audio Streams

Simultaneously encoding multiple audio streams is a common situation. A typical example is encoding different radio stations to be broadcast online. To encode multiple audio streams, use multiple encoders in a single system and run them concurrently. Because encoders are CPU-intensive, use a Pentium III if possible.

Another important consideration for encoding multiple audio streams is the sound card. Customers have reported problems using multiple Soundblaster cards in a single system. Instead, install a sound card that requires only a single slot but has multiple ports.

Encoding Multi-Bandwidth Video Streams

Windows Media Technologies includes the Intelligent Streaming feature that can detect network connection speeds, adjust to changing network conditions, and automatically improve video stream quality on the fly. As of Windows Media Technologies, version 4.0, Intelligent Streaming includes the following capabilities:

  • Multi-Datarate Encoding: Content providers can offer as many as six video bands in a single file, ranging from 16 Kbps to 1 Mbps. With multi-bit rate encoding, end users can click on a single link and the maximum bit rate is automatically selected, based on the user's network connection.

  • Intelligent Transmission: Traditionally, network congestion has forced the client to stop playback and rebuffer before it can continue the transmission. As of Windows Media Technologies 4.0, the client and server can now intelligently degrade quality to preserve continuous playback. First, the server decreases the video frame rate to maintain audio quality and to keep buffering to a minimum. If conditions worsen, the server stops sending video frames completely but maintains audio quality. Finally, if audio quality starts to degrade, the client intelligently reconstructs portions of the stream to preserve quality. This technique is called stream thinning.

  • Video Playback Enhancement Filter: When receiving a video stream, Windows Media Player uses intelligent filtering to remove artifacts and significantly improve overall video quality, especially at low bandwidths.

Automated Encoding

Automated encoding means the encoder starts automatically when the system boots and someone logs on. It is often used when a production service is online and continuously running. To enable automatic encoding, create a shortcut using the Taskbar and Start Menu Properties window (to open this window, point to Settings on the Start menu, and click Taskbar and Start Menu). Figure 4 below shows an example of this menu:

Figure 4: Taskbar and Start Menu Properties window

Click Add. In the Create Shortcut text box, type:

NsRex filename.asd /start

The name of the encoder is NsRex, and filename refers to the Advanced Stream Descriptor file (ASD) that stores the encoder configuration. For example, it includes information about which CODEC to use, the size of the window, and, for video, the frame rate and number of I frames. The /start option means that encoding will begin when someone logs in. (To make this process fully automatic, enable automatic log on so no one has to type in a name and a password.) Figure 5 below shows an example:

Figure 5: Selecting a title for the program

In this example, the encoder will use an .asd file named stereo28.8.

The Windows Media Server

This section discusses how to configure computers to run the Windows Media Service, how to tune the server to get the best possible performance, and how to make the server secure. We will first discuss the server's hardware configuration.

Computer Hardware Configurations

Unlike encoders, which are CPU-intensive, servers are I/O intensive. The bottlenecks for servers are the network interface cards (NIC) and the disk systems, in that order. The CPU and memory are in distant third and fourth places. In this section, we discuss the optimum hardware configuration for a Windows Media Server.

Selecting CPUs and Memory

For a typical Windows Media Server that will handle thousands of concurrent connections, use an Intel Pentium II, or equivalent. Multiple processors are unnecessary unless the server will be handling more than 2,000 or 3,000 concurrent connections, where each connection is 20 Kbps. Higher bit rates will lower the number of concurrent connections the server can handle. To handle the maximum number of concurrent connections, use multiple processors. For a single processor system, 256 MB of memory are optimal. For a multiple processor system, use at least 512 MB. More memory may be required depending on the configuration and the demands put on the server. To see how the server behaves under stress, use the Windows Media Load Simulator, which is discussed later in this paper.

Selecting a Network Interface Card

For live events, it is particularly important to have a fast connection between the encoder and the server. This connection is the master feed. If enough bandwidth isn't available, the master signal will degrade and users will receive low-quality transmissions as a consequence. For the network interface card (NIC), use either Fast Ethernet (100 Mbps) or 10/100 switched Ethernet. Switched Ethernet transfers packets from a 10 Mbps shared segment to a LAN segment or workstation running at 100 Mbps. This enables multiple end stations or workgroups running at 10 Mbps to connect to servers running at 100 Mbps.

To handle 4,000 concurrent connections, which will saturate two T3 lines, consider adding a second NIC so that there is a separate connection between the encoder and the server. Even if the network connection becomes saturated, the master feed won't be affected and degrade. Network cards should be configured for full-duplex, which means they can send and receive data at the same time.

Selecting Disk Drives

Fast disk drives are essential for good server performance. The scalability of a Windows Media Server is frequently limited by the performance of the disk array. Multiple hard drives in a RAID configuration are recommended for large numbers of concurrent connections. Because of their high data transfer rates, interfaces such as SCSI and Fibre Channel (see below) should be considered, but consult with your preferred hardware vendor to determine the best configuration.

Disk speed requirements also increase as more files are used and/or less caching is available. Note that the Windows Media Server does not use caching. Therefore, unless the disk controller has caching on it, each read to obtain data is an explicit fetch from the physical disk.

Don't store the ASF root directory on the system drive because of the intense activity and disk-swapping that can occur there. Also, store duplicates of heavily used content on multiple drives so users can connect via different paths. A rule of thumb is that one disk can support approximately 500 28.8 Kbps connections.

Once the server is configured, use the Windows Media Load Simulator in conjunction with the Performance Monitor to detect bottlenecks, such as memory paging and processor time. If the server is unable to handle the load, add additional hardware or a second server.

Storage Area Networks

IT managers may want to consider Storage Area Networks (SAN) if they are managing large sites where fast throughput and scalability are critical. SANs are networks dedicated to storage. They interconnect, at high speeds, servers and storage devices such as RAID disk arrays, disk drives, and tape drives. Aside from providing high bandwidth, SANs isolate all the storage I/O into a separate section of the network so that other network traffic is unaffected by it.

The underlying network infrastructure for a SAN is called Fibre Channel – Arbitrated Loop (FC-AL). This is an industry-standard, high-speed interface designed for bi-directional, point-to-point serial data channels. It can connect systems across distances of up to 10 kilometers at speeds exceeding 100 MB/s.

Fibre Channel supports multiple protocols, such as TCP/IP and SCSI, running concurrently over the same cable. Up to 126 nodes can be attached to a single loop. Examples of hard drives that support the FC-AL interface are the Barracuda and Cheetah drives available from Seagate. More information about these drives is available at:

https://www.seagate.com

Performance Tuning the Server

There are several things that can improve server performance. They include:

  • Disabling extraneous services

  • Minimizing memory

  • Setting registry keys

  • Using the latest NIC drivers

Disabling Extraneous Services

Servers often have services running that aren't being used. Usually, they start automatically when the machine is booted. One example of such a service is license logging, which checks to see if customer licenses for applications are current. There is no reason to keep this service running if the server is dedicated to distributing streaming media. Another example is the print spooler. Unless the server is used as a spooler, turn this off. Also, for high-end performance, don't run the Microsoft Internet Information Service (IIS) on the same server as the Windows Media Service. Make the server a dedicated Windows Media Server. If IIS is running on the same machine, consider turning off its content indexer and FTP service. The indexer requires a great deal of memory and disk space and the FTP service will probably not be used. In general, evaluate what services you really need and shut down everything else.

Setting Registry Keys

There are two registry keys whose values can be adjusted to improve the performance of the server when it is heavily loaded. Use the Registry Editor to either add the keys if they're not already there, or to modify the settings.

MaxConnectionPerSecondKey

The MaxConnectionPerSecond registry key controls the number of client connection requests per second that a server can process by setting the size of the queue that holds pending requests. Processing client connection requests uses system resources (CPU cycles and memory) and, depending on the computer hardware configuration, may adversely affect server performance and the quality of the media streams delivered to clients.

When a connection request is sent from a client to a Windows Media Server, the request is placed in a connection queue and processed serially. If the rate of clients attempting to connect to the server exceeds the client connection rate for processing these connection requests, the queue becomes full. The default value for the number of client connection requests processed per second is set to 25 because a computer that meets the minimum system requirements for a Windows Media Server can process 25 connection requests per second without impacting the quality of streams being delivered to connected clients. The value for the number of client connection requests placed in the queue is equal to twenty times the number of client connections per second, or 500 by default. This value is set to twenty times the connection rate because the Windows Media Player is set to wait 20 seconds before attempting to connect using a failover URL. All requests in the queue get processed within the 20-second wait period.

The server keeps a count of clients placed in the queue. When the maximum allowed number of requests has been placed in the queue, the server stops listening for connection requests. Any client that attempts to connect is immediately sent a message that the server is unavailable. Each time this occurs, a Windows Media log entry is made with the error code 503. A Microsoft Windows 2000 Server Application Event Log entry is also made with the message Windows Media Services has reached its maximum pending connections value of %1. However, this entry is only made when the server stops listening and a log entry has not been made in the preceding minute. Here, %1 is a variable, and the number displayed is the size of the queue. The server then checks every 2.5 seconds to see if the queue is full. If clients have been processed and removed from the queue, the server again begins to listen for connection requests.

If you are using a computer with multiple processors and a large amount of memory, your computer may be able to process a greater number of connections. However, before deciding to increase this value, it is recommended that you carefully evaluate the use of your computer's CPU and memory, using the Windows Media Load Simulator.

To set the server connection rate to a custom value, edit the system registry for each Windows Media Server that must be changed. The registry key HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \nsunicast \Parameters \MaxConnectionsPerSecond can be set to a custom value if the connection rate is too high or too low for a particular hardware configuration. On a high-end server, a value of 75 or even 100 should be possible.

MaxUserPort

By default, when an application requests a socket from the system to use for an outbound call, the system supplies a port between the values of 1024 and 5000. The MaxUserPort parameter sets the value of the uppermost port that can be used for outbound connections. If the Windows Media Server will be operating under heavy loads, it may be necessary to raise this upper limit. To set this value, navigate to HKEY_LOCALMACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters. Add the value MaxUserPort if it's not already there, and set it to 0xFFFE.

Using the Latest NIC Drivers

It is important to keep NIC drivers up-to-date. You can have significant increases in performance when they have gone from an outdated driver to the current version.

Server Port Numbers

In a TCP/IP-based network, a port number is assigned to an application running in the computer. This number links incoming data to the correct service. Well-known ports are standard port numbers used by everyone; for example, port 80 is always used for HTTP traffic (Web traffic). Windows Media Technologies uses the following port numbers:

  • The client creates a TCP socket bound to server port 1755 for command and control packets.

  • For UDP streaming, the client creates a UDP socket also bound to server port 1755. This is used to issue packet resend requests.

  • For UDP streaming, the client creates a UDP socket to which to listen. This port number is randomly assigned and lies between 1024 and 5000.

Firewalls may have to be configured to allow traffic on these ports. For those sites where opening a non-well-known port is a problem, Windows Media can also stream via HTTP on port 80.

Port Numbers and Distributed COM

Distributed COM (DCOM) dynamically allocates one port per process. You need to decide how many ports you want to allocate to DCOM processes, which is equivalent to the number of simultaneous DCOM processes passing through the firewall. You also need to open port 135, which is used for remote procedure call (RPC) End Point Mapping. In addition, you must edit the registry to tell DCOM the ports you reserved. You do this with the HKEY_LOCAL_MACHINES \Software \Microsoft \Rpc \Internet registry key, which you will probably have to create using the Registry Editor.

The following example tells DCOM to restrict its port range to 10 ports:

Named Value: Ports
Type: REG_MULTI_SZ
Setting: Range of port. Can be multiple lines such as:
3001-3010
135

For more information about port numbers, firewall configurations, and DCOM, see:

https://www.microsoft.com/windows/windowsmedia/forpros/serve/firewall.aspx

Server Security Issues

This section discusses methods of securing the Windows Media Server, and of protecting content. The server can be secured using one of two methods of authentication. Content can be protected with the Windows Media Rights Manager.

Authentication with Unicast Transmissions

Authentication means verifying the identity of someone who is accessing the server. Unicast transmissions lend themselves to authentication because there is a point-to-point connection between the client and the server. Multicast transmissions, where there is no direct connection between the client and the server, present a different problem. Authentication with multicast transmissions is discussed later in this paper.

The Windows Media Server can use one of two methods of authentication. They are:

  • Anonymous (the default)

  • Basic authentication

Either of these is selected using the Windows Media Administrator, under Server Properties.

Anonymous Authentication

This option is selected by choosing Do not choose authentication, which is the default. With anonymous authentication, the network administrator specifies an Anonymous Logon user account name (or accepts the default user name of Netshow Services), and enters the account's password. If the client's Web browser requests a URL without supplying a user name or password, the server impersonates the anonymous user account and attempts to access the resource.

With anonymous access, IT managers can deny access to a specific file by not accepting the NetShowServices user name. To do this, set an Access Control List (ACL) on the file. (See the section "Using Access Control Lists" later in the paper.) If a user attempts to access Windows Media content anonymously and if the NetShowServices account doesn't have read privileges for the file, the user will be required to log on. If this is rejected, he or she will be denied access to the file.

Basic Authentication

With basic authentication, the client is prompted for a plain text (unencrypted) user name and password, which are then Base64-encoded and passed to the server. The server checks them against a directory database and, if the user name and password are correct, the server impersonates the user and attempts to access the resource. Basic authentication can use either the information in the account database or, if it is installed, the information in the Microsoft Site Server Membership account.

Note that Base64 encoding is a minimal type of encryption. Although someone monitoring network traffic will not see the actual user name and password, decrypting them is trivial. Nearly anyone sophisticated enough to monitor the traffic can research the algorithm and reverse it, revealing the plain text user name and password that can be used to break into the Web site.

Applying an Authentication Package

To apply an authentication package, open the Windows Media Administrator by pointing to Programs, pointing to Administrative Tools, and clicking Windows Media.

To apply an authentication package

  1. In the Windows Media Administrator menu frame, click Server Properties.

  2. The Configure Server - Server Properties page appears. The content on the General tab appears by default. Figure 6, below, shows an example:

    Figure 6: The Server Properties Page

  3. Click the Publishing Point Security tab.

  4. Select an Authentication Package from the list. Click Apply.

Using Access Control Lists

If an authentication package is active, the Windows Media Server also allows you to enable Access Control List (ACL) checking by selecting the Enable Access Control List (ACL) checking check box. An access control list is a list of entries associated with a file or folder that specifies which users and groups have access to that folder or file. Without ACLs, all files and folders require authentication. With ACLs, you can set per-user permissions on individual files and folders.

Each entry in an ACL assigns a user or group one or more of the following levels of access to files:

  • None allows a user no file access.

  • Read Data allows a user to view data in a file.

  • Write Data allows a user to change a file's data.

  • Execute File allows a user to run a program file.

  • Delete allows a user to delete a file.

  • Change Permissions allows a user to change permissions on a file.

  • Take Ownership allows a user to take ownership of a file.

A similar set of privileges is set on folders:

  • None allows a user no folder access.

  • List Folder allows a user to view file names and subfolder names.

  • Create Files allows a user to add files and subfolders.

  • Traverse Folder allows a user to change to subfolders.

  • Delete subfolders and files allows a user to delete a subfolder.

  • Change Permissions allows a user to change permissions on a folder.

  • Take Ownership allows a user to take ownership of a folder.

For more information, see the "Restricting access to ASF Streams" page of the Windows Media Administrator Help files.

Windows Media Rights Manager

Windows Media Rights Manager, a digital rights management application, lets content authors deliver songs, videos, and other media over the Internet in a packaged, encrypted file format. End users need a separate license containing the key that decrypts the file to play it with the Windows Media Player.

Windows Media Rights Manager uses a strong digital-rights-management encryption scheme. Every file is stored in an encrypted format unique to each PC running the Windows operating system, which makes it extremely difficult to break the license protection or to copy the file. This Windows-based PC-by-PC encryption scheme protects consumers from inadvertently pirating a file. It also acts as a deterrent to intentional piracy. For more information about Windows Media Rights Manager, go to:

https://www.microsoft.com/windows/windowsmedia/forpros/drm/default.aspx

Logging and Server Performance Information

There are a variety of tools for logging information about clients and evaluating and monitoring server performance. This section has an overview of:

  • The Windows Media Administrator Log Files

  • The Windows Media Performance Tool

  • The Windows Media Load Simulator

All of these tools have extensive Help files of their own. Consult them for more detailed information.

Windows Media Administrator Logs

The Windows Media Administrator can log information about events and about clients connected to unicast publishing points. (Logging information about multicast problems is a more difficult problem and is discussed in the section on multicast.) Logging is disabled by default. To enable it, open the Windows Media Administrator by pointing to Programs on the Start menu, pointing to Administrative Tools, and then clicking Windows Media. Click Server Properties in the menu on the left, and click the Publishing Point Logging tab. Figure 7, below, shows an example screen:

Figure 7: Enabling Unicast Logging

The publishing point event log shows the date, time, and a description of client activity. Figure 8, below, shows an example of this log:

Figure 8: Load Simulator Publishing Point Events

The Windows Media Administrator publishing point client logs show the following information:

  • The client ID (these are assigned sequentially as each client connects to the server)

  • The client's IP address

  • The port number assigned to the client

  • The client's status (such as streaming or stopped)

  • The name of the file being streamed to the client

Figure 9, below, shows an example of the Publishing Point Clients dialog box:

Figure 9: Example of Publishing Point Clients Log

In this case, the client IP address is the same in all instances because the data was gathered using the Windows Media Load Simulator and a single computer simulated multiple clients. Each client has a separate port number that is randomly assigned.

Log file entries are stored for a period of time that you select or until the file reaches a size that you specify. The files are saved in W3C standard format. They can be viewed in Notepad, and the Windows Media SDK contains sample Windows Script Host scripts for parsing the logs. Also, there are a number of third-party products available for reading and interpreting the log. Some companies that provide such products include:

Windows Media Performance Tool

As part of its set of administrative tools, the Windows 2000 operating system includes a monitor that displays statistics specifically related to Windows Media Technologies performance. To access this tool, point to Programs on the Start menu, point to Administrative Tools, and click Windows Media Performance.

The tool is shown in Figure 10, below:

Figure 10: Windows Media Performance Tool

It is similar to the more general Performance Monitor but includes counters that are relevant for streaming media. One statistic that is particularly important for stored, on-demand content is the Late Reads counter. This number should be 0. If it isn't, it means the disk response is deteriorating and cannot keep up with the demand. Late reads are rarely problems when serving static data such as still images and Web pages, but when serving real-time multimedia content, data must be available instantaneously.

Windows Media Load Simulator

The Windows Media Load Simulator is included in the Windows 2000 resource kit, or can be downloaded from:

https://www.microsoft.com/windows/windowsmedia/download/default.asp

It runs on a client machine and tests the capacity of the Windows Media unicast service on a Windows Media Server by simulating a large number of Windows Media Player connections. Offline servers can be both peak and stress tested. A peak load is the maximum number of clients using the system under normal conditions. Stress testing is done by gradually increasing the number of clients beyond the peak load.

The load simulator can also monitor an online Windows Media Server and can be configured to automatically alert an administrator when server performance begins to degrade or if the server stops responding. Figure 11, below, is an example of what the load simulator looks like:

Figure 11: The Windows Media Log Simulator

The following logs contain information that will help you interpret the results of tests that are run using the load simulator:

  • The load simulator itself keeps a log that contains information such as client connection status, playback status, and connection errors. This is data from the client's perspective.

  • The Windows Media Performance Monitor, discussed above, provides information from the server's perspective. The monitor takes a snapshot of the server's performance every 5 seconds and presents the data graphically. Information such as the number of late disk drive reads, number of refused authorizations, stream information, and server CPU usage is available.

  • The Windows Media Administrator log, discussed above, also contains information from the server's perspective. This information includes connection status information, the content being accessed, and the amount of data lost during transmission.

The Windows Media Performance Monitor also contains information that can be used in conjunction with the simulator. For a more complete description of the load simulator, see the article called "Checking Server Performance with Microsoft Windows Media Load Simulator" at:

https://www.msdn.microsoft.com/workshop/imedia/windowsmedia/loadsim.asp

Multicasting

Multicasting is a one-to-many form of transmission that sends data to a group of users. Multicasting saves network bandwidth because the files are transmitted as a single data stream until the last hop, where individual streams are sent to the target stations by the router at the end of the path.

There are some terms Windows Media Technologies uses that apply specifically to multicast sessions. We will explain them before discussing how to use multicast and how to troubleshoot a multicast session.

Understanding Windows Media Technologies Multicast Terminology

There are three terms that are used when setting up a multicast transmission: station, program, and stream.

Stations are used for distributing content via multicast transmissions (publishing points are used with unicast transmissions). A station is similar to a television station. Stations distribute content called programs, and a program is typically made up of several streams. A program, might, for example, use video clips interspersed with advertisements. More complete information on using multicast and creating a multicast station is available in the Windows Media Administrator Help files.

Defining a Station

Stations are defined in an .nsc file. This is a configuration file containing all the information, such as IP addresses, port numbers, and required CODECs, that is necessary for joining a multicast transmission. The Windows Media Server creates an .nsc file from the information entered when the multicast station was configured.

The .nsc file is necessary because users don't necessarily join a multicast transmission when a program begins. They can become a member of a multicast group at any time, which means the Windows Media Player immediately starts receiving the streaming data without any header packets that contain information about the transmission. The Windows Media Player uses the .nsc file to get this information.

Administrators typically make the file available either by e-mailing it to the users who can join the group or by posting it on a Web site. This means that, even though the Windows Media Server creates the file, it doesn't distribute it. Keeping distribution of the .nsc file under the control of the administrator helps stop unauthorized users from listening to a transmission. For example, by posting the file on a Web site, administrators can require authentication before granting access to the information.

The .nsc file may include the name of the .asd file containing the encoder configuration. You need to specify this file when you create a multicast station if you did not use the Windows Media Encoder default values in the templates. If you changed any of the default values, save the .asd file, copy it to the server, and, when configuring the multicast transmission, specify it. This is done in the Specify stream format information dialog box. The Windows Media Administrator stores the information in the .nsc file.

Configuring a Multicast Station

This section walks you through the process of defining a station for a multicast session.

To define a station for a multicast session

  1. Open the Windows Media Administrator by pointing to Programs on the Start menu, pointing to Administrative Tools, and then clicking Windows Media.

  2. To begin, click Multicast Station under the Configure Stations heading in the menu. The Configure Server – Multicast Stations dialog box will appear. Figure 12, below, shows a sample screen:

    Figure 12: Configure Server – Multicast Stations

  3. Make sure the Use wizard to create new station option is checked. Select Stations, and then New from the drop-down menu. The QuickStart Wizard dialog box, shown below in Figure 13, appears:

    Figure 13: Wizard for Configuring Multicast Stations

    Click Next.

  4. The Select a Station dialog box, shown below in Figure 14, appears:

    Figure 14: Selecting or Creating a Multicast Station

    In this example, we create a new station, so select the Create a new station option. If any stations already existed, they would be listed and the second option, Select an existing station, could also be chosen. (This is how you can change an existing station's configuration.) Click Next.

  5. The Create a new station dialog box, shown below in Figure 15, appears:

    Figure 15: Specifying the Station's Name and Description

    By selecting the Multicast and distribution option, the server will try to stream across unicast if multicast isn't possible. Click Next.

  6. The Specify a program and stream name dialog box, shown in Figure 16, appears below:

    Figure 16: Specifying a Program and Stream

    Click Next.

  7. The Specify a source for the stream object dialog box, shown in Figure 17, appears:

    Figure 17: Specifying a Source

    If the stream is a stored file, then select the Advanced Streaming Format (.asf) File option. If it is a live event being encoded in real-time, select the Windows Media Encoder option. If the source is a station or publishing point located on a remote computer, select the Remote station or broadcast publishing point option. Click Next.

  8. The Specify a source URL for the stream object dialog box, shown below in Figure 18, appears:

    Figure 18: Specifying an URL to an .asf File

    In this example, we specify an URL for the .asf file that is our source. Later in this process, the Windows Media Administrator will generate an .asx file that wraps the URL into a format browsers other than Internet Explorer can understand. (See the "Using ASX Files" section earlier in this paper.)

  9. If we had selected the Windows Media Encoder option, the screen shown below, in Figure 19, would have been displayed:

    Figure 19: Specifying an URL to a Windows Media Encoder

  10. If we had selected the Remote station or broadcast publishing point option, the dialog box shown below in Figure 20 would have appeared:

    Figure 20: Specifying an URL to a Remote Station

  11. Once you have specified the URL, click Next.

  12. The Specify stream format information dialog box, shown below in Figure 21, appears:

    Figure 21: Specifying a Path to the Source

    Specify the location of the .asf file. The Windows Media Administrator needs to look at this file's header to learn information about it that the Windows Media Player will need, such as the type of media the file contains and the CODEC that was used. This information will also be stored in the .nsc file generated by the Windows Media Administrator.

  13. The user must specify where the .nsc file will be saved. This is done in the "Export path for the station information file" screen shown in Figure 22, below:

    Figure 22: Specifying a Path for the .nsc File

    Specify the location where the .nsc file will be stored. This is usually on a Web server or network share. It must be accessible to your users so that their players can read it. To protect the file from unauthorized access, place it on a share that requires authentication. Click Next.

  14. The Station information file URL screen, shown below in Figure 23, appears:

    Figure 23: Specifying an URL for the .nsc file

    This is the URL a Windows Media Player uses to access the .nsc file. The URL can point either to a Web server or to a network share. In our example, we've specified a Web server. A Universal Naming Convention (UNC) path uses double slashes or backslashes to precede the name of the computer, while the directories are separated with a single slash or backslash. The examples shown on the screen are UNC paths. Click Next.

  15. The Select publishing method dialog box, shown below in Figure 24, appears:

    Figure 24: Selecting a Publishing Method

    This screen specifies how the .asf stream will be referenced. Remember that it is generally unwise to point directly to the mms stream. In our example, the Windows Media Administrator will generate an .asx file that references the stream. Click Next.

  16. The Ready to publish dialog box, shown below in Figure 25, appears:

    Figure 25: Summary of Multicast Options

  17. The final screen shows a summary of the station definition.

Logging User Information

With multicast, there is no direct communication between the server and the users. This makes it difficult to gather information about who is listening and about the quality of the network connection to specific clients. To help with this problem, the Windows Media Player includes logging capabilities for multicast transmissions. These are implemented as an ISAPI DLL called Nsiislog.dll that runs on the IIS Service. To enable logging, (it is disabled by default) follow these steps:

  1. Verify that the IIS directory containing nsiislog.dll is shared as a Web directory. Network clients must be able to access this file.

  2. In the Windows Media Administrator menu frame, click Multicast Stations. The Multicast Stations page appears.

  3. Under Stations, click the station for which you want to create the logging file, then click Stations, and then click Properties. The Edit Station page appears.

  4. On the Edit Station page, in Logging URL, type the URL to Nsiislog.dll and then click OK. For example, type https:// server_name /scripts/Nsiislog.dll, where server_name is the name of the IIS server.

For more information on enabling logging, see the Windows Media Administrator Help files.

In general, the statistics fall into one of three categories: transmission quality, content information, and client information. Examples of transmission quality statistics are:

  • How many packets were dropped

  • How many packets were resent

  • How many bytes were transmitted

Examples of content information include:

  • Which audio and/or video CODECs were used

  • What the URL of the .asf file is

  • What the embedded URL is

An embedded URL is the URL of the Web page that contains an embedded Windows Media Player. By knowing this URL, you can discover who is using your content.

Examples of client information include:

  • The Windows Media Player Globally Unique Identifier (GUID)

  • How long a client received a particular stream

  • The IP address of the client receiving the stream

  • The Internet service provider (ISP) the client used

Other Uses for Multicast

Multicasting can be used to distribute files other than .asf files. Any time a single stream of data needs to be sent to multiple users, multicast should be considered as a way of conserving bandwidth. (This assumes that the network can support multicast. This is true, for example, if the network consists of a single LAN, or if the network devices, such as routers, support multicast.) A common example is to use Windows Media Technologies multicast to send Microsoft PowerPoint® presentations over a network, but it can be used with other types of files, or directories of files, as well. To configure a multicast file transfer, select the Multicast File Transfers option displayed by the Windows Media Administrator. There is a variety of parameters that can be set, including:

  • The maximum bandwidth that should be used to send the data

  • The duration of the transmission

  • Whether clients can request that the server resend dropped packets

For more information, see the Windows Media Administrator Help files.

Troubleshooting Multicast Transmissions

Although a complete guide to troubleshooting a multicast session is beyond the scope of this paper, this section includes some suggestions that may make your task simpler. Also, although not discussed in this paper, there are similar statistics available for unicast as for multicast. For more information on logging capabilities, see the Windows Media Administrator Help files.

Checking the Files

First, make sure that the asx and .nsc files are accessible and that they contain no errors. Without these files, clients cannot join the multicast. Remember that if a default template for the encoder was not used, or if any of the values were changed, the .asd file must be specified. If any changes were made to the encoder after the multicast was configured, you must re-specify this file so that the .nsc file is up-to-date. If anything in the server configuration has changed since the multicast was configured, re-export the .nsc file. To do this, select Multicast Stations on the Windows Media Administrator, and then select Export.

Checking Statistics

During the transmission, use the Windows Media Player to check statistics. To do this, right-click on the Windows Media Player and click Statistics. An example display is shown below, in Figure 26:

Figure 26: Windows Media Player Statistics

Figure 26: Windows Media Player Statistics

Make sure that Protocol is set to Multicast. Check Packets Recovered and Packets Lost to see if data is being lost. If the Packets Recovered counter is incrementing, the Windows Media Player is reconstructing packets that were dropped. This may be a sign of problems in the network. (These statistics are available for unicast broadcasts, as well.)

If, when configuring the multicast session, you enabled logging, you can use the Nsiislog.dll log to get more information once the session is over. Try to find trends, such as many users on a single segment having a problem.

Keeping Track of IGMP Versions

Be aware that different versions of the Windows operating systems implement different versions of the Internet Group Management Protocol (IGMP), which is used by clients to join a multicast session. The following table summarizes which version of Windows uses which version of IGMP:

Operating System

Version of IGMP

Windows 95

Version 1

Windows NT® 4.0 with SP3 or earlier

Version 1

Windows 98

Version 2

Windows NT 4.0 with SP4 or SP5

Version 2

Windows 2000

Version 2

Isolating the Problem

Unless you are multicasting over a single LAN, multicasting typically involves multiple subnets and routers. Start on the segment where the server resides and move, hop-by-hop, through the network to try and isolate the problem. Also, make sure that the time-to-ive (TTL) value is high enough to take the packet through every hop it must traverse. Basically, the TTL should equal the number of hops. If this number is too low, the packet will be discarded before it reaches the edges of the network. The default value is 5. To set the number of hops, click Configure Server, and then the station you want to edit. The Configure Server – Edit Station dialog box opens, shown below in Figure 27:

Figure 27: Changing the TTL Parameter

Change the TTL entry to a higher value.

Finally, look for firewalls or any non-multicast enabled devices that might block the transmission to some segment of the network. If a router or switch that the packets must traverse doesn't understand multicast, then the packets are dropped. Also, as mentioned earlier, many firewalls will not pass UDP packets, which is the transport used for multicast transmissions.

There are a number of third-party monitoring tools available for investigating network problems and the Windows 2000 operating system itself contains some utilities. We will briefly discuss two: the network monitor and the tracert utility.

The Network Monitor

The network monitor, available with the System Management Server and, in an abbreviated version with the Windows 2000 Server, allows you to look at packets on the network. To access the network monitor, point to Programs on the Start menu, point to Administrative Tools, and click Network Monitor.

The Network Monitor is illustrated below, in Figure 28:

Figure 28: The Network Monitor

The Network Monitor works by placing the NIC of the capturing host into promiscuous mode so that it passes every frame seen on the wire to the tracing tool. Capture filters can be defined so that only specific frames are saved for analysis. These filters can be configured based on source and destination NIC addresses, source and destination protocol addresses, and pattern matches. Once a capture has been obtained, display filtering can be used to further narrow down a problem. Display filtering allows specific protocols to be selected as well. For more information on using Network Monitor, consult the Help files.

The Tracert Utility

The tracert utility operates by sending a succession of groups of packets toward a specific destination--the IP address of the desired destination computer. If you want to trace the route from your machine to whitehouse.gov, for example, type: tracert whitehouse.gov. Each router along the path returns information to the machine that initiated the trace, showing the user the IP address of the machine that received the packets and the round-trip time (in milliseconds) of each packet. When the trace is complete, you will know the number of hops the packets needed to move from origin to destination, as well as the time taken by each hop.

The crucial component of the tracert operation is the TTL (time-to-live) values of the packets. Tracert sends a succession of three-packet groups with increasing TTL values. Along the path, each router decrements the TTL value by 1, then passes it along to the next router. The first group of packets is sent with a TTL of 1. The router at the first hop decrements the value to 0, causing the packet to expire, and sends the expiry information back to the origin machine. The second group then goes out with a TTL of 2, with the second router rather than the first returning the expiry information. This continues until either the maximum TTL value is reached or, ideally, the destination computer receives the packet. The tracert utility has a default maximum TTL value of 30, which means it can report the first 30 hops. You can increase this value by using the -h option (enter tracert alone on the command line for the list of options).

A sample tracert session is shown below in Figure 29:

Figure 29: Sample tracert Session

  • Following is a response time rule of thumb:Up to 200 ms is good.

  • 200 to 500 ms is marginal.

  • Over 500 ms is unacceptable.

  • An asterisk instead of a time means there was no response at all.

For more information about tracert, see the Windows 2000 Help files.

Load Balancing

Load balancing distributes the processing load across an array of servers so that no one server bears the brunt of the work. It may also provide failover ability, which switches the load from a failed server to one that is functioning. There are several ways of implementing load balancing. They include:

  • Domain Name Service (DNS) round robin

  • The Windows Load Balancing Service

DNS Round Robin

The DNS round robin method works by answering DNS queries with an entire list of IP addresses rather than a single IP address. The Windows Media Player that performed the query usually chooses the first IP address and references that server for the duration of the connection. To ensure that the same IP address isn't chosen over and over, the list is rotated so that a different IP address appears at the top of the list each time.

As an example, assume we have three servers, whose names and IP addresses are:

  • example.microsoft1.com at 150.1.1.1

  • example.microsoft2.com at 150.1.1.2

  • example.microsoft3.com at 150.1.1.3

To set up the servers so that client requests are rotated via round robin use multiple A records. (These DNS records map hosts to IP addresses.) In our example, we want all clients that access the site to use the name example.microsoft.com but for these requests to be shared among the three servers. We set up the A records as follows:

  • example.microsoft.com. 60 IN A 150.1.1.1

  • example.microsoft.com. 60 IN A 150.1.1.2

  • example.microsoft.com. 60 IN A 150.1.1.3

The period at the end of the name example.microsoft.com in each A record is mandatory because names without trailing dots are sometimes interpreted as relative to some domain other than the root, just as directory names without a leading slash are often interpreted as relative to the current directory. The trailing dot indicates that the domain name is absolute, which means it is written relative to the root. The TTL field in our example tells the name server to remove these entries from the name cache after 60 seconds. This ensures that the records aren't cached for long periods of time on intermediate name servers that don't support round robin.

Advantages and Limitations of DNS Round Robin

The main advantages to DNS round robin are that it's simple and it's free. Adding a few records allows a pool of servers to appear to act as a single server when, in reality, requests are being rotated among all the hosts in the pool. The first limitation is that round robin is really neither a load sharing technique nor a load balancing technique. Actual load balancing solutions measure the load on the servers and gauge where to send the client requests in order to distribute the work evenly. Round robin doesn't measure the server load in any way—it simply alternates client requests among multiple hosts, regardless of the server's capabilities. One or more of the hosts tend to get more activity than the other hosts do. The second limitation is that, if one of the servers is down, requests from clients will still go to this IP address, and these clients will not receive a proper response.

Windows Load Balancing Service

The Windows Load Balancing Service (WLBS) allows incoming IP traffic to be dynamically distributed across multiple servers. WLBS transparently distributes the client requests among the hosts and lets the clients access the pool using one or more virtual IP addresses. From the clients' point of view, the pool appears to be a single server that answers these IP addresses. Customers often ask if they should use WLBS or the Microsoft Cluster Service (MSCS) with Windows Media: the answer is to use WLBS. MSCS, discussed below, is for data-intensive applications such as Microsoft SQL Server™.

WLBS servers communicate among themselves to provide the following:

  • Failure detection. The WLBS servers emit heartbeats that the other WLBS servers monitor to make sure all the servers are healthy. If a server fails, the others adjust and take over the workload.

  • Load balancing. WLBS servers use a distributed algorithm to statistically map the workload. The hosts communicate with each other to determine the status of the pool and which hosts are available for load balancing.

  • Scalability. WLBS scales to meet the demands of the service. As traffic increases, just add another server to the pool, with up to 32 servers possible in any one pool.

You can configure WLBS to load balance on multiple servers filtered to use single affinity, no affinity, or Class C. The best choice for Windows Media Server servers, which is a non-stateless application, is single affinity. When configured for single affinity, all incoming packets using the WLBS virtual IP address are locked to a specific node in the WLBS cluster. Every packet that is sent from the client using the cluster IP address connects to that node.

Microsoft Cluster Service (MSCS)

The MSCS is used with data-intensive applications such as SQL Server and Microsoft Exchange Server. It should not be used for load-balancing Windows Media services. However, the WLBS and MSCS technologies can be used together to provide a very high degree of scalability and availability for an entire site. For example, a database-driven site can host its database on a MSCS cluster that is accessed by WLBS-clustered HTTP and Windows Media-based servers. This configuration provides a high degree of availability at the database level and a high degree of both scalability and availability at the Web/HTTP level.

WIndows Media Player HTTP Error messages

The network error messages that may occur while the Windows Media Player is running are standard HTTP 1.1 status codes, defined in RFC 2068. This is available at:

ftp://ftp.isi.edu/in-notes/rfc2068.txt

The most commonly seen codes are server error messages, which fall in the 5xx range and represent cases where the server is either signaling that it has made an error or that it is incapable of handling the request. These codes are listed below:

Code

Name

Meaning

500

Internal Server Error

The server encountered an unexpected condition that prevented it from fulfilling the request.

501

Not Implented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

502

Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

503

Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay may be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

504

Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server it accessed in attempting to complete the request.

505

HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

More Information

For information about Windows Media Technologies, software downloads, and links to articles about creating and deploying content, see the official Windows Media Technologies web page at:

https://www.microsoft.com/windows/windowsmedia/default.aspx

For answers to specific technical questions, use the Microsoft Knowledge Base. It is located at:

https://www.microsoft.com/support/kb.htm?RLD=32

There are also several public newsgroups users can subscribe to. They are:

  • microsoft.public.windowsmedia.technologies

  • microsoft.public.windowsmedia.technologies.beta

  • microsoft.public.windowsmedia.technologies.rightsmanager.beta