Windows 8.1 Won't get updates in audit mode.

I just installed Windows 8.1 in a Hyper-V virtual machine. The release version that was distributed through msdn not the preview. I enter audit mode as soon as I can, so there have been no changes or customization applied to the install prior to entering audit mode. I start up windows update to search for new updates. The status is displayed as "Checking for updates..." "Most recent check for updates: Never." "Updates were installed: Never." The status never changes from "Checking for updates...". I have even left it running over night and it still says "Checking for updates...". There is never any error message or failure. Network connectivity is functional. I have attempted an install on a physical machine as well with the same result. If instead of entering audit mode a proceed through setting up windows and a user account, updates will work just fine. There should be an update to defender as well as an update to ie11.

I considered the possibility of a corrupt download so I compared the sha-1 hash to what is listed on the msdn download page and it does match.

 
September 24th, 2013 4:10pm

Windows Update for Windows 8.1 installed on a VM will come online on October 18, 2013, the date of Windows 8.1"s general availability.
Free Windows Admin Tool Kit Click here and download it now
September 24th, 2013 4:31pm

I would have assumed the same thing except as I indicated above updates do work when not in audit mode. I get an update for defender and there was an update to flash player for internet explorer 11. KB2267602, KB2880289, and KB2859675 are listed. Again these updates are not available only when in audit mode. The problem here is not the availability of windows updates.
September 24th, 2013 5:21pm

Also our WSUS server finds several updates for 8.1. So the updates are definitely "live" prior to general availability.
Free Windows Admin Tool Kit Click here and download it now
September 24th, 2013 7:41pm

I'm experiencing exactly the same issue here.
October 8th, 2013 10:33am

Please see this thread for a workaround.

http://social.technet.microsoft.com/Forums/en-US/afc7f693-f742-402f-b513-063989b79c2f/windows-81-enterprise-windows-updates?forum=w8itproinstall

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2013 1:49pm

Please see this thread for a workaround.

http://social.technet.microsoft.com/Forums/en-US/afc7f693-f742-402f-b513-063989b79c2f/windows-81-enterprise-windows-updates?forum=w8itproinstall

October 8th, 2013 4:49pm

Quoted from http://social.technet.microsoft.com/Forums/en-US/afc7f693-f742-402f-b513-063989b79c2f/windows-81-enterprise-windows-updates?forum=w8itproinstall.  Emphasis added.

Thank You for sharing the logs. I was able to reproduce the issue in my virtual environment. To understand more about this behavior, I engaged the Product Group and I have been informed that this behavior is By Design. WU uses the OOBEComplete() Windows API call to determine whether OOBE is in progress or not, and if so, it will not perform automatic or UI update searches. HRESULT code 0x8024a008 is the WU error code WU_E_AU_OOBE_IN_PROGRESS. WU automatic and UI updates wont run while Setup reports that OOBE is still in progress. This is to prevent automatic updates from causing a system reboot during OOBE, which is needless to say a Very Bad Thing. This problem has always existed. Unfortunately, when the computer is in Sysprep audit mode, Setup will report to WU that OOBE is in progress even though it might not actually be so. This is the reason that updates from WU UIs are blocked in audit mode.

 

I was having the same exact issue when creating an updated WDS image for deployment to select end-users for testing.  At first, I thought I was doing something wrong.  This process--having a VM boot into audit mode so that it can be fully updated with Windows Updates along with new and updated third-party applications so to become the baseline/template for deployment--has worked wonderfully since the Vista days.  And it worked perfectly with Windows 8.  Why did Microsoft choose to deprecate the functionality is beyond me.

Its bad enough there is so very little traction in the corporate/Gov't world for Windows 8/8.1.  Now it seems that Microsoft, once again, is hades bent on destroying all that was good with Windows.

This is to prevent automatic updates from causing a system reboot during OOBE, which is needless to say a Very Bad Thing.

So this was a problem?  Really?  I don't ever recall that happening to me or ever reading about such an issue.  Even if this "issue" was a problem, why not just add another switch to the sysprep command to allow admins to specify the allowance of updates.  Something like like sysprep /oobe /audit /AllowUpdates?  Is that too hard or too much to ask?

So now with the current Windows-won't-update-in-audit-mode default, if I chose to deploy over 200 Windows 8.1 Enterprise clients, I now have to have ALL 200 machines contact Microsoft Update or my internal WSUS (or push via Shavlik) for updates.  Regardless of which method is used, the result is that 200 COMPUTERS must consume valuable network bandwidth for updates.  Not to mention there is always several machines that never act right.  Instead of having 200 identically configured machines, I end up with 200 similarly configured machines.

Exactly who is making these decisions?  Has anyone experienced the OOBE update issue that Microsoft claims is such a problem?

So disappointing.


  • Edited by DarienHawk67 Saturday, October 26, 2013 2:56 PM Spelling
Free Windows Admin Tool Kit Click here and download it now
October 26th, 2013 2:55pm

Quoted from http://social.technet.microsoft.com/Forums/en-US/afc7f693-f742-402f-b513-063989b79c2f/windows-81-enterprise-windows-updates?forum=w8itproinstall.  Emphasis added.

Thank You for sharing the logs. I was able to reproduce the issue in my virtual environment. To understand more about this behavior, I engaged the Product Group and I have been informed that this behavior is By Design. WU uses the OOBEComplete() Windows API call to determine whether OOBE is in progress or not, and if so, it will not perform automatic or UI update searches. HRESULT code 0x8024a008 is the WU error code WU_E_AU_OOBE_IN_PROGRESS. WU automatic and UI updates wont run while Setup reports that OOBE is still in progress. This is to prevent automatic updates from causing a system reboot during OOBE, which is needless to say a Very Bad Thing. This problem has always existed. Unfortunately, when the computer is in Sysprep audit mode, Setup will report to WU that OOBE is in progress even though it might not actually be so. This is the reason that updates from WU UIs are blocked in audit mode.

 

I was having the same exact issue when creating an updated WDS image for deployment to select end-users for testing.  At first, I thought I was doing something wrong.  This process--having a VM boot into audit mode so that it can be fully updated with Windows Updates along with new and updated third-party applications so to become the baseline/template for deployment--has worked wonderfully since the Vista days.  And it worked perfectly with Windows 8.  Why did Microsoft choose to deprecate the functionality is beyond me.

Its bad enough there is so very little traction in the corporate/Gov't world for Windows 8/8.1.  Now it seems that Microsoft, once again, is hades bent on destroying all that was good with Windows.

This is to prevent automatic updates from causing a system reboot during OOBE, which is needless to say a Very Bad Thing.

So this was a problem?  Really?  I don't ever recall that happening to me or ever reading about such an issue.  Even if this "issue" was a problem, why not just add another switch to the sysprep command to allow admins to specify the allowance of updates.  Something like like sysprep /oobe /audit /AllowUpdates?  Is that too hard or too much to ask?

So now with the current Windows-won't-update-in-audit-mode default, if I chose to deploy over 200 Windows 8.1 Enterprise clients, I now have to have ALL 200 machines contact Microsoft Update or my internal WSUS (or push via Shavlik) for updates.  Regardless of which method is used, the result is that 200 COMPUTERS must consume valuable network bandwidth for updates.  Not to mention there is always several machines that never act right.  Instead of having 200 identically configured machines, I end up with 200 similarly configured machines.

Exactly who is making these decisions?  Has anyone experienced the OOBE update issue that Microsoft claims is such a problem?

So disappointing.


  • Edited by DarienHawk67 Saturday, October 26, 2013 2:56 PM Spelling
October 26th, 2013 5:55pm

Couldn't agree more with Darien. We utilize several virtual computers for reference comptuers for MDT. We update the images quarterly, snapshot the machines, capture, and then revert to allow us to do so again next quarter.

This designed behavior is going to cause exactly the issue Darien reported. Each deployment is going to have to use LAN/WAN traffic to update each and every time a new PC is deployed. Doesn't make a lot of sense.

Free Windows Admin Tool Kit Click here and download it now
October 28th, 2013 10:55pm

Hello,

I think I may have found a easy workaround.

The old System Builder Bypass Tool seems to work fine in Windows 8.1!

You can download it from here;

http://www.microsoft.com/oem/en-gb/installation/downloads/Pages/system_builder_bypass.aspx#fbid=0en0pM4ljU_


It was originally designed for bypassing the Windows Genuine Advantage in XP so you could still do updates before activation.

PLEASE NOTE:
This software was not designed for this purpose, I have only run some initial tests confirm that it works. There may be unknown future issues.

October 29th, 2013 4:56am

I have been fighting the same issue as everyone else.

I believe I found a work around that seems to be working for me. I installed a PowerShell module that does windows updates.

http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc

1.)  Copy the whole module folder (after unzipping) to %WINDIR%\System32\WindowsPowerShell\v1.0\Modules

2.) Start up PowerShell ISE as admin from admin tools

3.) Set-ExecutionPolicy RemoteSigned

4.) Import-Module PSWindowsUpdate

5.) Get-WUInstall

6.) The rest should be automated with some prompts

After Reboot

Hope this helps.


  • Edited by HenkelsGuy5 Tuesday, October 29, 2013 7:46 PM Spelling
  • Proposed as answer by -HermanW- Monday, December 01, 2014 10:27 AM
Free Windows Admin Tool Kit Click here and download it now
October 29th, 2013 6:46pm

I have been fighting the same issue as everyone else.

I believe I found a work around that seems to be working for me. I installed a PowerShell module that does windows updates.

http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc

1.)  Copy the whole module folder (after unzipping) to %WINDIR%\System32\WindowsPowerShell\v1.0\Modules

2.) Start up PowerShell ISE as admin from admin tools

3.) Set-ExecutionPolicy RemoteSigned

4.) Import-Module PSWindowsUpdate

5.) Get-WUInstall

6.) The rest should be automated with some prompts

After Reboot

Hope this helps.


  • Edited by HenkelsGuy5 Tuesday, October 29, 2013 7:46 PM Spelling
October 29th, 2013 9:46pm

Might you can help me with this, because I'm stuck.

I followed the steps you put down:

1.)  Copy the whole module folder (after unzipping) to %WINDIR%\System32\WindowsPowerShell\v1.0\Modules

2.) Start up PowerShell ISE as admin from admin tools

3.) Set-ExecutionPolicy RemoteSigned

4.) Import-Module PSWindowsUpdate

5.) Get-WUInstall

But I'm getting no answer from the commands what so ever.

At step 3 I get to chose yes, no or suspend.

But at step 4 where you get to see all the files in that module, I'm getting nothing but a new command line.

Are you familiar with this problem?

Kind Regards,

Bas

Free Windows Admin Tool Kit Click here and download it now
November 25th, 2013 5:17pm

-Bas

You should select Yes to the Set-ExecutionPolicy RemoteSigned prompt. Also make sure you are running as an Admin.

Some members have reported that they needed to first unblock the zip file BEFORE extracting the files. This  can be done by first copying the zip file to the local computer. Go to the zip file properties and select unblock, then Apply.

Another member reported that they needed to drop the module into C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules

Hope this helps.

November 25th, 2013 6:19pm

None of these things helped really.

Tried with a clean windows install and press CTRL-SHIFT-F3 before OOBE to get into audit mode as Administrator.

Downloaded the zip file on the system that's in audit mode (also downloaded the zip file on an other pc, not that it makes much difference), unblocked it, copied the module to C:\Windows\System32\WindowsPowerShell\v1.0\Modules (also tried in C:\Windows\SysWOW64\WindowsPowerShell\V1.0\Modules). Run PowerShell ISE as Administrator.

Executed the commands:

ExecutionPolicy RemoteSigned : Y

Import-Module PSWindowsUpdate: No Answer

Get-WUInstall: No Answer

Something I done wrong here?

Kind Regards,

Bas

Free Windows Admin Tool Kit Click here and download it now
November 25th, 2013 7:54pm

I had to CD into the C:\Windows\System32\WindowsPowerShell\v1.0\Modules directory to get the import to work.

November 27th, 2013 7:46pm

After turning off UAC this worked for me.
Free Windows Admin Tool Kit Click here and download it now
December 16th, 2013 12:13am

Excellent!  This works like a charm
December 31st, 2013 8:27pm

Thanks for your solution that it's very useful. 

I've put Set-ExecutionPolicy RemoteSigned in restrited after. 

I think that it's imporant. What do you

Free Windows Admin Tool Kit Click here and download it now
February 6th, 2014 3:32am

Thanks very much for putting this up, worked fine for me after I did a CD into the C:\Windows\System32\WindowsPowerShell\v1.0\Modules directory and ran the import.
June 13th, 2014 10:46am

This is a good work around but you will need to do all the next Windows update the same way after, in my case the Windows update continue to look for update forever.

What i found is at the beginning during the installation, at one point it say "Finalizing your settings", for an unknow reason it never finish and the computer have been restarted.

I think that both issue are related, i have reinstall from scratch (Since it was a new installation) and now everything is fine (I can do my update, no audit, etc).

Free Windows Admin Tool Kit Click here and download it now
June 27th, 2014 3:56pm

I used this program called portable update to install updates in windows 8.1 audit mode. Its a portable program that will download and install updates for you and you can remove the portable folder afterwards. here is the link for it http://www.portableupdate.com



  • Edited by Mike K Y Saturday, September 06, 2014 1:13 AM
September 6th, 2014 12:53am

How do we get updates for other Microsoft products other than Windows?
Free Windows Admin Tool Kit Click here and download it now
October 16th, 2014 7:48am

First off I do like this solution and appreciate your providing it.

I am having no luck with this.  I receive no reply when running the Get-WUInstall.  I have unblocked the zip before extraction. Ran execution policy as unrestricted.  Put in SysWOW64 powershell module directory as well as the system32 powershell module directory.  Changed directory to both of these. Ran powershell as admin with both ISE an ISE x86 and ISE.  Any ideas?

December 11th, 2014 5:51pm

This powershell module is great! One thing to note thou; If you have Office or other Microsoft products installed while in audit mode the powershell module doesn't find or install updates for office by default! You need to first turn on autoupdate and select "give me updates for other Microsoft products when I update Windows". After setting these Get-WUInstall powershell gives all Office and other updates.

One hint about Get-WUInstall ... add -verbose at the end of the command and you have better feedback about the command.
Free Windows Admin Tool Kit Click here and download it now
May 13th, 2015 5:28am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics