Windows 10 Update (any 4GB version) and Cannot empty

Running these updates to update Windows 10 to the next version seem to be problematic. I would gather due to the 4+GB ISO file that has to be dealt with.

In this case, we are using the “Windows 10 Enterprise Version 1703 Available - Windows 10 (x64) (English (United States))” fixlet.

Since it take so long, we figured we would only display a Post-Action message, saying that we’re going to update Win10 and to reboot to kick off the process (the install setup.exe has already run).

However, the reboot message never pops up and I think it is because when the initial process finishes, the error below appears and goes into a loop. I’m guessing that because of this, the Post-Action message is never displayed. I’ve seen this on the two different systems I’ve tested on.

The status in the Console is “Pending Restart” yet my Post-Action message isn’t showing.

Update: I noticed that the ISO is still mounted, which means that the setupcomplete.cmd isn’t running and therefore the task isn’t finishing? Only the setupcomplete.cmd is no where to be found.

Any thoughts?

At 09:52:27 -0400 - 
   ActionLogMessage: (action:77401) Cannot empty _Download directory
1 Like

UPDATE: In addition to what I mentioned above, the updates have been failing (getting to 90%+ and restoring back). I figured that was a separate issue to deal with. Again, we’re talking several installs to a VM; reverting to the snapshot afterwards.

To test my theory about the ISO still being mounted, I deployed to the same VM changing the action script.

setup.exe /auto upgrade /Quiet /DynamicUpdate disable /noreboot /postoobe “{pathname of client folder of current site & “\setupcomplete.cmd”}”`

setup.exe /auto upgrade /Quiet /DynamicUpdate disable /noreboot

The job finished, and like always, the ISO stayed mounted (I guess this time it would as I think the postoobe script is supposed to unmount it) and the “Cannot empty” logs started streaming. No Post-Action pop-up.

I then dismounted the ISO manually (right-click, eject). The Post-Action prompt popped up and the “Cannot empty” stream stopped. I rebooted.

The bonus was that the upgrade finished successfully!

So something is up with the postoobe, which makes sense since the upgrade failures were near the 90%+ mark…

I opened up a PMR on the dismounting of the ISO not happening and was told it was a Microsoft bug… moving on…

I created my own fixlet using the “standard” method, basically zipping up the files within the ISO. A bit more overhead on the endpoint, since it has to uncompressed the files instead of just mounting an ISO. Things looked to have worked. No “Cannot empty” errors and my post-action worked. Unfortunately upon reboot, the upgrade made it as far as 0% before restoring back.

I next modified the fixlet to place the files in a C:\Win10-1703\tmp folder instead of within the standard BigFix file structure. I also choose NOT to delete the \tmp files when the fixlet completed (I have a feeling of a timing issue). The update completed successfully! We’ll test on additional systems of course, but at least we have a small win.

I did something similar but a bit less intrusive. If you read the IBM version of setupcomplete.cmd, they use a powershell command to unmount the iso. I used their existing actionscript, then appended the powershell to unmount the iso when thebscript is finished.

Come to think of it, you could probably just execute the setupcomplete.cmd as well.

That’s what it is supposed to already do in the IBM fixlet. It doesn’t perform the dismount.

I think I was unclear, or misreading the fixlet, or we’re talking about different fixlets.

For instance, Fixlet 1110593 Windows 10 Enterprise Version 1703 Available - Windows 10 (English (United States)) has this bit in it …

// Create the cleanup file.
delete __appendfile
delete setupcomplete.cmd

appendfile @echo off
appendfile SET WindowsISO="{parameter "workISO"}"
appendfile powershell.exe "Dismount-DiskImage ""%WindowsISO%"""
appendfile rmdir /S /Q "{parameter "workPath"}"

move __appendfile setupcomplete.cmd

The action script itself never executes setupcomplete.cmd to dismount the ISO, it relies on Windows Setup executing the setupcomplete.cmd. What I’m talking about is triggering the setupcomplete.cmd in the action script itself with a waithidden, so that the ISO would get dismounted even if Windows Setup doesn’t execute the setupcomplete.cmd.

The fact that Windows Setup itself isn’t executing the setupcomplete.cmd is a problem all its own. It should be running the setupcomplete. But I also saw instances where the setupcomplete.cmd did not execute, but if I manually unmount the ISO and reboot, it looks like the version update did occur.

Thanks. I think I understand…

The command it kicks off is below and you are saying that we’re relying on the /postoobe to run it. You are suggesting that we in fact remove the /postoobe switch and just run it ourselves in the Action Script. Am I understanding?

setup.exe /auto upgrade /Quiet /DynamicUpdate disable /noreboot /postoobe "{pathname of client folder of current site & "\setupcomplete.cmd"}"

I leave it in the /postoobe, but yes I do also run it again with a waithidden. Granted, I’ve only done a few systems since I’m still testing with build 1703, but I had enough similar failures on the earlier upgrades that I think I still need the workaround.

I think this is a problem with Windows Setup, but I can’t let it hang up the client to any following actions.

Just curious… Why use the ISO at all then if it seems more problematic than packaging its contents? Is it the additional time added in unzipping the contents?

I made a custom copy and added my own extra dismount command after a short pause, which seems to work most of the time:

wait mount.and.install.bat > “{parameter “workPath”}\cmd.log”

// added below

parameter “startTime”="{now}"
pause while { (now-time(parameter “startTime”) < 30*second) }

delete __appendfile
delete dismount.bat

appendfile @echo off
appendfile SET WindowsISO="{parameter “workISO”}“
appendfile powershell.exe “Dismount-DiskImage “”%WindowsISO%””"
appendfile rmdir /S /Q “{parameter “workPath”}”

move __appendfile dismount.bat

wait dismount.bat

// to here

// setup must finish with RC=0 at this stage if things are ok. If that is not the case content of C:"\win10_upgrade_temp dir holds useful info.
// Apart from log files, you can run upgradeCheck manually to check with the UI what the problem is.

Thanks. I’m going to stick with the way I have it now. It’s been pretty much rock solid.

Have any of you opened a PMR around this issue? It seems valid to open one to get this cleaned up in the content we provide

We did open a PMR. We were told it was a Microsoft bug.

Could you provide that PMR info? If you both are able to work around it in content it seems like a valid thing to push into our content to work around a bug

Yep… Was working on getting that. PMR 09577 442 000

I’ve pointed the patch team at this thread to have them evaluate the workarounds you have come up with for possible inclusion in the content.

Thanks all for reporting the issue and the discussion.

Can we know if this issue only be found with the Fixlets for Windows 10 Version 1703 or also previous other versions? We are currently verifying the workaround and will re-release the contents for Windows 10 Version 1703 after that.

In the meantime, please be noted that there is a new release of feature upgrade for windows 10 version 1703 recently. We are currently working on them and will post updates here when contents are released. Thanks!

The updated Windows 10 Version 1703 Fixlets are published to Patch for Windows version 2814. Please let us know if there are further enquiries.Thanks!

I have that site version:

Id: 20	Date: Wed, 09 Aug 2017 09:11:22 +0000	Version: 2815

But the release date on the fixlet hasn’t been updated. Shouldn’t it have?

ID 1100689 
Site Patches for Windows 
Category Upgrade 
CVE ID Unspecified 
Download Size 3.96 GB 
Source Microsoft 
Source ID Unspecified 
Source Severity Unspecified 
Source Release Date 4/5/2017

Hi @AlexaVonTess,

The source release date is the microsoft’s patch release date so that it won’t be updated in this case. Please let us know if you have any other concern. Thanks!