Unified Messaging - Secure and Compliant UM — Transcription
Neil:Today we're going to take a look at Unified Messaging and a little bit in terms of kind of
the technology used, but mostly we're going to look businesses practices piece in terms of addressing the questions that tend to come up time and time again as we do presentations to customers evaluating new solutions.
So we'll just jump in here. We'll talk a little tiny bit about who we are and to so you have a comfort factor that we have a right to be holding this webinar. Then we'll look at the options, not just on our system but overall for the way Unified Messaging can be deployed.
Then we'll kind of wrap it up with the five top considerations that we've seen as we talked to perspective customers and then in the end with some questions. Maybe you can give us some more considerations or your comments on this.
AVST's been around, actually this week is our 30th anniversary, founded back in 1982 and we were doing Unified Messaging by 1991. we have a long history with Unified Messaging, the CX product has been continuously been developed since that time and we believe we have the most flexible set of Unified Messaging options that are available.
We certainly have years and years of experience both talking to customers and implementing solutions in everything from a small single side enterprise right up to some of the largest global enterprises.
We're going to talk about what we found over those years of history in terms of Unified Messaging.
Today, we're going to talk about Unified Communications, that's the driving phrase and we believe we offer in those areas that we're in the best of these solutions, mobility, best in business processing. We'll kind of define what that is as we go along.
Like I said, we've been doing this for a long time and our feature set tends to be very impressive, but the inner-operability layer underneath it is perhaps equally as important. We'll talk about why you want to look at that layer when you look at Unified Communications as we go through this.
We'll talk about the different models as I said for deployment of UC just as we talk about it in terms of our general architecture. So, single site premise of private card for an enterprise and then that hybrid model that tends to be fairly popular right now.
If you look at some of the surveys that have been done lately you'll find Unified Messaging as part of Unified Communications, tends to be getting the most focus right now.
Those two top entries as you've noticed sort of dwarf what information we found and they were asked, as you look you see, what are you really looking at. What are you evaluating, where are you going to go first?
Unified Messaging is that top one and that's good for us.
Ann:Neil. We're not seeing the slides changing.
Neil:Oh. I'll be kind and won't go backwards. Let me jump ahead here.
Ann:OK. I can see that now.
Neil:All right. That's the important one.
Neil:Sorry about that. So if you look at the survey from information week, you can see these
are the results when asked, "What's driving you towards UC? Why are you evaluating it? What particular solutions are high on your list?"
And like I said, Unified Messaging tends to be the most important one and we're going to focus on that one today and we think we have some pretty interesting information for you.
Gartner talks about the UC quadrant. They’re probably the company that tracks it and gets the most attention with what they're doing. Then, the UC quadrant itself, to be in their quadrant there's a list of things you have to provide, a rather large list.
We don't actually make it into that quadrant directly because we only focus in a very small area of this. We tend to be focused, you know, our best of breed solution.
If you read the Gartner quadrant, they talk about, if you look at the sweeps where people are offering everything all in one package, the problem there is you don't tend to get the best of breed in every solution and then they refer to us by name saying, "If you are interested in the best of the breed Unified Messaging solution you should go talk to AVST."
So we're setting our credentials here, hopefully for why we're presenting what we're presenting.
If you look at the COMMfusion quadrant and this unlike a UC quadrant, this is tracking specifically Unified Messaging. We're up in the upper right hand quadrant in terms of, furthest to the right for the most complete solution although we aren't ranked as high [[inaudible 04:35] in our ability to shape the market. That has to do with our marketing budget as opposed to our functionality.
So we believe we can talk with a fair amount of expertise on Unified Messaging in the enterprise today.
Our platform kind of helps us out here. From the very early days our architecture was such that, where the UC inner-operability layer have had from long before the term of UC was used, the inner-operability for us means those pieces that connect to the outside world are in a separate segment of the application code which lets us do two things.
One, it lets us build new applications on top of that very easily and quickly and two, it lets us change that inner-operability layer without affecting the core software.
So to add a new integration to a new voice mail system let's say, or to a new e-mail system, it's very easy to connect based on this architecture.
Then the other thing this architecture reflects is the way we've packaged our solutions in terms of presenting them to customers. The application tiers on the top, rest on top of UC inner-operability and the three tiers: UC mobility, UC voice and business process tend to be the categories that we can talk to an individual customer.
Some customers want all those. Some are only looking for one, but this architecture lets us focus on those areas.
The UC mobile piece contains a number of things, and in this case Unified Messaging is what we'll be focusing on.
Unified Messaging, we've been out there doing it like I say, for a lot of years and it's fairly easy in terms of concept. You want to be able to get your e-mail, voice messages, fax messages perhaps, all on whatever your device of choice is, at any given time and that includes different devices as you move through your day.
It isn't good enough to just deliver those to the phone or to the mobile client or the e-mail client or the web browser, you're going to have to deliver them to everything. So the user can control their work environment without having them not have something or one critical element available.
The second thing we look at in our environment where we sell in the larger enterprises, is it's also extremely advantageous to be able to deliver it multiple e-mail systems.
While the goal of most IT partners would be to centralize down to one single, consolidated e-mail platform, that's sometimes a bit of a challenge, specific to acquisitions and mergers in process.
And then there's also a bit of a move to, at least trial, if not actually start moving to some of the cloud based systems like Gmail and Office365. Our ability to take a single CX system and host an enterprise and let them connect to as many different e-mail systems as they need and migrate users over whatever time frame is appropriate, we think is one of our strengths in terms of the overall architecture of the system.
The second real point there that is the storage options, so that's probably the single biggest discussion we have on Unified Messaging in terms of where we're going to store those messages. Where the customer feels they have to be and why. We're going to go through the architecture pieces and talk about that.
Then of course we have a mobile client that's going to get Unified Messaging on it as well. All of those pieces are important to Unified Messaging.
And as much as I'd love to say we have hundreds of features that no one else has, the truth is Unified Messaging has been around long enough where there's a fair amount of equality in the feature sets.
You know, if I see a bullet point presentation on competitors, it talks about pretty much the same things we have. We have a few little advantages depending on environment, like multiple e-mail systems and things.
The discussions really have to do with architecture. That tends to be what's of most concern to users.
So it will be interesting now for us to run a little poll like we do here so we can get some information from you, to talk about the e-mail servers you have deployed.
Ann:OK. Let me pull up that first poll. This, again, we are curious of what e-mail server or
servers you have in your organization right now. You can choose multiple answers. We'll just give it a few seconds and then see what you guys have gone.
OK. Just a few more seconds. Most people have voted. All right. Let me share the results.
Neil, there's about 85% that have Microsoft Exchange and then about 5% with Microsoft Office 360. 10% for Google Gmail, about 5% for Lotus and then 5% other.
Neil:Interesting. The number of quality systems continues to grow every time we run this
which is not surprising considering the structure in what some of the advantages are. So very good.
So certainly I'm guessing some of you, because of the percentages we just saw, have multiple e-mail systems.
One of the advantages we offer is our ability, particularly if you're looking at migrating from maybe Exchange in your enterprise to Office 365, the ability to do that in a staged manner by moving users in groups or blocks, however you're doing that is one of the features we offer as well. So multiple e-mail systems and all the normal players as we'd expect.
From our point of view, interoperability is fairly easy because of that architecture piece we looked at. We simply build connectors between that lower level of product functionality and the e-mail system itself.
We use whatever technologies are relevant. With exchange, we might use MAPI on the older exchange servers and web services on the newer. Office 365 is all new web services. Lotus is using their VIM protocol. GroupWise is using a modified flavor of IMAP. Gmail is secure IMAP.
Pretty much the rest of them out there tend to be IMAP4 of one type of another. This lets us take any user and dedicated them to any different e-mail store for the full range of Unified Messaging functionality.
Some of you have looked at this. Some of you may have already deployed it. It would be interesting to take a look at what your concerns are.
Ann:Okay. For this one, we do just want one answer. What's your primary concern with your
Unified Messaging implementation, whether it's compliance, confidentiality, flexibility, the message store, or the cost?
We have a lot of people voting. That's great. So, we'll just wait a few more seconds to make sure everyone gets a chance to vote.
Okay. I'll go ahead and close it out. It's pretty spread out. Neil, just so you can hear the results, for compliance it's about 20 percent: confidentiality is 20 percent, flexibility is at 24 percent, message store is at 17 percent, and cost is at 20 percent.
Neil:That's very interesting. I bet that's almost the only feature we could run that kind of poll
on and have cost not be the absolute highest one, because there are a lot of concerns.
We're going to address all of those I think, not in terms of what you should worry about, but just in terms of how once you've decided what's important to you, you can configure our system and our architecture to make sure that we're addressing that concern.
First, we're going to run through really quickly the architectures. While not a lot of people are all that interested or concerned with where things are on a network for the general applications, the message store is the concern.
Almost two-thirds of those concerns are all about where that message is and what those implications are.
There are really four ways to do this, and this is not just our product this is everyone's product. There is what has come to be called server based or single message store where the messages are stored on the e-mail server in the user's inbox. Sometimes that's called full Unified Messaging.
There's client based. It's also called dual store or integrated messaging. That's where the messages remain on the voicemail platform, but they're visible and accessible from the e-mail client. In other words, the unification actually happens at a client level instead of a server level.
Then there are various versions of secure. The concept for secure Unified Messaging tends to be your own employees can't get those messages out of the system. They can't go file, attach, and save them. They can't forward them to another e-mail address. They can pass them around within the system, but that's still keeping those messages within the enterprise.
Then there's simplified or notification. That's where we simply send a message.
Let's look at the implications from the architecture point of view of each of these. With server based, the voicemail system takes a message just like it always would. But, instead of storing it in a local database it pushes it using various kinds of message transport, depending on the e-mail system, and puts it into the e-mail message store.
That message is an e-mail now. It's an e-mail with a WAV file attachment, and it has usually a unique message class so we can handle it a little differently.
Most answers to questions on a feature level are, yes, it's just an e-mail. In other words, will it appear in my e-mail web client like Outlook, web access, or iNotes? Yes. It's just an e-mail.
If I'm using cache float on exchange will it get pushed to my laptop? Again, yes. If you just consider it an e-mail from a feature point of view most of that functionality is pretty easy to understand.
We do have custom forms to help you play those messages in your e-mail client, call back the message sender, click-to-call kind of things. There are enhancements that we've put in there. But the basic architecture for this, one is we make it an e-mail.
Now, all of your e-mail tools that are presenting e-mails, whether it's a Blackberry enterprise server pushing it to your Blackberries, or Exchange ActiveSync, or Good Technology, any of those technologies will now also leverage your voice messages by virtue of the fact they're in the e-mail store.
The concept from our point of view, is whether you have RightFax for fax or CX server. Basically, it goes into the e-mail.
There's just a quick screenshot. This happens to be Outlook 2010 showing you a typical mailbox where you notice there's voice, fax, and e-mail all in the same inbox. And, in this case, because it's Outlook 2010 you've got the nice player pane preview window with all the tools. That's server based.
The concern about server-based tends to be if the messages are in the e-mail what does that mean about discovery. We'll talk about that separately as we wrap up in the end here.
Server-based for hosted is effectively the same thing. All that really changes is the location of the message store and generally the protocols being used to interact with it.
In our case the RightFax CallXpress piece would push them out, and whether this was Gmail using secure SMTP and secure IMAP or Office 365 using the secure web services it's the same exact functionality in terms of the messages are out on the Cloud.
In the case of Gmail there's one difference. That is you don't get message waiting light control for your phone when you have Gmail. It just doesn't have that feature. We do have it for 365, but of these two hosted ones that would be the biggest difference between the two.
If you look at client-based Unified Messaging the architecture is the messages get taken and they remain on the voice fax server, on our server. Now, you take your client that's probably already connected to your e-mail system, although it makes no difference to us, we then build a second connection to the server.
Now you have a separate inbox. That inbox has messages that are voice and fax in one inbox and messages that are e-mail in another.
From a desktop perspective this is fairly similar. There's not really much difference except for the two inboxes. But if you go ahead and look at the functionality here, you will notice there's a separate inbox that actually has your voice messages in it.
Now, in this case this is an older version of Outlook showing the older form. It doesn't matter. As far back as anything that Microsoft supports we support the full functionality in the client for both server and client based.
Secure Unified Messaging, this is probably the one that varies the most between different vendors in what they'll offer you. In our case, our customers came to us and said, “We want a desktop where we're getting the voice messages that are restricted where our users can't forward messages out of the system.
“Up to now voice messages remained in the system. They can forward around to other users. You can play them over the phone. But there was really no way for that recorded file to easily get outside the enterprise. We need you to duplicate that.”
What we did is we took our existing web for managing client, and that's the client that comes with the system for the users to configure their mailbox settings, and we expanded it and put an inbox in it.
Now the user can look at their messages and basically play them from their browser, stream them. If they stream them there's no cache copy they can get a hold on.
They can't go file, attach them, and save. They can delete them. They can forward them to other users. But, they can't forward them out to an e-mail address. So, that's our version of secure Unified Messaging.
The last one is maybe not even Unified Messaging so much as advanced notification. In this version the administrator can enable any user to be able to send copies of their messages to them when they come in. I get a new voice message. The system will send out an e-mail message to the user. It will attach the voicemail as an attachment to it.
There are now two copies of that message. There is one still in the e-mail server and one out back in the voicemail server. Now, those have to be maintained separately. So you have to delete them both or manage them separately.
We think the value of this is a little less, so in our particular case this one's free. You can set up any user. We don't license users on CX then. Any user, the administrator can enable them to have simplified Unified Messaging.
We take it a little further. You can also enable the user to turn it on and off themselves. You can enable the user to change their e-mail address, to decide whether or not they want a copy of the messages. So, it's admin control at the highest level, and then that control can be delegated down to the users.
So simplified, UM becomes a nice applications tool for a wide range of solutions like contractors and things like that where you can actually extend out the voice messaging piece to people that may be on even a part of your network.
We look at all those architectures. If you go back 10 years, you know, our discussions were about features. Our discussions were about licensing. They were about the new things that people were coming across as they looked at Unified Messaging.
Now, these are the five C's from our point of view. This is what we spend our time talking about in the Unified Messaging market. The first one is compliance. Compliance is the most difficult one, because there are corporate legal requirements having to do with eCommunications.
Unfortunately, those aren't spelled out all that clearly most of the time in regards to voicemail messages. So an argument can easily be made that if you put a voicemail message in your e-mail then whatever compliance laws you have that control your e-mail, your voicemail goes along with it.
They're now discoverable, you have to archive them, all of those pieces. But an argument can also be made that there's no specific law that focuses on voice messages.
So how you deal with compliance is really up to you. From our point of view you simply tell us, this is what we feel. We want our messages in exchange or we don't want our messages in exchange in whatever e-mail we're using.
You have the ability on a per user basis to set that message store location, and you can change it at any time. If you go down one path and later on you get a different slant on what the laws are requiring, you can easily change that.
I have to say I have conversations with customers that go both ways where they say, “Oh, no, we understand. We believe we have to archive our voice messages and the easiest way would be to put them all in Exchange.” You certainly can set your system up that way.
We have ones that say, “No, as long as we don't put them in Exchange they're not discoverable, so we don't want them to touch e-mail at all.” Once again, you can set that up. So complete freedom, once you figure out what is correct for you our system can handle it.
Confidentiality kind of falls into compliance a little bit in terms of some of the laws have to do with confidentiality but some of them also simply have to do with, there are jobs where your employees have messages of a type that you really can't afford to get out there.
So maybe you'd go with secure so they can pass them around in the company the way they needed but they couldn't get outside the company. Or, maybe you would go with the client based one to make sure that they didn't get an e-mail.
Once again, the choice is yours. In terms of what you believe you have to do on a legal level or even just on a good business practices level, you're going to be able to match that. Once again, the ability to do it on a per-user basis sometimes is a very powerful tool.
There are certainly people maybe who work in the supply chain side of a particular business where it's a great advantage to them to have their messages in e-mail so they can get them from all the different clients.
Whereas at the same time, perhaps in the legal department, the decision is those messages need to remain more confidential, and they might use the secure version.
Configuration, one of the great things about this, and we've referred to this, is this is a per user choice. The first thing is you don't have to enable every single user for Unified Messaging. Unified Messaging does require a license. As a result, if you have a lot of users that you simply want to have voicemail, then there's no need to spend the money on that license.
Once you've bought a license for a user you now can configure the message store and the flexibility any way you want. Your ability to change it going down the road is a great future proofing in terms of as things change, particularly in the discoverability area, it's nice to know you're protected.
Capacity is sometimes an issue we discuss, less so now. Ten years ago capacity was more of an issue. Now, when people ask about the load on an e-mail server and a storage server, I'll generally tell the people open up your e-mail client. Click on the attachment paper clip icon to bring all your messages to the top. Look at how many messages you have with huge attachments in the megs and megs and megs size range.
Then, think about the fact that an average person maybe gets 5 voicemails a day, keeps them in their mailbox for 2 days, and those messages are 250K. So you know if you have two meg or three meg of additional storage per user, that's probably pretty typical and probably not much of an issue. If it is, then of course you do want to control some of that.
The load on the servers is interesting. We've built kind of an architecture piece in there called a message cache. If you call me and leave me a message, and I'm using server-based and that message gets moved to Exchange, and I call in an hour later and I want to retrieve that message, I'll have a copy of that audio that I left on my server.
I can actually play that message from my server, reducing our impact on the network and on the Exchange or whatever e-mail server you have by somewhere in the neighborhood of 40 percent. Just one more thing we've done over the years to improve the way that works on your network.
Then, at the bottom, and interestingly enough at the bottom of your list as well, is cost. There are a couple of things you want to look at with cost. There's obviously the upfront buy some licenses piece.
There’s also the training piece: the how well it integrates with your other environment piece; the maintenance piece: how easy it is for you to delegate some of the things like changing simple message notification addresses. If you can delegate that to your user, down term you've reduced the load on your help desk.
These are the discussions we tend to have with customers. I think they're pretty close to being in the order of importance not only from our discussions but probably fairly close to what you showed us on your poll. It's not surprising. We're all dealing with the same issues out there.
It would be interesting to know where you are with UM and, oddly enough, we have a polling question for that.
Ann:Another poll. Okay, yes. We're curious to know where you are in your Unified Messaging
Implementation, are you doing it currently? Do you already have UM and you just want to add additional users? Is it in the budget for this year or next year, or no budget at this time?
Okay. We have almost everyone, it looks like, has voted. So, we'll just give it a few more seconds.
Okay, the results: 20 percent are currently implementing, 45 percent already have UM and are adding additional users, 15 percent have it budgeted for next year, and then 20 percent have no budget at this time.
Neil:I always find these polls interesting. We've watched that number grow slowly over the
years. In our early years of implementing Unified Messaging we were looking at single digit percentages for people that were looking at it. It's one of those things that has grown continually.
I think it's shown its value over the years. I think the number of mobile devices that are out there now drives that even a little bit more. If you have a mobile device and you're connected to e-mail it just makes sense to give you your voicemail on it as well. So, it's interesting to watch that.
I am always surprised that there are people that haven't budgeted for it at all yet. I would think the drive from your employees would push that to happen. But it's good to have that information.
Now, what can we tell you? We've asked you some questions. Now it's only fair we give you a chance to ask us some questions.
Ann:Okay. We do have a few questions. The first one is, is this presentation being recorded.
Yes it is being recorded, and we also will have the slides for download available. After the webinar you should receive an e-mail today.
The recording will take a little bit longer, but once that is ready we'll also send you an e-mail with that.
The next question is a customer that says we are starting to use a mix of Gmail and exchange, but we'll eventually be full Gmail. How will you be able to resolve the MWI light issue?
Neil:I think what you're going to find is the issue sort of resolves itself. In the early days of
Unified Messaging if you couldn't light that light when you put the message in e-mail, customers absolutely couldn't accept that that would be possible.
Then, if you went back to that customer six months later they didn't care about the light, because we all live in e-mail. We already knew that message was there. We have desktop notification popups and all sorts of things that happen.
The fact that we couldn't light the light on some of the different e-mail systems was only a problem during the very initial sale. What happens today, because most Unified Messaging systems for the current e-mails have the ability to light message waiting, we face that again when somebody who has exchange UM now and it's lighting the light moves.
I think if you talk to your customers, your own employees, your own end users, you'll find that it's not that critical.
Unfortunately, with Gmail there is no way to light the light. If I put the message into Gmail I have to rely on Gmail to tell me when it opens the messages. Since it doesn't, the only option would be to write an app that constantly polled the mailboxes.
While we tried that approach in the early days, it tended to be extremely slow and it brought the e-mail system to its knees.
That was one of the early ways people tried to deal with Exchange. Now, Office 365, just like Exchange 2010, that web services package pushes us the information we need to know to control the message waiting light.
If you're going to move to Gmail then I think your choice is to do an education program for your users in terms of why they absolutely don't have to have that. Right now to the best of my ability there's no way to do a message waiting light for anyone when you're using Gmail in the Cloud.
Ann:Okay. The next question is, my organization has some mailboxes in Office 365, and the
rest are On-Premise. Can UM work with them all?
Neil:Yes, no problem. That interoperability architecture we have lets us build one connector to
Office 365, another connector to your local exchange regardless of whether it's 2003, 2007, 2010. It won't make any difference.
And then, one of the really great things is once that architecture is in place with those two connectors, as I decide to move, you know, 50 users across, I simply go to the mailbox and re-point them to that other connector. So it's a very painless process.
Now, that changes our connection, that doesn't deal with moving the messages. You've undoubtedly already discovered you have some challenges in that area. But from our point of view, we can do that mix today and we make it very easy. If you're looking at migrating more users over to 365.
OK, and the next question, how will end users control notification from different forms of messaging?
We have a pretty good messaging engine. Most of our clients, most of our applications that users can use to manipulate their mailbox do some level of message notification.
If I kind of break ours down really quick, we have the old, traditional, telephony based message notification, the call list, where you can go in and you can put up to 9 numbers in a list, with time delays in between them, and then when you get a new message it does the dialing for dollars, and it goes and finds you.
When you answer one of those calls, you can log in and get that message, and the notifications stop. That's traditional, you can maintain that over the telephone user interface, you can call in with DTMS commands, set that up, turn it off, add numbers, etc.
Or, you can maintain that from web phone manager, our web client. It's a little easier to do from web phone manager if you're doing complex things. Then that whole other step in web phone manager lets you do things like, I'm going out on the road today, I only want to be bothered when I get that urgent e-mail message from my boss.
Go ahead and notify me when I get that urgent e-mail message or when I get the urgent voice-mail message from my boss. Or, only notify me of urgent messages of a certain kind. So it becomes more of an application tool because of that GUI, which means users can very easily implement what they're looking for.
The next level of notification for us is text notification, and text can be true SMS to a mobile phone, if you want to add an SMS gateway, or SMTP notification to mobile phones or any e-mail address. That type basically has kind of two flavors.
The first flavor is just a notification. You'll get the e-mail and it'll tell you, you have a new voice mail from John Tyler [SP], and you can embed in that things like "click here to go to web phone manager" or "click here to call into your call express mailbox."
We have a very flexible way of building custom templates for people to use when they want that message to be different, then they kind of upgrade from that flavor.
If the administrator has enabled the user, they also can get a copy of the message. They can maintain that from web phone manager. They can go in, over the weekend let's say, and say, “I'm going out of town, I'm not taking my business phone, I'm just taking my personal phone, I'll only be in Yahoo or Google or whatever I want, so let me go and arrange to have notifications go to that.”
So that level of control is first enabled by the administrator, and then it can be actually run, if you want, by the end user. Those are the tools. The speech interface also does that in terms of turning some of the notifications on and off, but the two primary tools tend to be the desktop interface with web phone manager and the DTMS interface over the phone.
Ann:OK, great. Next question. If a user has secure messaging, but a message is needed for
legal reasons, is there any way to get the message saved out of the system?
Neil:There's always a way to do anything with our product. The question is, how often do you
that? Let's say you do that fairly often.
Then we talk about writing a custom app for an administrator to be able to go in and do that. If it only happens occasionally, what you can do is, let's say I have a message and I need it.
I can call my administrator and they can go in short term and allow me to play those messages by downloading them. That is an optional feature on the web client. If I'm enabled, when I click it, it downloads, and it will open up, typically, media player or whatever you have associated with wave files.
I can then go file attachment save, the administrator can then go turn me back into the secure mode. So if it doesn't happen a lot, that's probably how I would approach it. If it happens a lot, I would talk about building an app to do it, because that would be the easier way.
Ann:OK. This looks like it's the last question. With server-based UM, if my exchange is
off-line, can I still access voice mail via 2E? Will it synchronize once exchange is back on?
Neil:Here's what's going to happen with server-based with any of the systems. Since I can't
push the message, the new message, to the system, our system actually is intelligent enough to turn that into a voice mail user. So, message comes in for me, I'm normally server based, our systems are down, it talks to exchange and doesn't get an answer.
It says, “OK, you know what, right now, let's make me a voice mail user.” Next time I call into my mailbox and log in, it says "The external message store is temporarily unavailable. You have three new messages."
I can handle those messages over the phone, just like a voice mail user. When the exchange system or whatever system it is comes back up, we have a re-sync package that makes sure it syncs everything back up, and then all those messages will be moved. If I deleted a message, it'll be moved into the deleted folder.
If I listened to a message and left it in my mailbox, it'll be moved into my mailbox as read, and any new messages I haven't listened to will be moved into my mailbox as unread.
If the exchange server is down, you cannot get to existing messages because they're stored on the exchange server, and we can't connect. So that's the down side. New messages, fine. Existing messages, not until it comes back up.
Ann:OK, great. And that looks like it's all the questions we have. We'd like to thank everyone
for joining us again today, and look forward to seeing you on a future webinar. Also, look for an e-mail for the Unified Messaging report, and we hope to see you soon. Neil, did you have anything to add?
Just that, you know, we really appreciate when people come to these webinars. It's one thing for us to arrange to do this, it's on our calendar, it's part of our day. It’s what we're doing. For you, you have to take time out of your day to come to these.
We hope we give you enough value to make it worthwhile, and if we do, that's great and you'll keep coming back, because we offer quite a few of these. If we don't, what we'd like is to hear from you to let us know maybe the kind of things you would find more value in.
We do find this a great tool to get information to existing customers and prospective customers alike.
Ann:OK, thanks everyone.