Dead on! Grandparent is assuming that the cost and value of a system are identical. All you need to do is show that the value of a system during downtime is greater than the cost of a good DR architecture.
4 Node (2 active and 2 passive) cluster attached to continuous replicating SANs. 2 nodes (1 active and 1 passive) & 1 SAN onsite, 2 nodes & the other SAN in a remote side, CoLo, or hot site.
That's our basic design for critical applications. Active nodes provide network load balancing while the passive nodes allow us failover potential. Granted the cost for such a solution is extremely high, but in an enterprise environment where 3 days of downtime cost more than an entire year of housing and bandwidth the cost definitely justifies the cost. One of the nice features of having remote locations is that you can essentially drop nodes in them and use them as hot sites. They are already housing dedicated bandwidth to the central office, so that aspect becomes a non-issue. Additionally, that configuration allows our hot site to be a true DR location for offsite testing and rebuilding boxes and services. Again, this solution is not cost effective for all businesses, and your assessment of the HA design you've given is fully accurate. There's an element of better availability, but the architecture leaves a lot to be desired for many enterprise concerns. Ultimately, both HA and DR are financial concerns that dictate what a company can afford to spend... and that ultimately determines architecture.
I thought most government agencies with enterprise level data storage were on either Veritas, Net Backup, or Commvault. All of which support tape barcodes that can be organized whether or not the library has a robotic arm and barcode scanner. I can see smaller agencies using non-enterprise class versions of Veritas, but as you remove software management layers from things, you'd better be hiring competent enough employees to get tape rotation and labeling correct.
High Availability will always trump Disaster Recovery. Build a highly resilient system for your services and recovering from a disaster should be a non-issue. This involves building scalability, redundancy, and replication into every critical application. Additionally, backups are still a good source of recovery for corrupted and then replicated data. The biggest problem is ensuring that you can recover the data within a reasonable time frame. That's why we are moving to a Falconstor VTL and Single Instance Repository solution to ensure a deduplicated backup set that is replicated to our hot site. $1200/year is a small cost in comparison to the cost of recovery loss sue to a local disaster like fire or flood.
Not even close. We use LTO2 tapes and keep them offsite for 18 months. We've run several test recoveries on tapes > 12 months old with success. Some of our tapes have been in circulation for about 24 - 30 months now and are still writing without difficulty. For restoration purposes, the actual media is rarely the problem. Changes in encryption passwords (with a poorly documented history), files in use, and lost/orphaned files are the most common reasons for restoration failure.
Definitely true, and in most prior positions, things ran this way. However, in a law firm environment, it is much more difficult to put restrictions in place. The dynamics are like this:
Lawyers work for clients and brings in revenue to the firm
Partners have equity or income shares in the firm. Thus, the more profit the firm makes, the more money the partner makes.
IT department spends a portion of this revenue.
From the partners' perspective it is a simple matter: "I am directly paying you from my income. Because of this, I want to make sure I have every capability possible." As soon as you begin discussing limitations for any reason, you get the same response. "We're paying you to do this without limitations. Thus, we will proceed that way." The thing is that this phenomenon is not isolated to the firm I work in. Every firm any of my coworkers and myself have worked in are the same way.
Definitely good points. Our problem is that the E2K3 DB for our main Exchange Server is a bit over 1.5TB. Backing that up to LTO2 has been quite a challenge on a nightly basis. Especially when it interferes with our offsite tape copy. We've balanced this out so far by performing full backups MWF and incremental backups TR. The real problem is the brick level full backups. With a maximum throughput of 10GB/h per stream (maximum 5 streams), this backup of 1.5TB runs from Friday evening to Monday evening. Obviously an email archival solution would bring this time down tremendously, but as you stated, there is a high cost associated with that.
EMC, CommVault, CA, Quest, and many other vendors have email archiving solutions that do exactly this. Settings are customizable, and easily allow for a tiered storage approach that would fit the main idea you are looking at. However, 100MB limits on mailboxes are essentially impossible in many fields. Plus, can you imagine telling your company president, CEO, managing partner, or head of staff that they need to trim their mailbox because they are over 100MB? I know we tried to cap the mailboxes at 2GB in our firm under the pretense that MS would not directly support mailbox issues greater than that. It got up to our managing partners and was immediately shot back down. I know that email is not meant to be an archival solution, but realistically, it is becoming just that (both by users and from a legal perspective). In fact, many DMS solutions like Interwoven are merging interfaces into Outlook for that exact purpose.
Anybody that thinks Gmail / Exchange are in realistic competition is stupid. (Microsoft) Those two services may sound similar when you compare "features", but in the real world they really are not competitors.
I couldn't have said that better myself. However, I think that in the enterprise environment, the storage issues are addressed even when using existing hardware. For instance, our environment will be upgraded to Exchange 2007 by migrating the LUNs that hold our current storage to the new server and upgrading from there. At the same time, we have reached space issues already (when our E2K3 DB reached 1.5TB). We were very grateful to have out database volumes running from SAN, as we were easily able to create a metaLUN to increase the available space. If an enterprise environment is planned well, such as using SAN space for volumes that can easily fill up quickly, storage should rarely be an issue.
PST files do not always work in areas where corporate compliance issues exist. Unfortunately, rogue PST files are the main reason why email archiving solutions require a discovery agent to be loaded on clients. If you are a publicly traded company and wind up in court, discovery can subpoena all relevant emails sent out in the past 7 years. Even if these emails are sitting off the exchange server and on a PST, the corporation is still responsible for presenting them.
The summary is misleading, if not wholly inaccurate. The article basically states that MS is trying to urge companies that keep smaller mailbox quotas to bump them up to 2GB at least. Supposedly, the feature set of Exchange 2007 is supposed to make doing this more attractive to corporate IT departments.
Our department doesn't use quotas or any method of limiting mailbox sizes. In our site we have mailboxes upwards of 17GB. The main problem with this is that as of Exchange 2003, MS will not provide assistance resolving mailbox issues for mailboxes > 2GB.
Yes, but the BB device has a 10x missed password limit. Once that has been achieved, the data is wiped. Hopefully you can trust your password to not be guessed in 1/10 tries.
The feature is not meant to thwart theft of hardware. It seems like it is there to thwart the theft of information. Most companies and firms have a site insurance coverage on handheld devices through the WSP, which makes lost and stolen devices less of a concern from the hardware level.
My original response was fairly short. Let me provide a different view. For the most part, the enterprise activation and intial synchronization with the BES will get the majority of your data back. So once the password is incorrectly guesses 10 times and the blackberry wipes itself, a hard or wireless reactivation and synch with your exchange account will get you pretty close to where you were before the wipe occurred. If you have data that is not replicating to Exchange, then you want to make sure you perform periodic backups within the Desktop Manager. This will allow for restore points for the unsynched data. Again, understand that I am assuming an enterprise environment because that really seems like the major market for RIM. Hope this was a bit more useful than the first answer I gave.
Assigning a lock password on a Blackberry takes care of the direct impact of this. The password lock on the Blackberry unit allows 10 possible logins before it performs a wipe of the handheld data. If you have a remotely strong password, you'd be fine. Also, there is an option to "Kill Handheld" directly on the BES (Blackberry Enterprise Server) which wipes the user's data from the handheld the next time it contacts the WSP. The only problem with this is that the kill command will only try to execute for a set period of time (I think 3 days), so if someone finds the blackberry after that (assuming it is not powered on) there is a potential for data compromise. However, the password protection should mitigate any further issues.
This makes me think that this feature set is going to be marketed at non-enterprise users. I've always thought that non-blackberry smartphones are more common among that user base, though. The entire point (as I see it) of using blackberries is to interface directly with your exchange server at an enterprise level. For instance, our law firm uses it because the messages leave our office encrypted by the BES. Thus, any priveliged information sitting on a WSP's queue for delivery is not cleartext.
If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.
The firm that I work for gets something like 160,000 emails from external sources a day. Roughly 10% of these are legitimate. How prudent is it to force users to sift through 90% crap in order to get to the legitimate 10%. Currently, we use Postini as our primary MX host. They forward legitimate messages directly to our Exchange server, filter out 100% guaranteed spam, and drop the remainder into a quarantine that we check every few hours. Basically, all I am getting at is that spam filtering is necessary for enterprise environments and that there are actually some good tools to acheive it.
Not according to the judge. The judge decided that a license is not granted until the EULA is accepted. This means that the box does not contain a license, but rather a "nonrefundable nontransferable potential license."
Someone help me here. The judge states that the COA is not proof of licensing and that a license is not granted until the EULA is agreed upon. Because of that, an end user is not allowed to sell their license for X software (because they don't have a license until the EULA is agreed). The only way this seems possible is if the software manufacturer never sells a license. This means that the shrink wrapped box includes software and a nontransferable ownership of a license to the purchaser. It isn't a license until the purchaser agrees to the EULA, however. So basically (by this logic), I cannot buy software as a gift for a friend. Once I purchase the software, the license can only be granted to me (as the purchaser).
Since that doesn't seem reasonable, where I am interpreting this incorrectly?
Similar story with D-Link. We were troubleshooting a wireless router. Support kept asking me to go into the device manager. I informed the analyst that I was using a OS X and that there is no device manager in the OS. He insisted that there was once, and I asked him how to get there. He tells me to click on the START button. I informed him that I didn't have one. He informed me that he couldn't go any further in troubleshooting because I obviously had a virus.
Slashdot Mirror
Dead on! Grandparent is assuming that the cost and value of a system are identical. All you need to do is show that the value of a system during downtime is greater than the cost of a good DR architecture.
4 Node (2 active and 2 passive) cluster attached to continuous replicating SANs. 2 nodes (1 active and 1 passive) & 1 SAN onsite, 2 nodes & the other SAN in a remote side, CoLo, or hot site. That's our basic design for critical applications. Active nodes provide network load balancing while the passive nodes allow us failover potential. Granted the cost for such a solution is extremely high, but in an enterprise environment where 3 days of downtime cost more than an entire year of housing and bandwidth the cost definitely justifies the cost. One of the nice features of having remote locations is that you can essentially drop nodes in them and use them as hot sites. They are already housing dedicated bandwidth to the central office, so that aspect becomes a non-issue. Additionally, that configuration allows our hot site to be a true DR location for offsite testing and rebuilding boxes and services. Again, this solution is not cost effective for all businesses, and your assessment of the HA design you've given is fully accurate. There's an element of better availability, but the architecture leaves a lot to be desired for many enterprise concerns. Ultimately, both HA and DR are financial concerns that dictate what a company can afford to spend... and that ultimately determines architecture.
I thought most government agencies with enterprise level data storage were on either Veritas, Net Backup, or Commvault. All of which support tape barcodes that can be organized whether or not the library has a robotic arm and barcode scanner. I can see smaller agencies using non-enterprise class versions of Veritas, but as you remove software management layers from things, you'd better be hiring competent enough employees to get tape rotation and labeling correct.
High Availability will always trump Disaster Recovery. Build a highly resilient system for your services and recovering from a disaster should be a non-issue. This involves building scalability, redundancy, and replication into every critical application. Additionally, backups are still a good source of recovery for corrupted and then replicated data. The biggest problem is ensuring that you can recover the data within a reasonable time frame. That's why we are moving to a Falconstor VTL and Single Instance Repository solution to ensure a deduplicated backup set that is replicated to our hot site. $1200/year is a small cost in comparison to the cost of recovery loss sue to a local disaster like fire or flood.
Not even close. We use LTO2 tapes and keep them offsite for 18 months. We've run several test recoveries on tapes > 12 months old with success. Some of our tapes have been in circulation for about 24 - 30 months now and are still writing without difficulty. For restoration purposes, the actual media is rarely the problem. Changes in encryption passwords (with a poorly documented history), files in use, and lost/orphaned files are the most common reasons for restoration failure.
Last time I was in college, GPA was a number, not a letter. Have things changed?
- Lawyers work for clients and brings in revenue to the firm
- Partners have equity or income shares in the firm. Thus, the more profit the firm makes, the more money the partner makes.
- IT department spends a portion of this revenue.
From the partners' perspective it is a simple matter: "I am directly paying you from my income. Because of this, I want to make sure I have every capability possible." As soon as you begin discussing limitations for any reason, you get the same response. "We're paying you to do this without limitations. Thus, we will proceed that way." The thing is that this phenomenon is not isolated to the firm I work in. Every firm any of my coworkers and myself have worked in are the same way.Definitely good points. Our problem is that the E2K3 DB for our main Exchange Server is a bit over 1.5TB. Backing that up to LTO2 has been quite a challenge on a nightly basis. Especially when it interferes with our offsite tape copy. We've balanced this out so far by performing full backups MWF and incremental backups TR. The real problem is the brick level full backups. With a maximum throughput of 10GB/h per stream (maximum 5 streams), this backup of 1.5TB runs from Friday evening to Monday evening. Obviously an email archival solution would bring this time down tremendously, but as you stated, there is a high cost associated with that.
EMC, CommVault, CA, Quest, and many other vendors have email archiving solutions that do exactly this. Settings are customizable, and easily allow for a tiered storage approach that would fit the main idea you are looking at. However, 100MB limits on mailboxes are essentially impossible in many fields. Plus, can you imagine telling your company president, CEO, managing partner, or head of staff that they need to trim their mailbox because they are over 100MB? I know we tried to cap the mailboxes at 2GB in our firm under the pretense that MS would not directly support mailbox issues greater than that. It got up to our managing partners and was immediately shot back down. I know that email is not meant to be an archival solution, but realistically, it is becoming just that (both by users and from a legal perspective). In fact, many DMS solutions like Interwoven are merging interfaces into Outlook for that exact purpose.
I couldn't have said that better myself. However, I think that in the enterprise environment, the storage issues are addressed even when using existing hardware. For instance, our environment will be upgraded to Exchange 2007 by migrating the LUNs that hold our current storage to the new server and upgrading from there. At the same time, we have reached space issues already (when our E2K3 DB reached 1.5TB). We were very grateful to have out database volumes running from SAN, as we were easily able to create a metaLUN to increase the available space. If an enterprise environment is planned well, such as using SAN space for volumes that can easily fill up quickly, storage should rarely be an issue.
PST files do not always work in areas where corporate compliance issues exist. Unfortunately, rogue PST files are the main reason why email archiving solutions require a discovery agent to be loaded on clients. If you are a publicly traded company and wind up in court, discovery can subpoena all relevant emails sent out in the past 7 years. Even if these emails are sitting off the exchange server and on a PST, the corporation is still responsible for presenting them.
The summary is misleading, if not wholly inaccurate. The article basically states that MS is trying to urge companies that keep smaller mailbox quotas to bump them up to 2GB at least. Supposedly, the feature set of Exchange 2007 is supposed to make doing this more attractive to corporate IT departments.
Our department doesn't use quotas or any method of limiting mailbox sizes. In our site we have mailboxes upwards of 17GB. The main problem with this is that as of Exchange 2003, MS will not provide assistance resolving mailbox issues for mailboxes > 2GB.
Yes, but the BB device has a 10x missed password limit. Once that has been achieved, the data is wiped. Hopefully you can trust your password to not be guessed in 1/10 tries.
The feature is not meant to thwart theft of hardware. It seems like it is there to thwart the theft of information. Most companies and firms have a site insurance coverage on handheld devices through the WSP, which makes lost and stolen devices less of a concern from the hardware level.
My original response was fairly short. Let me provide a different view. For the most part, the enterprise activation and intial synchronization with the BES will get the majority of your data back. So once the password is incorrectly guesses 10 times and the blackberry wipes itself, a hard or wireless reactivation and synch with your exchange account will get you pretty close to where you were before the wipe occurred. If you have data that is not replicating to Exchange, then you want to make sure you perform periodic backups within the Desktop Manager. This will allow for restore points for the unsynched data. Again, understand that I am assuming an enterprise environment because that really seems like the major market for RIM. Hope this was a bit more useful than the first answer I gave.
Simple. Turn the password lock off.
Assigning a lock password on a Blackberry takes care of the direct impact of this. The password lock on the Blackberry unit allows 10 possible logins before it performs a wipe of the handheld data. If you have a remotely strong password, you'd be fine. Also, there is an option to "Kill Handheld" directly on the BES (Blackberry Enterprise Server) which wipes the user's data from the handheld the next time it contacts the WSP. The only problem with this is that the kill command will only try to execute for a set period of time (I think 3 days), so if someone finds the blackberry after that (assuming it is not powered on) there is a potential for data compromise. However, the password protection should mitigate any further issues.
This makes me think that this feature set is going to be marketed at non-enterprise users. I've always thought that non-blackberry smartphones are more common among that user base, though. The entire point (as I see it) of using blackberries is to interface directly with your exchange server at an enterprise level. For instance, our law firm uses it because the messages leave our office encrypted by the BES. Thus, any priveliged information sitting on a WSP's queue for delivery is not cleartext.
You're being facetius right? Afterall, there is the Onion.
I don't see the words "Proof of License" on mine.
Not according to the judge. The judge decided that a license is not granted until the EULA is accepted. This means that the box does not contain a license, but rather a "nonrefundable nontransferable potential license."
Someone help me here. The judge states that the COA is not proof of licensing and that a license is not granted until the EULA is agreed upon. Because of that, an end user is not allowed to sell their license for X software (because they don't have a license until the EULA is agreed). The only way this seems possible is if the software manufacturer never sells a license. This means that the shrink wrapped box includes software and a nontransferable ownership of a license to the purchaser. It isn't a license until the purchaser agrees to the EULA, however. So basically (by this logic), I cannot buy software as a gift for a friend. Once I purchase the software, the license can only be granted to me (as the purchaser).
Since that doesn't seem reasonable, where I am interpreting this incorrectly?
Similar story with D-Link. We were troubleshooting a wireless router. Support kept asking me to go into the device manager. I informed the analyst that I was using a OS X and that there is no device manager in the OS. He insisted that there was once, and I asked him how to get there. He tells me to click on the START button. I informed him that I didn't have one. He informed me that he couldn't go any further in troubleshooting because I obviously had a virus.
Blame it on the Das Keyboard.
Your ability to stay off topic is remarkable.