This content has been marked as final. Show 10 replies
The problem is really when things go wrong - if you break a standard drive, we have 20 years of experience in recovering the data from it.
However, if you break a raid array on an EFI bios server, I don't have a clue where to start.
In theory a hardware raid array presents itself as a single volume to the machine, so (again in theory) all the standard diagnostic tools should work fine. But, what happens if the array isn't supported at BIOS level, if it requires windows drivers etc? Then there's no way we can run the toolkit on it.
So, officially no, we don't support RAID - this is clearly spelt out in the release notes. However, we do have many customers encrypting servers successfully, but not holding us to any SLA's if things go wrong.
Can you share why you want to encrypt the servers at disk level? Do you have a problem with people stealing drives from them?
Thanks for the quick response. These are serious servers using proper, hardware RAID controllers that are supported in the BIOS. They don't require windows drivers just to make the arrays visible - I'm not that crazy :)
As to why I want to encrypt the server drives it's simply because users will be saving files to them. I don't have the problem of people stealing drives - nicking entire servers is not unheard of though. And the files on these server may contain highly confidential data, so I want to encrypt the drives.
I'm working on the principle of "If it stores data, encrypt it! It's the only way to be sure". happy
then in theory it should work fine.
my advice is to install WITHOUT encryption first, if the machine still boots up fine after authentication then it's usually safe to encrypt.
of course, don't use Autoboot, that negates the point of encrypting in the first place.
Thanks for the advice, I shall take it. :)
Don't forget a good backup plan, and just wanted to say I feel for you - being in an environment where servers could be stolen? That's rough!
I used to support servers remotely when they were the size of refrigerators. One day one server went offline, I tried for an hour to get it to respond, then eventually called the local security guard and asked him to power cycle it for me.
He came back about 10 min's later to remind me that the server had been collected for repair earlier in the day, and thus was not going to respond until it was returned and reinstalled.
It was "collected" by an engineer who had been fired earlier that week for stealing parts.
The server was worth about $300k at the time....
And your management supports your effort to encrypt these servers? How will you handle Patch Tuesday with all your servers encrypted? When they reboot, they'll be sitting at the SB login with no network connectivity (yeah, sure... if you have a card for network console access). If you enable AutoBoot, then what is the point of encrypting?
I think you should do a sanity check before you get too excited about encrypting the world. Do you only have Windows servers storing data? Do your backups also go to these same servers? If so, then your SB server backups would be stored in an encrypted machine. In the event of a problem, you basically locked the keys in the car (or in this case a bunker). If your domain controllers can't boot, you can't login to the SB server to issue codes.
If you are talking about a specific set of servers (remote file servers) and not all core services servers, then it may be worth the effort. Encryption doesn't solve all problems. If data loss is a concern, you're going to have to use a form of Content Encryption too to prevent loss over network or removable media. Just make sure you think several moves ahead before your adversaries call checkmate.
If were sane, I wouldn't be in this job :)