Sorry, but there is a bit to much FUD in here for my taste. I do know this is not the place for flame wars, but I would never ever hire a person who has these views to be anywhere near an exchange server.
To me, this post shows a lack of understanding on how exchange works, and more so when it comes to the point on how to handle a corrupt server. - Databases can be corrupt but still *seem* to work True, so can a multi million dollar Oracle system. Part of your daily maintenance is to check this. Plenty of tools available for that, including all the major backup tools. >- Databases are used for several users at the same time Well, of cource you have several mailboxes in a storage group. >- Repairs often require databases stores to be dis-mounted Only if you have severe corruption, which you would avoid by actually taking care of your data. >- Corrupt databases will often stop information stores mounting Yes, by design. Would you mound a corrupted file system without checking it first? >- Backup agents often do not work as advertised and can be risky Well, Backup Exec, ARCServe and NT-backup work just as advertised, as long as you understand the difference between a "mail-store backup" and a "mail-box backup" >- Flat-file backups of a dismounted store are the most reliable I would like to disagree there, since you do NOT HAVE a consistant log state in such a backup. Online backups with log-trunking is the most reliable backup. >Offline Backup and Restoration Procedures for Exchange >http://support.microsoft.com/kb/296788/ Lets read the first few paragraphs in that article. " This article describes methods you can use to bypass the online backup application programming interfaces (APIs) and manually back up and restore Exchange information store databases." WHY would you want to bypass the built in routines? >Corrupt information stores are your worst nightmare Yes, that is true. (Do NOT let the log-space of a Pre-2000 exchange server run out.. let me tell you that) >- Your information store could have been corrupt for weeks before >crashing Uhm, only if you have not backed up the database in that time. Let's reiterate: ALL the major backup tools _will_ do a complete consistency check when you back up. If the store is corrupt, you _will_ be told. IF you find a corrupt tool, you have the choice of trying a soft recovery on a per item basis. You can do a somewhat nastier thing and to a hard recovery and just trash whatever was in that object. Or you can to a log replay and do a point in time recovery... pretty much the same choices as on a multi-million-dollar-Oracle cluster. >(your backups could be corrupt too) Yeah, if you rely on flat file offline backups, you bypass all the checking. >- Information stores are tied to custom Active Directory attributes No, you can run exchange without an AD, but you would loose the point of it. >- Information stores are tied to individual servers Yes, you have to store the mail of a user somewhere, that is correct. >- All of this has to be correct for stores to mount Where is the problem? >- Just copying databases back will not always work See above, if you rely on offline backups you _will_ run a greater risk of corrupting your store, since you bypass the checks. >- A "consistency adjuster" may need to be used to "mask" big problems A what-now? There are a few tools that let you repair and diagnose the store, but in what way do they "mask" the problem`? >- If your Exchange server "crashed" and cannot be started again to > properly "remove" it from active directory, One words: ADSIedit. Beautiful tool to manipulate AD. I've used it plenty when it comes to doing swing-migrations of SBS-sites. >you may not be able to add a >new exchange organization cleanly and may have to START AGAIN with a NEW >active directory (THIS IS COMPLETELY TRUE - THE MS ARTICLES ON THE >SUBJECT DO NOT WORK IN SOME INSTANCES) Such as what instances? >For more information see: >How to recover the information store on Exchange 2000 Server or Exchange >Server 2003 in a single site >http://support.microsoft.com/kb/313184/ IF you end up having to use that article, the admin has been a clutz to let the server get to a state where that method is required. >If you do decide to use Exchange (which I strongly advise against) > >- Do not rely on live backups See above. Do NOT rely on _offline_ backups! >- Use flat-file backups of databases by scheduling a job to dismont the >message stores and copy files to another disk, drive or server See above: You do NOT have a consistant log state when doing that. >- If your exchange server is also a domain controller everything gets 3 >times harder. Do not run exchange as a DC or GC, PDC or infrastructure >master. Why three times harder? It makes no difference what so ever. >- Note: You can't help running exchange as a DC, GC, PDC and >infrastructure master in Small Business versions of exchange or single >server sites. Wrong. You can add several DC's to a Small Business Domain. The SBS has to be the first installed server however, but that is by design.
smime.p7s
Description: S/MIME cryptographic signature
-- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/