Windows Media Services Deployment Guide

Abstract

With Microsoft® Windows Media™ Technologies you can create, deliver, and play streaming media files for applications ranging from news and entertainment to e-commerce to corporate communications and training. Windows Media Technologies components include Windows Media™ Tools, Windows Media™ Services, and Windows Media™ Player. Together, these components provide an end-to-end solution for streaming multimedia, from content authoring to delivery to playback.

This document is designed to be a guide to help you build an infrastructure to use Windows Media Technologies. It is intended for IT professionals who want to implement Windows Media Technologies as an easy-to-use, feature rich, and powerful streaming media platform.

On This Page

Introduction
Before You Begin
About Windows Media Services
Microsoft Solutions Framework
Envisioning
Planning
Developing
Implementing
Running IIS and a Windows Media Server with HTTP Streaming Enabled
Support
References

Introduction

Welcome to the Microsoft® Windows Media™ Services deployment guide. This guide is written for information technology (IT) professionals involved in deploying Microsoft® Windows Media™ Technologies in their organizations.

This guide is intended to help you take your Windows Media solution from pilot to production environment. It explores the best practices for configuring, testing, and deploying Windows Media Services in large-scale environments.

This guide follows the Microsoft® Solutions Framework (MSF) structure, as described in the Microsoft Solutions Framework section, and is a suggested method of deployment, which may or may not be appropriate in your case.

Before You Begin

Recommended Reading

You should be familiar with the following list of documents and references:

• Online documentation included with Windows Media Services

• TCP/IP Implementation Details

• Domain Planning Guide

• Web Services Deployment Guide

• Multicasting White Paper

Assumptions

In addition, you should be familiar with the following networking concepts:

• Microsoft® Windows 2000 Server networking

• Windows 2000 and Windows NT domain structure and security

• TCP/IP networking concepts

You should also have a basic knowledge of Windows Media components and their roles, relationships, and interactions.

This document assumes that you have an existing Windows NT or Windows 2000 Server environment and that there is an existing intranet infrastructure.

About Windows Media Services

Microsoft® Windows Media™ Services is the component of the Microsoft® Windows NT® Server and Microsoft® Windows® 2000 Server operating system software for streaming multimedia content over the entire range of an enterprise network; from low-bandwidth, dial-up Internet connections, leased wide area network (WANs) to high-bandwidth local area networks (LANs). When companies, educational institutions, and other organizations use Windows Media Services, they can stream multimedia content for applications such as employee training, corporate communications, entertainment, educational programs, and advertising to users all over the world. Windows Media Services is a powerful media delivery system that is easy to use.

What's New In Version 7.1

• An update to Windows Media Player. Windows Media Player 7.1 has several enhancements that make it a step up from Windows Media Player 7. Two examples are: CD copying using Windows Media Audio 8 codecs and smart transcoding to WMA.

• An Enterprise Deployment Pack for Windows Media Player 7.1 provides several benefits for corporate customers. Windows Media Player has new features such as: pre-installed version 8 codecs, improved authentication, and cache/proxy support, that are of particular importance to enterprise users. The deployment pack explains these features.

• The Windows Media Audio 8 and Windows Media Video 8 codecs have been added to Windows Media Encoder 7.1.

Features

• Highest quality audio. Windows Media Audio 8 offers CD-quality audio at 64 kbps, and near CD-quality audio at 44 kbps. 28.8 kpbs modem users can listen to Windows Media audio files at FM-stereo-quality music.

• Wide bandwidth range. Offers one of the industry's widest range of bandwidths for high-quality streaming, ranging from mono-quality audio of 2.4 kilobits per second (Kbps) to broadcast-quality video greater than 6 megabits per second (Mbps). Provides the highest quality in the industry at every data rate.

• Advanced compression technologies. Delivers better media quality with faster encoding speeds through two new codecs.

• Intelligent streaming. Allows multiple bit rates to be encoded in the same file, and facilitates communication between client and server to dynamically determine the correct stream based on network conditions. Intelligent Streaming can be used for both Windows Media files and live-encoded streams.

• Built-in Multicasting Support. Provides optimal multicast support, allowing a business to conserve network bandwidth while supporting very large audiences during multimedia events and broadcasts. Managing server environments and multicast streams is simplified with new administrative wizards.

• Multiple bit rate encoding. Enables developers to encode multiple data rate streams into a single streaming media file, so users click once and always receive high-quality video, regardless of the speed of their network connection.

• Highly scalable. Supports more than 9000 clients connecting simultaneously at 28.8 Kbps– the most cost-effective solution in the industry. Fully multithreaded for greater scalability with dual processors.

• Built-in multicast service. Conserves network bandwidth by delivering a single stream of high-quality video to support unlimited users.

• Fast video encoding. Encodes lengthy, on-demand content at the fastest rate in the industry, saving content producers valuable time.

• Encoding profiles for wireless streaming. New encoding profiles enable Windows Media Encoder to deliver a video stream designed specifically for playback on a portable device such as a Compaq iPAQ with a wireless NIC (network interface care).

• Microsoft® Windows NT® Load Balancing Service. Enables multiple Windows NT servers running Windows Media Services to be clustered for greater scalability and availability.

• Seamless stream switching. Provides a smooth viewing experience by eliminating delay between linked content segments, regardless of data type.

• Scalable to full-screen. Video playback window can be increased up to full-screen.

• Integration with other Microsoft products. Enables you to leverage your investment in other Microsoft products such as Windows 2000 Server, Microsoft® Office, Microsoft® Internet Explorer, Microsoft® Site Server, and the rest of the Microsoft® BackOffice® family.

• Server throttling. Enables administrators set limits on total bandwidth and the number of connections to a Windows Media server.

Windows Media Applications

Multimedia provides people with an exciting new way to communicate. Moving images and sound add a new dimension to communication, and greatly enhance the power of text and graphics. Multimedia-enabled applications are the next wave of Web-based technology, and Windows Media Services provides the complete platform for integrating audio and video into Web-based applications to deliver advertising and retailing, corporate communications, entertainment and information, and training.

Training

Many organizations devote substantial resources to training employees. Using Windows Media Services to extend the reach of professional instructors through corporate intranets allows organizations to obtain the full value of their resource investment.

Microsoft® Windows Media™ Tools makes it easy for trainers to create training content, and for employees to receive this training whenever and wherever they need it. For example, a speech recorded in conjunction with a slide presentation can form a Windows Media Services broadcast. The training material can be provided to all divisions and subsidiaries of a corporation, so all employees have the advantage of hearing the material delivered from the same speaker.

Delivering multimedia data and presentations over corporate networks and the Internet can help companies save money formerly spent distributing training materials in binders or on CD-ROMs. Because hard-copy materials go out of date quickly and are expensive to revise, the ability to update Windows Media content immediately on the network can provide more current information and save money.

Corporate Communications

Using Windows Media Services, everyone in an organization, regardless of their geographic location, can hear important internal presentations or customer events as they occur. These same presentations can be captured for later playback to those who missed the initial, live presentation. Stored presentations can grow into a library of on-demand information for reference or training.

Windows Media Services can reduce the burden of having employees travel to a central location for a training session by streaming the session over the corporate network to each employee's computer. Windows Media saves time for the presenters, who only need to deliver their messages once to reach everyone in the enterprise – saving time and money while delivering the information more quickly to the target audience.

Knowledge Management

Using Windows Media Services, knowledge workers can easily capture, store or retrieve information pertinent to their decision-making. Using video capabilities, employees can record and share their best practices and lessons learned from key projects or experiences, capture important meetings and presentations, or even create project-related video journal entries. Employees can access this information whenever they need it. They can use search tools to categorize content by title, description, author, date, etc.

Windows Media Services offers you new options for sharing and interacting over several sites. Innovation depends on information sharing, collaboration on new ideas, and empowering employees to put these ideas into action. Windows Media can play a vital role in removing the barriers to efficient knowledge flow. Making relevant information and expertise instantly accessible throughout an organization can improve the speed and quality of decision-making and transform it into a competitive advantage.

E-Commerce, Advertising, and Retailing

Web pages that use audio and video to advertise products or services can be much more compelling than Web pages that only rely on text and graphics for advertising. For example, on a Web site, you can use audio commentary with images to guide users through product demonstrations, processes, or the site itself. You can advertise and show a product or concept to its best advantage with the rich, synchronized sounds and images of Windows Media illustrated audio.

When you use Windows Media Technologies to promote and sell products on Web sites, you can stream your messages to users. When users receive streamed messages, they can begin viewing them without waiting for the entire movie or audio clip to download to their computer, thus avoiding frustrating delays.

Microsoft Solutions Framework

Introduction

Microsoft Solutions Framework (MSF) is a suite of models, concepts, and guides for building and deploying distributed enterprise systems. MSF helps to align business and technology objectives, reduce the lifecycle costs of using new technology, and deploy Microsoft technologies.

Phases

The MSF process consists of four phases:

1. Envisioning, at the end of which the vision, scope, and goals are set.

2. Planning, at the end of which all plans, schedules, and designs are ready.

3. Developing, at the end of which the first version of the product/service is "in use."

4. Stabilization, at the end of which the final product/service is released for general use.

   

Teams/Leads

To implement a project using the MSF model requires a team that performs multiple functions. Some of the functions may require sub-teams, in which case one person may fill the role as the lead of a sub-team.

Deployment Team/Lead: A facilitator, and an experienced person in many different areas, the Deployment Team Lead should have a solid working knowledge of the overall network and application services in the environment and should have a positive working relationship with the specific leads on the team.

Product/Technology Team/Lead: The Product Technology Team Lead must be very familiar with the existing technology at use in the organization for all components related to the server operating system. This lead should also develop a thorough knowledge of the product being deployed and be very active in all aspects of the deployment project.

Corporate Standards Team: Members of the Corporate Standards Team should be well versed in the corporate standards for the server operating system, as well as the ancillary technology that provides connectivity of applications and/or network services. They are responsible for writing the standards guidelines for the high-level product configuration, as well as standard administration and management models.

Training Team/Lead: Thorough training of the customer's internal organization is essential for the success of the deployment project. Typically, training is often considered as a peripheral issue that needs to be addressed. However, the importance of deployment team training is critical for the deployment and helpdesk teams, not to mention the end users. By involving the training group from the outset, the Training Team Lead can correctly make the necessary plans to have the resources available and trained in a timely and cost-effective manner.

Help Desk Team/Lead: It is essential that the Help Desk Team Lead and the Deployment Team have ongoing communications, and that the Help Desk Team Lead is a dedicated participant on the Deployment Team. The Help Desk Team provides valuable feedback on its experiences with previous deployments. This team can provide insightful information on how to avoid common, possibly chronic deployment problems that could increase the cost of the deployment process in both time and resources.

Network Infrastructure Team/Lead: The Network Infrastructure Team Lead is responsible for the product deployment in the scope of the overall network infrastructure. This includes understanding the technology, traffic loads, traffic patterns, and how the new services will affect the existing corporate network infrastructure. The Network Infrastructure Team Lead is responsible for all communications to the Network Infrastructure group within the organization.

Deliverables

Various documents can be produced during the MSF process to track progress of the project:

Vision and Scope Documents

The Vision and Scope Documents are the basis on which the rest of the planning is performed. The Vision Document is usually phrased in technology-neutral terms and focuses on meeting a business need. It should include the business objectives and a high-level functional objective.

The Scope Document establishes the achievable limits in accordance with the user needs and requirements. It focuses the vision within manageable parameters and establishes achievable limits for the project. The scope may be phrased in more technology specific terms. It should include a preliminary projection of the target population, such as users and systems, a preliminary goal for performance and capacity, and a preliminary feature set.

The Vision and Scope Documents are delivered during the first phase of the project.

Risk Assessment Document

Assessment of risk is a continuous process throughout the project. A risk is broadly defined as any issue that threatens the overall success of the project or affects the ability of the team to fulfill the vision and scope. The identification of risk becomes a critical success factor for a project team. Schedules for all phases must use risk assessments as their fundamental planning assumptions.

The Risk Assessment Documents (in one form or another) are delivered during each phase of the project

Design Documents

The Design Documents describe:

• Administrative and security roles design

• Namespace and naming standards design

• Windows Media server hardware and software configuration design

• Windows Media client hardware and software configuration design

• Internet network layout design

• Intranet network layout design

• Extranet network layout design

• Migration and upgrade procedures design

• Training manuals

• (Updated) Risk assessment document

The bulk of this documentation is delivered during the Developing and Implementing phases.

By the end of the Developing phase, objectives as creation of release notes, training manuals, documentation and performance assistance tools, issues and bug database, and facility and platform installation should be fulfilled.

Envisioning

Sample Project Outline

A sample Windows Media Technologies deployment plan is included with this document in Microsoft® Project 98 format. It is a variation of the generic MSF structure, and describes the phases and resources needed to conduct a successful implementation of Windows Media Technologies in your organization. The project plan assumes a medium-sized company of 2,000 employees or more and a deployment schedule of nine weeks.

This sample plan should be treated as an example rather than as a step-by-step manual. Specifics of your business may require a different approach to Windows Media deployment, and MSF enables you to be flexible while still complying with general guidelines.

The following project outline is a sample (milestones only).

Sample Windows Media Deployment Project Plan

1. Envisioning

   • Define Needs (What does my company need streaming media for?)

   • Identify Audience

   • Review Project Objectives and Fit

2. Planning

   • Identify Content Sources

   • Bandwidth Considerations

   • Design Architecture

   • Master Plan and Schedule

3. Developing

   • Test Server Installation

   • Test Client Upgrade/Installation

   • Content Creation

   • Intranet Integration

   • Internet Integration

   • Extranet Integration

   • Final Design (putting all together)

   • Integrated Beta Testing

4. Implementing

   • Pilot Test

   • Support Review

   • Security Review

   • Technical Review

   • Release to Production

Planning

Basics

When planning to implement Windows Media Services, there are several issues and considerations that will affect your ability to achieve a successful implementation. Some of these issues are discussed in the following section.

Streaming Server vs. Web Server

One fundamental question to ask before embarking on a streaming infrastructure implementation is whether streaming is required at all. Depending on your needs, using a Web server to deliver media clips to your viewers may be suitable for real-time multimedia delivery.

By hosting media content on a Web server, the client starts playing the audio or video while it is downloading, after waiting only a few seconds for buffering. This small buffer allows the media to continue playing uninterrupted even during periods of high network congestion. With this delivery method, the client retrieves data as fast as the Web server, network, and client will allow without regard to the bit rate setting of the compressed stream. It is possible, if network conditions permit, for most of the media file to be transmitted to the client in the first few moments of playback, so that the file plays back from the local buffer. This form of delivery, called bursting, is characterized by a spike in network utilization as a client requests a media file.

Using a streaming media server, rather than a Web server, data is delivered at the exact bit rate associated with the compressed audio and video streams. The server and the client stay in communication during the delivery process, and the streaming media server can respond to any feedback from the client. Aside from the buffer, data is never stored on the client; rather, it is played and then "thrown away." Streaming, unlike bursting, is a steady method of delivery.

Using a streaming media server offers many advantages over Web server delivery, such as more efficient network throughput, support for VCR-like controls including fast forward and rewind, dynamic quality adjustment based on network conditions, multicast delivery, and improved scalability. Nevertheless, Web servers may be an acceptable solution in environments where there is a strong Web server infrastructure and there is a need for infrequent on-demand clips.

Outsourcing

In certain scenarios, turning to third-party vendors for hosting or creating your content may be a more cost-effective solution than building an in-house streaming media infrastructure. Initially, outsourcing your hosting or production can be used to phase in your streaming media architecture.

For example, if a company has thousands of hours of training videos, it may be cost-effective to outsource the process of converting the videos to digital media. Once a digital video library of training classes is created, any future videos can be converted in-house and added to the library.

Many Internet service providers (ISPs) offer streaming media solutions for hosting your live events, company meetings, classes, or product demonstrations. These events can be streamed over the Internet or the ISP's own private network to your remote sites or dial-up users in distant locations. You may choose to outsource high-volume events such as live streaming, and host the on-demand streams yourself when the event is finished. See the Windows Media Technologies Web site for a list of Windows Media Hosting Providers.

Pre-configured out-of-the-box solutions designed for specific needs of a company may be useful in your enterprise. The Windows Media Training Server, for example, jointly developed by Microsoft and Compaq, is a simple plug-and-play solution for delivering technical information and training to employees in your organization. Windows Media Training Server includes hardware, software, ready-to-stream Microsoft and Compaq seminars, and a simple administrative interface that IT managers can use to add and update company-specific content.

Capacity Planning

It is difficult to project the number of users you need to plan for in a deployment because the number can vary greatly based on the type of event, duration, and reach of the audience. In a large enterprise, when calculating the number of concurrent users, consider time zones, network traffic during different business hours, and viewer interest.

One way to determine usage is to conduct a limited pilot project involving the different areas of your organization. By examining usage logs generated by the Windows Media server during the pilot, you can determine the average number of concurrent connections achieved. This average can be extrapolated to give a metric for the entire organization.

This method, however, is flawed for two reasons; as a new technology becomes available, either users will use it infrequently until they get used to it, or they will use it more frequently in the beginning and then less and less as the "newness" factor decreases. So a pilot project should be used to build a basic expectation of usage and after the service is put into production, usage should be monitored and capacity adjusted as needed.

Migration

Many organizations that already have version 4.0 of Windows Media Services (which is for use on Windows NT 4.0), or version 4.1 (which is an optional component in Windows 2000 Server) streaming infrastructure may want to take advantage of the improved features found in the Windows Media Technologies 7.1 suite. Deploying Windows Media Technologies 7.1 can be gradually phased in with minimal downtime.

Of all products in the suite, Windows Media Services, has the least amount of change. Download the Windows Media Services Add-In to take advantage of the increased opportunities in Windows Media Player 7.1. If you do not care about adding or replacing ads in your streams, then you don't need to change your server. Version 4.1 servers work will all Windows Media 4.1 components. Version 4.1 servers are backward-compatible with version 3.0 on-demand content and live streams from a version 3.0 instance of Windows Media™ Encoder. Windows Media Services 3.0 and 4.1 can also co-exist as downstream distribution servers for content encoded prior to the release of Windows Media 4.1 content. Both version 3.0 and version 4.1 of Windows Media™ Administrator can be used to administer version 3.0 and version 4.1 services.

Versions 3.0 and 4.1 of Windows Media Tools should be upgraded to Windows Media Tools 7.1 to produce on-demand and live content; however, a server with Windows Media Services 4 or later is required for multiple bit rate encoding support. Single bit rate files encoded with a version 4.1 Windows Media Encoder are backward compatible with Windows Media Services 3.0.

With its automatic codec download feature, instances of Windows Media Player earlier than version 6.4 can continue to play Windows Media Technologies 4.1 content encoded with the new Microsoft Windows Media Audio and MPEG-4 version 3.0 codecs. Therefore, earlier versions of Windows Media Player do not have to be upgraded if they are already deployed within your organization. Upgrading to Windows Media Player 6.4 or later adds multiple bit rate support and support for playback of licensed content that was encrypted using the Windows Media Rights Manager software.

Upgrading to Windows Media Player 7.1 from version 6.4 provides the opportunity to copy CDs to your PC using the Windows Media Audio 8 codecs, organize all music on your computer, add skins to the player, view visualizations while listening to audio tracks, and transferring music on your PC to your portable device.

Security

Microsoft Windows Media Services includes built-in security features that integrate fully with Microsoft Windows NT Server version 4.0 and Windows 2000 Server to control access to content and Advanced Streaming Format (ASF) files or streams.

Using Windows NT or Windows 2000 security, helps you protect your computer and its resources by requiring assigned user accounts. You can control access to all computer resources by limiting the user rights of these accounts. The settings for these features are configured easily by using Windows Media Administrator and Microsoft® User Manager (under Windows NT Server 4.0), or the Local Users and Groups tool (under Windows 2000 Server).

Windows 2000 introduces a number of new security features:

• Central storage of security policy and account information

• Automatic updating and synchronization of all security policy and account information across domain controllers

• Per-property access control for objects

• Transitive trust relationships between domains

• Multiple authentication mechanisms, for authenticating both internal and external users, including users of Windows NT Version 4.0

• Common administrative tools to manage access control and account information

• Smart card support for secure storage of user credentials

• Encryption for data that is transported over the network or stored on disk

For more information on Windows 2000 security, see your Windows 2000 Server documentation.

Authentication

Windows Media server components can be configured to require clients to be authenticated before they can access Windows Media unicast content. Authentication is the process of verifying the identity of a user, usually through a user name and password. When a user is authenticated, the security permissions for the user are read from the security database. This information is passed to the server, and either the requested title is opened or the request is rejected. Only one type of authentication can be presented to the client at a time, so the type must be determined before any attempt is made to authenticate the client. Authentication is not enabled by default when Windows Media component services is installed; however, you can enable one of the three authentication packages installed with Windows Media Administrator:

• Windows NT® LAN Manager (NTLM) authentication and NTLM account database authentication. This mechanism uses an encrypted challenge/response scheme to authenticate the user who is logged on to the client computer against a Windows NT domain. This form of authentication is best used on an intranet, where all users are part of the same or trusted domain.

• HTTP-BASIC authentication and NTLM. This is the same as the mechanism described in the previous paragraph, except users are prompted for a domain, user name and password before they are granted access to the media. For example, to play ASF content from a publishing point, the client must supply a user name and password. This method is best for use on the Internet or for intranet environments that require cross-platform authentication.

• HTTP-BASIC authentication and Membership Services. This mechanism verifies the client by checking client credentials against user accounts stored in a Microsoft® Membership Services database. Membership Services is a feature of Microsoft® Site Server version 3.0, a member of the Microsoft BackOffice product family. This form of authentication is best for non-Windows NT domain intranets or large-scale Internet and/or intranet implementations.

Authentication can be extended via the Windows Media Services Software Development Kit (SDK) to work with any ODBC-compliant user database.

Authorization

Authorization refers to a security feature for granting or denying access to protected resources based on the privileges of an authenticated user. For Microsoft Windows Media Services, the protected resources include content or media to which you want to control access, such as real-time content. Authorization works hand in hand with authentication, which confirms the user identity. In general, a user who fails authentication does not have permission to access the requested resource.

By enabling Access Control List (ACL) checking, a Windows Media server can check the access privileges of an instance of Windows Media Player against the access rights for any .asf, .wma, or .wmv file, directory, or .asf, .wma, or .wmv stream. In addition, you can restrict access to multiple files simultaneously by assigning an ACL to the directory where the files are stored. You can set an ACL for stored content on an NTFS file system partition by assigning an ACL for the file or the physical directory where the file is stored. Furthermore, you can set an ACL for on-demand content stored on a FAT partition by setting an ACL for the registry key associated with the on-demand unicast publishing point. You cannot use ACL checking without enabling an authentication mechanism because unknown users cannot be authorized. Lastly, a Windows Media server can grant or deny access to streams based on the IP address of the client.

Windows Media Tools Packages

There are several Windows Media Tools packages available on the Windows Media Web sites. They include tools and utilities for Windows Media Encoder 7, the Windows Media format, Windows Media services, and content creation. The content creation tools include tools for authoring both live and on-demand content, converting other file formats (WAV, AVI, and MP3) to ASF, WMA, and WMV, add-ins for Microsoft PowerPoint that integrate Windows Media streaming, and more. Except for the Windows Media Encoder and the Windows Media 8 Encoding Utility, all content creation tools are now part of Resource Kit packages that are available from the Windows Media web site (https://www.microsoft.com/windows/windowsmedia). The packages that are available are Windows Media Encoder 7.1 Tools, Windows Media Format 7 Tools, Windows Media Services Tools, Windows Media 4.1 Tools, and Digital Broadcast Manager. Here is a sampling of the files that are available in these packages.

• Windows Media Encoder 7.1. Converts existing AVI, WAV and MP3 files as well as live audio or video into Windows Media 8 Audio and Video format. The encoder can stream live audio or video directly via unicast or multicast, or save it as Windows Media files for future broadcasts with Windows Media Services.

• Windows Media 8 Encoding Utility. A command line utility for encoding on-demand streaming and download and play files. This utility uses the Windows Media 8 Audio and Video codecs. Use this utility for doing two-pass encoding, variable bit-rate encoding, and batch encoding. This utility should be used, in place of Windows Media Encoder 7.1, for doing the encoding best-quality video for download and playback.

• XP or PowerPoint 2000 Presentation Broadcaster. Enables PowerPoint slides to be integrated into any streaming media presentation, from an audio overview to a recorded presentation. For more information on configuring Microsoft PowerPoint 2000 for Presentation Broadcasting, see the article titled Presentation Broadcasting in PowerPoint 2000 .

• Windows Media On-Demand Producer. The Windows Media On-Demand Producer translates AVI and WAV files to Windows Media, enabling high-quality, stream-able file production with very little effort. Video editors can adjust elements such as brightness, contrast, markers, script commands and fade in/fade out.

• Windows Media Plug-In for Adobe Premiere. Enables content creators to output Adobe Premiere movies directly to Windows Media.

• Windows Media Presenter and Windows Media Publish to ASF. Add-on tools to PowerPoint 97 that provide an easy-to-use way to create streaming media presentations using Microsoft PowerPoint. These add-on tools can save PowerPoint 97 slides and accompanying audio clips together as a single ASF file.

• Windows Media Author. A tool for combining audio with still images, such as photographs and original artwork. Based on Digital Renaissance's T.A.G. Editor, Windows Media Author provides tools that insert graphics, markers and URL transitions into the Windows Media stream.

• Windows Media Advanced Script Indexer. This GUI-based tool enables users to edit scripts and markers within any Windows Media-based file and place those scripts in the header portion of the file. This is especially useful if users wish to encode a file and later insert new markers and scripts in the file. .

Multiple Bit Rate Video

Whether you are creating content for live broadcast or on-demand distribution, you can use multiple bit rate video to make your content accessible to users whose network connections range from 28.8-Kbps dial-up modems to high-bandwidth LANs. This is ideal for creating content that will be used by corporate dial-up, WAN, and LAN connected users, or on the Internet between modem users and high-speed DSL/cable modem subscribers.

Using multiple bit rate video enables Windows Media Player to continue rendering content when network bandwidth is reduced. If the server detects a reduction in the amount of network bandwidth available during playback, the lower bandwidth video stream will be sent to the player. The user will experience a slightly lower quality stream during the time when the bandwidth is reduced, but the stream will not be interrupted or buffer to recover from the loss of bandwidth.

Please note that multiple bit-rate content cannot be used for multicast streaming because in a multicast situation clients have no connection to the server and cannot negotiate a bandwidth.

Choosing a Bit Rate

The bit rate of an .asf, .wma, or .wmv stream depends on a number of factors including compression, frame size, frame rate, quality, codec, and type of content. When choosing a bit rate, find the rate at which bandwidth is kept as low as possible while at the same time offering the best user experience. The Windows Media Audio 8 and Windows Media Video 8 codecs are optimized to provide the highest quality sound and video at both low- and high-range data rates. It is important to keep in mind the target bandwidth for which you are authoring. For example, you can achieve CD-quality audio for music at 48 Kbps, but 28.8 kbps modem users will not be able to listen to the stream because it will require excessive buffering that entails a long wait.

If you are planning on supporting a wide range of bandwidths, such as those required by users with dial-up modem and LAN connections, multiple bit rate encoding is a good solution, but not a cure-all. When using multiple bit rates to encode at dial-up (28.8 Kbps) and LAN (300 Kbps) speeds simultaneously, you cannot increase the audio higher than the lowest target bit rate. For high quality encoding, this may not be the best solution. Therefore, it is suggested that you offer multiple versions of your media content, each with a range of connection speeds. For example, you could offer a stream targeted at dial-up modems encoded for 28.8-Kbps and 56-Kbps speeds with a small frame size (176 x 144 pixels) but good image quality and little pixel distortion; a second targeted at ISDN, WAN, and cable modems/DSL users (from 80 Kbps to 128 Kbps) with a larger frame size (320 x 240 pixels) but lower frame rate (15 frames per second [fps]) and some pixel distortion; and a third targeted at users with high-speed LAN connections (250 Kbps to 512 Kbps) at 320 x 240 or larger frame size with full motion (30 fps) and near-digital-quality video.

You should experiment with different types of content and encoding templates, using the Windows Media Tools or third-party tools. When deciding on an acceptable bit rate for your media, consider your network capacity. For help with network capacity planning, see the Network Capacity Planning section later in the document. In addition, see the Windows Media Audio and Video 8 page on the Microsoft Web site for samples of audio and video encoded at various bit rates. The audio comparison page includes comparisons with other common audio formats.

Network Design

This paper is primarily focused on planning for unicast streaming, but recognizes that the difference between unicast and multicast streaming is important in planning your network and your hardware configurations. The total aggregate bandwidth requirements for multicasting are much less than those for unicasting, but the overall network configuration for multicasting could be more complex than that for unicasting.

For a more detailed discussion on multicasting, read the Multicast White Paper on the Microsoft Windows Media Technologies Web site. Other helpful resources on multicasting include the IP Multicast Initiative Web site and the Internet Engineering Task Force (IETF) Web site, which help develop multicast standards.

Protocols

Windows Media Services supports three transport protocols: User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Hypertext Transfer Protocol (HTTP).

UDP is not a session-based protocol. It is often called a connectionless transport protocol. Only unicast UDP is discussed in this section. UDP and TCP run on top of Internet Protocol (IP) networks.

Applications that use UDP typically rely on other mechanisms to guarantee packet delivery. This has several implications that make UDP-based communication especially applicable to streaming media. Because UDP provides very few error recovery services, it is an efficient and direct way to send and receive datagrams over an IP network.

UDP does not provide guaranteed delivery, but it is useful when TCP would be too complex, too slow, or unnecessary. Packets that are not recovered in time to be useful are left out. This allows content to degrade gracefully.

TCP is a connection or session-oriented protocol. Each client connection to the server requires a session setup and breakdown. TCP sessions ensure that packet delivery is completed without intervention from the application using the data. TCP is a more reliable transport that has higher overhead and is more complex than other protocols. Processor utilization and the additional bandwidth required for session setup, maintenance, and breakdown can affect servers.

For the client, TCP adds reliability, which can adversely affect the user experience. If the server is operating under a heavy load, or if there is latency or heavy congestion on the network, TCP causes the client to wait for all packets to be delivered before continuing. If packet delivery is delayed long enough, the player can pause and re-buffer, although it would continue if UDP was used.

In addition to standard transport protocols, Windows Media Services uses three protocols to transfer information between services and to transfer unicast data: HTTP, Media Stream Broadcast Distribution (MSBD) and Microsoft Media Server (MMS) protocol.

HTTP is a TCP-based protocol, and is used to distribute streams between Windows Media Encoder and Windows Media Services. MSBD is also a TCP-based protocol and is used to distribute (or transfer) streams between servers. MSBD is useful for testing client/server connectivity and the quality of Windows Media Services content, but it should not be used as the main method of receiving content. Windows Media Encoder can support a maximum of 50 HTTP clients; Windows Media server components can support a maximum of five MSBD clients. The main method of connectivity between Windows Media Encoder and Windows Media Server should be HTTP. The MMS protocol is used to transfer unicast data. When a client connects by using MMS, protocol rollover is used to obtain the best connection. In the attempt to connect with MMS, the UDP protocol is primarily used. If the connection is not negotiated successfully, the client then attempts to connect with the TCP protocol. If that protocol cannot negotiate a good connection, the client then attempts a connection with HTTP. In this way, an instance of Windows Media Player will find the most efficient way to stream audio and/or video from a Windows Media server.

Firewall Considerations

Many corporations use firewalls to prevent unauthorized access to their corporate networks. Firewalls filter the packets of information that pass across bridges, routers, or gateways, and control traffic between the corporate network and the Internet. Firewalls provide control by monitoring all packets and providing access to only those packets whose source and destination IP address have been given authorization.

If you have problems streaming information past or receiving information through your firewall, you can open different ports on your firewall to allow streaming traffic to pass through. Consult your firewall vendor and the following list to decide if you need to adjust your firewall to accept Windows Media streaming.

Port Settings

To configure a firewall to allow users with the Windows Media Player behind a firewall to access Windows Media servers outside the firewall:

• Streaming ASF, WMA, or WMV with Multicast:

  In: Port between 1-65000

  IP Address 224.0.0.1 to 239.255.255.255

• Streaming ASF, WMA, or WMV with UDP:

  Out: TCP on 1755

  Out: UDP on 1755

  In: UDP between ports 1024-5000

• Streaming ASF, WMA, or WMV with TCP:

  In/Out: TCP on port 1755

• Streaming ASF, WMA, or WMV with HTTP

  In/Out: TCP on Port 80

Port In is the port that the server uses to get past the firewall. Port Out is the port that Windows Media Player uses to communicate with the server.

To configure a firewall that allows users with Windows Media Player outside of the firewall to access a Windows Media server behind a firewall:

• Streaming ASF, WMA, or WMV with Multicast:

  Out: Port between 1-65000

  IP Address 224.0.0.1 to 239.255.255.255

• Streaming ASF, WMA, or WMV with UDP

  In: TCP on port 1755

  In: UDP on port 1755

  Out: UDP between ports 1024-5000

• Streaming ASF, WMA, or WMV with TCP

  In/Out: TCP on port 1755

• Streaming ASF, WMA, or WMV with HTTP

  In/Out: TCP on Port 80

The following firewall configuration allows users with the Windows Media Encoder outside of a firewall to access a Windows Media server behind a firewall:

• Protocol: HTTP

  In/Out: TCP on port 80

The following firewall configuration allows users with a Windows Media server outside of a firewall to access a Windows Media server behind a firewall:

• Protocol: MSBD

  In/Out: TCP on port 7007 if doing Server to Server distribution or any free port that you decide to use for server to encoder communication not using DCOM.

The following firewall configuration allows users with the Windows Media Administrator outside of a firewall to access a Windows Media server behind a firewall:

• Protocol: HTTP

  In/Out: TCP on port 80

• Protocol: DCOM

  In: TCP on port 135

  You must open TCP and UDP on port 135. This port is used for initial Windows Media server-to-client and server-to-encoder communications, as well as essential processes. For more information about using DCOM with firewalls, refer to the Microsoft white paper, Using Distributed COM with Firewalls.

To get the most updated firewall configuration for Windows Media Services , see the Windows Media Technologies Web site.

In cases where firewalls cannot be adjusted to allow open ports for Windows Media streams, HTTP streaming is useful for delivering streams through firewalls. HTTP uses the default port 80, which most firewalls do not block. Although Windows Media Services is configured to use the MMS protocol by default, you can configure it to use HTTP streaming. If the user viewing your video is behind a firewall, it is recommended you enable HTTP streaming in the Windows Media server.

Multicast vs. Unicast

IP traffic can be classified based on different parameters. This document uses classification built upon data-sending methods: unicast (a distinct copy of the data is sent from the source to each client that requests it), broadcast (a single copy of the data is sent to all clients on the network), and multicast (in a one to many environment, a single copy of the data is sent across the network and only those clients who request the data, receive it). Since Window Media Services does not use broadcast, this section focuses only on unicast and multicast.

The definitions indicate the strengths and weaknesses of each method. Unicast sends multiple copies of the same data for each request (in streaming media terms, unicast is a one-to-one connection between the Windows Media server and each client; every client gets its own stream). Multicasting is more efficient in its bandwidth usage because multiple copies of data are not sent across the network. Data is not sent to clients who do not want it (in streaming media terms, multicast is a one-to-one connection between the Windows Media server and a group of clients; every group receives just one stream). The user is simply instructing the network card on the computer to listen to a particular IP address for the multicast. The client does not have to be identified to the computer originating the multicast. Any number of computers can receive a multicast transmission without bandwidth saturation (again, only one copy of the data is sent over the network). For streaming media across an enterprise network, which generates a considerable amount of traffic, multicast is an affordable and effective solution. The following figure reflects unicast and multicast bandwidth usage based on the number of clients. You can see significant savings in the bandwidth when using multicast.

Multicasting has its drawbacks: clients have no control of the data stream – they cannot stop, pause, rewind, or advance it. Multicast streams must be scheduled rather than offered on-demand. Clients can only connect to the multicast stream, or disconnect from it. In addition, to enable multicast, you may have to update your routers and make changes to router configurations.

Table 1 Comparison of Unicast and Multicast

Feature	Unicast	Multicast
Live streaming	X	X
Scheduled streaming	X	X
On-demand streaming	X
Over the Internet	X	Within MBone; tunneling
Video	X	X
Audio	X	X
Multiple bit rate	X
Required bandwidth grows with the number of users	X
Requires multicast-enabled routers		X
User control	X

Currently, multicast is enabled on the Internet on what is called the Internet multicast backbone (MBone). MBone consists of multicast-enabled islands connected by unicast (tunneling). However, most of the Internet is not yet on the MBone. Therefore, private enterprise networks are best suited for multicast.

In summary, plan to use multicast and unicast streaming on your intranet, and unicast streaming over the Internet.

The remainder of this section assumes that unicast will be used to deliver streams to clients unless otherwise stated.

Network Capacity Planning

You will need to determine how much streaming media traffic your network can support as well as how much traffic you want to allow on your network. You can configure Windows Media Services to control the amount of streaming traffic allowed on your network.

Bandwidth

In planning for the deployment of Windows Media Services, you should determine how much bandwidth your network might need to support. To determine this, estimate how many concurrent users you will have on a regular basis and during peak times.

The amount of bandwidth you need to allocate equals the number of users multiplied by the stream size in kilobits per second (Kbps). Suppose you are offering streaming content encoded at a target of 50 Kbps. If you support 100 concurrent viewers on a single network segment, you would require 5 megabits per second (Mbps) of available bandwidth on that segment, according to the following calculation:

(100 users * 50 Kbps) = 5,000 Kbps, or 5 Mbps

When calculating bandwidth requirements, use the actual encoded bit rate, not the target bit rate. For example, the Windows Media Encoder templates for single ISDN lines (56 Kbps) and dial-up connections (28.8 Kbps) encode audio at an actual bit rate of approximately 37 Kbps and 24 Kbps respectively. The discrepancy between actual and target bit rates is because, over dial-up connections, there must be some additional bandwidth available for other traffic (such as compression and error correction) to be transmitted.

Streaming traffic is different from other network traffic. If you have used a network analyzer (for example, Network Monitor, included in the Windows NT operating system) to monitor traffic on your network, you may have noticed spikes in your bandwidth utilization while large files are being copied. Streaming traffic, unlike the burst-like traffic of a typical network, is a consistent stream of data.

It is important to determine how much bandwidth your network can dedicate for streaming without adversely affecting other applications. You should begin by determining a baseline of network usage for a business week. A baseline is a measure of network capacity and performance that is used to compare different configurations. Once you have determined a baseline for network usage you can estimate the additional bandwidth available for the peak of your streaming traffic. Also, keep in mind that when your streaming traffic is at its peak, such as during a company-wide announcement, there will be less traffic from other sources, such as e-mail, Web browsing, and document transfers, because most people will be watching the stream.

For networks with bandwidth constraints, certain techniques can be used to reduce the impact of streaming on the network. For example, frequently requested on-demand .asf files can be scheduled and delivered via multicast rather than made available on-demand. Other technologies, such as content replication, caching, and Quality of Service can also reduce the load on the network. These technologies will be discussed later in the document.

Server Throttling

Windows Media server components allow you to set limits on the number of clients connecting to, and bandwidth served from Windows Media server. For unicasts, limits can be set on a server-wide level, or at the publishing point level. This is useful in preventing your network and server from being saturated by too many client connections.

At the server level, it is also possible to set a maximum bit rate that for any single stream being delivered from the server. The Maximum File Bit Rate parameter limits the amount of bandwidth at which any one file can be streamed. For details on server throttling, see the Windows Media Services Help.

Advanced Network Technologies

Networks are considered to be more or less "intelligent" depending on how hubs, switches, routers, and network operating systems handle the network traffic. Recently, some advanced technologies have been (and are currently being) developed, enabling traffic prioritizing based on contents of the traffic. These technologies are extremely well suited to multimedia streaming, because they can successfully fight network congestion.

Quality of Service

Quality of Service (QoS) is a set of standards enabling network operating systems as well as other networking devices to selectively handle network traffic in the presence of congestion. During periods of congestion, applications with QoS receive preferential access to limited network resources.

Quality of Service (the framework) uses Resource Reservation Protocol (RSVP) to request a specific QoS (a resource) from the network on behalf of an application data stream. A primary feature of RSVP is its scalability. It scales to very large multicast groups because it uses receiver-oriented reservation requests that merge as they progress up the multicast tree. While the RSVP protocol is designed specifically for multicast applications, it can also make unicast reservations.

Microsoft introduced important Quality of Service (QoS) features with the release of the Microsoft Windows 2000 operating system.

802.1p Packet Priority

The 802.1p specification is a standard that hubs and switches use to determine packet priority in an Ethernet network. On a congested network that uses the 802.1p extension, a packet with higher priority receives preferential treatment and is serviced before a packet with a lower priority. With Windows Media Technologies, for example, a multicast stream packet could be given higher priority than other packets on the network, and is therefore less likely to be dropped or delayed by a network device. The stream becomes less sensitive to network congestion, and the user experiences better quality and less buffering. Alternatively, streams can be given a lower priority than other traffic on the network, thereby letting other traffic take precedence over streams.

802.1p is an important component of the QoS features that are part of the Windows 2000 Server operating system. Support for 802.1p packet priority is included in NDIS 4.0 in Windows NT 4.0 and Windows 95 or later.

IP ACLs

Routers have so-called IP ACLs (Access Control Lists). The lists are interface-based, and each of them explicitly defines what range of source and destination addresses, ports, and protocols is allowed.

Contact your router administrator to find out (and modify, if necessary) router settings.

Tunneling

Tunneling refers to the process of distributing multicast packets through a non-multicast environment. Two segments on a network, for example, can have multicast support but the router between them does not pass multicast datagrams. In this situation, a solution is to tunnel the multicast between them. Tunneling can be performed in two ways: through hardware (routers) and through software. Both solutions will be explored:

Tunneling through routers

IP multicast static routes enable multicast paths to diverge from the unicast paths. A multicast static route enables tunneling by configuring a static multicast source. Multicast static routes are local to the router on which they are configured, and not advertised or redistributed in any way to any other router.

Tunneling through Windows Media Services

Another way of tunneling through a unicast environment is to set up both multicast and unicast distribution servers in one multicast zone, and have the distribution server in another multicast zone pulling over the unicast stream by using HTTP and delivering what is received via multicast.

The technology described earlier enables smart handling of large amounts of diverse traffic, thus enabling the streaming data to be seamlessly integrated into the network. It may not be necessary to switch to the new, more advanced networking equipment immediately, but changing to QoS-enabled devices as part of upcoming hardware and software (Windows 2000) upgrades makes sense (and not just for streaming media applications).

Planning for the Future

If your existing network infrastructure prevents you from implementing an entire streaming media infrastructure, start slow and phase in the rest of the design as network conditions improve. For example, if your network is not configured to support multicast, start with low bandwidth unicast and eventually move to higher bandwidth when the network is multicast enabled. Supporting multicast may require router configuration, software, hardware or operating system updates which may not happen all at once throughout your entire enterprise. When multicasting does reach different points in the network, take advantage of it. You could limit the multicasts to just the enabled segments of the network or tunnel the multicast to reach other parts of the network. You could also use a combination of multicast and unicast distribution to support the different parts of the network.

If the bandwidth of your network is constrained, you could start by offering audio only or illustrated audio and eventually move to higher bit rates when the bandwidth becomes available. If you can, multicast live programs or events to begin with, and at a later time, expand availability to on-demand presentations.

Upgrading

If you have determined that your network is not capable of handling streaming traffic, assess the existing network to identify which components can be best upgraded to support what is possible. Cost versus benefit is often an issue when upgrading network infrastructure. Therefore, it is important to understand which upgrades can have the best impact on your organization. Below is a list of possible upgrades, ordered from more to less valuable.

• Implement IP throughout the entire organization. Since Windows Media streaming is only supported over IP, it should be a supported protocol in all of your network communications.

• Update routers to support multicast. In many cases, this may be the easiest way to support streaming. If you are planning on streaming live events the benefits of multicast over unicast are enormous. Routers may require a software, firmware, and in some, cases hardware upgrade.

• Upgrade switches and hubs. In shared desktop environments, replace hubs with switches. In the multicast scenario, this could have a great impact on increasing performance.

• Increase network throughput. Put bandwidth where it counts most – upgrade backbone to ATM or gigabit Ethernet with switched 10 Mbps or switched 100 Mbps Ethernet to desktops, it will have a dramatic affect on network performance.

• Upgrade WAN links. Depending on the number of users you need to support or bandwidth required for the application, consider upgrading your wide area network links. You may be able to identify certain points in your network that would benefit more than one site by increasing available bandwidth over the WAN.

• Use specialized network communication technologies such as QoS, ICMP, and DVMRP.

Scenarios

This section describes scenarios and proposed architectures for deployment of Windows Media in various environments. If applicable, it may be helpful to match your own deployment to one of the given solutions.

Although there are many ways you could potentially use Windows Media Services, this section focuses on the following scenarios:

• Live Executive Broadcast

• On-demand Video Archive

• Live Broadcast For Remote Users

• Bandwidth Constrained On-demand

• Live on the Internet

• On-demand on the Internet

Live Executive Broadcast

In this scenario, a large company wishes to stream a live executive presentation to all of their employees in four different sites, connected together by full T1 links. Most of the network is running 100 Mbps switched Ethernet to the servers and a mix of 10 Mbps switches and 100 Mbps hubs to the desktops. The move to 100 Mbps switched to the desktops is expected to be complete within the next twelve months. The company's routers are not configured to allow multicast traffic, and they do not wish to reconfigure routers, but it is an eventual plan to enable multicast forwarding in the future.

The solution design for this company involves using a mixed multicast and unicast model. In parts of the network that are not multicast enabled, a downstream Windows Media distribution server is deployed and software tunneling is used between Windows Media server on each side of the router to propagate the live stream. Once the unicast reaches the local subnet, all users in the subnet are able to receive the stream via multicast.

Before the event, the event coordinator requests an available class D multicast IP address from the company's network support group for the duration of the multicast. This is to prevent multiple on-going events from using the same multicast IP address.

The Presentation Broadcasting feature of Microsoft PowerPoint 2000 is used to schedule and deliver the live event. Presentation reminders are sent out to the entire company through e-mail, using the existing Microsoft® Exchange messaging infrastructure. Five minutes before the presentation, Microsoft® Outlook® reminds the user that the presentation is about to begin and automatically loads the Web browser to the presentation's URL location.

The live broadcast is accompanied by a two-way, Web-based chat that allows viewers to ask questions during the broadcast and receive feedback in real-time. A moderator fields questions from the audience and reads them to the executive. The executive then responds to the questions during the live broadcast.

On-demand Video Archive

In this scenario the same company wants to make their CEO presentation available on-demand to all users in the company. Business needs dictate that all content must be available to all users within 24 hours of the live event. During the broadcast, a digital copy of the event is saved to a disk for later on-demand encoding.

Each remote site has a server farm of at least two Windows Media servers to support on-demand streams. The Windows 2000 server farm uses Network Load Balancing to provide load balancing and fault-tolerance to the cluster, and allow the cluster to be scaled up if needed. A Microsoft Site Server 3.0 Content Deployment project is set up to replicate all published on-demand Windows Media files over night, when network usage is lowest.

Content creation takes place in the company's main headquarters. Content authors use multimedia-editing tools to clean up the captured video and encode the content at pre-determined bitrates. Once encoded, Windows Media files are published to a central distribution server from where they are replicated to all second level Windows Media servers. A SQL database is put in place that stores the range of all IP addresses in the company as well as the location and associated media server farm. Dynamic .asx (or announcement) files are generated using Active Server Pages (ASP) for each on-demand content stream published. The .asx file performs an IP-lookup against the SQL database when a user makes a request and returns the name of the Windows Media server farm closest to the user's location. Once the .asx files are generated, they are saved on the company's intranet IIS servers and hyperlinks are added to the content.

A transcript of the chat session is captured and provided along with the video in the form of a Web page.

Live Broadcast for Remote Users

In this scenario, the company wants to make their live executive broadcasts available to LAN connected users as well as their off-site dial-up and Virtual Private Networking (VPN) users. They are using Windows 2000 Routing and Remote Access service for 28.8 Kbps to 56 Kbps dial-up connection users and Point to Point Tunneling Protocol (PPTP) for VPN connections from the Internet.

In this design, the multicast infrastructure with tunneling is retained to support the LAN connected users. The multicast station is configured so that it can be accessed as both a multicast (via LAN) and unicast (via dial-up). The live stream is encoded as a multiple bit rate stream at 28.8 Kbps modem, 56 Kbps modem, and 300 Kbps high-speed LAN bit rates. When the stream is multicast, the 300 Kbps band is served; when dial-up modem users request the stream, the Windows Media server calculates the proper band to deliver based on the modem connection speed. Windows Media servers are placed in the same subnet as the Remote Access servers so that the dial-up connection users do not have to pull streams over the wide area network.

Since VPN users in this scenario can access the Internet from any number of local ISPs, the company has an ISP host the live event for them on the Internet. This allows the company to support remote users while at the same time not stressing their own links to the Internet. To prevent unauthorized access to the live streams from the Internet, the ISP's media servers are configured to use HTTP authentication against a Microsoft Site Server 3.0 Membership Database. Users connecting via the Internet must supply their username and password to gain access to the live stream.

Bandwidth Constrained On-demand

In this scenario, the company wants to provide on-demand access to training videos and multimedia versions of corporate policies and procedures in a single site. The network infrastructure group has determined that network utilization at the site is very high and they are concerned that the network might not be able to handle the additional burden of on-demand streaming. A network upgrade is planned for the future, but will not be in place for another 12 to 18 months.

In this design, the illustrated audio technique is employed. Quality audio, encoded at a low bit rate and synchronized with Microsoft PowerPoint slides, provides the delivery users are looking for while having a minor impact on network usage. When additional network bandwidth becomes available, the stream's bandwidth can be gradually increased to provide high-quality audio and video.

Network administrators monitor the Windows Media unicast usage logs and determine the top 10 requested on-demand streams. To save network bandwidth, the top 10 streams are streamed via multicast throughout the day. Users can watch the stream during one of its scheduled times throughout the day. This way, higher quality streams, including video, can be delivered over the network.

An internal Web page is used to schedule and advertise the training video's multicast schedule. The schedule is integrated with the company's intranet so that upcoming events can be advertised on the company's Internet homepage. Users can browse the schedule and bring up the event at its scheduled time.

Content authors export the PowerPoint slides to JPG graphic file format and synchronize the audio with the slides. Slides are published on the company's existing intranet Web servers and .asf or .wma files are published to the Windows Media server.

Live on the Internet

In this scenario, a company wants to announce their annual earnings to shareholders, investors, clients, vendors, or partners over the Internet. The announcement should be accessible live. Security is a major concern, as the company does not want the information to be released to the general public. The company would also like to know how many people participate in the live event.

In this design, the company chooses to host their own event by leveraging their high-speed connection to the Internet. A centralized server design is used where the Windows Media servers and a single Web server are placed outside the company's firewall. For the live unicast event, HTTP is allowed on the firewall for the streaming media traffic between the live encoder on the internal network and the media servers external to the network.

Windows Media Services Pay-Per-View Solutions is used in conjunction with Microsoft Membership Server security from Microsoft Site Server 3.0 to create a registration page through which viewers must register and be authenticated before they are authorized to view the live stream.

After the live event, a third-party reporting tool is used to read the Windows Media Services unicast logs and generate a custom report. The Web-based report is posted on the Web server and delivered to management.

On-demand on the Internet

This scenario is very similar to the scenario described in the preceding section. The only difference is that Windows Media Encoder and the firewall are excluded from the schema – all data was recorded in advance and is streamed directly from the Windows Media servers located outside of the internal network.

Server Design

Once you have determined how you will use the Windows Media components, your available bandwidth, and how many users will connect to the system, you can then decide on a server design.

In general, when developing a streaming server platform, the rule is "scale wide rather than scale high." In other words, use a distributed approach rather than a single configuration. For example, consider deploying two dual-processor servers or four single-processor servers in place of one quad-processor server. Using this scheme, you can avoid bottlenecks found in single high-end server configurations by distributing the load. Also, by eliminating a single point of failure, you can make your solution more fault-tolerant.

Server Sizing

Several components contribute to the performance of a Windows Media server. This section describes how CPU, memory, disk subsystem, and network card affect throughput.

Table 2 Windows Media Services Requirements

Component	Minimum required	Recommended	Optimal
Processor	Intel Pentium 166 MHz	Dual Intel Pentium II 400 MHz or better; Alpha processor	Eight Pentium IV-type processors (the fastest available)
Memory	128 megabytes (MB)	256 MB or greater	512 MB
Network card	10-Mbps TCP/IP Ethernet card	10/100-Mbps TCP/IP Ethernet card	Two 10/100 Mbps TCP/IP Ethernet cards
Available hard disk space	21 MB for Windows Media Services; enough disk space for content storage	21 MB for Windows Media Services; 500 MB or more disk space for content storage; SCSI RAID 0	Sufficient storage for on-demand content; SCSI RAID 0
Software	Internet Explorer 4.01 or later; Windows NT Server 4.0 with Service Pack 4	Internet Explorer 4.01 or later; Windows NT Server 4.0 with Service Pack 4 or later or Windows 2000 Server	Internet Explorer 4.01; Windows NT Server 4.0 with Service Pack 5 or Windows 2000 Server

CPU

If the capacity of a server is reached, adding more processing power does not necessarily increase server throughput. Windows Media Services scales fairly linearly from one to eight processors. However, beyond two processors, there is a point of diminishing returns that often does not justify its cost/benefit.

The Compaq ActiveAnswers Web site contains a Web-based Windows Media server sizer application for estimating server hardware and storage for unicast streaming.

Memory

Adding more RAM to a Windows Media server increases the number of clients the machine can serve – assuming that other limiting factors such as CPU, disk, and network I/O do not max out first. Since Windows Media Services does not use system memory to cache file system data, adding RAM does not relieve performance bottlenecks related to disk I/O. The optimal configuration for a high-availability Windows Media server is 512 MB of RAM. Beyond this number, the cost/benefit ratio tends to decline.

Network Interface

To obtain best results from each of your servers, the network connection should be through a dedicated Fast Ethernet (or OC3 ATM) switched network segment. Consider using multiple network cards: one dedicated to streaming content to clients; and one for remote administration, monitoring, replication, receiving streams from Windows Media Encoders, and for distributing streams to secondary distribution servers. The benefit of this configuration is that remote administration is not at risk if the client segment becomes saturated.

Disk

Because disk output performance is a pivotal concern in streaming on-demand content, it is important to optimize the disk read configuration on each server. The server should have three high-RPM, low-access time disks configured as a RAID array. Throughput from hardware-based array controllers and from striping across multiple drive controllers is preferred to software-based RAID, such as that provided with Windows NT® Server or Windows 2000 Disk Administrator. Typically, more than three disks in each array do not increase performance because of bus saturation (some high-performance drives can saturate a drive chain with only two disks attached). Also, you can increase performance with dedicated memory on the hardware-based disk array controller. This enables the array controller to cache commonly accessed data.

Consult your hardware vendor to determine the suggested configuration for optimal disk read throughput.

If you are only concerned with streaming live content and don't plan on storing or streaming on-demand, then a "lighter" disk configuration is appropriate.

Capacity Planning

A common problem encountered when deciding on a base media server platform is estimating the amount of storage required for on-demand .asf files. It is important to not only plan for immediate storage needs, but for future demands as well.

There are three parameters that contribute to the size of an .asf file: the actual bit rate encoded, the type of content, and the length of the content. A video with high motion, such as a rock video, generally produces a larger file size than a video with little motion, such as a talking head.

To estimate the file size of a captured stream, use the following calculation:

(X Kbps * S seconds) / 8192 = Y MB

where X is the encoded bit rate in kilobits per second (Kbps) and S is the length of the stream in seconds. Y is the approximate total file size in megabytes (MB).

Take special notice of multiple bit rate encoded .asf files. Although Windows Media Services is intelligent enough to stream just the optimal band in a multiple bit rate file, when stored as an .asf file, the file size equals the aggregate bandwidth of each band chosen plus an "insurance" band at approximately two-thirds of the lowest selected bit rate. For example, a multiple bit rate .asf file encoded at 80 Kbps, 37 Kbps, and 22 Kbps has an aggregate bandwidth of 127 Kbps (80 + 37 + 22 + an insurance band of 17 Kbps).

Once the bit rates are decided, the content must be encoded. Use the following chart to determine storage requirements for on-demand .asf files.

Table 3 .asf File Storage Requirements

Aggregate bit rate	Minutes of content	Approximate file size
22 Kbps	30	4.8 MB
37 Kbps	30	8.2 MB
50 Kbps	30	11 MB
100 Kbps	30	22 MB
300 Kbps	30	67 MB
1 Mbps	30	220 MB

Performance Statistics

Windows Media Services is the most scalable streaming platform in the industry today. On a standard dual-processor Pentium III server with enough RAM, you can expect to serve about 9,000 simultaneous on-demand clients connecting at 28.8 Kbps. If you are streaming live content, the number of clients is even higher, since disk I/O in many cases is a limiting factor when dealing with on-demand streams.

Streaming long-playing files improves server performance because long-playing files have less impact on the server. Long-playing files, however, do not guarantee that users can view the entire file. If you are streaming longer on-demand files, you can expect to stream content to more clients from a given configuration in contrast to streaming content to many clients accessing many shorter on-demand files.

Stream bit rates affect performance in several significant ways. High-bit rate streams are more efficient with respect to the overhead of the transmission protocol. This means that in a high bit rate stream there is less overhead incurred in sending the data; but because more data is sent, the total aggregate network bandwidth is greater. Because of the larger stream size, fewer total streams can be delivered simultaneously in comparison to lower bit rate streams.

In the best possible case, you are supporting access to low-bit rate, live streams, and in a worst possible case, access to many short, high bit-rate streams. Both establishing a connection and having clients use the fast-forward or rewind features can adversely affect the performance of the server, especially when these activities occur at high levels.

Testing Capacity

After you have completed your deployment planning, and you have procured and configured your hardware, you are ready to begin testing and start formulating a baseline. It is the process in which you determine the maximum capacity of your configuration and monitor the effect of changes in the system.

One of the most useful tools in testing Windows Media unicast server capacity is Windows Media™ Load Simulator. Windows Media Load Simulator simulates a high client demand by initiating a large number of client requests for streams to potentially overwhelm the Windows Media server and network resources at your site. Windows Media Load Simulator can simulate file opening and closing as well as stream requests and seeks in order to imitate activities performed by users. During the load test, Windows Media Load Simulator can capture Windows Media component services performance counters and save the results to a log file for detailed analysis. By examining the generated performance logs after every configuration change, you can get a good feel for the optimal network and server settings for your solution.

You can download the Windows Media Load Simulator from the Windows Media Technologies Web site (Load Simulator is part of the Windows Media Services Tools package). For more information on configuring and using Windows Media Load Simulator, see the product documentation.

Optimizing Performance

There are a number of software optimizations you can make to your Windows Media servers to increase overall throughput. These include:

• Changing Windows NT (or 2000) Server cache settings to Minimize Memory Used . Windows Media Services does not use system memory to cache file system data. Therefore, it is recommended that you configure the server to minimize the memory used by the operating system to increase the memory available for handling client connections.

• Setting the foreground application performance boost to none. This gives more CPU time to background services such as Windows Media Unicast service.

• Disabling non-essential Windows 2000 and Windows NT services such as spooler, license logging, alerter, and messenger. If Microsoft® Internet Information Services (IIS) is installed, consider disabling the content indexer, FTP, SMTP, and World Wide Web publishing service if they are not needed. Each one of these non-essential services uses resources that could be dedicated to serving streams. Disabling some of these services may affect other functions on the server. If you are not completely aware of the consequences of disabling a service, consult the operating system product documentation.

Although Windows Media Services and IIS can co-exist on the same server, it is not suggested for anything other than a test environment. Windows Media Services should be dedicated to serving streams and the overhead required for Web serving is unnecessary. If you do choose to install Windows Media Services with HTTP streaming enabled and IIS on the same server, check the Windows Media Services Help or the Troubleshooting section in this document for special configuration notes for these services.

Client Requirements

Microsoft Windows Media Player enables playback of live and on-demand streaming content in addition to many other non-streaming file formats. Its tight integration with the Windows operating system, Microsoft Internet Explorer, and Netscape Navigator browsers enable users to experience rich multimedia presentations, from corporate communications to online training.

Table 4 Windows Media Player Client Recommendations

Client	Description
Windows Media Player 7.1	Windows Media Player 7.1 gives you the best audio and video experience in a personalized way on your PC or portable device.The new And coming soon to the Windows Media web site will be a new Enterprise Deployment Pack that will provides the capability togive you the availability to standardize the look and feel of Windows Media Player 7.1. With this Pack you can specify player settings including those for proxies and streams. You can also specify a desired skin, limitinglock the Player into a standard skin, limit accessibility of consumer features such as CD burning and copying.
Windows Media Player 6.4 (While still common, corporate network administrators will find that the Enterprise Deployment Pack for Windows Media Player 7.1 offers the flexibility of the 6.4 player with the advanced feature set of the 7.1 player.)	Designed for corporate customers to meet their needs, Windows Media Player 6.4 enables playback of high-quality, local and streamed multimedia content over multiple bandwidths ranging from less than 14.4Kbps audio to broadcast-quality, full-screen video.

Hardware

A basic hardware requirement for streaming audio to the desktop is having a sound card installed in the desktop computer. Many organizations, however, may not have sound cards in every computer, or may be in the middle of updating their corporate desktop standards to include sound support in the future. Do not be discouraged. With Windows Media Technologies, content authors can easily integrate and synchronize closed captioning to accompany video content. Therefore, Windows Media Technologies can be deployed and supported by machines while sound support is phased in. At a minimum, designated training rooms can be assigned that enable users whose computers do not have sound cards to listen to audio presentations when necessary.

Table 5 Windows Media Player 6.4 Requirements

Component	Minimum required	Recommended	Optimal
Processor	Pentium 166 MHz	Intel Pentium II 266 Mhz	Latest Intel Pentium III
Memory	16 MB for Windows 95 or 98 32 MB for Windows NT	64 MB	128 MB or greater
Network card (optional)	10-Mbps TCP/IP Ethernet card	100-Mbps TCP/IP Ethernet card	100-Mbps TCP/IP Ethernet Card
Modem (optional)	28.8-Kbps modem	56-Kbps modem or ISDN	High-speed connection, such as DSL or cable modem
Audio	16-bit sound card	Creative Labs SoundBlaster compatible 16-bit sound card	High-quality SoundBlaster compatible 16-bit sound card
Video	16-color display	16-bit color display	16-bit color display with Microsoft® DirectDraw® support
Software	Windows 95; a Web browser such as Internet Explorer 4.01 or Netscape Navigator 4.0 or later	Windows 98 or Windows NT 4.0 with Service Pack 3; a Web browser such as Internet Explorer 4.01 or Netscape Navigator 4.0 or later	Microsoft® Windows NT® Workstation version 4.0 with Service Pack 5 or Microsoft® Windows® 2000 Professional; Microsoft® Internet Explorer 5

If you want to deploy Windows Media Player 7.1, here are the requirements.

Table 6 Windows Media Player 7.1 Requirements

Component	Minimum required	Recommended	Optimal
Processor	Pentium 166 MHz	Intel Pentium II 266 Mhz	Latest Intel Pentium III
Memory	32 MB	64 MB	128 MB or greater
Network card (optional)	10-Mbps TCP/IP Ethernet card	100-Mbps TCP/IP Ethernet card	100-Mbps TCP/IP Ethernet Card
Modem (optional)	28.8-Kbps modem	56-Kbps modem or ISDN	High-speed connection, such as DSL or cable modem
Audio	16-bit sound card	Creative Labs SoundBlaster compatible 16-bit sound card	High-quality SoundBlaster compatible 16-bit sound card
Video	256-color video card	24-bit true color display	24-bit color display with Microsoft® DirectDraw® support
Software	Windows 98, Windows 98 SE, Windows 2000, or Windows ME; a Web browser such as Internet Explorer 5 or later	Windows 98, Windows 98 SE, Windows 2000, or Windows ME; a Web browser such as Internet Explorer 5 or later,	Microsoft® Windows 98, or Windows 98 SE, Microsoft® Windows® 2000 Professional, or Windows ME; Microsoft® Internet Explorer 5

Windows Media Player takes advantage of the advanced multimedia capabilities of the Intel MMX instructions for the Pentium processor as well as those of the Microsoft® DirectX® technologies. If at all possible, you should ensure that your client desktops have hardware that can take advantage of native DirectX support. For example, many video cards have on-board logic that can offload video processing to the hardware and drastically improve video performance.

Headphones and Speakers

Even with sound cards in their machines, users need speakers or headsets to listen to audio content. Many corporate PCs with sound have integrated speakers. For those that do not, consider purchasing quality headsets or directional speakers that do not disturb other employees around them.

Software

Microsoft Windows Media Player 6.4 is available for the Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows 3.x, Macintosh, and UNIX operating systems. Windows Media Player 7.1 is available for Windows 98, Windows 98 SE, Windows 2000, and Windows ME operating systems.

Be sure that your desktop computers have the most recent video, audio, and network drivers installed to take advantage of enhancements and special features that could benefit the Windows Media Player.

Your desktops should also have a Web browser standard such as Microsoft Internet Explorer or Netscape Navigator to take advantage of how Windows Media Technologies integrates with Web technologies. Special features in Internet Explorer 5 (and later), such as HTML+TIME support and the Windows® Radio Toolbar, enhance the functionality of Windows Media Player.

Network

Streaming in one or another form can be deployed in any company, even in low bandwidth conditions. Windows Media Technologies employs a technology known as intelligent streaming, which dynamically optimizes stream quality based on network conditions. This means that content is displayed at the best possible video and audio quality regardless of the network connection. When Windows Media Services and Windows Media Player connect, they automatically determine the available bandwidth. The server then selects and serves the appropriate video stream. Even under the worst network congestion, Windows Media Player tries to maintain audio quality but avoid buffering by decreasing video frame rate or even stopping video all together.

Consult the Firewalls section for suggested firewall configuration to allow Windows Media Players to request streams using the MMS protocol. Windows Media Player can also be configured to receive UDP data on a specific port, to prevent opening too many inbound ports on the firewall.

Portable Devices

Many portable devices can play Windows Media content, and Windows Media Player can be used to transfer audio and video content to those devices. For a complete explanation of the various portable and hand held devices that can play Windows Media content, please see the Windows Media or Windowsmedia.com web site. Windows Media Player 7.1 for Pocket PC can play audio and video files, and it can play streaming files delivered over a wireless network connection.

Windows Media Player Deployment

Windows Media Player can operate as a stand-alone application, embedded in a Web page or Microsoft® Visual Basic® application as an ActiveX control, or as a Netscape browser plug-in.

Windows Media Player is installed with most of the recent Microsoft software releases such as Windows 98 Second Edition, Office 2000, Internet Explorer, and Windows 2000. Chances are, your desktops already have Windows Media Player installed. If they don't, there are many ways to customize and deploy Windows Media Player:

• Internet Explorer Administration Kit enables organizations to customize settings and deploy Windows Media Player with Internet Explorer from a centrally managed distribution point.

• Windows Media Player Custom Player Kit enables system administrators to customize, install and uninstall, and package Windows Media Player. Examples of customizations possible with the Windows Media Player Custom Player Kit include configuring all players to use a corporate proxy server, setting a default buffering time, displaying a custom graphic when the player is launched, playing a custom AVI while connecting to content server, and adding a custom watermark logo. The Windows Media Player package can be delivered via any software delivery mechanism such as Microsoft® Systems Management Server (SMS).

• Internet Explorer ActiveX download and Netscape plug-in delivery enable Windows Media Player to be installed on-demand and automatically when the user visits a Web page with the embedded Windows Media Player. Once the player is installed, the stream is loaded and plays without having to restart or refresh the browser.

Windows Media Player includes an auto-upgrade notification feature that checks for a new version of the player when it is closed. It also downloads new codecs automatically, as they are needed to play updated content.

Tools Planning

Encoding and producing multimedia content can be highly CPU-intensive operations. Depending on the quality, size, and bandwidth of the video, encoding can overwhelm a computer's resources. With this in mind, it is important to plan your video production platform accordingly. The following table outlines the requirements for Windows Media Encoder 7.1. The supported operating systems for the Encoder are: Windows 98 SE, Windows 2000, Windows ME, and Windows NT 4 (with Service Pack 6 and DirectX Media 6.0 and later).

Table 7 Windows Media Encoder Requirements

Encoding Task	Minimum configuration	Recommended configuration
Convert existing .wav, .avi, .mpg, and .mp3 files to Microsoft Windows Media format	Intel Pentium 200 MHz with MMX 32 MB of RAM	Intel Pentium 500 MHz or higher, such as a Pentium III 128 MB RAM or more
Real-time capture and broadcast of audio files	Intel Pentium 200 MHz with MMX 32 MB of RAM Supported audio and video capture device	Intel Pentium 300 MHz or higher 128 MB RAM or more Supported audio and video capture device
Real-time capture and broadcast of audio and video files for dial-up modem and mid-bandwidth audiences using Windows Media 7 codecs	Single stream and multiple bit rate content for 28.8 Kbps and 56 Kbps modems (Use Recommended configuration)	Single stream and multiple bit rate content for 100 Kbps through 500 Kbps Intel Pentium 450 MHz or higher 256 MB of RAM Supported audio and video capture device
Real-time capture and broadcast of audio and video files for dial-up modem and mid-bandwidth audiences using Windows Media 8 codecs	Single stream content for 28.8 Kbps and 56 Kbps modems Intel Pentium III 700 MHz 32 MB RAM Supported audio and video capture device	Single stream and multiple bit rate content for 100 Kbps through 500 Kbps Intel Pentium III 700 MHz, or higher such as a 1.5 GHz processor 256 MB RAM Supported audio and video capture devices
Real-time capture and broadcast of audio and video for high bandwidth	Use recommended configuration	Single stream and multiple bit rate content for 500 Kbps through 2 Mbps or more 700 MHz dual processor or higher 256 MB of RAM Supported audio and video capture devices

Because the quality of a live video stream depends greatly on the speed of the CPU, the faster the CPU, the better video quality you can achieve. Windows Media Encoder is multithreaded and scales very well on dual- or quad-processor workstations. On a dual processor Pentium III workstation for example, you can achieve full-screen, 640 x 480-pixel, 30-fps high-quality video.

If there are enough CPU cycles to spare, a single workstation can support multiple instances of Windows Media Encoder for real-time encoding of live video and/or audio. For each simultaneous video stream, the encoder requires a dedicated video capture card and sound card. For audio only, each simultaneous audio stream requires its own dedicated audio card or a multi channel audio card. A single workstation has been known to support up to 8 simultaneous 20 Kbps live audio encoders with a pair of multi-channel audio devices. Check with supported hardware manufacturers for products that support multiple devices in a single workstation. The Windows Media Technologies Web site maintains a list of tested and supported hardware manufacturers for video and multi-channel audio capture devices.

Windows Media 8 introduces new codecs optimized for the Intel Pentium III processor. Use Windows Media Video 8 codecs for most encoding scenarios. The compression quality of Windows Media Video 8 codec is better than the quality of version 7 and delivers near DVD-quality at 500 Kbps. This codec supports a wide variety of network bandwidths and enhances video quality for broadband Internet users. The Windows Media Video 8 codec has greater CPU performance requirements than the Windows Media Video 7 codec. When selecting a profile for encoding video with Windows Media Encoder, you'll notice that some profiles start with WM8. These profiles use the Windows Media Video 8 codec.

Windows Media Encoder 7.1 encodes content at a constant bit rate. This type of encoded content is ideal for streaming. If you are converting high-quality, file-based content and want to preserve the variable bit rate of that content, then you should use the Windows Media 8 Encoding Utility (which is available on the Windows Media web site). The encoding utility has several modes that enable you to encode your content in one or two passes, depending on your desired results. Content encoded in this way, however, is not suitable for streaming because network data rates are constant and cannot accommodate large bit-rate fluctuations.

The following audio codecs are installed with Windows Media Encoder 7.1. The Windows Media Audio 8 codec is recommended for most content because it usually produces the best sound quality in a media file with mixed media types and music-based content. However, if you are creating a low bandwidth stream (below 20 Kbps) that has voice-only audio content, better results may be obtained by using the Sipro Labs ACELP.net codec.

Table 8 Windows Media Audio Codecs

Codec	Description
Windows Media Audio Codec version 8	A scalable codec that provides high quality mono and stereo audio content over a wide range of bandwidths. You can use the Windows Media Audio codec to encode audio content at bandwidths ranging from 5 kilobits per second (Kbps) to 160 Kbps. The audio sampling rate ranges from 8 kilohertz (kHz) to 48 kHz. This allows you to choose the best combination of bandwidth and sampling rates
FhG MPEG Layer-3	Moving Picture Experts Group (MPEG) Layer-3, which is created by FhG, is a high-fidelity mono audio codec that is particularly good for CD-quality audio for an intranet or the Internet. MPEG Layer-3 comes with several formats depending on the network bandwidth you choose.
Sipro ACELP.net	ACELP is a low bit-rate codec that provides excellent voice compression. ACELP comes with several audio formats depending on the network bandwidth you choose.

Windows 2000 or Windows NT 4 Workstation is the suggested operating systems for Windows Media Encoder because of its stability/reliability and multi-processor support. The system should also connect to the network via a 100 Mbps switched Ethernet network.

Third-Party Tools

Being an open standard file format, the Microsoft Advanced Streaming Format (ASF) benefits from having broad support from some of the multimedia industry's largest vendors. A wide variety of additional tools for Windows Media ASF authoring, audio processing, audio and video production, and Web media authoring are available from third parties. See the Windows Media Technologies Web site for a list of Windows Media content tool providers.

Developing

Implementation

When implementing Windows Media Services, just as when planning any implementation, there are several issues and considerations that will affect your ability to achieve a successful implementation. Some of these are discussed below.

Placement of Streaming Servers

In a single site deployment, your Windows Media servers should tie into your backbone segment via a Fast Ethernet switch.

In a multiple site deployment, there are several technical and administrative tasks to consider before building your design. One can take a centralized or distributed approach to supporting more than one geographical location in your company.

A media server farm is a group of media servers clustered to support high availability. In a centralized architecture, your media server farm resides in one physical location and users in remote locations connect via the WAN. You could configure the Windows Media servers with a publishing point for each remote location and set an individual bandwidth limit on each publishing point based on the available bandwidth over the WAN. In this case you would need to redirect each remote user to the proper publishing point. In unicast live scenarios, this solution does not scale well, as the number of simultaneous users you can support is limited by the speed of your WAN. This solution is best when you have high-speed connections between remote sites or have a relatively small number of users in each remote site that would not warrant an implementation in that location.

In a distributed architecture, each remote location has its own media server farm, and techniques such as replication, scheduling, and distribution enable remote users to view streams originating from a central location. For example, rather than having every remote user pull live streams over the WAN from a central location, you could configure a distribution server in the remote site to pull a single stream from the server in the central location and "re-broadcast" the stream to all of the users in the remote site. For the on-demand scenario, content replication could be used to maintain the same content in each site for local users. Again, some form of redirection would be needed to direct remote users to the proper local media server farm to request streams.

In a multicast scenario, live events scale very well if the entire enterprise is multicast enabled. In this case, only one Windows Media server is needed to broadcast the multicast throughout the network. In mixed multicast environments where multicasting is enabled at the subnet level but not between subnets, hardware or software tunneling can be a used to propagate the multicast. Multicast stations can also be set up so that they support both multicast and unicast requests. Therefore, if users on a non-multicast-enabled subnet request a multicast stream, they are still able to view the stream.

Most organizations employ a firewall to protect their network from unauthorized outside traffic. Windows Media servers can be deployed inside or outside a firewall, depending on your company policy. In an intranet environment your Windows Media servers should be placed on your production network inside the firewall. Configure your firewall to enable MMS connections to the Windows Media servers. If configuring your firewall to enable MMS is not an option, enable HTTP streaming on your Windows Media servers. Since MMS is a more efficient protocol for Internet streaming, it is suggested that your Windows Media servers be placed outside the firewall. Windows Media Encoder 7.1 delivers its streams via HTTP, which passes easily through the firewall to Windows Media servers. You can use FTP to maintain files on your servers. Open a port for DCOM to administer the servers using Windows Media Administrator.

For details on configuring your firewall to support Windows Media Technologies, consult the preceding Firewalls section.

Placement of Other Servers

Windows Media Encoders should reside on your production network. To communicate with Windows Media servers outside the firewall, use HTTP to transmit live streams between them.

Windows Media Encoders have a limit of 50 client connections. Each connection however, degrades the performance of the encoder. Therefore, it is recommended that you have a first level of Windows Media servers that receive the streams from Windows Media Encoders and re-distribute the stream to other Windows Media servers downstream or in remote locations over the WAN. This enables centralized starting, stopping, and management of live stations or server-side play lists.

Linking to your streams requires ASF Stream Redirector (ASX) announcement files that tell Windows Media Player which server to connect to and which ASF stream to play. Other supported announcement files are .wmx and .wvx. Generally, .asx files are stored on Web servers and are downloaded when a user clicks on a hyperlink from a Web page. Additionally, for multicast events, Windows Media station configuration files (NSC) are also required; these configure Windows Media Player before a multicast stream loads. You can use your existing intranet Web infrastructure to store your ASX and NSC files. If your Web servers are centrally located, you may keep the same design and store your ASX and NSC files in the central position. Since ASX and NSC files are smaller than an average Web page and are only downloaded when a stream is first requested, it does not generate much traffic over a WAN. If you have intranet Web servers in your remote locations, you can replicate .asx files and .nsc files along with your Web content.

For multicast distribution, an ISAPI DLL running on Microsoft IIS handles logging. Since stream requests generate little traffic and are only generated when a client first requests a multicast stream, it is okay to have your logging server centralized rather than having a logging server for every Windows Media server farm. However, because the beginning of a live event can generate a high volume of stream requests every second, consider distributing or load-balancing your logging servers for this scenario.

Handling Slow Links

Multicasting high-bandwidth streams to conserve bandwidth on a local subnet may be a good solution, but over a slow wide area network link, it may consume too much bandwidth. In this case, you can offer different versions of a multicast stream for the different types of users: a high-bandwidth encode for local area network users and a lower bandwidth encode for remote users. One way to offer streams to remote users while maintaining high bandwidth and high quality is to consider "delayed live" or "scheduled" multicast. In this scenario, high-bandwidth streams are multicast live to local network users and saved to an .asf file simultaneously. At certain points during the live event, or when the event is complete, the saved high-quality .asf file(s) can be distributed to Windows Media servers in the remote locations and multicast to local users in that site, with a time delay.

By encoding your content at multiple bit rates, you can support users that connect via slow links such as WANs or dial-up connections. Multiple bit rate encoding ensures that remote users get the same access to streams as local LAN users.

For remote access users that use dial-up connections to the corporate network or VPN users that connect via the Internet, there are a number of ways to support streaming. Due to the nature of multicast packets, multiple bit rate encoding is not supported during a multicast; only the highest band will be transmitted. Therefore, for live events, if multicast is supported over remote access, consider a separate low-bandwidth multicast station that supports your lowest modem speed (e.g., 22K). If multicast forwarding is not supported over remote access, then configure your multicast station as both a multicast and unicast distribution point. That way, LAN users can connect to the stream via multicast to the high-bandwidth version and dial-up users can connect via unicast to the low-bandwidth version.

In order to alleviate traffic over the corporate network, consider hosting streams over the Internet to VPN users or trusted clients. In this model, live and on-demand streams are delivered via unicast over the Internet. If your ISP and your VPN users' ISP support MBone, then you could multicast your live events over the Internet to remote users. See the sections entitled Authentication and Authorization to learn more about securing your content when streaming on the Internet.

Handling Networks with Bandwidth Constraints

There are other techniques for handling networks with bandwidth constraints and remote users. Scheduled multicast can be used to reduce the amount of unicast requests on a network. The most popular .asf files can be scheduled and multicast at certain publicized times throughout the day, rather than having each user request their own unicast stream. For example, a popular training video that is normally watched by 20 users at a time on average, can be offered via multicast four times during the day: 10 A.M., noon, 2 P.M., and 4 P.M.

Another option is to tune down the bandwidth of the audio or video. CD-quality sound and TV-quality video may not be required to deliver a talking-head presentation. With the optimized codecs included with Windows Media Technologies, near CD-quality audio and near VHS quality video can be delivered in a fraction of the bandwidth required for full-quality transmission. Reducing the size of the video or lowering the frame rate will also contribute to a smaller bandwidth stream.

If video is not an option, consider illustrated audio, meaning audio synchronized with PowerPoint slides or images, rather than motion video. In many cases, this may be a better solution than a low bandwidth video stream; most users would much rather watch low motion, high-quality snapshots than fuzzy or blurry video.

Redirecting Clients

When designing your solution with WAN users in mind, you will want to make sure that users in remote sites connect to their own local media server, rather than having a remote user pull a stream from a media server over the WAN. There are a number of ways to redirect users to the closest media server. One method, if there are different Domain Name Service (DNS) servers in each remote location, is to have each site resolve to its own local Windows Media server farm. For example, if a user clicks on a link to watch a stream from media.company.com in New York, DNS would resolve this to the IP for the New York server, whereas in San Francisco it would resolve to the IP of the San Francisco media server.

Another way of redirecting clients is using .asx files. These files are useful because they can be dynamically generated on a per-request basis. When a user requests a stream, for example, a CGI script or ASP page checks the user's IP address against a database of IP address ranges. If the client's IP address is in New York, the .asx file is returned with the name of the New York server in its URL. If the IP falls within the San Francisco IP range, the .asx file returns the name of the San Francisco server farm.

Load Balancing

Load balancing involves distributing traffic among media servers in a media server farm for high availability. Several software and hardware solutions exist that can help scale Windows Media Services.

Microsoft Windows NT Load Balancing Service (WLBS) is an add-on to Windows NT Server 4.0 that load-balances Transmission Control Protocol/Internet Protocol (TCP/IP) traffic to and from servers in a WLBS cluster. In Windows 2000 Server, this is called Network Load Balancing. When Windows Media servers are added to a WLBS cluster, WLBS automatically determines which server has the least amount of traffic and redirects them to the appropriate server. This process is invisible to the user. For more information on the Windows NT Load Balancing Service, see the documentation included with WLBS. In Windows 2000, see the documentation for Network Load Balancing.

Hardware-based IP load-balancing solutions also exist which accomplish the same thing as WLBS. Check with your network vendor for IP load-balancing solutions.

DNS Round Robin is another technique that can be used to balance the load of requests to a server. It is much less sophisticated than WLBS, but generally simpler to implement. DNS Round Robin involves returning a different IP address from a collection of designated IPs each time the DNS name is requested. Statistically, if there are four IP addresses in a DNS CName group and there are 100 requests for the DNS name, each IP address will get one quarter, or 25 requests. Another variation on the same theme is to use .asx files to cycle through server names. Since .asx files can be generated dynamically using CGI or ASP, a different server name can be returned every time. DNS Round Robin has some disadvantages: 1) It does not provide fault tolerance if one server goes down and 2) It does not measure traffic to and from servers, only requests – so it may not distribute load evenly.

Clustering is a technology similar to load balancing which attempts to distribute processing load among servers. Clustering is best for data processing applications such as database processing and may not be cost-effective or beneficial for streaming.

Fault Tolerance

In any production environment, some form of fault tolerance is necessary to prevent prolonged service outages. For streaming media, fault tolerance can be achieved at the hardware level and in the design level. Redundant network devices and RAID disk configurations contribute to a fault tolerant design, but are common to most applications, not specifically streaming. Generally, the same fault-tolerant design techniques apply to streaming as to other applications.

There are ways to build an infrastructure that supports unplanned outages and still supports your users. One technique, already discussed, is the use of Microsoft Windows NT Load Balancing software with Windows Media Services. If one server goes down from a planned or unplanned outage, WLBS automatically removes the server from the WLBS cluster and continues to redirect users to other servers in the cluster.

ASX files can also be used to provide fault-tolerance for users. If a user tries to connect to a server and the server is unavailable, they will be presented with an error. However, an ASX file can contain multiple REF entries in its URL to specify multiple locations where users can connect to a stream. If the connection to the server's first REF tag fails to connect, the Windows Media Player will automatically roll-over to the next server in the list and try to connect, transparent to the user. If all of the servers fail to connect, then Windows Media Player will return the user an error.

Content Replication

Replication is essential when implementing a distributed on-demand streaming architecture. In a distributed design, content originates from one or two locations but needs to be distributed to Windows Media servers in remote locations. Replication can be as simple as a file copy, a batch file, or a complete packaged solution such as the Content Deployment product in Microsoft Site Server 3.0.

Content Deployment in Microsoft Site Server can be used to remotely manage distribution of .asf files between Windows Media servers. From one central location, replication projects can be set up to replicate immediately, at a scheduled time, such as after peak network usage hours or whenever content changes. Web-based reports are generated after every event and can be viewed via a Web browser, or e-mail notification can be sent to a group of administrators in order to monitor replication events.

Scheduling and Content Management

Eventually, you will need a way to administer and control your media as well as provide a useful, intuitive tool with which viewers can access the media. For example, you could add a Web page to your intranet to fill this function.

Securing Content

Microsoft's Windows Media Rights Manager lets content providers deliver songs, videos, and other media over the Internet in a protected, encrypted file format. Windows Media Rights Manager helps protect digital media (such as songs and videos) by packaging media files. A packaged media file contains a version of a media file that has been encrypted and locked with a "key." This packaged file is also bundled with additional information from the content provider. The result is a protected media file that can only be played by a person who has obtained a license.

Windows Media Rights Manager can be very useful to organizations that need to provide secure downloadable media to their local and remote users, vendors, clients or partners. An organization, for example, can use Windows Media Rights Manager 7 to gather information about the people who request the media or to make content licenses expire after a specific duration.

For more on Windows Media Rights Manager and DRM technology, check the Microsoft Windows Media Technologies Web site.

Caching

Caching for streaming media is a rather new technology that tries to bring streaming content closer to remote users. It involves retaining a copy of the media stream in its local disk or memory cache for a period of time after it is initially requested. By placing caching appliances in remote sites, an initial request for a media stream is served from the original point of origin, but all subsequent requests for the same file are served from the device's cache.

Caching can be used in conjunction with content replication as a method of providing high-quality on-demand streams to remote users without utilizing the WAN for transmission. Caching appliances are generally dedicated hardware devices and often require less configuration and maintenance than a separate Windows Media server in a remote site.

Security

Securing servers from unwanted user access should be a concern when designing an enterprise-wide streaming infrastructure. If there is a presentation by the finance department that should only be seen the members of that department, then you must ensure that only the people who have permission to see the content can do so. By implementing security on your streaming servers, you can control access to the content on the servers.

Security can be applied in many ways. IP address security, for example, could prevent unauthorized access from users in remote subnets. IP address range restrictions can be set for each publishing point on a server. Another way to secure content is to apply ACLs (permissions) to multicast and on-demand publishing points and files. You can set permissions on .asf files, publishing points (for on-demand content) and .nsc files (for multicast content) to grant or deny access on a user or group policy basis just as you can set permissions on files on a version of the NTFS file system used in the Windows NT operating system, provided that you are on a LAN or a domain or are using Site Server Membership services. Depending on your choice of authentication package (see discussion on Security earlier in the document*)*, this could be integrated with Windows NT domain users and groups.

Training

Training is an important and often-overlooked step in deploying Windows Media Technologies in an organization. Users have to be trained to use Windows Media Player, help desk staff must be able to support trouble tickets, and IT staff must be able to deploy and support the production streaming infrastructure. Additionally, network administrators need to be aware of changes to the network that occur due to streaming. This does not only include the added network utilization and new protocols, but also changes to network devices such as routers and firewalls.

Fortunately, there are a number of resources that can help you with this task:

• Windows Media Training Server, a streaming solution itself, contains seminars on various Windows Media Technologies topics from Windows Media development to deployment and integration.

• Microsoft Online Seminarsfeature versions of the Microsoft training seminars streamed over the Internet (see the link on the References page).

• Windows Media Service Providers (includes training providers)

• Microsoft has created the Windows Media Service Provider Program to provide businesses with a set of service providers, qualified to deploy and maintain Windows Media Services-based streaming media solutions. For the list of Windows Media service providers who have demonstrated expertise in Windows Media server live event production, hosting, online training, content creation, and integration services, see the link on the References page.

• Microsoft Developer Network (MSDN) MSDN Online Windows Media Technologies Workshop is an invaluable source of information for the Web and Windows Media Technologies developers. It provides the technical information one needs to create and serve streaming media content on the Web (see the link on the References page).

• Microsoft TechNet is a great collection of information on all Microsoft products. It contains installation, configuration, deployment, and troubleshooting manuals on Microsoft BackOffice and Microsoft desktop products. TechNet also features evaluation versions of Microsoft products and some extras, as Windows NT service packs, for example. Best of all, the collection is being updated monthly. You can subscribe to receive TechNet CD's monthly, or access TechNet documentation on the Web (see the link on the References page).

• Microsoft Knowledge Base is a subset of Microsoft TechNet. It contains various (including Windows Media Services) troubleshooting articles. Knowledge Base CD is included with TechNet, or you can access Knowledge Base online (see the link on the References page).

Implementing

Administration

Once Windows Media Technologies is put into production, you will need to gauge whether your design meets your business's needs.

Monitoring

A common need of administrators is the ability to monitor the health of a Windows Media server and automatically alert an administrator when server performance begins to degrade or if the server stops responding. There are a number of methods to do this:

Performance Monitoring

Microsoft® Windows NT® Performance Monitor is the single most important tool for generating a baseline and monitoring Windows NT server performance. Windows 2000 provides the Performance tool for System Monitor Performance Logs and Alerts. Both tools are valuable for monitoring resource usage and generating a performance baseline on your computer.

Windows Media Services supports several performance counters you can monitor locally or from remote servers. These counters enable you identify server or network bottlenecks and can be used to alert a user or group of users when errors occur. When monitoring a Windows Media server during normal load, be sure to do so remotely rather than locally on the server itself. Additionally, if your server is configured with two network cards, dedicate one to monitoring and administration and the other to serving clients. Otherwise, you may skew your results.

Certain trends can be witnessed when a server's resource usage is at the maximum. If these trends are noticed on a regular basis, you should consider upgrading or reconfiguring your solution. Examples of useful counters to look at for performance tuning include:

• % Processor Time is the percentage of CPU that is busy executing a non-idle thread. If this number is consistently higher than 85% it may indicate your server needs an additional CPU, a CPU upgrade, or an additional server to distribute the load.

• Available Bytes indicates the amount of memory not in use and available to Windows Media Services. If this number drops below 4 MB, it indicates insufficient memory.

• Late Reads. A late read is a disk read operation that takes significantly longer than expected to complete. If this counter is often greater than zero it may indicate that your disk cannot keep up with the demand placed on it.

• Pending Connections is the number of clients attempting to connect to the server but are not yet connected. This number can be high if the server is running near maximum capacity and cannot process a large number of connection requests in a timely manner. This could indicate insufficient memory or CPU.

• Stream Errors represent the number of stream data packets discarded by the server. They are introduced by the server when it cannot keep up with the demand for data, and must throw some packets away to avoid running behind schedule indefinitely. Stream errors show up most often after late reads and could indicate too much disk I/O or network traffic.

• UDP Resend Requests is the number of times clients request that the Windows Media server resend data packets that were not received. This value can be high when the server cannot send UDP packets reliably. This is a good indicator of network overload.

• UDP Resends Sent indicates the number of UDP Resend Requests processed by the Windows Media server. If the number of UDP Resends Sent is significantly lower than UDP Resend Requests then it is a very good indication that the server is under too heavy a load.

Creating Alerts

Windows NT Performance Monitor has the advantage of polling a number of servers at pre-defined intervals and generating an alert when values are outside of a range you set. For example, you may choose to designate a workstation to poll every Windows Media server every 60 seconds and send an administrative alert if the Available Memory counter drops below a given threshold.

Windows Media Technologies can also generate SNMP traps when certain values exceed a specified threshold. Using a utility called perf2mib from the Microsoft Windows NT Server 4.0 Resource Kit, you can use performance monitor to generate a MIB for use with third-party network management tools such as HP OpenView, NetIQ, etc.

Using Windows Media Load Simulator

Windows Media Load Simulator is an invaluable tool for testing server-streaming capacity and it can also be used as a monitoring tool. Windows Media Load Simulator will generate an error when it cannot connect to a server or successfully play a stream. This might happen when a server physically goes down or is overwhelmed by too many connections. You can configure the load simulator to constantly play one low bit rate stream or even automate its operation from a batch file or command line. When the load simulator encounters an error, it can be used to execute another program to log a Windows NT event, generate an SNMP trap or even send e-mail to an administrator. For more information on configuring Windows Media Load Simulator, see the product documentation. Windows Media Load Simulator can be found in the Windows Media Service Tools package on the Windows Media web site.

Logging

Logging is an important step in determining the effectiveness of your Windows Media implementation. Windows Media unicast and multicast events are written to standard W3C-compliant plain-text log files that can be imported into statistical analysis packages for report generation. A unicast log can record every action taken by a user on a Windows Media server. Examples of these statistics include the stream watched, client's IP address and DNS name, player version, start time, any fast forwards, rewinds, stops, pauses and duration of the stream watched. Recall that a multicast differs from a unicast in that in a multicast, users do not connect directly to the media server. Rather, Windows Media Player is configured by an .nsc file to listen to a multicast IP address. For this reason, multicast logs do not contain the same detailed information as unicast logs do. Specifically, multicast logs can only record initial connection information, examples of which include the stream name, client IP address, client DNS name and start time. Since users never talk back to the Windows Media server once the multicast is loaded, multicast logs cannot report things like duration of the stream, average quality received or total buffer time.

Multicast logs are generated on Microsoft IIS 4.0 Web servers rather than on the Windows Media servers themselves. This is because a log entry is generated when Windows Media Player downloads an .nsc file sitting on a Web server file. An ISAPI DLL (NSIISLOG.DLL) included with Windows Media Services handles the Windows Media Services multicast log generation for IIS.

Check the Windows Media Services help documentation for specific field names and values found in Windows Media log files and for details on enabling unicast and multicast logging.

Reporting

Reports generated from Windows Media Services log files can be used to filter, sort, and view user trends on Windows Media servers. Reports are an important part of the stabilization phase because they can provide usage information to business managers and administrators to identify potential problems and bottlenecks in the streaming design. For example, a high number of stream errors or abnormal stream terminations can mean an improperly configured Windows Media server; excessive client buffering may point to network bandwidth issues, and so on.

Sophisticated reports can be generated by a variety of third-party statistical analysis packages that support the W3C streaming log file standard. A list of software vendors that specialize in Windows Media reporting tools can be found on the Microsoft Window Media Technologies partners Web site.

Troubleshooting

This section provides troubleshooting tips for the most common problems encountered in setting up a Microsoft Windows Media solution.

Client

Most of the audio and video problems with Windows Media Player are usually related to non-supported or faulty hardware, such as a sound or video card, or wrong or outdated audio and video drivers installed. Please make sure that the video and audio cards used match at least the minimum hardware requirements for Windows Media Player. Contact your vendor to get updated video and audio drivers for your hardware.

Check (through Control Panel) if the sound is muted or not adjusted properly. This simple procedure can save you a lot of time when troubleshooting.

Sometimes problems with Windows Media Player are caused by the absence of an appropriate codec used to process the streaming data. To check for the presence of the correct codec or to download a codec, follow the instructions included with the Windows Media Player Troubleshooter.

If Windows Media Player cannot retrieve a media file, it can be for one of a variety of reasons:

• The volume of traffic on the Internet or LAN is high

• There are transient problems on the network or a server

• Your connection speed is too low to support the media file you are trying to play

• You selected a media file that uses the wrong bandwidth setting

• Your bandwidth setting in Windows Media Player may be wrong

• You are using the wrong network protocol

• The user does not have access to the requested media file.

Please consult Windows Media Player Help. The Troubleshooter can help you to isolate and fix the problem.

If you have a proxy server on the network and have to use the server to get to the Internet, Windows Media Player should be aware of it. To specify the proxy server and its settings, on the View menu, click Options, click Advanced, and then click Change. In the Advanced playback settings in the Protocols section, click HTTP, then select either Use browser proxy settings or Use proxy. If you have selected Use proxy you must click Configure Proxy Settings and specify your proxy hostname and port.

Sometimes problems with Windows Media Player occur because the wrong file permissions have been set on Windows Media server. To adjust permissions, contact your media server administrator.

The error messages generated by Windows Media Player can indicate what is wrong. Before proceeding with troubleshooting, always view the error details.

Actively use all available help resources including Microsoft TechNet or Knowledge Base (which are available online, see the reference page for the URL), and you will be able to fix the problem you are experiencing. Check the Help file, audio and video drivers, Control Panel settings, and the hardware, and then search for help online if required.

Server

If set up according to this document's guidelines and the installation Help, the Windows Media servers should not cause any problems.

Administrators have been known to try to install Windows Media and Web servers on the same computer. While this is not recommend, here are some useful tips for setting up both servers on one computer.

Running IIS and a Windows Media Server with HTTP Streaming Enabled

It is strongly recommended that you run Internet Information Services (IIS) and Windows Media Services on separate computers, however if you must run both services on the same computer, the following list shows what is required to run both :

• A minimum of two IP addresses bound to the network card.

• Microsoft IIS 5.0. The following steps do not work with IIS 3.0 or earlier.

• The IP address being used for the IIS server and the IP address being used for the Windows Media server should each have its own unique DNS "A" records.

• No Web site running under IIS 5.0 should be configured to use All Unassigned IP addresses.

First, you must ensure that no Web site running under IIS is binding to all unassigned IP addresses. This may be accomplished by performing the following procedure:

1. Open the Microsoft Management Console.

2. Right-click Default Web server to display the properties for the default Web server, and click the Web site tab.

3. In the IP Address list, enter the IP address that should be used for your IIS computer.

4. Repeat steps 2 and 3 for any additional Web sites you are running under IIS 5.0, including the Administration Web site.

   Now disable socket pooling for the each Web site.

5. Open a command prompt and type: cd systemdrive\inetpub\adminscripts.

6. At the systemdrive\inetpub\adminscripts command prompt, type: cscript adsutil.vbs set w3svc/disablesocketpooling true.

   The command prompt will return: disablesocketpooling : (BOOLEAN) TRUE.

Next you must enable HTTP streaming on your Windows Media server. The following procedure outlines this process for Windows Media Services:

1. Open Windows Media Services Administrator.

2. Click Server properties. The Configure Server Properties box appears.

3. Click the HTTP Streaming and Distribution tab.

4. Click the Enable HTTP streaming for Windows Media Unicast service, and then click Apply. When prompted, do not restart the server for the changes to take effect. Instead, click OK and proceed with the next set of steps.

Next you must edit the registry and make the Windows Media Unicast service dependent on the World Wide Web Publishing Service. The following procedure outlines how to make the needed changes to the registry.

1. Click Start, and then click Run. In the Open box, type regedt32, and then click OK.

2. Locate the following key in the registry:

   HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \nsunicast

3. Double-click the DependOnService value. This opens the Multi String editor.

4. Enter W3SVC to the list of services on which the Windows Media Unicast service depends.

5. Restart the Windows NT Server computer.

How to change the port used by Windows Media Services for HTTP streaming

1. Click Start and then click Run. In the Open box, type regedt32, and click OK. This opens Microsoft Registry Editor.

2. Locate the following key:

   HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \nsunicast \Parameters

3. In the key, double-click the value named HTTPport. This opens the DWORD editor.

4. In hexadecimal numbers, type the port number that you want the Windows Media server to use for HTTP streaming, and click OK.

5. Restart your Windows NT Server computer.

MIME type settings for Windows Media services

By using multipurpose Internet Mail Extension (MIME) types, different kinds of files can be exchanged on the Internet. For Advanced Streaming Format files to stream properly, the MIME types for both Web browsers and servers must be properly configured to recognize .asf and .asx files. Though browsers usually have their MIME types set automatically, in some cases you may need to do this manually. MIME types almost always must be manually configured on a server.

To configure the MIME types when running Windows NT Server and IIS 5.0, follow these steps:

1. Open the Microsoft Management Console (Internet Service Manager).

2. Select Properties for the Web site you wish to update.

3. In the web site properties dialog, select HTTP Headers.

4. In the MIME Map area, click File Types.

5. Add the following file extensions with their associated MIME types, and then click OK.

   File type (Associated extension)	MIME type (Content type)
   .asf	video/x-ms-asf
   .asx	video/x-ms-asf
   .wma	audio/x-ms-wma
   .wax	audio/x-ms-wax
   .wmv	video/x-ms-wmv
   .wvx	video/x-ms-wvx

Network

Most problems with streaming media are due to the wrong network layout. Some of the most common issues are:

• Wrong firewall settings.

  Make sure that the firewalls on your network are properly configured to allow the protocols, ports, and addresses required by your streaming media architecture. See the firewall manuals for details.

• Wrong router settings.

  Make sure your routers support multicast (if you use multicast on your network). Check the IP ACLs on the routers to find out which protocols, ports, and addresses are allowed. If necessary, set up multicast tunneling. See the router manual for details.

• Network congestion due to problems with the bandwidth.

  You will have to use special network traffic analysis tools, such as Network Monitor included in the Windows NT 4.0 operating system. For best results, use the complete version of the tool included with Microsoft Systems Management Server. See the Network Monitor documentation for details. You may have to take some special action to avoid network congestion (including usage of QoS-enabled equipment) or even redesign the network.

• Lost packets.

  Use the same technique as for bandwidth analysis. Tracing with Network Monitor (or other network analyzers) enables you to find the faulty devices (such as hubs, switches, or routers).

• Multicast issues.

  There may be quite a few reasons for multicast not to function properly (non-supported routers, firewalls, using the same group address for different sessions running simultaneously, and so on) For more information, see the Reference section of this document for a link to the IETF draft paper on the debugging of multicast.

Where To Get Help

• The Windows Media Technologies web site contains numerous troubleshooting guides and Frequently Asked Questions as well as downloads, product documentation, and the latest product news.

• Windows Media Technologies Newsgroups on msnews.microsoft.com:

  • microsoft.public.windowsmedia.technologies

  • microsoft.public.multimedia.windows.mediaplayer

• The MSDN Online Windows Media Technologies Workshop contains guides to help beginning and intermediate streaming media content authors and Web developers move into the fast lane. The site includes content creation overviews, step-by-step tutorials, code samples, and tools information.

• Microsoft TechNet

• Microsoft Knowledge Base

• Windows Media Technologies Online Seminars are do-it-yourself online streaming seminars covering a range of hosting and delivery issues.

• The Windows Media Technologies Discussion Group is an e-mail discussion group focused on developing for Windows Media Technologies. After you've subscribed, you can send messages to wmtalk@discuss.microsoft.com

  • To subscribe, send an e-mail message to:

    ListSERV@discuss.microsoft.com

    Leave the subject line blank

    Message text: subscribe WMTALK firstname lastname

  • To unsubscribe, send an e-mail message to:

    ListSERV@discuss.microsoft.com

    Leave the subject line blank

    Message text: signoff WMTALK

Support

Support for all Microsoft Windows Media components is provided through the standard Microsoft support policy. Microsoft support options are structured based on different types of customers.

Microsoft Authorized Premier Support

Microsoft Authorized Premier Support is a family of offerings designed for small and medium-sized businesses and enterprise customers who want to head off potential problems and increase availability. These offerings go beyond incident-based support through the addition of designated account management, proactive services, and online resources. Support is provided by industry-leading Microsoft Certified Support Center partners backed by additional personnel and resources from Microsoft, ensuring that customers get a high level of support delivered in the most cost-effective way.

Contact your Microsoft account representative or call Microsoft Enterprise Support Sales at (800) 936-3200 in the United States or Canada. Customers who are deaf or hard of hearing can reach Microsoft text telephone (TT/TDD) services at (800) 892-5234 in the United States or (905) 568-9641 in Canada. Outside the United States and Canada, contact your local Microsoft office.

Microsoft Professional Support for IT Professionals

Microsoft Professional Support for IT Professionals provides information services and incident-based access to Microsoft support professionals to help customers maintain their networks and their increasingly mission-critical applications.

Microsoft Professional Online Support is an extension to the existing TechNet IT Professional community Web site. This offering provides information dissemination, access to technical tools, Microsoft Knowledge Base, and IT Professional Hot Topics to ensure you remain current on technology issues and products.

Professional Support for IT Professionals provides access to the IT Professional Online Support Web site, including its tools, information services, online events and training at no charge. Some Microsoft products include a number of no-charge Professional incidents or time-limited no-charge Professional support.

Call Professional Support Sales at (800) 936-3500 in the United States. Customers who are deaf or hard of hearing can reach Microsoft text telephone (TT/TDD) services at (800) 892-5234 in the United States. If you have already purchased support incidents and would like to speak directly with a support professional, call (800) 936-4900. Outside the United States, contact your local Microsoft office.

For more information on Microsoft support options, visit the Microsoft Support Services Web site.

References

The following lists all of the documents referenced in the Windows Media Services Deployment Guide. For more information, visit the Windows Media Technologies Web site.

Multicasting White Paper https://www.microsoft.com/windows/windowsmedia/forpros/server/server.aspx

TCP/IP Implementation Details https://www.microsoft.com/technet/network/deploy/depovg/tcpip2k.mspx

Windows Media Hosting Providers https://www.microsoft.com/windows/windowsmedia/forpros/service_provider/service/default.aspx

Presentation Broadcasting in PowerPoint 2000 https://msdn.microsoft.com/library/en-us/dnwmt/html/pptbr2000.asp

Internet Engineering Task Force (IETF) Web site https://www.ietf.org/

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

Web-based Windows Media server sizer application https://vcmproapp02.compaq.com/sizers/wmtsizer/wmtsizer.html

ViewCast Osprey 100 Video Card https://www.viewcast.com/products/osprey/osprey100.html

Tested and supported hardware manufacturers https://www.microsoft.com/windows/windowsmedia/forpros/service_provider/service/default.aspx

Windows NT Load Balancing Service https://www.microsoft.com/technet/archive/winntas/maintain/featusability/wlbswp.mspx

Microsoft Online Seminars https://www.microsoft.com/seminar/

Windows Media Rights Manager and DRM https://www.microsoft.com/windows/windowsmedia/licensing/drmlicensing.aspx

Microsoft TechNet https://www.microsoft.com/technet

Microsoft Knowledge Base https://support.microsoft.com/default.aspx?scid=FH;EN-US;KBHOWTO&sd=GN&ln=EN-US

Microsoft Windows 2000 Resource Kits https://www.microsoft.com/mspress/books/1394.asp

Microsoft Support Services Web site https://support.microsoft.com/default.aspx

Microsoft white paper "Using Distributed COM with Firewalls" https://www.microsoft.com/Com/wpaper/dcomfw.asp

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2001 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows Media, Windows NT, ActiveSync, ActiveX, DirectDraw, DirectShow, FrontPage, JScript, Microsoft Press, NetShow, Outlook, PowerPoint, SQL Server, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual Studio, Win32, and Win32s are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Microsoft Windows Media software is based in part on the work of the Independent JPEG Group.