Ok. I see your point. However, consider this. By only having one file holding all the info. You decrease the conplexity of managing said system. You also decrease the complexity of backing up that system's critical files. Hence, making recovery that much easier. If your server is infultrated, and a script modifies all the mail on each users home dir. The recovery procedure will take more time because it is more complex.
As a systems admin's we all know that computer's and the systems that they run are subject to error. It is our job to migitate problems. With that I believe that recoverability definately plays a role in the solution that one is going to implement. No?
I see little talk of this and since you seem very familiar with the subject of unix based email, perhaps you could talk about the recovery procedure for for those systems.
1. Not necesarily. A util called xmerge.exe found in the BORK (Back Office Resource Kit) lets you export via comandline, all individual mailbox content to.psts and then inport them en masse. You can export this way and then just do a backup up of that directory of psts.
2. Exchange can be limited to use less resources that 75% of your ram at a time. You can set restrictions on how much ram it is permitted to use.
3. The exchange information store actually has one copy of that message and TEN indexes. NOT ten copies of the entire message.
4. IM?
5. What do you mean the size of the installation? Any program that covers an Enteprise Level messaging and colaboration system will be big. Show me the alternatives that provide the same functionality at a smaller MB cost.
I need clarification because I am not sure. BUT... How does Sendmail or any of the other email server solutions that you mentioned store email? On a database? In many little files, that are then referenced by a big index?
Just curious.
At my previus job we had made the same transition. From AIX to Solaris Sendmail and then ultimately to MSExchange. Some of the reasons that we moved over where.
1. The cost of the hardware for an x86 platform was significantly cheaper.
2. The cost of people to adminsiter the tech nology was cheaper. (UNIX admins are more expensive thatn NT Admins)
3. Exchange provided canned Web access to email. No development resources had to be reasigned.
4. We needed to standardized on an email platform. So that tech support needed only to manage one piece of software.
5. The tight integration between the MS Office product, which was already standard, and Exchange made the multimedia capable Exchange much more viable.
6. Exhcange is not just email it is groupware, meaning it facilitates the organization and sharing of information for teams.
There where many other reasons, but these are the ones that I am sure show up on every list. Basically, this is what management is thinking. If you can counter these points with solutions that run on your current unix setup then you have a good chance of turning the tide of change. Be forewarned, comercial solutions that do this on unix systems are just as if not more expensive than Exchange. Then you are left with the question of what Emial client do you standardize on?
Slashdot Mirror
Ok. I see your point. However, consider this. By only having one file holding all the info. You decrease the conplexity of managing said system. You also decrease the complexity of backing up that system's critical files. Hence, making recovery that much easier. If your server is infultrated, and a script modifies all the mail on each users home dir. The recovery procedure will take more time because it is more complex.
As a systems admin's we all know that computer's and the systems that they run are subject to error. It is our job to migitate problems. With that I believe that recoverability definately plays a role in the solution that one is going to implement. No?
I see little talk of this and since you seem very familiar with the subject of unix based email, perhaps you could talk about the recovery procedure for for those systems.
Well, I think that the bad is really not bad.
.psts and then inport them en masse. You can export this way and then just do a backup up of that directory of psts.
1. Not necesarily. A util called xmerge.exe found in the BORK (Back Office Resource Kit) lets you export via comandline, all individual mailbox content to
2. Exchange can be limited to use less resources that 75% of your ram at a time. You can set restrictions on how much ram it is permitted to use.
3. The exchange information store actually has one copy of that message and TEN indexes. NOT ten copies of the entire message.
4. IM?
5. What do you mean the size of the installation? Any program that covers an Enteprise Level messaging and colaboration system will be big. Show me the alternatives that provide the same functionality at a smaller MB cost.
6. Price. OUCH!
7 True.
8. Yup. no argument.
I need clarification because I am not sure. BUT... How does Sendmail or any of the other email server solutions that you mentioned store email? On a database? In many little files, that are then referenced by a big index? Just curious.
At my previus job we had made the same transition. From AIX to Solaris Sendmail and then ultimately to MSExchange. Some of the reasons that we moved over where.
1. The cost of the hardware for an x86 platform was significantly cheaper.
2. The cost of people to adminsiter the tech nology was cheaper. (UNIX admins are more expensive thatn NT Admins)
3. Exchange provided canned Web access to email. No development resources had to be reasigned.
4. We needed to standardized on an email platform. So that tech support needed only to manage one piece of software.
5. The tight integration between the MS Office product, which was already standard, and Exchange made the multimedia capable Exchange much more viable.
6. Exhcange is not just email it is groupware, meaning it facilitates the organization and sharing of information for teams.
There where many other reasons, but these are the ones that I am sure show up on every list. Basically, this is what management is thinking. If you can counter these points with solutions that run on your current unix setup then you have a good chance of turning the tide of change. Be forewarned, comercial solutions that do this on unix systems are just as if not more expensive than Exchange. Then you are left with the question of what Emial client do you standardize on?