can i delete windows update folder after updating windows 7 ?

Replies (7) 

which windows update folder and how does this pertain to microsoft security essentials functionality? [1]

is system restore functioning properly now or. ?

[1] A Moderator has moved your thread from the Microsoft Security Essentials forum to the Win7-specific Windows Update forum.

Robear Dyer (PA Bear)
Microsoft MVP (Windows Client) since October 2002

1 person found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

which windows update folder and how does this pertain to microsoft security essentials functionality? [1]

is system restore functioning properly now or. ?

[1] A Moderator has moved your thread from the Microsoft Security Essentials forum to the Win7-specific Windows Update forum.

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

when windows 7 update automatically then stored folder is too large.

what «stored folder?»

Robear Dyer (PA Bear)
Microsoft MVP (Windows Client) since October 2002

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

You can rename Windows Software Distribution Folder. It will recreate itself.

Start > Type CMD

Right click on CMD and select Run As Administrator

Before your rename the folder you must stop the Windows Update service. Here is how:

• type net stop wuauserv and press enter
• type rename c:\windows\SoftwareDistribution to softwaredistribution.oldand press enter
• type net start wuauserv and press enter
• type exitand press enter

Once you restarted Windows Update service, go back and verify the new folder was created

How to change Windows 10 Updates download folder location

Running out of storage space is nothing new. Most of us have access to the internet and keep downloading stuff. Then there are games which can occupy a lot of storage space. The biggest problem arrives when you run of storage space on your Windows Installation drive which is usually the C drive, and the updates stop downloading. Windows OS doesn’t offer you an option to change the download location of the updates. In this post, we will learn to change Windows 10 Updates download location.

Change Windows 10 Updates download location

Before you begin, you should know that you will need to have administrator privileges to complete this. If you have a regular account, it’s a good idea to get in touch who had set up your PC and take his help.

The default location of Windows Update is C:\Windows\SoftwareDistribution. The SoftwareDistribution folder is where everything gets downloaded and later installed.

Prepare a new directory for the system to download the Windows Update

Create a target directory in a drive other than C drive. It can be named as WindowsUpdateDownload for easy reference. Let’s assume that the path is D:\WindowsUpdateDownload

Next, use Ctrl+Alt+Delete to launch the Task Manager and switch to Services tab, and then right-click on wuauserv, and stop it.

Now rename C:\Windows\SoftwareDistribution to C:\Windows\SoftwareDistribution.old

Create Symlink

To create a symlink, in the start menu, search for CMD or command prompt. Right-click on it, and run it as administrator. Then type the below-mentioned command then hit Enter:

This will make Windows Update start the downloading files from zero to this new location.

In case it doesn’t work, you can try to boot Windows 10 in Safe Mode to get this done.

Restart Windows Update Service

After this, you need to start the Windows Update Service. You can either use the Task Manager to start it like we did above or execute the following command in CMD:

Check if Windows Update is working

Go to Settings > Update and Security > Windows Update > Check for Update. If it starts downloading an update or does not throw any error, you are all set.

Here is an interesting fact, after downloading the Windows Update, the OS unpacks it in the drive which has the freest space available and installs from there. Windows will clear the content of this directory from time to time.

We recommend you to use a storage space which usually remains empty. While you can choose an SD card (NTFS format) or an external drive, we recommend not to unless it always stays connected to the PC.

Date: May 15, 2018 Tags: Windows Updates

Related Posts

Windows 10 Show Hide Updates Tool wushowhide.diagcab download link broken

One of the update services is not running properly in Windows 10

Windows 10 Feature Update failed to install, Error 0x8007371b

[email protected]

Ashish is a veteran Windows, and Xbox user who excels in writing tips, tricks, and features on it to improve your day to day experience with your devices.

Delete Downloaded Windows Update Files in Windows 10

How to Delete Downloaded Windows Update Files in Windows 10

If you are running into issues with Updates, you can try to delete downloaded Windows Update files. When an update package is damaged or fails to install, Windows 10 may keep the corrupted file on the drive, so it will further cause issues with updates. Here is how to delete the downloaded Windows Update files that Windows 10 doesn’t delete itself.

Windows 10 checks for updates automatically unless you disable this feature manually. The operating system comes with the Windows Update service, which automatically downloads and installs the updates from Microsoft. The downloaded update files are stored on your system drive in the C:\Windows folder.

There are certain reasons for having corrupted Windows Update files. It can be an improper shutdown, OS crash, power failure, or something gone wrong with your Registry. After that, Windows Update may fail to do its job properly. The OS may fail to check for updates, or fail to install them. Sometimes, the Windows Update page in Settings cannot be opened!

To fix most of the Windows Update issues in Windows 10, usually it is enough to run the built-in Windows Update troubleshooter.

Run the built-in Windows Update troubleshooter.

1. Open the Start menu and type: troubleshooting and press Enter.
2. Click «Windows Update».
3. Click «Run as administrator» in the Troubleshooter’s dialog and complete the Windows Update troubleshooter. See if Windows Update works properly.

When you run into issues though with updates, you may spend hours or even days figuring out what is going wrong. In such case, you can try to delete downloaded Windows Update files to start over. The SoftwareDistribution folder contains files related to updates obtained via Windows Update, it is present on all versions of Windows. It could have a couple of hundreds megabytes of size. But if this folder is much larger, this indicates that some updates are corrupted.

To Delete Downloaded Windows Update Files in Windows 10,

1. Press Win + R on the keyboard and type services.msc in the Run box.
2. Stop the service named Windows Update.
3. Open File Explorer .
4. Go to C:\WINDOWS\SoftwareDistribution\Download. Copy-paste this path to the explorer’s address bar.
5. Select all files of the folder(press the Ctrl-A keys).
6. Press the Delete key on the keyboard.
7. Windows may request for administrator privileges to delete those files. Turn on the option «Do this for all current items» in the dialog and click on Continue.

Restart Windows 10 and check for updates. See if this fixed your issues.

Alternatively, you can create a batch file to automate the process.

Delete Downloaded Windows Update Files with a Batch File

1. Open Notepad.
2. Paste the following text:
   net stop wuauserv
   cd /d %SystemRoot%\SoftwareDistribution
   del /s /q /f Download
   net start wuauserv
3. Save it to a file with a *.cmd extension. You can place it on the Desktop.
4. Right-click the file you have created and start it as Administrator from the context menu.

You are done. Now restart the PC and check for available updates.

Here’s how does it work

The command net stop wuauserv stops the Windows Update service. Next, the cd command switches the current folder to C:\Windows\SoftwareDistribution. The del command erases the contents of the Download folder and its subfolders. Finally, the last command, net start wuauserv , starts the Windows Update service again.

To save your time, you can download this ready-to-use batch file.

Articles of interest:

Winaero greatly relies on your support. You can help the site keep bringing you interesting and useful content and software by using these options:

Share this post

About Sergey Tkachenko

Sergey Tkachenko is a software developer from Russia who started Winaero back in 2011. On this blog, Sergey is writing about everything connected to Microsoft, Windows and popular software. Follow him on Telegram, Twitter, and YouTube.

5 thoughts on “ Delete Downloaded Windows Update Files in Windows 10 ”

i haven’t noticed this before but Also disk clean-up has an option to delete update files also,

AFAIK it cleans up WinSxS instead.

Hi Sergey, Is any chance to fix loop booting PC after Windows OS updates without reinstalling OS ?

Windows folder update files

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Windows Update (and for all I know other MS Update services) appears to download to a temporary folder in the root of the drive with the most free space at the time of the download.

This may be OK for the average PC but is not good practise on servers where the drive with the most free space may be on a SAN or on a non-NTFS formatted drive.

Is there any way of steering the Update service to restrict itself to local drives or even better to specify an exact path for the temporary download folder.

I have been searching the internet for an answer to this but so far drawn a blank. I’m hoping this might be the forum with an answer.

• Moved by Stephen Boots MVP Thursday, March 18, 2010 5:46 PM not MSE, OS not specified (From:Microsoft Security Essentials: Updating Virus and Spyware Definitions)
• Moved by Mike — Support Engineer Microsoft Support Monday, March 22, 2010 3:43 PM Move to correct forum (From:Windows Update)

Answers

Windows Update (and for all I know other MS Update services) appears todownload to a temporary folder in the root of the drive with the most free space at the time of the download.

This may be OK for the average PC but is not good practise on servers where the drive with the most free space may be on a SAN or on a non-NTFS formatted drive.

Is there any way of steering the Update service to restrict itself to local drives or even better to specify an exact path for the temporary download folder.

I have been searching the internet for an answer to this but so far drawn a blank.

All replies

You’d be much better off posting in the appropriate Windows Server forum, Bill: http://social.technet.microsoft.com/forums/en-US/category/windowsserver/

Robear Dyer (PA Bear)

MS MVP (IE, Mail, Security, Windows & Update Services) since 2002

Disclaimer: MS MVPs neither represent nor work for Microsoft

Windows Update (and for all I know other MS Update services) appears todownload to a temporary folder in the root of the drive with the most free space at the time of the download.

This may be OK for the average PC but is not good practise on servers where the drive with the most free space may be on a SAN or on a non-NTFS formatted drive.

Is there any way of steering the Update service to restrict itself to local drives or even better to specify an exact path for the temporary download folder.

I have been searching the internet for an answer to this but so far drawn a blank.

As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios.

If the issue still persists and you want to return to this question, please reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish.

In addition, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.

Ok, I fully understand that this is the wrong place to look for an answer, but I have spent hours Binging and Googling, and still have no clue as to where to find the answer.

To restate the problem in slightly different terms, I am having a problem with Windows installer when it is invoked by windows update. In the root directory of what is currently my largest-free-space drive *something* (installer?) is creating many empty folders with names like 3f5a0b539bcd9c779f88d91d91531ed4.

Several of these folders are created each day at the same time I have Windows update scheduled to apply updates. They are all empty, and they can be manually deleted.

So, the question is «where can I look to find out how to tell windows to stop leaving these folders on my disk?». It will suffice to know how to get these written to my %temp% folder, as I already have a program which keeps it tidy.

Windows Update (and for all I know other MS Update services) appears todownload to a temporary folder in the root of the drive with the most free space at the time of the download.

This is not an accurate observation. The Windows Update Agent, regardless of whether operating within the context of AU, WU, MU, WSUS, Forefront, Defender, etc., downloads files to the %windir%\SoftwareDistribution\Download folder. For updates installed via the Windows Update Agent, those extractions are always done within the scope of the aforementioned

However, product installers executed locally may chose to extract their installation files into a folder of the root of the volume with the most free space.

This may be OK for the average PC but is not good practise on servers where the drive with the most free space may be on a SAN or on a non-NTFS formatted drive.

Absolutely agree. However, in such instances, and presuming familiarity with the behavior of the (likely FEW) installers that would be executed on a Server Operating System, it is also possible to PRE-extract those files onto the volume of your choice.

Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP — Software Packaging, Deployment & Servicing (2005-2013)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

Did you ever find a solution?

The solution is in understanding the problem.

The problem is misbehaving product/update installers that fail to clean up after themselves.

The solution is to complain to the vendors/product teams who are writing those misbehaving installers.

Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP — Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

Well, as you are a Microsoft MVP, consider this an official complaint to Micorsoft since I see updates provided via windows update exhibit this behavior.

First, I’m not a sounding board for official complaints to Microsoft. They have channels for doing that if that’s what you want to do. Being an MVP merely means that I’ve been recognized for VOLUNTEERING my time to help people like you in these forums. (I also, unlike a Microsoft employee, have the right to bail on the conversation when it becomes too pedantic.)

Second, the problem here hasn’t even been proven to be a *Microsoft* problem, because until each and every folder is identified by vendor/product, those MSI installations could be from anybody. Or perhaps a more fair answer would be that it’s not exclusive to Microsoft. Also, there are also possibilities that the CLIENT can be responsible for such issues as well.

But.. yes.. Microsoft products have been known to exhibit this behavior, I’m not denying that fact. But this is the wrong place to complain about this behavior because the *WSUS* environment has absolutely nothing to do with the behavior of client-side installers. So while I feel your pain. you’re beating your head on the wall. As I noted previously, the proper approach is to talk to the PRODUCT TEAMs who are building these misbehaving packages.

Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP — Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

Well I can confirm this behaviour categorically. When running Windows Update (in the cases I have observed for WHS 2011 — we use them as little test targets for our development) it will generate folders like the ones described on the drive with the greatest available space — There it decompresses the updates prior to installing them. ALL THE FILES ARE FROM MICROSOFT. We have verified this in multiple examples looking at the actual files. It also only occurs during running an update (something we only do manually on the test systems).

So this is clearly caused by an MS «feature» of Windows Update. It’s a nightmare for us because it pollutes data which is supposed to be an exact image of our test data and the Update junk gets synced up to our SAN. Others have noted it too and the only fix I have come across has been removing permission for SYSTEM from the drive in question. Of course this presents an issue where you need SYSTEM to have permission for some other reason (like we do).

So another genius behaviour built in to the Windows Update tool — no idea of a fix yet.

So this is clearly caused by an MS «feature» of Windows Update.

Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP — Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

Ok then ALL product teams are doing it. The .NET team, the Windows 2008 OS (Security, Updates and Kernel) team, the IE team, the Defender team . oh and the Windows Update Agent team . Curiously these all chose to put their temp files on the largest drive then to make the Windows Update Service Team look bad? Should we then complain in every single product area? That seems a lot of excessive cross-posting especially when they only time this happens is when doing a lot of updates through Windows Update at once. Still feel Update is the culprit here.

PS . the list above is based upon the files I actually manually trawled through left on the largest drive (in this case V:) after the temp location in C: (60GB free) and the free space in D: (120GB free) and E: (1TB free) were ignored as suitable locations. It went straight for the 10TB array on V:.

Curiously these all chose to put their temp files on the largest drive

Let’s separate what your gripe actually is here.

The Windows Installer Service has ALWAYS extracted installation temp folders to the VOLUME with the most free space, when those installers are run from the console.

When launched by the Windows Update Agent, they’re extracted inside the

\Download folder, because that’s the only resource the WUAgent has access to use.

Now, if your gripe is about where the working directory is built, then I’d say you’re barking up a tree you’ll never climb.

If your gripe is about installers that fail to clean-up after themselves, then I’m totally on the climb with you . I’m just saying you need to be climbing the right tree.

Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP — Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

My gripe is actually both because both behaviours are just dumb. pure and simple. There are numerous examples where updates need to be kicked off manually and similarly many situations where certain drives should be off limits. Then to rub salt in the wounds all these temp folders get left behind.

The common solution seems to be to take away right for SYSTEM to the drive you want to keep safe but of course there are numerous reasons why SYSTEM often needs access on such drives.

My gripe is actually both because both behaviours are just dumb.

Okay.. well, I have no time to coddle to gripes about the Windows Installer Service uses volumes. That’s been like that for 15 years, and software engineers way above the pay grade of either you or I had very distinct reasons for designing that way, I’m quite sure.

As for the failure of certain products to clean up after themselves, I think I’ve said all that can be said there too.

where updates need to be kicked off manually

I don’t see why this should matter.

and similarly many situations where certain drives should be off limits.

There are ways to address this issue, although I’m hard pressed to understand why «certain drives» should be off limits to a process running in the context of a system administrator anyway (who, by definition, has access to all of those drives).

Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP — Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

Above my pay grade . huh . unlikely though if they are that would explain why there are so many issues stupidities left in MS software these days .. it’s too expensive to do decent testing!

If you don’t understand why we would manually kick off updates then you don’t live in a real world which needs to quickly respond to business needs or realign with testing schedules. In fact if you don’t understand why drives should be off limits you don’t understand anything about enterprise configurations — it’s fantastic to attach 10 new servers to the SAN, have them all patched to very specific but different patch levels for testing and find that by morning said array has been shotgunned with literally tens of thousands of files.

Anyway, clearly this is the Micosoft zealots thread and any further discussion is a distinct waste of time as you are not interested in investigating a solution but developing a PR standpoint.

Anyway, clearly this is the Micosoft zealots thread and any further discussion is a distinct waste of time as you are not interested in investigating a solution but developing a PR standpoint.

Google led me to this den of patronizing MVPs. Like the original poster, I simply wanted an answer to the tech question, not a long thread of pompous rebuke and diatribe about forum catgories and the different flavors of Microsoft setup EXEs. If the question is in the wrong category, just move the question thread to the correct category and notify the member silently.

Microsoft’s .NET Framework 4.0 Standalone Installer is a glaring example of the tech problem: Without permission or warning, the EXE vomits onto the greatest-free-space drive a random-number-titled directory and squirts into it a boatload of temporary installation files. In my case, Microsoft’s POS crapped all over a failing drive from which I was in the process of rescuing deleted files: THAT IS THE WORST THING TO DO, IN SUCH A RESCUE.

BTW, I was compelled to install .NET 4.0, because Seagate’s SeaTools for Windows, lazily written, is .NET bloatware (and probably is not even worth the bother).

Microsoft’s .NET Framework 4.0 Standalone Installer offers no help response to command-line invocation with common switches such as «/?», «-?», «-o», etc.: The vomiting still proceeds as above.

So, rather than pompous self-aggrandisement («Badges» and «awards»? What is this, grade school?), multiline self-promotion signatures, self-serving «volunteerism,» and Microsoft-customer brushoffs, try treating everyone with respect, and forward questions to those who are capable of answering them precisely and without derision.

If you cannot do that, just remain silent and spare us from your useless, transparent, self-serving answers for your «badge» points.

Anyway, clearly this is the Micosoft zealots thread and any further discussion is a distinct waste of time as you are not interested in investigating a solution but developing a PR standpoint.

Google led me to this den of patronizing MVPs. Like the original poster, I simply wanted an answer to the tech question, not a long thread of pompous rebuke and diatribe about forum catgories and the different flavors of Microsoft setup EXEs. If the question is in the wrong category, just move the question thread to the correct category and notify the member silently.

Microsoft’s .NET Framework 4.0 Standalone Installer is a glaring example of the tech problem: Without permission or warning, the EXE vomits onto the greatest-free-space drive a random-number-titled directory and squirts into it a boatload of temporary installation files. In my case, Microsoft’s POS crapped all over a failing drive from which I was in the process of rescuing deleted files: THAT IS THE WORST THING TO DO, IN SUCH A RESCUE.

BTW, I was compelled to install .NET 4.0, because Seagate’s SeaTools for Windows, lazily written, is .NET bloatware (and probably is not even worth the bother).

Microsoft’s .NET Framework 4.0 Standalone Installer offers no help response to command-line invocation with common switches such as «/?», «-?», «-o», etc.: The vomiting still proceeds as above.

So, rather than pompous self-aggrandisement («Badges» and «awards»? What is this, grade school?), multiline self-promotion signatures, self-serving «volunteerism,» and Microsoft-customer brushoffs, try treating everyone with respect, and forward questions to those who are capable of answering them precisely and without derision.

If you cannot do that, just remain silent and spare us from your useless, transparent, self-serving answers for your «badge» points.

thanks for this, i came here in the hope of an answer to this issue, only to find condescension.

what i and the OP are asking, is how do we specify the extraction location for windows updates, there has to be a registry setting that defines the «drive with largest free space» and the extraction path to use, that is what i want to change.

since installing windows 10 i have over 100 random hexadecimally named empty folders clogging up my C:\ and as i’m in charge of an enterprise level distribution of windows 10 systems, nailing down this issue and finding a solid solution is an increasing priority.

Same here months later.

I just discovered the reason my Windows Home Server C: was out of space. Update / Installer CABs and temp files galore building up for months.

Like the previous poster, I assume there is a registry entry of something I can set to direct Update somewhere other than my intentionally small C: volume.

This is probably breaking some forum etiquette but who cares, try this out it may help you.

I wondered if a symbolic link might work. This might be the answer: http://blogs.msmvps.com/jeffloucks/2010/09/19/redirecting-updates-and-the-software-distribution-folder-using-junction-to-another-hard-drive/

There is no wrong tree it’s just people trying to get help where we can. Many of us search bing or google for similar answers and up here. We aren’t privy to Microsoft’s insider understanding of where the truth lives or otherwise wouldn’t be asking for help in the first place. Maybe just simplify your whole answer forum to one ombudsman smart enough to direct traffic to where it’s supposed to go for the right answer. Isn’t that what you advertise anyway?

Cheers, and thanks for even the partial help above.

For those in pain, I’ve found two links which may be useful.

https://msdn.microsoft.com/en-us/library/aa371372(VS.85).aspx — the exact reason. Because MSI was designed in almost-prehistoric times, I suppose. And never reworked.

https://serverfault.com/questions/372789/keep-windows-installer-from-using-largest-drive-for-temporary-files#763266 — may be useful. Or follow links.

For MVP guys here — I understand you don’t like to be treated this way. But you make yourselves to be treated like this. And honestly the way MSI behaves, like being unable to respect %TMP% environment (designed for these exact cases) tells much about competence of its implementors. I could continue arguing about some crappy aspects of Windows componentization and update aspects — but I won’t.

EDIT: just got NET update installer vomiting to external HDD. How do you like it? If WinUpdate uses such crappy tech as MSI and is unable to manage it in a reasonable fashion, then it’s crappy too.

%windir%\SoftwareDistribution\Download WORKED PERFECTLY FOR ME

iT WAS FULL OF FILES WHICH i DELETED AND THIS WAS THE ALMOST ENTIRE PROBLEM of disk space in the case of me

It is now 2018, and this problem still exists!

I like many others have come across this thread whilst trying to find an answer to a ‘real world’ (non ivory-tower) problem.

In my case, the problem started because the Cluster Aware Updating tool was not detecting the SQL Server 2016 Service pack 2 update, but Windows Update would.

As a result, we scheduled an update window with the client, then clicked to install the update on the primary online node, Windows Update downloaded the package and started the update . . . BAM! Failed update.

Because of the behaviour the OP and others have reported, when Windows Update invoked the Service Pack installer, it had extracted the update files onto the SQL SAN DATA disk (where all the critical business data is stored!). When it then shut down the SQL Cluster service to install the update, it also took down the drive the update had installed to.

I had to solve this (in case anyone else expreriences this) by using the following steps:

1. Shut down one of the nodes (to stop the cluster service interfering if it detected the failure).
2. Take SQL Server offline so that the cluster drives disappeared.
3. Start the service pack updated via Windows Update
4. Wait until the hexadecimal folder appeared on a local drive
5. Start ONLY the cluster disks in the Cluster manager role, just in case it needs access to any SQL Server files before it stops the cluster role.
6. Wait for update to complete, start up secondary node and run the update. As the secondary node is in passive state and the drives are owned by the other node, it will not extract to cluster disk and will install correctly (it should detect the updates are already applied to the other node and will only update the files rather than files + databases).

Following this process, the update was successful.

This is a classic example of WHY there needs to be and MSIEXEC drive/location blacklist. It’s all well and good adopting the condescending attitude of ‘it’s not a windows update problem’, but the touchpoint is the invocation FROM Windows Update.

If Windows Update is invoking windows installer files, it should either be specifying paths to the msiexec installer, or the windows update team should be feeding this back to a central team to raise awareness of a problem. Surely there is a central «architecture team» in Microsoft to ensure all groups are using the same approach, and to catch problems that are affecting multiple packages and operating systems? The attidude of «contact each vendor and group in Microsoft» is ridiculous.

The Windows Installer SERVICE and MSIEXEC exes that are invoked from Windows Update (or when an MSI, etc is executed manually) are owned by Microsoft. As Microsoft customers, we cannot be expected to know every Tom, Dick and Harry to raise a problem with every group in Microsoft, to track down the team responsible (whichever team it is that is supposed to maintain Windows Installer/MSIEXEC) to raise a problem in the behaviour of an operating system component.

The fix needs to be done by Microsoft, and rolled out using Windows Update (!) to stop this behaviour, or at least, as others have suggested over several YEARS, provide a registry key to set the default path and/or blacklist drives/locations from MSIEXEC’s use as a temporary location.

In the real world outside Microsoft, we also have lots of teams and groups. If we have a problem raised to us that is not in our area, which is a dependency of our product/service, we INTERNALLY assign/raise a bug with the team that ARE responsible for that area. We don’t fob off our customers with «we don’t look after this» style excuses.

Colin Smith, MSc, BSc, MCP, TOGAF 9 Certified Architect