This is unlikely (especially if you are talking about a multi-platform solution). Why write RPC\MAPI code when you could go the Evolution route and write a WebDAV hook. I honestly think this road is the path to moving away from Outlook from the corporate point of view. Evolution has come a long way and I suspect the 2.0 client will be awesome...lets see some other messaging\calendaring multi-platform projects use the WebDAV hook so we have a choice (not that Evo is bad, but choices are good).
I am well aware of the origins of Exchange. I have been working with it since day one. Where Exchange was then and where it is today is a totally different situation. As far a access controls, you are right, the OLD version of Exchange had separate access controls. This is no longer true. As to being amazed that it works, I am not amazed at all. The current version (Exchange 2003) is a highly stable, efficient, and powerful mail application that is well written and widely accepted by Microsoft's customers. There are definitely some areas that need work and believe me, Microsoft is aware of it. The road map for Exchange\Windows has some very interesting things coming out in the not so distant future that will show that Microsoft is truly learning from its competitors (today I would say that would be the *NIX space, whether you talk about Novell, SCO, IBM, or Open Source initiatives).
As much as I enjoy the debate as to which mail app is better, I prefer to leave that to the market to decide. *NIX MTA's work great in many environments (many of which I have been a part of...including now), but Exchange also has its niche (if you want to call it that..as its quite a big niche). With companies such as Cisco, EBay, ChevronTexaco, Qualcomm, etc...using Exchange as a primary mailhost this shows how scalable\powerful Exchange is. These companies do not put Exchange in house due to some religious\political belief. They do it because the technology under the hood provides them with something that other available mail apps don't. I recently read a paper that detailed a disaster recovery analysis was done at Ebay and they concluded that it costs EBay $700k for each minute their mail system is down. Why would a company such as EBay risk that on Exchange if there are so many flaws in its architecture and if there was something better out there?
Postfix, Sendmail, Qmail, etc....all have their niche\place. I have yet to work in an Enterprise environment that did not have Sendmail boxes out there (normally on the Internet gateways). I definitely would like to see some of these MTA's (and some others) be used more by "Corporate America", but until they can provide what Exchange is currently (or better yet...something totally different that Exchange doesn't that "Corporate America" needs) this will not happen. Innovation is the key to challenging Exchange's dominance in the mailhost industry, not replication.
You sure about that? I just did it on my Exchange 2003 system and it seems to work just fine:-).
Via SMTP...send mail to the contacts "internal" address and Exchange will reroute (rewrite) the message out to the contacts "target" address. This has been done with Exchange since v5.5 and its "custom recipients" (now called Contacts in AD).
This does things like allow an Exchange shop the ability to give a consultant an email address that is tied to the company (as far as internal and external parties are concerned), but have the mail actually rerouted once it hits an Exchange server to an external address. This also allows the company to not give a consultant a security principal in AD, but still give them a company "blessed" email address that routes their mail to an external system. This is one of the primary uses of Contact next to just creating a directory object for them in the Active Drictory so end users can see them in the GAL and they can be added to mail lists.
The ability to send to the "internal" address is only limited by a particular infrastructures design. When a contact gets created it gets a "target" address (external) as well as a number of proxy addresses (internal) that all other mail objects in AD get (such as mailboxes). As long as the mail infrastructure allows down stream messages to the assigned SMTP proxy address name space that the contact gets Exchange will happily rewrite the internal address to the external address as soon as Exchange accepts the message and route it back out to the Internet.
All that is needed to make this happen is one single contact object with a valid external address and the mail infrastructure that allows mail to be routed to the internal SMTP address that gets assigned to the contact (which should be the same SMTP address space used by other mail objects in the Exchange infrastructure).
If the Exchange database files were not active and checking for database corruption was not important, then Windows certainly does work more or less the same way:
xcopy/a source destination
or (my preference):
rar m -m5 destination source
Backing up active\online transactional databases is something of a different beast then normal files. You need to be able to get the database on tape in a consistant state while keeping them online, which for Exchange means being able to incorporate its transaction logs as part of the backup process. Just copying the online database files from one location to another would leave you with an inconsistant db, because a large portion of the transactions are not committed to the actual database files until the server has a low level of activity (or cleanly shut down), at which point it begins committing the transactions to disk.
Having an API allows for the database to be hooked into by a an application to spit that data to a file\external device and while doing it the app checks each database page for corruption before sending that page to tape and process the transaction logs, which in the end gives you a consistant database on tape. The API is required to also tell the app that uses it how to properly restore the database so that it is restored in a consistant state (database + transaction logs).
Just copying files is one thing, backup up databases without bringing them offline is another.
mvpll,
This is not accurate. To forward mail for a "virtual" user in an Exchange\AD setup all that is needed is the creation of a contact object. The contact will have the SMTP target address of the external destination (mymailbox@yahoo.com), but will also have an internal SMTP address (mycorpbox@my.corp.com). Sending mail to that "internal" SMTP address will actually reroute the message to the "external" SMTP address.
Not as difficult as you illustrated. Only 3 *clicks* and its done.
"Backups are easy, and self-referential. AFAIK, Windows file locking prevents an Exchange system from being properly backed up without shutting down Exchange during the backup process)"
This is truely an interesting thread, but this statement is absolutely not true. With the installation of Exchange the backup API is "enhanced" to allow for online "Exchange Aware" backups that perform online backups that also check each database page for corruption before putting it to tape. With the backup API "enhanced" you can use the builtin Windows NTBackup to backup the database to a tape or file while online or use a 3rd party backup app that also uses this extended backup API. This has been how backups for Exchange have worked since the beginning, so I don't know where you got this information from.
It is true that the patches that are of a critical nature that come out once a month mean some form of regular monthly downtime, but there are ways to minimize this impact.
Slashdot Mirror
This is unlikely (especially if you are talking about a multi-platform solution). Why write RPC\MAPI code when you could go the Evolution route and write a WebDAV hook. I honestly think this road is the path to moving away from Outlook from the corporate point of view. Evolution has come a long way and I suspect the 2.0 client will be awesome...lets see some other messaging\calendaring multi-platform projects use the WebDAV hook so we have a choice (not that Evo is bad, but choices are good).
I am well aware of the origins of Exchange. I have been working with it since day one. Where Exchange was then and where it is today is a totally different situation. As far a access controls, you are right, the OLD version of Exchange had separate access controls. This is no longer true. As to being amazed that it works, I am not amazed at all. The current version (Exchange 2003) is a highly stable, efficient, and powerful mail application that is well written and widely accepted by Microsoft's customers. There are definitely some areas that need work and believe me, Microsoft is aware of it. The road map for Exchange\Windows has some very interesting things coming out in the not so distant future that will show that Microsoft is truly learning from its competitors (today I would say that would be the *NIX space, whether you talk about Novell, SCO, IBM, or Open Source initiatives).
As much as I enjoy the debate as to which mail app is better, I prefer to leave that to the market to decide. *NIX MTA's work great in many environments (many of which I have been a part of...including now), but Exchange also has its niche (if you want to call it that..as its quite a big niche). With companies such as Cisco, EBay, ChevronTexaco, Qualcomm, etc...using Exchange as a primary mailhost this shows how scalable\powerful Exchange is. These companies do not put Exchange in house due to some religious\political belief. They do it because the technology under the hood provides them with something that other available mail apps don't. I recently read a paper that detailed a disaster recovery analysis was done at Ebay and they concluded that it costs EBay $700k for each minute their mail system is down. Why would a company such as EBay risk that on Exchange if there are so many flaws in its architecture and if there was something better out there?
Postfix, Sendmail, Qmail, etc....all have their niche\place. I have yet to work in an Enterprise environment that did not have Sendmail boxes out there (normally on the Internet gateways). I definitely would like to see some of these MTA's (and some others) be used more by "Corporate America", but until they can provide what Exchange is currently (or better yet...something totally different that Exchange doesn't that "Corporate America" needs) this will not happen. Innovation is the key to challenging Exchange's dominance in the mailhost industry, not replication.
You sure about that? I just did it on my Exchange 2003 system and it seems to work just fine :-).
Via SMTP...send mail to the contacts "internal" address and Exchange will reroute (rewrite) the message out to the contacts "target" address. This has been done with Exchange since v5.5 and its "custom recipients" (now called Contacts in AD).
This does things like allow an Exchange shop the ability to give a consultant an email address that is tied to the company (as far as internal and external parties are concerned), but have the mail actually rerouted once it hits an Exchange server to an external address. This also allows the company to not give a consultant a security principal in AD, but still give them a company "blessed" email address that routes their mail to an external system. This is one of the primary uses of Contact next to just creating a directory object for them in the Active Drictory so end users can see them in the GAL and they can be added to mail lists.
The ability to send to the "internal" address is only limited by a particular infrastructures design. When a contact gets created it gets a "target" address (external) as well as a number of proxy addresses (internal) that all other mail objects in AD get (such as mailboxes). As long as the mail infrastructure allows down stream messages to the assigned SMTP proxy address name space that the contact gets Exchange will happily rewrite the internal address to the external address as soon as Exchange accepts the message and route it back out to the Internet.
All that is needed to make this happen is one single contact object with a valid external address and the mail infrastructure that allows mail to be routed to the internal SMTP address that gets assigned to the contact (which should be the same SMTP address space used by other mail objects in the Exchange infrastructure).
If the Exchange database files were not active and checking for database corruption was not important, then Windows certainly does work more or less the same way:
/a source destination
xcopy
or (my preference):
rar m -m5 destination source
Backing up active\online transactional databases is something of a different beast then normal files. You need to be able to get the database on tape in a consistant state while keeping them online, which for Exchange means being able to incorporate its transaction logs as part of the backup process. Just copying the online database files from one location to another would leave you with an inconsistant db, because a large portion of the transactions are not committed to the actual database files until the server has a low level of activity (or cleanly shut down), at which point it begins committing the transactions to disk.
Having an API allows for the database to be hooked into by a an application to spit that data to a file\external device and while doing it the app checks each database page for corruption before sending that page to tape and process the transaction logs, which in the end gives you a consistant database on tape. The API is required to also tell the app that uses it how to properly restore the database so that it is restored in a consistant state (database + transaction logs).
Just copying files is one thing, backup up databases without bringing them offline is another.
mvpll, This is not accurate. To forward mail for a "virtual" user in an Exchange\AD setup all that is needed is the creation of a contact object. The contact will have the SMTP target address of the external destination (mymailbox@yahoo.com), but will also have an internal SMTP address (mycorpbox@my.corp.com). Sending mail to that "internal" SMTP address will actually reroute the message to the "external" SMTP address. Not as difficult as you illustrated. Only 3 *clicks* and its done.
"Backups are easy, and self-referential. AFAIK, Windows file locking prevents an Exchange system from being properly backed up without shutting down Exchange during the backup process)" This is truely an interesting thread, but this statement is absolutely not true. With the installation of Exchange the backup API is "enhanced" to allow for online "Exchange Aware" backups that perform online backups that also check each database page for corruption before putting it to tape. With the backup API "enhanced" you can use the builtin Windows NTBackup to backup the database to a tape or file while online or use a 3rd party backup app that also uses this extended backup API. This has been how backups for Exchange have worked since the beginning, so I don't know where you got this information from. It is true that the patches that are of a critical nature that come out once a month mean some form of regular monthly downtime, but there are ways to minimize this impact.