Updated: April 7, 2010
Applies To: Windows Server 2008 R2
Windows Media servers are typically deployed in one of the following scenarios:
While the general process of updating the platform is the same regardless of the deployment scenario, there are subtleties to consider in each case. For example, with multiple distributed servers, the update can be performed either on-site or remotely. Should you configure your servers at corporate headquarters or the main data center, and then ship them to field offices? And in the single-server scenario, how do you keep your data and configuration intact if you must restore it later? This section addresses these questions and offers recommendations to ensure a smooth transition.
In a single-server deployment, one Windows Media server works with one or more encoders to stream content to clients. The configuration might look like this:
The single-server update is easiest because you only run through the process once. Ideally, you would perform a clean installation of Windows Server 2008 R2 and Windows Media Services 2008 on a new computer, and then migrate your existing Windows Media Services configuration and media files to the new computer. This is beneficial because you can keep your existing Windows Media server in production until installation and testing of the new server is completed, minimizing service disruption for your viewers.
If you do not have a new computer, choose a time when you experience low traffic on your site and then upgrade the operating system as described later in this guide.
In this deployment scenario, two or more Windows Media servers are located on one site and work together to deliver content to clients. In some configurations, one server acts as a backup to the primary server if it fails. In other configurations, hardware or software load balancers distribute client requests among the servers so that none of them are overloaded. The configuration might look like this:
Updating a centralized server network is more complex than a single-server update because it requires that you run through the process multiple times. While you are updating one server, the other servers in the cluster can share the load. Be sure to redistribute any media content among the other servers so that it remains available throughout the process.
Updating a decentralized Windows Media server network is the most complex deployment scenario because you must update one or more servers in a central location, as well as servers that are dispersed among one or more remote locations. The configuration might look like this:
To update a collection of Windows Media servers in a decentralized environment, begin by selecting a candidate to update first. Configure that server, test it until you are sure it is performing as you expect, and then put it back into production. After you have an updated Windows Media server that is operating correctly, you can do the following:
Configure another computer to match the one that you have just updated and then ship it to the remote site.
Use a file-copy utility to copy the digital media content, publishing point structure, logging directories, and so on to all other computers that you are updating. This is useful when your servers mirror each other; it is not a good idea when you have different configurations on different servers.
Provide detailed update instructions to your remote data center staff. These instructions should include all of the required publishing point and security settings, directory structures, logging attributes, and so on.
Each updated server should be tested to ensure that it is functioning properly and can handle the client load. Much of this can be handled from a central location by using Terminal Services or by using Windows Media Services Administrator for the Web, which enables you to manage Windows Media servers remotely by using a Web browser. For more information, see Administering Windows Media servers remotely.