This has been driving me crazy the past couple of days:
Last week I started on an install for SCCM 2012 SP1 for a customer who has McAfee as the main security solution in their environment. I have some previous experience with McAfee, and i hadn’t previously experienced any issues with it. All of the previous clients I had that used McAfee were on 2012 RTM, and this was the first one I had done with SP1. Sp1 uses the ADK, instead of the AIK, of course, and all has not gone smoothly.
The first problem I encountered was with the site installation itself: the site seemed to install fine, but no boot images were created. This seemed a bit odd, so I checked the ConfigMgrSetup.log file located on the root of C:\
The boot images were not created properly during setup. The boot image files were both at their default location (\\server\SMS_sitecode\osd\boot) but they weren’t in the console. I decided to try and import them manually:
A bit of an odd error message, however, the DISM log file showed that SCCM was unable to insert the OSD binaries into the WIM. Now we’re getting somewhere. I figured I’d try creating one from scratch with MDT. That was also unsuccessful.
Searching around the web was not very helpful as most people seemed to be reporting problems related to permissions. Given the access denied error that others reported, and the fact that my permissions were fine, I believed the culprit would be McAfee. Since the logs didn’t show McAfee blocking or deleting anything, I didn’t have much to go on. I talked to the security team and got them to allow me to temporarily disable McAfee, and like clockwork, I was able to create a boot image. My first thought was to exclude C:\Windows\Temp\BootImages from McAfee, but the customer’s security team wanted specific justification before adding any exclusions. We tried it as a troubleshooting step, but once Access Protection was reactivated, the problem returned.
Earlier today I came across the article above from McAfee, hopefully they’ll come to a more permanent solution, but for the time being, we need to turn off Access Protection whenever we update or edit any boot image, or perform offline servicing on a WIM. I’ve been in other environments with SCCM 2012 SP1 and other AV solutions, such as Symantec Endpoint Protection, Kaspersky, and of course SCEP, but haven’t experienced this issue yet.
AV White-list Considerations
This issue has prompted me to review some of the community resources concerning AV policy on an SCCM site server. My personal feeling is to exclude these locations from any AV client:
- %programfiles%\Microsoft Configuration Manager\Inboxes\*
- %programfiles(x86)%\Microsoft Configuration Manager\Inboxes\*
- <C:>\ConfigMgr_OfflineImageServicing – defaults to the same drive the site is installed on
You may want to review the following links for more information: