Remove Mcafee Safeboot
We were able to get the RefreshTool to work after much trail and error. Interestingly enough, we cannot get an image to apply because of an access denied error in WinSxS. (In this scenario, we're deploying images through SCCM 2007, not MDT.) The errordoesn't occur on unencrypted devices or devices that are decrypted. After receiving no real assistance from McAfee and Microsoft Premier, we simply decided to call it a day and proceed without hard-link migration.I work for a healthcare company and patient information is of the utmost importance. Losing 3-5% of devices to any sort of error would not be acceptable, so it's just as well that we have to find another method for moving data.-Nick O. I have the tools stored in a different place in my file structure. However, they all seem to run correctly until after Windows 7 is installed.
I get an error on the Restore Safeboot MBR step (saying the MBR is already Safeboot and it can't be replaced, butMcAfee warns of this in their documentation and says to put a continue on error with that one.) I also get an error and the deployment halts with the –SetHookFlags step. When this happens, a reboot comes back with the 92h error and won't let me boot back intothe machine until I use the Safetech tools to restore the MBR from the database. Once I do that, the machine boots back into PE and finishes configuring the OS. At that point I have to manually finish the rest of the deployment steps (working to create a taskthat finishes it off for me though.) The safeboot files are migrated back with the USMT loadstate and I can install McAfee back on the machine after I finish.
Everything works as it should overall, but that error and fixing it is a major hassle and very timeconsuming. It's not a catastrophe or loss of data, just seriously annoying.I AM upgrading from 32 bit XP to 64 bit Win7.
I am using the respective tools with the correct OS versions or at least I think. My WinPE is 64 bit, so I'm using the 64 bit OSRefresh tool during those steps and later. I use the 32 bit tool while the machineis still in XP for the first few steps. Could that be my issue? I get to the part after the install where my MDT task is set to restore the MBR and set the hook flags. The computer should restart at that point, but my error occurs and halts the task sequence. The tools work within XP to store the MBR and unlock/unhidethe other Safeboot files.
Mcafee Removal Tool
It also apparently within WinPE stores the MBR before it installs the OS, because I can see the SafebootMBR.dat file in the root of X: when I go into the command prompt after the task fails. The paths to the tools are the same inall the places it works, as it is in the step that fails.I used the 2nd method in the McAfee documentation to create my 'golden' Win7 WIM. I mounted the WIM and installed the EE driver just as I did in my PE images. Then at the end of the process I install the application and sync to the server.
As I said, ifI use SafeTech and restore the EEPC MBR from the database, the computer will boot again, finish the Win7 configuration and be ready for me to install the rest of my drivers/apps and do my configuration/run loadstate to pull in the hardlinked USMT files. Ican install the EEPC application at the end and sync it and it works just fine. I just cannot get it to restore the MBR and set the hook flags after Win7 is installed within the task sequence. One thing everyone might find helpful. I add McAfee support to my PE boot images on the fly every time I create them using an UpdateExit script, located in the C:Program FilesMicrosoft Deployment ToolkitSamples folder.The safeboot.sys and SbAlg.sys files go in Extrax86WindowsSystem32Drivers and Extrax64WindowsSystem32Drivers, the SBWinPE.reg file goes in Scripts. The UpdateExit script runs every time you rebuild your boot wims, imports the PE registry andmodifies it, so you don't need to mount and edit the wims manually.'
//.' //' // Copyright (c) Microsoft Corporation. All rights reserved.' Nice script Joe. I run a similar script but I do it after MDT spits out my gold WIM.
I like to keep a 'clean' copy for archiving, but your method is definitely easier.Nick I will add that a good majority of the 3-5% were older model (Lenovo T/X 60, T/X 61) laptops. They were never valid win7 candidates in my opinion but the call was over my head.
To make it even more fun many of the failures were with the betaversion of the tool. All in all I've had a very high level of success with 'valid' devices, and production tools. On the rare occasion when the process does fail the supplied recovery tools did the trick to either repairthe MBR and continue migration, or in last resort copy the user data to a safe network location. I have not lost any user data to date.
I should have been more clear initially.
We don't have anything like that on our systems. I also started nosing around in the BIOS when you mentioned you had issues with Lenovo laptops onthis. My 'problem' laptops are also Lenovo. I disabled all the onboard security devices thinking something was causing the MBR to not be written back properly.
No luck there.BUT.that search made me remember that these laptops originally had the Lenovo recovery partition crap on them. My MDT step to install completely formats the harddrive and doesn't create that Lenovo partition. I'm thinking the saved MBR does get restored,but is looking for that no longer around partition? Would that theoretically explain the issue? Ladybug: Some of our legacy XP images contained a recovery partition created by the Lenovo 'Rescue and Recovery' app.
One of my pre-migration steps is to make sure that software is completely removed from the device. Failure to do so leadsto problems as natively it will not allow the 'MININT' folder to be created on the C. I have not tied failures to the recovery partition.Joe: We think along the same lines. I wrote a script that is run before the user capture that A) identifies the pesky.bak profiles B) enumerates the ProfileList, and scans through them one at a time, looking at the 'ProfileImagePath' value.If the ntuser.dat does not exist for that particular SID, it removes it and keeps moving. I call ZTIUtility within the script so I can dump the actions taken by the script into BDD.log.
Unfortunately it was a common practice for the floortechs to simply delete the profiles from DocsSettings folders. This cleanup step has proven to be a time saver as USMT will loop on profiles that do not have a ntuser.dat file present 20 times before continuing. From reviewing logs, I've seensome 5+ year old images have 20 or more profiles that were deleted improperly. The.bak issue is a bit more complex, as I am super anal about profiles containing.000,.Domain.Com etc.
Mcafee Endpoint Encryption Forgot Password
It's a manual cleanup step I have my techs do prior tomigration as of now, although I'm looking into a 'safe' way I can automate this.