It seems that wimcapture fails to capture some significant data or metadata for (at least) a particular DLL needed for a working office 2021 installation. I tested in a virtual machine running Windows 10 21H2 + Office 2021 but it seems to also break Office 2019 in the same manner. This DLL is specific to the cloud installation (used for Office 365 also), but I do not have a conventional/offiline license to test with the non-cloud edition. In case it matters, it is an x64 edition of office.
I have a snapshot before the capture of everything working fine, but simply wimcapture the volume (offline), format the partition, and wimapply the very same image back seems to break office. I am happy to help test/debug stuff since I have VM snapshots in the pre-capture and post-apply states as well as the image itself.
office.png (6.56 KiB) Viewed 9228 times
Edit: Just to be clear, the DLL is present and SHA256 identical to the base image, but it is not recognised by office for whatever reason... presumably some hidden NTFS stream or permission?
I second this. Have been seeing it for a while on one of my OS images. Another image is suspiciously immune to the issue, but they may have office installed and/or licensed in different modes. I'm pretty sure none are Office 365 but one was an and 2019 installation that upgraded itself to 2021 when a new key was provided and another was raw install or upgrade manually from media. I'm sure that confusion doesn't help for sure :/
Also have seen an issue with Xbox games/copy protection/encryption preventing successful runs of games after wimapply. Again if the games in question were installed before a certain date - the issue does not occur - but fresh installs result in some encrypted files created by Xbox, and ta ta, game breaks.
On that note, wouldn't the NTFS encrypted files Xbox creates be excluded automatically by wimlib anyways?