RE: exchange reporting tool
You could start here: http://www.solarwinds.com/register/registrationform.aspx?Program=825c=7015000Djc6lid=DD_DL_EMINTCMP=ILC-HP_DLDD_EM Clayton Doige IT Project Manager CME Development Corporation T: 020 7430 5355 M: 07949 255062 E:clayton.do...@cme-net.com W:www.cetv-net.com -Original Message- From: Nirav Doshi [mailto:nirav_n...@yahoo.co.in] Sent: 12 January 2009 10:05 To: MS-Exchange Admin Issues Subject: exchange reporting tool Dear All my it head wants me to genrate a manual report for our exchange 2003 box. pls guide me what kind of manual report we can genrate from exchange 2003. my boss purpose is like we have to monito whole echange server through this report. ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~ __ This email has been scanned by the MessageLabs Email Security System. __ __ This electronic mail message and any attached files contain information intended for the exclusive use of the person(s) to whom it is addressed and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this message or its contents may be subject to legal restriction or sanction. If you have received this message in error, please notify the sender immediately by electronic mail and delete the original message and any attachments without retaining any copies. _ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
Incremental backups
Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: exchange reporting tool
Exchange can gather a lot of information about itself. Performance Monitor can quantify usage on hundreds of different metrics. Weblogs can be parsed to show OWA usage. Protocol logging, message tracking, event logs, configuration information (AD), WMI... Here is a list of products that can produce comprehensive reports based on input from multiple sources for Exchange: http://www.promodag.com http://quest.com/messagestats http://www.sirana.com/products/appanalyzer/ http://www.solarwinds.com/products/freetools/exchange_monitor.aspx -- free http://www.microsoft.com/systemcenter/operationsmanager/en/us/default.aspx -Original Message- From: Nirav Doshi [mailto:nirav_n...@yahoo.co.in] Sent: Monday, January 12, 2009 2:05 AM To: MS-Exchange Admin Issues Subject: exchange reporting tool Dear All my it head wants me to genrate a manual report for our exchange 2003 box. pls guide me what kind of manual report we can genrate from exchange 2003. my boss purpose is like we have to monito whole echange server through this report. ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
Circular logging is not enabled is it? Anything in the app event log after the last full backup to indicate a problem? Were the transaction logs properly deleted after the last full backup? From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 2:37 AM To: MS-Exchange Admin Issues Subject: Incremental backups Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
Has someone been mixing streaming and VSS backups? But as William says - the details should be in the Application event log. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: William Lefkovics [mailto:will...@lefkovics.net] Sent: Monday, January 12, 2009 6:38 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Circular logging is not enabled is it? Anything in the app event log after the last full backup to indicate a problem? Were the transaction logs properly deleted after the last full backup? From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 2:37 AM To: MS-Exchange Admin Issues Subject: Incremental backups Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
Circular logging: disabled. Logs /are/ being truncated after a full backup. I've just noticed this error in the app log, which comes immediately before the full backup starting error: Exchange ESE HResult: -939523570 (0xc800020e); last error: 0 (0x) A quick Google seems to suggest this is related to circular logging. But I guarantee that option is disabled, and the Exchange services have all been restarted since that verification (on Friday, I generated about 250MB worth of transactions; I presume I wouldn't have seen those logs if circular logging was enabled!) Apart from that, and the rejected backup error, there's nothing untoward. Something I've just realised: Circular logging IS enabled on one of the storage groups. I assume then that this is blocking the incremental backup of ALL the stores on the server. Testing now, will let you all know. Richard From: bounce-8371552-8066...@lyris.sunbelt-software.com [mailto:bounce-8371552-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 12:07 To: MS-Exchange Admin Issues Subject: RE: Incremental backups Has someone been mixing streaming and VSS backups? But as William says - the details should be in the Application event log. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: William Lefkovics [mailto:will...@lefkovics.net] Sent: Monday, January 12, 2009 6:38 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Circular logging is not enabled is it? Anything in the app event log after the last full backup to indicate a problem? Were the transaction logs properly deleted after the last full backup? From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 2:37 AM To: MS-Exchange Admin Issues Subject: Incremental backups Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
Well, that was the problem - circ logging disabled on that storage group and now it works. So, since I've never used incremental logging before, is this by design? As in, ALL the storage groups need to have Circular Logging disable, or incremental backups of a server cannot be done? Cheers Richard From: bounce-8371579-8066...@lyris.sunbelt-software.com [mailto:bounce-8371579-8066...@lyris.sunbelt-software.com] On Behalf Of Sobey, Richard A Sent: 12 January 2009 12:26 To: MS-Exchange Admin Issues Subject: RE: Incremental backups Circular logging: disabled. Logs /are/ being truncated after a full backup. I've just noticed this error in the app log, which comes immediately before the full backup starting error: Exchange ESE HResult: -939523570 (0xc800020e); last error: 0 (0x) A quick Google seems to suggest this is related to circular logging. But I guarantee that option is disabled, and the Exchange services have all been restarted since that verification (on Friday, I generated about 250MB worth of transactions; I presume I wouldn't have seen those logs if circular logging was enabled!) Apart from that, and the rejected backup error, there's nothing untoward. Something I've just realised: Circular logging IS enabled on one of the storage groups. I assume then that this is blocking the incremental backup of ALL the stores on the server. Testing now, will let you all know. Richard From: bounce-8371552-8066...@lyris.sunbelt-software.com [mailto:bounce-8371552-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 12:07 To: MS-Exchange Admin Issues Subject: RE: Incremental backups Has someone been mixing streaming and VSS backups? But as William says - the details should be in the Application event log. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: William Lefkovics [mailto:will...@lefkovics.net] Sent: Monday, January 12, 2009 6:38 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Circular logging is not enabled is it? Anything in the app event log after the last full backup to indicate a problem? Were the transaction logs properly deleted after the last full backup? From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 2:37 AM To: MS-Exchange Admin Issues Subject: Incremental backups Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
I'm not familiar with EMC Networker, but if you select the entire server for backup, then that is the behavior I would expect. If you select each individual storage group for backup, then you should be able to do it per storage group. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 7:36 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Well, that was the problem - circ logging disabled on that storage group and now it works. So, since I've never used incremental logging before, is this by design? As in, ALL the storage groups need to have Circular Logging disable, or incremental backups of a server cannot be done? Cheers Richard From: bounce-8371579-8066...@lyris.sunbelt-software.com [mailto:bounce-8371579-8066...@lyris.sunbelt-software.com] On Behalf Of Sobey, Richard A Sent: 12 January 2009 12:26 To: MS-Exchange Admin Issues Subject: RE: Incremental backups Circular logging: disabled. Logs /are/ being truncated after a full backup. I've just noticed this error in the app log, which comes immediately before the full backup starting error: Exchange ESE HResult: -939523570 (0xc800020e); last error: 0 (0x) A quick Google seems to suggest this is related to circular logging. But I guarantee that option is disabled, and the Exchange services have all been restarted since that verification (on Friday, I generated about 250MB worth of transactions; I presume I wouldn't have seen those logs if circular logging was enabled!) Apart from that, and the rejected backup error, there's nothing untoward. Something I've just realised: Circular logging IS enabled on one of the storage groups. I assume then that this is blocking the incremental backup of ALL the stores on the server. Testing now, will let you all know. Richard From: bounce-8371552-8066...@lyris.sunbelt-software.com [mailto:bounce-8371552-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 12:07 To: MS-Exchange Admin Issues Subject: RE: Incremental backups Has someone been mixing streaming and VSS backups? But as William says - the details should be in the Application event log. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: William Lefkovics [mailto:will...@lefkovics.net] Sent: Monday, January 12, 2009 6:38 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Circular logging is not enabled is it? Anything in the app event log after the last full backup to indicate a problem? Were the transaction logs properly deleted after the last full backup? From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 2:37 AM To: MS-Exchange Admin Issues Subject: Incremental backups Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: exchange reporting tool
Webster likes GoExchange for these types of reporting needs... :) Shook -Original Message- From: Nirav Doshi [mailto:nirav_n...@yahoo.co.in] Sent: Monday, January 12, 2009 5:05 AM To: MS-Exchange Admin Issues Subject: exchange reporting tool Dear All my it head wants me to genrate a manual report for our exchange 2003 box. pls guide me what kind of manual report we can genrate from exchange 2003. my boss purpose is like we have to monito whole echange server through this report. ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
Re: Incremental backups
So you can do incremental backups on E2K7? I thought that 'incremental' + 'Exchange' = Brick Level Backups. On Mon, Jan 12, 2009 at 7:15 AM, Michael B. Smith mich...@theessentialexchange.com wrote: I'm not familiar with EMC Networker, but if you select the entire server for backup, then that is the behavior I would expect. If you select each individual storage group for backup, then you should be able to do it per storage group. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php *From:* Sobey, Richard A [mailto:r.so...@imperial.ac.uk] *Sent:* Monday, January 12, 2009 7:36 AM *To:* MS-Exchange Admin Issues *Subject:* RE: Incremental backups Well, that was the problem – circ logging disabled on that storage group and now it works. So, since I've never used incremental logging before, is this by design? As in, ALL the storage groups need to have Circular Logging disable, or incremental backups of a server cannot be done? Cheers Richard *From:* bounce-8371579-8066...@lyris.sunbelt-software.com [mailto: bounce-8371579-8066...@lyris.sunbelt-software.com] *On Behalf Of *Sobey, Richard A *Sent:* 12 January 2009 12:26 *To:* MS-Exchange Admin Issues *Subject:* RE: Incremental backups Circular logging: disabled. Logs /are/ being truncated after a full backup. I've just noticed this error in the app log, which comes immediately before the full backup starting error: Exchange ESE HResult: -939523570 (0xc800020e); last error: 0 (0x) A quick Google seems to suggest this is related to circular logging. But I guarantee that option is disabled, and the Exchange services have all been restarted since that verification (on Friday, I generated about 250MB worth of transactions; I presume I wouldn't have seen those logs if circular logging was enabled!) Apart from that, and the rejected backup error, there's nothing untoward. Something I've just realised: Circular logging IS enabled on one of the storage groups. I assume then that this is blocking the incremental backup of ALL the stores on the server. Testing now, will let you all know. Richard *From:* bounce-8371552-8066...@lyris.sunbelt-software.com [mailto: bounce-8371552-8066...@lyris.sunbelt-software.com] *On Behalf Of *Michael B. Smith *Sent:* 12 January 2009 12:07 *To:* MS-Exchange Admin Issues *Subject:* RE: Incremental backups Has someone been mixing streaming and VSS backups? But as William says – the details should be in the Application event log. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php *From:* William Lefkovics [mailto:will...@lefkovics.net] *Sent:* Monday, January 12, 2009 6:38 AM *To:* MS-Exchange Admin Issues *Subject:* RE: Incremental backups Circular logging is not enabled is it? Anything in the app event log after the last full backup to indicate a problem? Were the transaction logs properly deleted after the last full backup? *From:* Sobey, Richard A [mailto:r.so...@imperial.ac.uk] *Sent:* Monday, January 12, 2009 2:37 AM *To:* MS-Exchange Admin Issues *Subject:* Incremental backups Is there anything special needs to be done before I can run an incremental backup of an Exchange 2007 SP1 mailbox database? I'm getting this error from my backup software (EMC Networker): The Exchange Server has rejected the backup request level. A full backup will be performed. The server has had plenty of full backups in the past couple of weeks. Richard -- Sherry Abercrombie Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. J Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover-as almost everyone has to do eventually-you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A normal backup is also known as a full backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (flush) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A copy backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A daily backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An incremental backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a filesystem backup, an incremental backup backs up everything created or modified since the last normal or incremental backup and then clears the archive bit. Differential Backups A differential backup will back up all created transaction logs since the last normal or incremental backup. It does not flush the transaction logs. To consider it in terms of a filesystem backup, a differential backup backs up everything created or modified since the last normal or incremental backup. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Sherry Abercrombie [mailto:saber...@gmail.com] Sent: Monday, January 12, 2009 9:05 AM To: MS-Exchange Admin Issues Subject: Re: Incremental backups So you can do incremental backups on E2K7? I thought that 'incremental' + 'Exchange' = Brick Level Backups. On Mon, Jan 12, 2009 at 7:15 AM, Michael B. Smith mich...@theessentialexchange.com wrote: I'm not familiar with EMC Networker, but if you select the entire server for backup, then that is the behavior I would expect. If you select each individual storage group for backup,
RE: Incremental backups
Thanks Michael. Seems like it will be a good purchase. From: bounce-8371736-8066...@lyris.sunbelt-software.com [mailto:bounce-8371736-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 14:17 To: MS-Exchange Admin Issues Subject: RE: Incremental backups I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. :) Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover-as almost everyone has to do eventually-you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A normal backup is also known as a full backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (flush) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A copy backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A daily backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An incremental backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a filesystem backup, an incremental backup backs up everything created or modified since the last normal or incremental backup and then clears the archive bit. Differential Backups A differential backup will back up all created transaction logs since the last normal or incremental backup. It does not flush the transaction logs. To consider it in terms of a filesystem backup, a differential backup backs up everything created or modified since the last normal or incremental backup. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Sherry Abercrombie [mailto:saber...@gmail.com] Sent: Monday, January 12, 2009 9:05 AM To: MS-Exchange Admin Issues Subject: Re: Incremental backups So you can do incremental backups on E2K7? I thought that 'incremental' +
RE: Incremental backups
I agree, especially if it will help Shook. Did you write it in small enough words? J From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 9:19 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Thanks Michael. Seems like it will be a good purchase. From: bounce-8371736-8066...@lyris.sunbelt-software.com [mailto:bounce-8371736-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 14:17 To: MS-Exchange Admin Issues Subject: RE: Incremental backups I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. J Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover-as almost everyone has to do eventually-you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A normal backup is also known as a full backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (flush) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A copy backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A daily backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An incremental backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a filesystem backup, an incremental backup backs up everything created or modified since the last normal or incremental backup and then clears the archive bit. Differential Backups A differential backup will back up all created transaction logs since the last normal or incremental backup. It does not flush the transaction logs. To consider it in terms of a filesystem backup, a differential backup backs up everything created or modified since the last normal or incremental backup. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php
Re: Incremental backups
Ok, so it's not exactly an incremental in the 'normal' definition of incremental, it's not doing an incremental on the actual database, just the logs. I do a daily full, flush the logs after successful backup on my E2K3 setup. When is that book going to be available anyway?? I would really like to get it before I start setting up E2K7. I mean, I only went to training for it in Sept. 07 and am finally going to start working on it by the end of this month. (Going on vacation next week, won't be back until late the 26th, so I'm NOT starting any big projects this week.) On Mon, Jan 12, 2009 at 8:16 AM, Michael B. Smith mich...@theessentialexchange.com wrote: I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. J Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover—as almost everyone has to do eventually—you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A *normal* backup is also known as a *full* backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (*flush*) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A *copy* backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A *daily* backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An *incremental* backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a filesystem backup, an incremental backup backs up everything created or modified since the last normal or incremental backup and then clears the archive bit. Differential Backups A *differential* backup will back up all created transaction logs since the last normal or incremental backup. It does not flush the transaction logs. To consider it in terms of a filesystem backup, a differential backup backs up everything created or modified since the last normal or
RE: Incremental backups
I've already got the book on pre-order and I've got quite an impressive vocabulary; I just like the redneck versions of the fancy words better. :) Shook From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Monday, January 12, 2009 9:23 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups I agree, especially if it will help Shook. Did you write it in small enough words? :) From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 9:19 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Thanks Michael. Seems like it will be a good purchase. From: bounce-8371736-8066...@lyris.sunbelt-software.com [mailto:bounce-8371736-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 14:17 To: MS-Exchange Admin Issues Subject: RE: Incremental backups I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. :) Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover-as almost everyone has to do eventually-you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A normal backup is also known as a full backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (flush) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A copy backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A daily backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An incremental backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a filesystem backup, an incremental backup backs up everything created or modified since the last normal or incremental backup and then clears the archive bit. Differential Backups A differential backup will back up all created transaction logs since the last normal or incremental backup. It does not flush the
RE: Incremental backups
Graduating from elementary school and watching, R U smarter than a 5th Grader doesn't mean you have an impressive vocabulary. J From: Andy Shook [mailto:andy.sh...@peak10.com] Sent: Monday, January 12, 2009 9:30 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups I've already got the book on pre-order and I've got quite an impressive vocabulary; I just like the redneck versions of the fancy words better. J Shook From: gswe...@actsconsulting.net [mailto:gswe...@actsconsulting.net] Sent: Monday, January 12, 2009 9:23 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups I agree, especially if it will help Shook. Did you write it in small enough words? J From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Monday, January 12, 2009 9:19 AM To: MS-Exchange Admin Issues Subject: RE: Incremental backups Thanks Michael. Seems like it will be a good purchase. From: bounce-8371736-8066...@lyris.sunbelt-software.com [mailto:bounce-8371736-8066...@lyris.sunbelt-software.com] On Behalf Of Michael B. Smith Sent: 12 January 2009 14:17 To: MS-Exchange Admin Issues Subject: RE: Incremental backups I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. J Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover-as almost everyone has to do eventually-you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A normal backup is also known as a full backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (flush) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A copy backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A daily backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An incremental backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a filesystem backup, an incremental backup backs
RE: Incremental backups
I was told, originally, that it would be available before Christmas. I keep hearing any day now. So, if you've been around long enough to remember Jerry Pournelle's columns in BYTE Real Soon Now! J Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Sherry Abercrombie [mailto:saber...@gmail.com] Sent: Monday, January 12, 2009 9:28 AM To: MS-Exchange Admin Issues Subject: Re: Incremental backups Ok, so it's not exactly an incremental in the 'normal' definition of incremental, it's not doing an incremental on the actual database, just the logs. I do a daily full, flush the logs after successful backup on my E2K3 setup. When is that book going to be available anyway?? I would really like to get it before I start setting up E2K7. I mean, I only went to training for it in Sept. 07 and am finally going to start working on it by the end of this month. (Going on vacation next week, won't be back until late the 26th, so I'm NOT starting any big projects this week.) On Mon, Jan 12, 2009 at 8:16 AM, Michael B. Smith mich...@theessentialexchange.com wrote: I cover Exchange backups in detail in Chapter 12 of my upcoming book which should be available any minute now. Please buy it. J Here is an excerpt that answers your question. Backup Types As you might expect, there are a number of kinds of Exchange database backups. They all map directly to standard filesystem types of backups and thus share similar names. However, there are only two database backup types that you can use without another backup: normal and copy. All of the other backups will require a normal backup to be useful. type=note The backup types discussed in the following sections apply both to streaming backups and to VSS backups. Generally speaking, the easiest mechanism for recovery is daily normal backups. The mechanism that uses the least media is a weekly normal backup plus daily incremental backups, at the expense of a much more complicated recovery. The standard compromise is a normal backup each weekend with differential backups during the week. When it comes time to recover-as almost everyone has to do eventually-you will thank yourself if you have made daily normal backups. You absolutely should do daily backups and retain them until at least the next successful backup has been done. OpsMgr generates a warning alert if transaction logs are not flushed within a period of three days and generates an error alert if transaction logs are not flushed within a week. Transaction logs are flushed only by normal (full) backups and by incremental backups. Normal Backups A normal backup is also known as a full backup. This is the backup type that most people probably think of when they think of a backup. A normal backup copies the entire database, and the backup can be restored on its own. A normal backup will remove (flush) all current transaction logs if the normal backup is successful and update the database header indicating that a full backup occurred with a particular time stamp (signature). To think of it in terms of a filesystem backup, a normal backup backs up everything and clears the archive bit; that is, it indicates that the file has been backed up. Copy Backups A copy backup is similar to a normal backup. However, a copy backup does not flush transaction logs, and it doesn't update the database header. You can use the copy backup to fully restore to the point of a backup and roll forward from there. Generally speaking, if a support person asks you to make a backup of your database(s) outside of your normal backup rotation, you should be doing a copy backup and not a normal (full) backup. This preserves your options in the case of requiring any reload or restore. Executing a normal (full) backup outside your normal rotation can possibly complicate a recovery scenario if transaction logs need to be replayed. To consider it in terms of a filesystem backup, a copy backup backs up everything but does not clear the archive bit. Daily Backups A daily backup bears some resemblance to differential and incremental backups. A daily backup will back up the transaction logs that were generated today. This is not a recommended way to back up an Exchange database since it can potentially have missing transaction logs (consider that a transaction log was in use and not available for backup at midnight). To consider it in terms of a filesystem backup, a daily backup backs up everything modified or created today but does not clear the archive bit. Incremental Backups An incremental backup will back up all created transaction logs since the last normal backup or incremental backup, and then it flushes the transaction logs. This is a mechanism to keep your transaction log volume clean, at the expense of complicating your restore/recovery process. To consider it in terms of a
RE: Is it safe to remove ExchangeLegacyInterop group from AD?
I'm in IT, I can multi-task. ;-) From: Andy Shook [mailto:andy.sh...@peak10.com] Sent: Friday, January 09, 2009 8:50 PM To: MS-Exchange Admin Issues Subject: RE: Is it safe to remove ExchangeLegacyInterop group from AD? It's a pleasant change from your typical Friday night activity of soliciting truck drivers ;) Shook From: Tim Vander Kooi [tvanderk...@expl.com] Sent: Friday, January 09, 2009 8:01 PM To: MS-Exchange Admin Issues Subject: RE: Is it safe to remove ExchangeLegacyInterop group from AD? Gee thanks! :) I'm having the joy of trying to clean up AD after my last E2k3 box wouldn't uninstall via the wizard, so I had to do it manually. I think I am now down to just having to decide whether or not to remove that legacy group via ADUC and the First Administrative Group via ADSI. No better way to spend a Friday night! From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Sent: Friday, January 09, 2009 6:57 PM To: MS-Exchange Admin Issues Subject: RE: Is it safe to remove ExchangeLegacyInterop group from AD? H. I would say yes. But don't quote me on that! Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Tim Vander Kooi [mailto:tvanderk...@expl.com] Sent: Friday, January 09, 2009 7:20 PM To: MS-Exchange Admin Issues Subject: Is it safe to remove ExchangeLegacyInterop group from AD? If you have no Exchange 2000/2003 servers in a domain, is it safe to remove the ExchangeLegacyInterop group from ADUC? TVK ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
Anyone know how to force plain text encoding to an E2K7 internal recipient?
I've got some internal mailboxes used by an automated system that can't cope with HTML, and need to force anything to those mailboxes to plain text. I can force it to plain text for messages going to remote domains or recipients, but I'm not finding anywhere to specify it for mail sent internally. ** Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. ** ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Anyone know how to force plain text encoding to an E2K7 internal recipient?
I don't know of any way to do that per-user. You can force it for all users who use POP or IMAP though. Would that help? Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Campbell, Rob [mailto:rob_campb...@centraltechnology.net] Sent: Monday, January 12, 2009 3:47 PM To: MS-Exchange Admin Issues Subject: Anyone know how to force plain text encoding to an E2K7 internal recipient? I've got some internal mailboxes used by an automated system that can't cope with HTML, and need to force anything to those mailboxes to plain text. I can force it to plain text for messages going to remote domains or recipients, but I'm not finding anywhere to specify it for mail sent internally. ** Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. ** ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Anyone know how to force plain text encoding to an E2K7 internal recipient?
Actually, I already figured it out. It appears you can force it for all POP or IMAP using: set-popsettings -server CAS servername -messageretrievalmimeformat textonly You can override it per-user using: set-casmailbox identity -popmessagesretrievalmimeformat textonly There is one gotcha. If you set it per user, you also have to do: set-casmailbox identity -popuseprotocoldefaults $false or it will ignore the mailbox format setting in favor of the POP settings on the CAS server From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Sent: Monday, January 12, 2009 4:06 PM To: MS-Exchange Admin Issues Subject: RE: Anyone know how to force plain text encoding to an E2K7 internal recipient? I don't know of any way to do that per-user. You can force it for all users who use POP or IMAP though. Would that help? Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Campbell, Rob [mailto:rob_campb...@centraltechnology.net] Sent: Monday, January 12, 2009 3:47 PM To: MS-Exchange Admin Issues Subject: Anyone know how to force plain text encoding to an E2K7 internal recipient? I've got some internal mailboxes used by an automated system that can't cope with HTML, and need to force anything to those mailboxes to plain text. I can force it to plain text for messages going to remote domains or recipients, but I'm not finding anywhere to specify it for mail sent internally. ** Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. ** ** Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. ** ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: Incremental backups
From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Subject: RE: Incremental backups I was told, originally, that it would be available before Christmas. I keep hearing any day now. So, if you've been around long enough to remember Jerry Pournelle's columns in BYTE Real Soon Now! J From Amazon: Items not yet shipped: https://images-na.ssl-images-amazon.com/images/G/01/x-locale/common/icons/ar row_subordinate._V47081670_.gifShipping estimate: February 23, 2009 * 1 of: Monitoring Exchange Server 2007 with System Center Operations Manager Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~image001.gif
RE: exchange reporting tool
-Original Message- From: Andy Shook [mailto:andy.sh...@peak10.com] Subject: RE: exchange reporting tool Webster likes GoExchange for these types of reporting needs... :) No, that is William Lefkovics. He covers GoExchange in Chapter 22 of his book. Never seen a product covered in so much detail before. Made me want to go out and spend my own money on the product and give it to MBS for an early birthday present. Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: exchange reporting tool
Oooo... It's the Big One... You hear that Elizabeth... I'm comin' I'm comin'!!! Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php -Original Message- From: Webster [mailto:carlwebs...@gmail.com] Sent: Monday, January 12, 2009 6:05 PM To: MS-Exchange Admin Issues Subject: RE: exchange reporting tool -Original Message- From: Andy Shook [mailto:andy.sh...@peak10.com] Subject: RE: exchange reporting tool Webster likes GoExchange for these types of reporting needs... :) No, that is William Lefkovics. He covers GoExchange in Chapter 22 of his book. Never seen a product covered in so much detail before. Made me want to go out and spend my own money on the product and give it to MBS for an early birthday present. Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
RE: exchange reporting tool
-Original Message- From: Webster [mailto:carlwebs...@gmail.com] Sent: Monday, January 12, 2009 3:05 PM To: MS-Exchange Admin Issues Subject: RE: exchange reporting tool -Original Message- From: Andy Shook [mailto:andy.sh...@peak10.com] Subject: RE: exchange reporting tool Webster likes GoExchange for these types of reporting needs... :) No, that is William Lefkovics. He covers GoExchange in Chapter 22 of his book. Never seen a product covered in so much detail before. Made me want to go out and spend my own money on the product and give it to MBS for an early birthday present. Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~image001.jpg
RE: exchange reporting tool
LOL (The Other) Webster From: William Lefkovics [mailto:will...@lefkovics.net] Subject: RE: exchange reporting tool -Original Message- From: Webster [mailto:carlwebs...@gmail.com] Subject: RE: exchange reporting tool -Original Message- From: Andy Shook [mailto:andy.sh...@peak10.com] Subject: RE: exchange reporting tool Webster likes GoExchange for these types of reporting needs... :) No, that is William Lefkovics. He covers GoExchange in Chapter 22 of his book. Never seen a product covered in so much detail before. Made me want to go out and spend my own money on the product and give it to MBS for an early birthday present. Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~image001.jpg
RE: exchange reporting tool
How did I get dragged into this… I didn’t write about GoExchange by Halucin8. From: Webster [mailto:carlwebs...@gmail.com] Sent: Monday, January 12, 2009 4:30 PM To: MS-Exchange Admin Issues Subject: RE: exchange reporting tool LOL (The Other) Webster From: William Lefkovics [mailto:will...@lefkovics.net] Subject: RE: exchange reporting tool -Original Message- From: Webster [mailto:carlwebs...@gmail.com] Subject: RE: exchange reporting tool No, that is William Lefkovics. He covers GoExchange in Chapter 22 of his book. Never seen a product covered in so much detail before. Made me want to go out and spend my own money on the product and give it to MBS for an early birthday present. Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~image001.jpg
Re: exchange reporting tool
Denial is not a river in Egypt! John W. Cook Systems Administrator Partnership For Strong Families Sent to you from my Blackberry in the Cloud From: William Lefkovics To: MS-Exchange Admin Issues Sent: Mon Jan 12 20:10:07 2009 Subject: RE: exchange reporting tool How did I get dragged into this… I didn’t write about GoExchange by Halucin8. From: Webster [mailto:carlwebs...@gmail.com] Sent: Monday, January 12, 2009 4:30 PM To: MS-Exchange Admin Issues Subject: RE: exchange reporting tool LOL (The Other) Webster From: William Lefkovics [mailto:will...@lefkovics.net] Subject: RE: exchange reporting tool [cid:image001.jpg@01C974D8.9E3C9C20] -Original Message- From: Webster [mailto:carlwebs...@gmail.com] Subject: RE: exchange reporting tool No, that is William Lefkovics. He covers GoExchange in Chapter 22 of his book. Never seen a product covered in so much detail before. Made me want to go out and spend my own money on the product and give it to MBS for an early birthday present. Webster CONFIDENTIALITY STATEMENT: The information transmitted, or contained or attached to or with this Notice is intended only for the person or entity to which it is addressed and may contain Protected Health Information (PHI), confidential and/or privileged material. Any review, transmission, dissemination, or other use of, and taking any action in reliance upon this information by persons or entities other than the intended recipient without the express written consent of the sender are prohibited. This information may be protected by the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and other Federal and Florida laws. Improper or unauthorized use or disclosure of this information could result in civil and/or criminal penalties. Consider the environment. Please don't print this e-mail unless you really need to. ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~ inline: image001.jpg
RE: exchange reporting tool
From: William Lefkovics [mailto:will...@lefkovics.net] Subject: RE: exchange reporting tool How did I get dragged into this… I didn’t write about GoExchange by Halucin8. Martin says you are always in drag, just like TVK. Webster ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja~
