Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

Wav file location

Where does the wav file reside if a person sends a message to a distribution list? Does it reside in anyone's particular message store? <br><br>


Re: Wav file location

This is actually a really good question. I spent some time last night poking around and trying to find a definitive answer for where Exchange actually stores the data associated with a message sent to a public distribution list (voice mail or otherwise) and couldn’t turn up a solid answer. Several books and on line resources turned up lots of info on how the address lists are resolved and how DLs are replicated etc… etc… but no info specifically on how the messages (and more to the point, message attachments) are actually stored.

The short story is Exchange is supposed to keep a single copy of the message in the PRIV.EDB on each server in the site and each user’s mailbox simply points to that one instance until all users have deleted the message from the inbox. Each user, however, definitely gets “charged” for the size of the message against their inbox quota. You can see this by sending a really big message to a DL and poking around in the private store info in the Exchange administrator.

However, I can’t find out where, exactly, the one true copy of the message attachment resides. It’s definitely not tucked into the sender’s box, I tested for that (either that or it doesn't show up in the private store info there). There’s no message store resources associated with public DLs, so nothing tricky is going on there that I know of. I’m not really sure where it resides.

I’ll search around in MSDN, but if anyone out there knows for sure, I definitely like to hear from you…

Jeff Lindborg
Unity Product Architect
Active Voice


Re: Wav file location

Well… after poking around in MSDN I still couldn’t find the exact location where it stores the message/attachment when you send to a distribution list, however there were a number of articles out there talking about the “Single Instance Messaging” scheme Exchange uses. In short any time a message is sent to more than one recipient, only a single copy of that message is stored on the server they reside… each server in the site that had at least one user homed on it that got the message would have a copy of the message sent to their PRIV.EDB. None of the articles talked about WHERE in the PRIV.EDB they were stored, it’s just some system controlled hidden repository of some sort. You can’t eyeball it with any tools that I can find.

The Single Instance Storage scheme is in effect regardless of if the message was sent to a DL or to a list of individual recipients… doesn’t matter. Further, Exchange treats attachments and the text (body) of the mail as separate entities with respect to the single store scheme. In other words if there’s an attachment to the message (i.e. a WAV file) and one of the users that got the message edits the text portion of the mail, they get a copy of the text part moved to their personal mailbox store, however the WAV file itself stays in the shared storage… which is pretty cool. This is why each user’s inbox quota gets “charged” for the full amount of the message size even though in most cases it’s actually stored external to the mailbox. If everyone decided to edit the body and/or attachments, it could screw up the mail limits in a hurry… as such Exchange assumes “worst case” and it counts against your store size restrictions.

Anyway… I’ve included some text from a couple of the articles in MSDN if you want to read more on the subject.


Microsoft Exchange performs single instance storage in the database on a Microsoft Exchange Server, so the 16GB limit on the private database is really a much larger logical storage. Single instance storage means that if 1000 users on a Microsoft Exchange Server get the same message, the message is only stored once in the database and each of the users gets a pointer to the message. The same single instance storage also holds for attachments. If a user opens their copy of a message and modifies it but they don't modify the attachment, Microsoft Exchange doesn't resave the attachments, just the new message body.

The Microsoft Exchange beta sites saw at least 3:1, and sometimes upwards of 6:1, single instance storage rates because most messages have an average of between 3 and 6 recipients. To extend this, the logical storage limit for users on a single Microsoft Exchange Server is at probably least 16GB*3 and possibly upwards of 16GB*6.


Single instance storage means that if the same message is sent to two users on the same server, that only one copy of the message is inserted in the database. Both users access the single instance of the message to read it. If this were the only message in the database, the single instance storage ratio for this database would be 2.

If the message were sent to four people, two on your own server and two on another, only a single copy of the message would have to travel to the other server to deliver the message to both users.

Thus, single instance storage ensures that only one copy of a message is needed on any given server, no matter how many users receive the message.

You may monitor your storage ratio in Performance Monitor using the MSExchangeIS Private and MSExchangeIS Public objects Single Instance Ratio counter.

There is a common misconception that the primary benefit of single instance storage is that it greatly reduces the storage space requirements for user data on a mail server. The truth is that its primary benefit is to greatly enhance delivery efficiency of messages sent to large distribution lists. Disk space savings from single instance storage are transient and drop off very quickly over time.

For Example: Suppose a message is sent to 500 mailboxes on a single server. This gives you a huge initial ratio of 500. Within a day or so, 80 percent of the recipients are likely to have deleted the message, plunging your ratio to 100. Over the next week, probably 98 percent will delete it, cutting your ratio to 10. Making the drop-off curve even steeper is the general rule that the larger the distribution list, the shorter the life of the message.

The most important benefit of single instance storage in sending this message was that it got delivered with approximately one-five hundredth of the work that would otherwise have been necessary--one copy was generated instead of 500. Between servers, single instance storage greatly reduces the network bandwidth required to transmit a message with a large distribution list.

Jeff Lindborg
Unity Product Architect
Active Voice

CreatePlease to create content