Future Proof Capture: Best Practices for Planning Your Server and Storage Strategy

Hi.

Welcome to our continuing series of why webinars

documenting creative use of media site around the world.

I'm Sean Brown, vice president of education, and today's

webinar is titled, Future Proof Capture.

best practices for planning your

server and storage strategy.

Once again, we have a very large audience joining us from

all over the world.

There's just under 250 people online right now as we start

off, from all over the world.

Just a quick rundown as I like to do, Argentina, Brazil,

Belgium, Colombia, Croatia, friends joining us from the

Czech Republic, the Dominican Republic, England, Ethiopia,

France, Germany, for the first time, India, Italy, the

Netherlands, New Zealand, Spain and Saudi Arabia.

And a huge contingent of corporations, universities,

and government agencies joining us from North America

from every single state in the United States and every single

providence in Canada.

So welcome to all of you.

Before we get started, I'd like to point out a few

interactive features of our newest Mediasite player, the

Silverlight player, that you might be using today.

If you hover below the video, you'll see the normal controls

show up allowing you to make some viewing options.

And also to the right, you'll see a viewing pane where you

can make some viewing options, switching between large

slides, large video, and those types of things.

In the classic viewer or in the Silverlight player, you

will see a speech bubble.

If you have a question at anytime during the

presentation today, click on that, type your question, and

it will get to me, and I'll relay it to our presenter.

If you'd like to include your email address, we can also get

back to you offline, or if we don't get to your question in

time before the end of the presentation.

Also in the same tool bars, you'll see an attachments

link, and there will be supplementary information

about today's presentation, including the

slides from our presenter.

Now to introduce my guest. Before joining Sonic Foundry

as the director of systems engineering, Tom Irons was the

manager for smart classrooms and emerging technologies at

East Carolina University, responsible for over 100

classrooms at that institution.

At ECU, he was among the principal architects of the

Mediasite server support infrastructure, which to this

day, remains one of the largest and most prolific

classroom content capture infrastructures in the world.

In his current role, now that we've gotten him to Sonic

Foundry, Tom and his team of field assistance engineers are

in touch with virtually every Mediasite

installation around the globe.

Tom holds a master's degree in industrial technology from

ECU, and he has unique distinction of being the first

person I know that achieved his master's degree with

almost all of the class work coming via Mediasite.

So welcome Tom.

Welcome home.

Thank you.

Before we get started today, I'd like to take a moment to

thank the people at the various institutions that

helped me, helped us put this documentation together.

There are three groups of people that were major

contributors to what we're going to talk about today.

The names have been omitted to protect the innocent, but

again, thank you very much for your contribution.

So what are we going to talk about today?

We're going to look in a very high level way at three case

studies of Mediasite deployments.

We're going to look at vital statistics related to each

institution, the challenges those institutions faced, and

the resources they were able to utilize to take care of

their deployment.

And then ultimately, what their deployment

model ended up being.

After that, we're going to spend a few minutes on

considerations for new Mediasite deployments.

New applications.

What are you going to use Mediasite for?

What do you think you're going to use Mediasite for?

Storage considerations.

And then, what are future plans?

So let's dive right in.

Our first case study is a large regional university.

They have somewhere in the neighborhood of 30,000

students, and a very large distance education base.

So they have the need to deliver a large quantity of

distance education content, in this case, via Mediasite to

students over the internet.

They've got about 40 recorders deployed in classrooms across

the campus, existing storage in the form of a very robust

storage area network.

So we worked with this group to put together a plan to

leverage existing resources and put together what we're

calling here a three server multi-site deployment.

Attached to this presentation is the deployment guide for

Mediasite EX server.

And in it, starting about page eight, you'll see several

recommendations for a typical three server deployment.

This is very similar to that, with a couple of exceptions

that I'm going to talk about here.

If you'll follow me on this slide from right to left,

you'll see a Mediasite recorder that's delivering

content across whatever firewall might exist at the

departmental level in whatever building the recorder is

located in.

There are actually 40 recorders in this deployment

scenario, but just to simplify things, were

looking at one here.

Content's pushed across whatever firewall exists to a

central IT group Mediasite deployment.

So let's start in the middle at the top.

The SQL database portion of the Mediasite deployment was

placed on an existing SQL cluster.

Very often in higher education, we encounter

schools and groups that already have SQL resources.

They already have nice, robust, redundant places to

put a database.

The Mediasite database, generally speaking, is not

particularly demanding, so it's very often trivial to

place Mediasite resources on some existing hardware.

And in this case, it made a lot of sense, because it's

already redundant and already very powerful.

If you move below the line that illustrates the actual

network traffic, we'll start on the left and we'll look at

the blade chassis where we have three

blade servers in place.

The first one is the EX application server.

That blade is a very robust piece of hardware that is

running 12 concurrent Mediasite EX server instances

to service the various colleges and departments that

wanted their own logically separate Mediasite servers.

So they can all share the same hardware, but have separate

administrative functions.

The second server in that chassis is a Windows media

server that serves the media for all of those instances.

This isn't particularly unusual.

If you look at the way it's described in the deployment

guide, it looks like there's a one to one ratio.

But the media services portion of Mediasite, generally

speaking, is very capable of handling multiple

instances of Mediasite.

The sales engineering group and our technical support can

help you scope that more specifically, depending on

your particular needs.

And we'll get into that in a little while.

There's a third blade in that chassis, and that's a cold

spare blade.

It's just sitting in the chassis off.

What's it there for?

Well if you look at the second yellow box, you'll notice that

the blade servers boot from the university

storage area network.

What does that do?

Well that allows us, or allows this university, in the case

of a hardware failure, to shut down the failed blade, bring

up the cold spare blade, and have it boot to the same

location as the failed hardware, so that recovery

from a hardware failure can take place, generally

speaking, in less than five minutes.

This university does have 24 hour coverage of their network

operation center.

So it's relatively simple to recover from a failure.

The storage area network itself is redundant, so data

is in two places.

There is also near real time backup to an array of serial

ATA drives.

And then nightly backup to tape.

Those tapes are taken off site.

So you've got a disaster recovery plan, in that should

there be a real catastrophic occurrence, a fire, a flood,

you have your data on tape, off site.

And that includes the database data.

And then on the left, of course, the content's being

delivered out over the internet to your end users.

Let's move on to scenario number two.

Scenario number two is a little different.

This is a multinational manufacturing company.

They have in excess of 50 offices

distributed around the world.

And they do a couple of things that are pretty critical to

their mission.

They perform, or they offer regular live broadcasts from

C-level executives that everybody in the

company needs to see.

They also have a lot of mission critical corporate

information that needs to be available on demand and needs

to be available all the time.

What are their challenges?

Again, they need reliable delivery to large numbers of

concurrent users.

A resource here that's not on the slide, is that this

company does and did have the money to invest in some server

infrastructure.

So in this case, we helped them put together what is more

or less a typical high availability Mediasite

deployment.

Again starting on the right, you'll see the Mediasite

recorder or recorders delivering content to a

centralized Mediasite delivery system.

In this case, it's a high availability system.

So again, we'll start in the middle and above the line.

You'll see two redundant network load balancers.

Those load balancers perform two functions, in this case.

They perform a fault tolerance function and a load

distribution function.

If you look right above that, there are three redundant EX

web application servers taking care of content delivery.

So those load balancers, in the case where there are high

numbers of concurrent users, the load balancers can

distribute that load across those three servers.

The secondary function is that should one or more of those

servers fail, the load balancers are smart enough to

know that a server's gone offline and route traffic to

the servers that are still up.

So you get the ability to address higher numbers of

viewers, and you also get more reliability in terms of your

Mediasite delivery.

Down below the line, again, to this institution was able to

utilize an existing SQL cluster.

Again, it's a two server cluster that provides some

redundancy and some reliability for the database

component of Mediasite.

And then you'll see the media server that provides the video

portion of our presentations.

Finally, moving off to the left, again, content's

delivered to your end users.

Let's move on to scenario number three.

This goes back to a higher ed deployment, but this one's a

little bit different.

This is a departmental deployment at a reasonably

small regional university where a department was able to

find some funds and start off with five recorders, and the

aim being to deliver content to a low number

of concurrent viewers.

I say less than 500 on this slide, but honestly, the

initial deployment, we were looking at in the neighborhood

of 50 to 100 concurrent users.

So not a lot of demand in terms of demand on the

application server.

There are some challenges.

The university, like many others right now, didn't have

the resources, the capital resources, to purchase

dedicated hardware for Mediasite system.

However, they did have a reasonably robust virtual

server infrastructure in place where they had some resources

that could be allocated to Mediasite.

There also, in this case, was the potential for the

Mediasite deployment on this campus to expand to additional

departments or even to go campus wide.

That eventually did happen.

So we're going to talk about, in this next chart, we're

going to talk about how we could help them prepare and

how they were able to expand.

So this is a simplified diagram of a virtual three

server deployment.

Again on the right, you'll see your Mediasite recorders

delivering content.

But the important stuff here is below the network line in

the middle where we're looking at a virtual host server or

group of servers.

And then below that, a simple diagram.

Basically what we're saying here is I've got this big

chunk of CPU and memory resources available in my

virtual infrastructure.

And I've dedicated a small slice of that chunk to my web

services, my EX server, to my media services, and to my

database services.

But I've got a whole lot of other capacity available.

Well at some point, this group moved from 50 concurrent users

to adding five more recorders, adding a whole additional

department, and going up to the few hundreds, in terms of

concurrent users.

Very quickly started to experiencing high load on

their servers.

Called us up.

We helped work out a plan, helped them determine the

additional resources they might need.

And the beauty of virtualized deployment is that it's

relatively simple for an administrative, for a server

administrator to take those servers and say, I need twice

as much CPU dedicated to the Mediasite application server.

I need eight gigs of RAM instead of four.

I need more processing resources available for the

database server.

So with minimal downtime and minimal administrative work,

it's relatively easy in a virtualized deployment to

increase your load tolerance.

I'll qualify this a little bit by saying that were always big

fans of dedicated hardware.

We think that's great.

If you can provide really high end dedicated stuff, you are,

in the long run, going to be able to deliver, at least

internally, to a large number of users.

But this is a cost effective and easy to manage way to

deploy Mediasite.

Now moving on.

I know we said we're going to have three case studies, but

there is a fourth option that needs to be discussed.

And this isn't really a case study.

This is more of a general discussion of some of the

issues that a lot of people that we talk to face.

Very often in the corporate environment and sometimes in

higher education, we encounter networks where internally,

inside the building, inside the office, however it's

configured, network bandwidth is great.

You've got to gigabyte of space, of bandwidth, to

everybody in your office.

But your wide area network links are very restricted.

Or your internet pipeline is very restrictive.

And you're trying to deliver content to people who live

outside of that space.

Sonic Foundry offers a very robust and flexible option to

help you address those issues.

This is our hosting services.

Now this is a vastly oversimplified diagram of how

Sonic Foundry hosting services work.

But I want to walk you through it very briefly.

Again, a Mediasite recorder at your location on the right is

going to deliver content out of your firewall and via the

internet to one of the Sonic Foundry data centers.

The Sonic Foundry data centers are going to take care of all

your storage, backup, server administration, and bandwidth

challenges, and allow you to offload that work and that

expense to somebody else.

And then we're going to deliver your content to your

end users over the internet.

I want to get into that in a little bit more detail.

When should you consider hosting services?

Well there are lots of reasons.

But generally speaking, we see a lot when there are internet

bandwidth limitations at the end user or at the client.

But also, maybe local servers are unavailable, or maybe

local servers are prohibitively expensive.

In my past life in higher education, for every server we

deployed, we had to allocate a percentage of an FTE to manage

that server.

So on paper, putting a server in a rack could get very

expensive very quickly.

Maybe you just need to offload the administrative

responsibility.

Maybe you don't have enough server admins or maybe this is

a departmental deployment and the server admins are at

central IT.

Or maybe this is just an initial deployment.

You've got the idea that you want to deliver

content using Mediasite.

You bought a recorder, you bought two recorders, but

you're just not sure how fast it's going to grow and how

best to handle your content.

Hosting is a very good option in that situation.

Our hosting options are very flexible.

We offer all the functionality of on premises servers.

We can scale your hosting from five or ten to literally

thousands of concurrent viewers.

And our data centers have redundant servers, redundant

storage, redundant power, and are very, very reliable.

And we also back everything up.

And then, of course, we have event hosting options.

So if you have an on premises server, or you have a hosting

server that's let's say, scoped to 200 concurrent

users, but you have an important

person coming to campus.

An event where you need 10,000 people to be able to view it.

It's very simple for you to contact us, have us put

together an event hosting package for you, and help you

distribute that content to all of your end users, wherever

they might be.

Moving on.

I want to talk in a very general way about some of the

important considerations for planning your Mediasite

deployment.

All of these things that we're going to talk about over the

next few minutes come down to how much server horsepower do

I need to throw at this thing?

How much storage do I need?

And what are my bandwidth considerations?

And I think, as you'll find in a couple of slides, storage

and bandwidth kind of go hand in hand.

And these are just a few of the considerations, but these

are the ones that seem to come up the most often.

So let's start with your target audience.

How big is it?

How much of it is live?

How many people at any given time do you have watching

Mediasite presentations?

This is going to speak to what kind of server, servers, you

need to deploy.

What you need that deployment to look like.

Whether you need to utilize hosting services.

And how you'll structure your content.

With the next two questions, what's the low end of

bandwidth for your clients?

What can your client tolerate?

Can I send them a 700 kilobyte stream, or do I need to be a

little more reasonable and send things at more like what

we typically see in a university setting, 225

kilobytes on the video.

You need to make sure that your content, however you're

delivering, is A, not going to overwhelm your network when

you look at your aggregate number of streams. And B, be

acceptable to your end users.

And then, where are your clients located?

Are all your clients inside your in-house network?

In that case, your bandwidth question is significantly

different then I've got 1,000 clients, half of them are

across wide area network links or in other places.

So just considerations to be thinking about as you plan or

consider your existing Mediasite deployment.

Then the content itself.

How much content are you going to generate?

I say be conservative here.

And what I mean is make sure you allocate more space than

you think you're going to need.

Attached to this presentation are some knowledge base

documents that will help you estimate the amount of

aggregate bandwidth you'll consume.

And from that number, you can also estimate the amount of

content you'll store, depending on how many hours

you want to keep online, how your encoding your content,

how many slides you deliver, and other similar

considerations.

How much of that content is going to be live?

Live delivery of Mediasite content, from an application

server perspective, it can be significantly more demanding

than on demand delivery.

So if you have ten recorders delivering content, but it's

all on demand, the server configuration you end up with

may look significantly different from the server

configuration you planned if you're going to deliver 10

live streams at the same time.

And then, how many simultaneous recordings, live

or on demand, what's the total amount of stuff you're going

to push up to the server at any given time?

All of those things are important things to think

about when your planning your server deployment.

Finally, reliability.

Is your content mission critical?

Does it need to be up all the time?

If it does, then that's when you immediately need to be

looking at a high availability kind of deployment where if

you experience a server failure, it doesn't

necessarily take your system offline.

Let's say you can tolerate some down time.

How much downtime can you actually tolerate?

In the first case study with the large regional university,

the addition of the spare blade in the chassis allowed

that group to go back online within just a couple of

minutes of a hardware failure.

But let's say you deploy what we think of as a typical three

server deployment.

You turn to page eight of our deployment guide, which I

think I mentioned is attached to this, to the links section

of this presentation.

You buy the servers, you put them out there, and you start

delivering content.

You don't have any extra server resources.

And one of those servers dies.

You have a motherboard failure, you have a parts

issue with that machine.

Well you've got down time while you repair or

replace that unit.

It could run from minutes to hours to days.

So you need to be thinking in terms of, if I go offline with

my content, how long can I be offline before I'm in trouble.

And then what's plan B?

What's your backup strategy?

Where are you putting all this data that you're generating,

besides on the Mediasite servers?

Are you backing them up?

Are you taking them off site?

Are you hosting with us so that we're taking

care of that for you?

All of those things are important things to consider

when you plan a Mediasite deployment or when you look at

repurposing the deployment you've got.

So we've talked in a very general way today about

deploying Mediasite Sites servers.

Every case is different.

Every case is very specific.

So I strongly encourage you to call or email your sales

engineer if you have any questions.

Or if you want to talk about the deployment planning, best

practices, how we can help you.

If you don't know who your sales engineer is, your sales

representative can help find that person.

And if you don't know who your sales

representative is, call me.

My contact information's below, my

email address is there.

I am available and I will point you

in the right direction.

And now I'd like to hand this back to Sean and take

questions and any additional discussion.

Well great job on your prepared remarks.

Got a lot of questions coming in for you.

But the people who work for you at Sonic Foundry are some

of the most famous people at Sonic

Foundry out in the field.

That's Paul Baumgartner and Scott Reynolds.

I'll miss them.

But Paul and Scott and Bill Cherne and Fred Thimme and Ian

Vogel and all those people around the world who probably

helped you when you got started your very first day

with Mediasite or in all of your upgrades.

And they're a great team, Tom.

You've put together a great team.

A lot of the questions I'm going to try to organize into

themes and just hit a couple really quickly.

A lot of people are extremely interested in your rules of

thumb that you hit about storage.

Rule of thumb for size of today's webcast, i.e.

megabytes per hour, and also, amount

kept online per semester.

What are you seeing out there?

If you look in the deployment guide and you look at the

server recommendations, we do publish our rules of thumb.

But in the aggregate, the rule of thumb for content storage

is about 2.5 megabytes of storage per minute of content

that you generate.

Now this can vary wildly.

If you're a group that likes to publish very high bandwidth

content or you push a whole lot of slides, that

number can go way up.

If you're very conservative because you have bandwidth

challenges or you're really not concerned about your

talking head and so you push the bit rate on that down,

they can go down.

Now there's a knowledge base document attached to this

presentation that says, give me your bit rate, give me the

number of slides you expect to generate, and here's an

estimate for you in terms of consumption.

So you can certainly explore that.

If you want guidance on that, absolutely contact one us and

we'll help work through your specific scenario.

Another question that's come up in a lot of different ways

that relates to this is the classic question, sixteen by

nine or four by three?

What are you really seeing out there, and what's the impact?

Are you seeing schools switch to widescreen format, or is it

something that just certain elegant professors are really

excited about?

What do you think?

On the content side and the video side, we're seeing more

sixteen by nine content.

I think that a lot of the time, yeah,

it's the early adopters.

It's the professors that like things to look fancy.

That said, we can absolutely accommodate it in the content

side or the video side.

So it depends on the institution.

We have a lot of people doing it.

We have a lot of people not doing it.

But we absolutely can do it.

If you need help figuring that out, we can certainly have

that discussion.

Does it impact your storage or your processor power

considerations for the service stacks that you

were talking about?

Generally speaking, no.

Sixteen by nine stuff is from a space consumption standpoint

really about the same.

Gotcha.

In the newer Silverlight players, people wonder if the

Silverlight players versus the classic players impact storage

or server power considerations either?

Are they pretty much the same?

Or more effecient?

From the back end, they're actually, they're the same.

From the back end, we're using the same technology to

compress the video and to capture the image content.

For Silverlight players as we do for--

excuse me, my microphone is falling off.

Bear with me for just a moment.

We haven't solved that.

We haven't solved the microphone falling off issue.

We're using the same technology to capture and

encode our video and our image content, regardless of the way

it's delivered.

So a Silverlight player is going to look neat, but it's

not going to really impact, in one way or another, your space

consumption, your bandwidth consumption.

I'll be more specific.

In the Silverlight player, the attachments, if you click on

the information button underneath Tom's slides, the

eye, you'll be able to see these other links.

Another question that has come in is you touched on very well

in your documents virtualization.

So is virtualization something that you think is a growing

trend for people to use Vmware or whatever?

Yeah, absolutely.

We're seeing a lot more virtualization.

For a while, the utilization of virtualized servers was

sort of creeping up, and now it's sort of flying up.

A lot of institutions find it significantly more efficient

to dedicate a very robust set of hardware resources to a set

of virtualized servers so that resources can be allocated

dynamically as needed, rather than throwing lots and lots

and lots of dedicated servers into racks.

So again, we love dedicated servers, but virtualization is

something we're seeing a lot of and something that we're

absolutely supporting.

Another very specific question a person asked, we're thinking

about putting 55 classrooms online with Mediasite.

and we have no server infrastructure

at all right now.

Do you recommend load balancing, any other

recommendations out of the box?

First of all, I want that person's phone number.

That's actually my first question is

what's your phone number?

The answer is yeah.

Basically, if you're talking about 55, an initial

deployment of 55 recorders, and you don't have any server

infrastructure, we would want to look at a very robust,

presumably load balanced deployment

right out of the gate.

That's a conversation that we can have. We can get in touch

and look at all the variables involved.

Where these recorders are located?

What's coming out of your system?

And where your servers are located?

And help you to scope that.

Got it.

Another question that just came in that's for me is

they'd like to share this presentation

with their IT committee.

Will this be available on demand?

And yes.

I'm sorry I didn't say that in my housekeeping.

This exact presentation will be available at the url that

your watching it now on demand for later viewing.

You can share it with anybody that you care to.

Another question along those lines that came in, you

mentioned that a SAS or ASP option is

available from Sonic Foundry.

What happens if you start that way, but you decide to take it

on premises later?

Can you do that?

Absolutely.

We do that all the time.

We're very good at taking your initial hosted deployment and

helping you migrate your content to an on premises

server or servers.

That's not a problem.

That's something we work with you as a

professional service on.

Got it.

Another question is about Silverlight

players and older Macs.

My friend Mike from Texas asked will the Silverlight

players work on non-Intel Macs, or do they only work on

Intel Macs?

There are ways to make our content work on all Macs.

Occasionally there are some tweaks that have to happen,

but the answer is, yes.

And we're more than happy to have a discussion with you

about specifically the technical requirements for

playing Silverlight players.

The next question is on demand versus live.

Like we like to do, I force us all to do, Erica and I, in

marketing here, to do high wire act.

We do a live event once a month for as many people as we

can get on.

But most universities are recording

classes for on demand.

If you're going live, if that's your primary function,

does that affect what scenario you might use to deploy and

where does it affect it?

That's a question.

Yeah absolutely.

If you're going live a lot, and let's assume we're talking

about an on premises deployment, then you need to

be considering a more robust server infrastructure.

Well let me qualify this by saying if you're going live

with a lot of simultaneous live streams, like we've seen

at some of our larger higher education deployments, then

you're going to need a more robust deployment up front.

If you're going live occasionally to large numbers

of concurrent users, that is really about the same

calculation as having large numbers of on demand users.

Obviously you need to be considering and if you've

already got 500 on demand users all the time, and you're

going to go live to a 1,000 people, you need to be able to

accommodate that aggregate number.

So there are a lot of considerations there.

Another question that people have is

about storage practices.

How much content do people keep online?

So it's basically a lot of these questions relate to your

planning guides, and they want to know what are most people

doing. so how much stuff do they keep up?

Again, this is all over the board.

There are people that are very restrictive in the amount of

content they keep online.

And there are groups that are not so much.

Let's start with higher education.

The group, the university that I discussed in scenario number

one is a high end content producer and keeper of large

amounts of content online.

They keep somewhere in the neighborhood of 5,000 hours of

content online at any given time.

That amounts to about two semesters worth.

So the current semester's content, plus the previous

semester, are kept online in case they're needed.

Anything before that time period is archived by the IT

guys, placed in offline storage.

It's never thrown away.

It's all there so it can be recovered if you need it.

If you have a professor that has a lecture they delivered

three years ago and they want to deliver it again, they can

get it back.

But the policy is let's not let anything

age more than a year.

In this case, it's 4,000 or 5,000 hours of content.

On the other hand, a lot of our corporate clients, I think

we find, that they only keep what's critical

to the moment online.

They may have what they delivered this week and what

they delivered last week.

There's sensitive stuff in that content.

They're talking about things that are specific to the

mission of the company and are proprietary.

So it doesn't sit out there simply because it was the kind

of thing to be delivered once and not delivered again.

And so it's difficult to answer in a sort of what is

everybody doing form, because everybody does it a little

differently.

But again, that's a discussion that we can certainly have

based on what you're trying to accomplish.

Here are some best practices for doing that.

We certainly have that conversation.

What do you think is the most important planning step that

people aren't doing out there when they're making their

server deployment plan for on premises?

I think the most important planning step that doesn't

happen or that should happen more often than it does is the

things that we talked about at the end.

I want to buy 10 Mediasite recorders.

I've just decided I want to buy 10 Mediasite recorders.

Well what are you going to do with them?

How many people are going to watch the content you deliver?

How many servers do you need to buy, or how much hosting do

you need to purchase, and how do you need to deploy this?

The initial consideration, what we really want to avoid

but do you find ourselves doing occasionally is walking

into a situation where the organization has said, I'm

buying 20 recorders, I've got no idea how to

put the servers together.

And that conversation needs to happen while you're thinking

about how you're going to buy these things, and who you're

going to deliver to.

So that it's part of the initial plan, it's not

something that gets tacked onto the end.

It's sort of akin to the thing that I've seen a thousand

times where you build a building and then you decide

what projectors to put in the classrooms, but you didn't put

any power outlets in the ceiling.

So it's a consideration that all needs to take place as

part of the initial discussion whenever possible, which is

why I encourage you to reach out to your SE, or we'll reach

out to you, and we have those conversations.

And also to involve IT, which most people watching this just

said amen to what you're saying, because they're mostly

from the IT part.

And basically, I agree as a person who's involved in a lot

of these conversations that the beautiful thing about

Mediasite is it's so easy to conceptualize that the

architects and the professors and everybody, and the deans

get excited, and they involve IT last. You're saying get

them involved early and often.

Absolutely.

On both sides.

Another question that people have, and my friend Michael

asks it the best, in a corporate environment

especially, but what are the options to provide failover

for the Windows media server itself?

So when you're going live like this, and it's a high profile

event, and that server--

I'm going to start with an on demand scenario, then sort of

back in to the live question.

In an on demand Mediasite deployment, you can absolutely

load balance to Windows media portion of the delivery.

If we were to skip back to that diagram, you would just

add an additional Windows media server

behind a load balancer.

Out of the box Mediasite doesn't support directly load

balancing Windows media servers

for live event delivery.

There are ways that can be accomplished.

There are some processes that have to be gone through to

make that happen.

That's a discussion we would need to have with you,

depending on your scenario.

And then there's always the hosted or event hosting

options where we have the redundant, reliable

infrastructure in place for you.

So you have a big important event, we can pull it off

without you having to make major changes on your end.

And we're getting asked that a lot.

We're seeing that increase that Sonic Foundry's being

brought in, in a blended world where people have robust, some

of the scenarios of the of the clients that he diagrammed

here, use our cloud based services exactly like you just

said for exactly those challenging times and

challenging webcast. Getting down to the last questions,

this is kind of for you to conjecture or consider.

One client asks any chance of Sonic Foundry thinking about

taking on IP type video camera inputs for

automated video capture?

How do you feel about that?

I know you have some feelings about the new cameras that can

just sit and and be partners on the network.

Yeah, IP based cameras are something that right now, out

of the box, most of you that are watching will know, that

that's not something we can directly support.

We can't capture the stream from an IP based camera

directly as the video feed for a Mediasite presentation.

That said, assuming that you can get the quality you're

looking for, I think IP based cameras are great.

And what that would imply most of the time, is that you're

using some sort of centralized Mediasite recording

infrastructure.

You've got cameras all over the building, but you recorder

are all in a rack in the control room.

And you just need a really good way to utilize existing

infrastructure to get your video downstairs to that

control room.

Well in that case, right now, you'd accomplish that by just

putting a receiver for that IP based camera that can output

some analog video in that control room and translate it

to something Mediasite can process and redistribute.

That question comes up a lot.

We consider that in different ways all the time.

I can't tell you that we have that coming

out in the next version.

But there are ways we can accommodate almost anything

given the chance to talk about how to deploy it and what the

details are.

I have a provocative question from Canada.

What are the most common infrastructure concerns that

are underestimated, what are the most common infrastructure

concerns that are

overestimated, during planning.

Underestimated is easy.

Bandwidth.

If you don't have the discussion up front about how

much bandwidth you're going to consume and where your end

users are, then you can get in trouble.

Small universities, little tiny internet pipes, hey, we

can deliver a lot more content to our satellite campuses with

this thing.

Oh wait, we only have 10 megabits going out, and that

also has to accommodate the faculty email.

And especially in corporate, sorry to interrupt.

And corporate as well.

Remote offices outside of headquarters.

That's one of the things that comes up, and you go, oh!

It's one of those moments.

Overestimated?

I don't believe you can overestimate resource needs.

Oh, you're a geek.

I am.

If you can throw all the resources you have it, I'm

thrilled to death.

I think that it's always a good idea to overestimate a

little bit.

The one place I see people thinking that we're going to

consume more than we really do is in the storage calculation.

The university, I hate to keep going back the case study

number one, but this particular university gave me

some information last week.

They keep those 4,000 almost 5,000 hours of content online,

but they're only consuming about 700 gigabytes on their

storage area network.

And they've got three terabytes available.

They anticipated by now that they would've filled that up.

They're nowhere close.

So I think what you'll find, once you do the math, is that

we really consume a lot less space than you think.

So that's one way we might, that you might overestimate.

Be conservative but also understand that you're

probably going to have more storage than you think.

You're probably going to be fine.

And the very last question, is-- oh no, there's two.

The second to the last question is when you look at

near line storage that you talked about in tape formats,

two different people are asking

essentially the same thing.

What's the most popular offline storage methodologies

for Mediasite?

The thing that I see the most is still just backup to tape.

Getting it off site somehow.

Automatically?

[INTERPOSING]

You know a lot of universities have a robot.

So they're just pulling all their data to tape and then it

all goes in a big box and gets trucked out every night to the

building next door or across town or whatever, wherever

their disaster recovery site is.

There's also a fair amount of offline backup to just

additional disk storage.

If you have a set of inexpensive ATA storage

sitting somewhere, you can back up NAS or your

SAN stuff to that.

So it's in the same building, but it's not on the same disk.

So if you have a failure, you can come back fairly quickly

while you repair the issue.

I see a fair amount of that as well.

A couple of questions on the same theme, I don't know if we

have a comment on this.

But basically get another shout out that WMV rocks, but

are there any chances that we're considering opening it

up to other formats, like H.264 as well?

I think that at Sonic Foundry, we're always considering

what's going to be best for the end user, for the people

that are producing content and for the people that are

consuming content.

Right now we are on the back end Windows media.

Obviously we deliver via Silverlight player to other

platforms and to Windows platforms for

compatibility reasons.

And so that we can make the really

neat looking new players.

We feel like there's a lot of future in Silverlight.

I can't say definitively that we are looking at any new

codex, and new encoding methods.

But I will say that we continue to evaluate those

technologies, and we will stay with whatever is the most

effective and the most advanced as we move forward.

Fantastic.

So that concludes your prepared remarks and your Q&A.

You're off the hot seat.

Great job, Tom.

Hi to Grant and Janie, I know your children are watching.

So he did a good job, didn't he?

I'd like to thank all of you for joining us once again for

this live web cast. Be sure to watch it on demand and share

it with whomever you want.

Thank you to Sonic Foundry event services for producing

this webcast. We'll see you the next time.