Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, April 18, 2019 2:05 AM
Window version : Windows 10 1903 (18362.30)
I run the "sysprep" program with administrator but it doesn't work. I check the log file which show the error :
2019-04-18 09:53:28, Error SYSPRP Sysprep_Clean_Validate_Opk: Audit mode can't be turned on if there is an active scenario.; hr = 0x800F0975
2019-04-18 09:53:28, Error SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'Sysprep_Clean_Validate_Opk' from C:\Windows\System32\spopk.dll; dwRet = 0x975
2019-04-18 09:53:28, Error SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Cleanup.xml; dwRet = 0x975
2019-04-18 09:53:28, Error SYSPRP RunPlatformActions:Failed while validating Sysprep session actions; dwRet = 0x975
2019-04-18 09:53:28, Error [0x0f0070] SYSPRP RunDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x975
2019-04-18 09:53:28, Error [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep cleanup internal providers; hr = 0x80070975
2019-04-18 09:53:30, Info [0x0f0052] SYSPRP Shutting down SysPrep log
2019-04-18 09:53:30, Info [0x0f004d] SYSPRP The time is now 2019-04-18 09:53:30
I also run the Powershell to clean the package before run the sysprep
"Get-AppxPackage -AllUsers | Remove-AppxPackage"
Please help me !
All replies (38)
Friday, April 26, 2019 7:56 AM ✅Answered | 10 votes
Thanks God !
The problem has been solved. According the log file, "Sysprep_Clean_Validate_Opk" is from C:\Windows\System32\spopk.dll. I try to replace the "spopk.dll" from another Windows 10 (nor 1903). The sysprep is working.
I compare the two versions "spopk.dll". The file size is not same. I think Microsoft had modified the file.
Friday, April 19, 2019 6:38 AM
Hi,
Please understand that from our professional level, we do not provide log analysis. But from my personal point of view, I still hope to do my best to help you analyze. In addition, if this problem is more urgent for you I still recommend that you open a case to Microsoft for further professional help.
Before we start fixing this issue, I’d like to confirm that what’s the Sysprep scenario, Creating a Build-to-Plan (BTP) Windows Image, Creating a Build-to-Order (BTO) Windows Image or Booting to Audit Mode?
Meanwhile, please note Sysprep has the following limitations:
1. You must use only the version of Sysprep that is installed with the Windows image that you intend to configure. Sysprep is installed with every version of Windows and must always be run from the %WINDIR%\system32\sysprep directory.
2. Sysprep must not be used on upgrade installation types. Run Sysprep only on clean installations.
3. If you plan to use the imagex /apply command to apply a Windows image to a computer, the partition layout on the reference and destination computers must be identical.
For more information, please read this official document: /en-us/previous-versions/windows/it-pro/windows-vista/cc721940(v=ws.10)
In addition, here is a similar link just for your reference:
How to Fix Sysprep was not able to validate your Windows installation".
https://www.wintips.org/fix-sysprep-not-able-validate-windows-installation/
Note: This is a third-party link and we do not have any guarantees on this website. And Microsoft does not make any guarantees about the content.
Hope these are helpful. If you have any question, please feel free to let me know.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
Monday, April 22, 2019 9:04 AM
Hi,
Was your issue solved?
If yes, would you like to share your solution in order that other community members could find the helpful reply quickly.
If no, please reply and tell us the current situation in order to provide further help.
Best
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
Thursday, April 25, 2019 8:03 AM
Hi,
Thank you for your reply.
I have follow the above suggestion but the problem has not been solved. I can't find any solution on internet because it is a new windows version (1903).
Anyway, Could you tell me how to open the case in Microsoft Support ?
Regards !
Andrew
Tuesday, May 21, 2019 8:55 AM | 1 vote
UPDATE: Now resolved after installing the Cumulative Update of 05 2019
ASEBB
Wednesday, May 29, 2019 12:19 PM | 1 vote
Worked perfectly for me on a new 1903 image. Changed ownership of spopk.dll to administrators, gave full permissions, renamed to .old and replaced the file from my current 1809 machine. Sysprep worked fine and is creating my WIM now.
Thursday, May 30, 2019 4:56 PM | 1 vote
Thank you sooo much! I copied the spopk.dll file from a computer running Win10 ver 1809 and it worked beautiful!
Thursday, May 30, 2019 8:32 PM
UPDATE: Now resolved after installing the Cumulative Update of 05 2019
ASEBB
This update did the trick! Thanks for posting!
Friday, May 31, 2019 11:10 AM
UPDATE: Now resolved after installing the Cumulative Update of 05 2019
ASEBB
I installed this update and still failed. Replacing the SPOPK.DLL did the trick for me
Friday, May 31, 2019 11:11 AM
Thanks God !
The problem has been solved. According the log file, "Sysprep_Clean_Validate_Opk" is from C:\Windows\System32\spopk.dll. I try to replace the "spopk.dll" from another Windows 10 (nor 1903). The sysprep is working.
I compare the two versions "spopk.dll". The file size is not same. I think Microsoft had modified the file.
Many thanks for posting the solution. I was pulling my hair out on this issue :-)
Monday, June 3, 2019 4:31 PM
Thanks God !
The problem has been solved. According the log file, "Sysprep_Clean_Validate_Opk" is from C:\Windows\System32\spopk.dll. I try to replace the "spopk.dll" from another Windows 10 (nor 1903). The sysprep is working.
I compare the two versions "spopk.dll". The file size is not same. I think Microsoft had modified the file.
This fixed my issue as well. I was using Dell Image Assist (uses Sysprep) to take my image and I was getting the same error in the setupact.log. Running the May update didn't make a difference for me.
As an additional note you need to take ownership of the spopk.dll file and grant permissions to replace the file.
Take ownership of the file:
takeown /f C:\Windows\System32\spopk.dll
Grant ability to modify file:
icacls C:\Windows\System32\spopk.dll /Grant Administrators:f
Wednesday, June 5, 2019 10:11 AM
I had the same problem - replacing the SPOPK.DLL with a previous version (1809) allows the sysprep to run.
(The only thing is to be able to access the faulty one you need to take ownership of the file and then drop the security - I did it all the way down to "Everyone Full control" - low enough to remove it.
Friday, June 7, 2019 3:03 PM | 1 vote
The Windows product team is following this thread and wanted to relay the following points
This failures means that an update from WU is currently using reserved storage. Audit mode cannot be entered while reserves are in use. More information on reserved storage is available @
This issue should NOT be worked around by copying binaries from other OS releases
Restricting WU updates is a temporary way to circumvent this problem.
PG is reviewing this issue and will post an update as to how to better handle this issue.
Good if you could share EXACT steps to repro this issue.....
Friday, June 7, 2019 4:03 PM | 8 votes
Ran into the same sysprep error in the logs when I used MDT to capture a newly built v1903 disk image. The CU5-2019 update was already installed from applying all Windows Updates before the capture. Didn't want to resort to copying the spopk.dll file from the previous v1809 installation or make manual permissions to the existing file just yet, so I tried simply toggling the new "Pause Updates for 7 days" option before running the MDT capture sequence and MDT ran through the sysprep process and disk capturing sequence without a hitch.
Sunday, June 9, 2019 8:54 AM
i had installed CU5 (KB4497935) , and the problem is still the same.
and after installed the CU5, my spopk.dll version is 10.0.18362.1 ,the Date of the dll is 2019/03/19 12:44...
it seems the file is not replace by the CU5...but the winver is 18362.145 now
Monday, June 10, 2019 1:07 AM | 1 vote
Pausing updates temporarily (and then resuming) worked for me... once. And now I can't get it to work again, unfortunately, after multiple attempts. But definitely worth a shot for anyone running into this issue.
Sunday, June 23, 2019 12:50 PM | 1 vote
Hello!
The key here may be to be absolutely doubly certain that all updates have processed.
I had this issue also, system was (so I believed) fully up-to-date with June Cumulatives (it had just rebooted from that install). However, the sysprep failed with the error mentioned in these posts.
I reverted my VM to pre-sysprep stage and checked for updates, based on your comment about "An active WU scenario". A Defender Definition update came through. I then executed my pre-sysprep routine and sysprepped. The sysprep dialog went away - where the system usually shuts down - but never did. I'm writing that off to cosmic radiation (can't you guys harden the OS against that? ;-)
Anyway, I reverted again, installed the Defender update again, and sysprep went smoothly. So while pausing updates sounds like a possible solution, it might be that there is at least one more update in the pipe, which would often be the case just prior to a sysprep when you've got a machine being brought up to date from a base image of some sort.
Thank you to the product team for monitoring these posts. I don't suppose it would be viable to have a button to 'clear reserved storage' specifically for situations like sysprep (or even part of the sysprep execution)? If that meant that whatever update was in an 'active scenario' just had to be discovered again, I think that would be preferable. Of course, if it broke an in-progress update, I guess that wouldn't be so good!
Wednesday, July 3, 2019 7:52 PM
Worked for me.
Friday, August 16, 2019 8:59 AM | 1 vote
Nothing worked for me. This image worked fine in July, but after update to August 13, 2019—KB4512508 (OS Build 18362.295)
it came with this error ( Sysprep_Clean_Validate_Opk: Audit mode can't be turned on if there is an active scenario.; hr = 0x800F0975 ) - how MORE CRYPTIC these messages can get?
All updates are definitely done. Suspending WU makes zero difference
Replacing the .dll from 1809 RS5 171763.292 15/02/2019 did the trick
Seb
Friday, August 16, 2019 4:43 PM
This worked for me as well. After this fix I had to uninstall about a handful of packages as well. Which wasn't a big deal. Once I got through all this it's working 100%. THANK YOU!
Windows 10 ver 1903 Version 10.0.18362.295
Had to give the account I was using full access to c:\windows\system32 renamed spopk.dll to spopk.old
Used spopk.dll from Windows 10 ver 1809 Version 10.0.17763.615.
spopk.dll ver that didn't work - 10.0.18362.1
spopk.dll ver that DID work - 10.0.17763.292
"In victory, be humble. In defeat, be strong. In all things be fair." - Hu Lee
Friday, August 16, 2019 9:01 PM
No need to mess with permissions, just use nsudo.
I user 7-zip FM running as TruestedInstaller (way easier) for any replacements (like that one)
Wednesday, August 21, 2019 3:44 PM
Worked for me, thanks.
Wednesday, August 21, 2019 4:34 PM
Perfect! The same worked for me also. Thanks
Thursday, September 12, 2019 3:23 PM
Thank you! Replacing the .dll file from 1809 did the trick as well!
Wednesday, October 2, 2019 2:19 PM
trying to run sysprep on freshly installed and fully patched W10 1903,
getting the "famous" error discussed here:
SYSPRP Sysprep_Clean_Validate_Opk: Audit mode can't be turned on if there is an active scenario.; hr = 0x800F0975
FROM one of the post above:
The Windows product team is following this thread and wanted to relay the following points
This failures means that an update from WU is currently using reserved storage. Audit mode cannot be entered while reserves are in use. More information on reserved storage is available @
This issue should NOT be worked around by copying binaries from other OS releases
Restricting WU updates is a temporary way to circumvent this problem.
PG is reviewing this issue and will post an update as to how to better handle this issue.
What is the real solution, if dll replacing is not a "solution" that fixing the prob?
When you hit a wrong note its the next note that makes it good or bad. Miles Davis
Saturday, October 5, 2019 3:03 PM
Obviously nothing,
Anyway, it should be only for:
This feature is available to Windows Insiders running Build 18298 or newer.
I do not run any insider build!
Friday, October 25, 2019 8:02 PM
Thank you for this, worked perfectly with 1903 fully updated with latest October update.
Tuesday, November 12, 2019 9:02 PM
So I'm reading multiple answers that work for some people and not for others. Can someone from Redmond give us the definitive answer?
And what do those of us who have no Windows 10 1809 installations do?
Ken Carter
Tuesday, November 12, 2019 9:18 PM
I finally got SYSPREP to work but I had to reboot my PC three times to ensure that all of the October Windows Updates were fully installed.
Ken Carter
Friday, November 29, 2019 2:42 PM
Had the same problem.
As I work on virtual workstations when creating a golden image I traced some snapshots back. Turns out, originally the file is fine, but some update obviously messes it up.
As long as Microsoft is not willing to acknowledge the problem the only remaining choice is to copy a working DLL from an earlier installation or version.
Makes me wonder how long this will work, though.
Tuesday, December 3, 2019 12:04 PM
I stopped this error by running disk clean-up.
Wednesday, December 11, 2019 5:49 AM
Pausing updates fixed the issue for me. Replacing spopk.dll did not.
Thursday, December 12, 2019 1:26 PM
Pausing the updates for 7 days did the trick on build 1909 as well.
Thursday, January 16, 2020 5:51 PM
Your comment about making doubly sure that all updates have in fact finished running was true for me, as well. I was getting this exact same sysprep error about there being an "active scenario" (not the much more common "app not provisioned for all users", which I already take care of by removing provisioning.)
I reverted my capture vm back to pre-sysprep attempt, tried running windows update one more time, and sure enough, there was some sort of security definition trying to install. Once that finished, I clicked the update button a few more times just to be sure, and nothing else came through. Then I checkpointed again, and this time when I tried, sysprep completed with no problems. No messing about with the spopk.dll was necessary at all. So I guess, the moral of the story is, always check your updates! :)
(This was Windows 10 version 1909 by the way, and I am also using Dell ImageAssist for capture.)
Friday, January 31, 2020 1:12 AM
Worked for me on 1909 image!
Saturday, February 1, 2020 1:07 PM
Pausing updates fixed the issue for me. Replacing spopk.dll did not.
Totally OPPOSITE. Pausing updates does nothing, replacing the dll is the only way Sysprep does work!
Wednesday, February 5, 2020 11:10 PM
The Windows product team is following this thread and wanted to relay the following points
This failures means that an update from WU is currently using reserved storage. Audit mode cannot be entered while reserves are in use. More information on reserved storage is available @
This issue should NOT be worked around by copying binaries from other OS releases
Restricting WU updates is a temporary way to circumvent this problem.
PG is reviewing this issue and will post an update as to how to better handle this issue.
Good if you could share EXACT steps to repro this issue.....
Can confirm this works on the latest updates of 1909. Simply going into the Settings and Pausing the updates for 1 day did the trick. Thank you for the post!
Thursday, February 6, 2020 11:25 PM
For me to, 1909. Give file ownership to the local administrators group, and replace the file