Here is a trick you might find useful once in a while: forcing the computer to write its recovery file now instead of later.
Every once in a while I get my hands on a computer that has Pointsec installed, but is not encrypted. The most common reason why a machine doesn't encrypt is that the recovery file hasn't been written. This usually happens on computers where the user is almost never on site or the user is not logging in with their regular user account. For whatever reason the computer might not have access to write the file.
Today I got in just such a machine. The user had too many failed logon attempts and the computer rebooted into the Pre-Boot Environment. I got the machine, but I didn't plug it into the network because both of my network ports were in use. So I authenticated in the Pre-Boot environment and clicked the enable WIL check box because I have set the 'Display Enable WIL' option in the system settings of my machine. Windows booted.
Remember that WIL doesn't actually get turned back on until someone logs into Windows. Since I had never logged into this computer before, and since I wasn't connected to our wired network, I logged on with a local administrator password. So now WIL was re-enabled, but I checked and the computer was 0% encrypted. I looked at the local event database and saw that the process of writing the recovery file had failed.
It had also failed just now when I logged in. I wasn't connected to any network. I wanted to get this computer fixed up quickly. I could connect to our wireless network, but then I would still have to wait for Pointsec to take another shot at writing the recovery file. Luckily for me there is a way to force Pointsec to write it now instead of waiting up to 30 minutes for it to happen on its own. Navigate to C:\Program Files\Pointsec\Pointsec PC and double click on CreRec.exe. You will see no output showing that anything happened, but the recovery file will be written. You can go to the network share and confirm that it is written. I have found that the encryption process will begin about five minutes after the recovery file has been written.
One thing that irritates me is that I don't see any new event written in the local event database. But the file was written and the encryption process did begin. So you can use this trick to jumpstart the process a bit. I always like to wait until I see the encryption process hit 1 or 2 percent before I shut down and deliver to the customer regardless of whether I use this trick, or just let it happen naturally.
4 comments:
That's a nice trick. You can also force update profiles to apply immediately by placing the .UPP file in c:\program files\pointsec\pointsec for PC\work.
I just wish Check Point would include stuff like this in the Mac version!
Hey wes, are you using the Mac version? How do you like it? I have had some problems with it as you can see from some of my blog postings.
I work at an university, and our department has decided to roll out FDE for Mac R71 (we're probably about 80% Macs) while the main Campus IT group has decided not to.
For the most part FDE for Mac hasn't been that problematic - I've only seen the hanging blue screen thing that you saw a couple of times, and it was resolved by re-imaging the computers. Single Sign On works well with our OpenDirectory authenticated accounts (we set them up in OS X as "mobile" accounts), but password synchronization apparently only works in one direction (OS X -> FDE).
Have you looked into the recently released R72 update?
version 6.2 has an issue with the signed certificate, thats why it doesnt start encrypting. There is now a hotfix for this.
There are only these 4 reasons why encryption doesnt start -
1. The disk is physically damaged.
2. The service is not running.
3. Recovery path is not set, or set incorrectly, or user has no rights to write to the path, or user that have rights is not a user that Pointsec is running on it.
4. License.
Post a Comment