I found this arcicle on McAfee's solution to do an OS build upgrade on MDE encrypted drives:
I tested it and the process worked for a single system, but it seems like way too labor intensive of a process to scale to more than just a few workstations.
Having to do manual upgrades for all our Windows 10 systems using the process in the above link is unworkable. We would be better off removing MDE and switching to Bitlocker so we can have a more seamless and automated process (such as being able to upgrade systems via WSUS and Windows Updates. .
Are there any better processes coming soon or any way to automate the existing process?
We will otherwise have to halt our MDE rollout to new systems and start migrating our Windows 10 systems ro Bitlocker ASAP in anticipation of the regular Windows build upgrades for Current Branch and Current Branch For Business that everyone knows are coming.
Can you help us understand what part of the process you're finding difficult to scale?
You only have to build the setup environment once - then it's just a matter of running it on all the machines?
The normal process of an unencrypted drive or a Bitlocker encrypted drive is to simply approve the upgrade in WSUS and set deadline for the installation. The systems check in to WSUS and download then pull the upgrade files from either our WSUS server or from Microsoft and install automatically. WSUS also centrally reports whether the upgrade was installed the next time the system checks in.
This process for a MDE-encrypted system requires every user (having administrator rights) or else IT administrators to manually install the update. There is no automation, installation deadline or central reporting of the statuse. It also will not work from laptops out of the office since we need to use modified custom upgrade image rather than the upgrade files that come from Microsoft.
Hi. Can you please share what ISO you used for this? I cannot find one under the VLSC and the others I downloaded have not worked. Thanks.
Appears to be the same requirement for upgrade from 1511 to 1607 Anniversary. So presumably for every branch upgrade going forward.
Having 'recalled the fleet captain' to upgrade the encrypted Win7/8's to Win10 manually using KB84962 before the free upgrade deadline, we're now facing the same requirement to get Anniversary on there.
Not workable in our distributed environment of roaming laptop users.
It's not a choice either, sooner or later we will *have* to get everyone on 1607 in order to stay in support etc.
Perhaps there is a way of injecting the MDE drivers into the .esd that is hosted on WSUS. So we can still use WSUS to deploy.
Otherwise looking at remote decrypt, remote upgrade, remote re-encrypt which is far from ideal....
I wonder how McAfee internal IT are dealing with this and their roaming devices? Presumably they eat their own dog food so will have the same issue at a much bigge scale?
End users modifying the WSUS ESD files would never be allowed. That would be a good way to get malware loaded onto systems via modified update files..
Maybe Microsoft would need to host the McAfee encryption drivers in Windows Update and install them during the upgrade just like they host and install Intel's and other vendor's device drivers.