This content has been marked as final. Show 4 replies
* Don't use programs which edit the MBR (System Comander, Partition Magic, Drive Image, etc) - this one you obviously don't want to have as it confuses Safeboot and makes it enable to activate itself at bootup (obviously that would leave the disk encrypted)
* Do not use biometric authentication systems (Wave System Embassy Suite)
* Do not repair or upgrade the OS (Windows update, service packs (!!!))
Service Packs I wouldn't be worried about, since you're doing this inside Windows, so Safeboot can remain active. However you must test this first before a rollout.
* Do not update the IDE / SCSI controller drivers and phsical disk drivers
No idea. But this warning seems reasonable.
* Do not change partition settings (resize, or add addtional partittions)
True. Safeboot wouldn't know anymore where the sectors start and end. Thus it wouldn't be able to decrypt anymore.
* Do not connect external storage devices while the PC is starting.
It's exaggerated to say this warning, however as mentioned in the Encryption Admin Guide for the setting Enable Boot Disk Compatibility it says "Some machines have BIOS
code which mounts USB disks as physical drives. This is an
unusual mode of operation and means that after SafeBoot has
finished it’s authentication, Windows will hang trying to access the
drive through the BIOS physical interface (because SafeBoot is
also a 32 bit platform, it unloads all BIOS drives when it finishes).
This option forces the low-level SafeBoot drivers to block access
to disks other than the boot disk meaning Windows will not detect
these USB drives until the USB stack is initialized. An alternate
solution would be to unplug all USB drives before booting the
This one definitely requires testing, but may be necessary, because obviously you can't prepare for every brand of exteranl storage.
* Do not use third party defragmentation programs (Defraggler, for instance)
I would say if it's working inside Windows, then fine. If outside, don't even try.
* Do not use Ghost to create images of the HDD
I could tell some horror stories about this if not used appropriately. You might want to talk to McAfee about this. I would say that you need:
1. Good documented procedure on how to do this
2. Have it tested properly.
3. Don't allow end users to use this tool.
* Turn off all BIOS passwords
I'm not familiar with this topic.
Tegsan hit on most of the them, but I'll add a few comments.
Regarding biometric authentication systems, that's probably more of a support policy. If they're setup to work with SafeBoot, they'll work fine. Otherwise, the user will need to user their password to login.
For the IDE/SCSI controller drivers, the worry is probably that they may not be compatible with SafeBoot. They've probably only tested the current ones you're using on your images, and you'll need to test newer drivers as they become available.
Creating images with Ghost is possible, but as tegsan, get some documentation from McAfee if you must do this. You need to create RAW images for it to work properly.
BIOS passwords aren't a SafeBoot issue - we use BIOS passwords and have no problem. It may be that their using some tool that modifies BIOS settings such as Compaq's SSM and may have issues making the changes during deployment if passwords are set.
Take our thoughts for what they are - thoughts. If you want specific reasoning why your International support staff has set some policy, you can probably ask wink
Thank you both for the info... I am still looking over the admin guide so I am gathering my information together. Some of their restrictions seemed excessive, but I can see where some do apply.
Our international staff was using a previous version, 4.2 I think, and they had a pretty hard time of it. In their preperation of the hard drives, they had something like a 30% failure rate where the drives became corrupted / unbootable. Some of their guidelines do come out of this experience. Considering that we have users all over the country, I want to minimize the chance of this kind of failure as much as possible.
Anyone have any problems with foreign characters? East asian characters for instance?
I suggest that you run chkdsk on each system and review the application event logs to ensure no bad sectors are found. In addition, look at the system log for event ID 7 and 11 source disk. If you pass on both counts, the disk is good. We are in testing mode, have deployed to over 100 systems with 0 failures so far. We are using version 5.X however.