Single Copy Object Store in ND6
Good Day Experts:
Are any of you out there using Single Copy Object Store (also called Shared Mail) in ND6?
We experimented with it in version 4.x and gave up because of reliability issues (read: major headaches, lost email and upset users).
With the ever-increasing use of attachments in our organization, we are considering it again. At LotusPhere 2003 (didn't go to 2004), I asked around about it... Lotus personnel claimed that it works, but I could find no Domino Administrator that had used it. All that I asked (like me) were scared off by the previous issues -- preferring to deal wit the space management issues than the potential for losing email messages.
I will assign 50 points (125 for answers that relate details of the experience) to the first 10 that reply. Points will only be assigned to those that can relate first-hand experience of SCOS in ND6, or those with first-hand and informed knowledge of a fellow administrator's experiences.
Thanks in advance!
Regards, Doug
Are any of you out there using Single Copy Object Store (also called Shared Mail) in ND6?
We experimented with it in version 4.x and gave up because of reliability issues (read: major headaches, lost email and upset users).
With the ever-increasing use of attachments in our organization, we are considering it again. At LotusPhere 2003 (didn't go to 2004), I asked around about it... Lotus personnel claimed that it works, but I could find no Domino Administrator that had used it. All that I asked (like me) were scared off by the previous issues -- preferring to deal wit the space management issues than the potential for losing email messages.
I will assign 50 points (125 for answers that relate details of the experience) to the first 10 that reply. Points will only be assigned to those that can relate first-hand experience of SCOS in ND6, or those with first-hand and informed knowledge of a fellow administrator's experiences.
Thanks in advance!
Regards, Doug
I am still worried abot it. I'd arther just have more storage, or use one of the products that "consolidates" duplicate attachments (e.g., Mail Attender, or one of the big document policy/archival solutions for mail, e.g., Access One, or Legato).
I do not think Single Copy Object Store is in real use. There is a good amount of work to be done in the area to make it take off. In fact, there isn't even enough awareness aboutt he same. Personally, I am very keen about experiencing this techonology. In programming world, they have sorted out the problem this is targeted to solve. But with human users playing the major role, such a technology would success, I doubt that untill I see it working.
May be you can share some of your past experience on the same?
May be you can share some of your past experience on the same?
Don't use it.
To clarify : I've developped a solution myself to handle this : a server mailrule will drop all mails with attachments in a central database, where they are picked up by a scheduled agent. This agent sends notifications to everybody that the message has been put in the database, and will set access restrictions on the document (readers fields). To handle internet trafic, it will create the necessary login/password combination for the webserver, where the internet user can pick up the attachment. You can set up archiving on this database to archive older attachments .... There could be problems with this approach, but the advantage is that these problems will not result in you losing all your data (as is the case with shared mail).
There are commercial products out there that do the same thing, too.
cheers,
Tom
To clarify : I've developped a solution myself to handle this : a server mailrule will drop all mails with attachments in a central database, where they are picked up by a scheduled agent. This agent sends notifications to everybody that the message has been put in the database, and will set access restrictions on the document (readers fields). To handle internet trafic, it will create the necessary login/password combination for the webserver, where the internet user can pick up the attachment. You can set up archiving on this database to archive older attachments .... There could be problems with this approach, but the advantage is that these problems will not result in you losing all your data (as is the case with shared mail).
There are commercial products out there that do the same thing, too.
cheers,
Tom
Ranjeet, I don't kow, I think of it more as a solution looking for a problem, so they won't bother putting that much nito it.
Why do I call it that? Storage management is a big issue, but mostly in the VOLUME and POLICY areas, less so on the absolute storage size needs. That's because:
1) storage has come way down in price -- fasterthan needs have gone up
2) SANs make storage capacity relatively easy to manage
I'd rather throw disk at the mailboxes than throw the mailbox into a maelstrom. Plus there are better solutions if you want to really make this work -- solutions that address storage, archiving, retention policy, duplicate messages, and duplicate attachments all in one. SCOS just becomes a band-aid on the least imporatnt aspects of the problem.
Why do I call it that? Storage management is a big issue, but mostly in the VOLUME and POLICY areas, less so on the absolute storage size needs. That's because:
1) storage has come way down in price -- fasterthan needs have gone up
2) SANs make storage capacity relatively easy to manage
I'd rather throw disk at the mailboxes than throw the mailbox into a maelstrom. Plus there are better solutions if you want to really make this work -- solutions that address storage, archiving, retention policy, duplicate messages, and duplicate attachments all in one. SCOS just becomes a band-aid on the least imporatnt aspects of the problem.
ASKER
Hi Everyone:
Thanks for the comments. So far, they are echoing our thinking in that simply adding storage is more cost effective and reliable than SCOS. What is not addressed is the exponential growth in storage requirements that comes with (1) greater use of attachments, (2) greater numbers of recipients of the same attachments, and (3) the sending of larger attachments and graphics. In that light, adding storage solves the short-term problem, but does not stop/reduce the trend of exponential growth. SCOS (if we could trust it) reduces the exponential growth problem to something much more linear.
Tom: We've actually considered your solution, with a slight variation. It's nice to hear that someone has implemented it.
Ranjeet: Personally, I am the same... would love to play with the technology. But I won't risk email loss, at our end-users' expense, for a technology that isn't confirmed for third parties.
To answer your question: My previous experience was indeed poor. In part, because of human error (we did not understand the maintenance requirements and procedures that Shared Mail would introduce). In part, because the system simply was not reliable and robust.
Hopefully, someone out there with first-hand experience in SCOS will throw in their two-bits worth...
Thanks for the comments. So far, they are echoing our thinking in that simply adding storage is more cost effective and reliable than SCOS. What is not addressed is the exponential growth in storage requirements that comes with (1) greater use of attachments, (2) greater numbers of recipients of the same attachments, and (3) the sending of larger attachments and graphics. In that light, adding storage solves the short-term problem, but does not stop/reduce the trend of exponential growth. SCOS (if we could trust it) reduces the exponential growth problem to something much more linear.
Tom: We've actually considered your solution, with a slight variation. It's nice to hear that someone has implemented it.
Ranjeet: Personally, I am the same... would love to play with the technology. But I won't risk email loss, at our end-users' expense, for a technology that isn't confirmed for third parties.
To answer your question: My previous experience was indeed poor. In part, because of human error (we did not understand the maintenance requirements and procedures that Shared Mail would introduce). In part, because the system simply was not reliable and robust.
Hopefully, someone out there with first-hand experience in SCOS will throw in their two-bits worth...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree to you qwaletee. But there are areas where it can benefited from. Despite storage device prices coming down to dirt, this is still a bottle neck. Personally, I can never have more of storage. Still a long way where it becomes redundant.
The trick lies in management of Duplicates, Version control of attachment (may be i am tossing something new), retention policy etc. I am of the opinion that there is a strong need of version control at OS level for any such technology to make real sense to the end-user. No technology that bothers users to manage their own versions of the same document can be successfully used for a long term purpose. I sometimes feel like telling people about how to develop a file system. A file system that will in a way act as the core engine for a Single Point Object Store (or any other term you give it).
To add to Tom's idea of a programmatic solution, it can be done. But its like reinventing the wheel. Not really an easy thing to do to implement a sophisticated SPOS.
I heard about the implementation of same for some web based email systems. May be Google can show us the way?!?
The trick lies in management of Duplicates, Version control of attachment (may be i am tossing something new), retention policy etc. I am of the opinion that there is a strong need of version control at OS level for any such technology to make real sense to the end-user. No technology that bothers users to manage their own versions of the same document can be successfully used for a long term purpose. I sometimes feel like telling people about how to develop a file system. A file system that will in a way act as the core engine for a Single Point Object Store (or any other term you give it).
To add to Tom's idea of a programmatic solution, it can be done. But its like reinventing the wheel. Not really an easy thing to do to implement a sophisticated SPOS.
I heard about the implementation of same for some web based email systems. May be Google can show us the way?!?
The programmatic solution is NOT a replacement of a SPOS ! It's a low-tech solution that's a lot cheaper than anything on the market, without the problems that Shared mail has, but it has of course limitations. If you are short on cash and can't add storage space, it's a good idea to consider nonetheless. (If you can't afford to add storage, you won't be able to afford any of the SPOS systems on the market !)
BUY A POLICY BASED SYSTEM.
If you are a big company and care enough to work with SCOS, you probably care enough to buy this sort of thing.
If you are a small company, it is equally economical to buy a few big, cheap hard drives and/or insitute archiving policies.
If you are a big company and care enough to work with SCOS, you probably care enough to buy this sort of thing.
If you are a small company, it is equally economical to buy a few big, cheap hard drives and/or insitute archiving policies.
ASKER
Thank you TheLearnedOne for the reminder. I will review the question tomorrow and grant points based on my original statement:
"I will assign 50 points (125 for answers that relate details of the experience) to the first 10 that reply. Points will only be assigned to those that can relate first-hand experience of SCOS in ND6, or those with first-hand and informed knowledge of a fellow administrator's experiences."
"I will assign 50 points (125 for answers that relate details of the experience) to the first 10 that reply. Points will only be assigned to those that can relate first-hand experience of SCOS in ND6, or those with first-hand and informed knowledge of a fellow administrator's experiences."
I HAVE had experienece with NOT using it and using policy-based management, but I guess that's is what you are, ahem, NOT looking for.
Give the points to JJ. She, at the very least, pointed to Ed Brill's missive about including it only for the feature list, which is pretty much equivalent to an engineer saying "I tried it, and I don't see any good reason to try it again."
Give the points to JJ. She, at the very least, pointed to Ed Brill's missive about including it only for the feature list, which is pretty much equivalent to an engineer saying "I tried it, and I don't see any good reason to try it again."