none
Windows Update Temporary Folder location

    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.

    Thanks - Bill
    • Moved by Stephen BootsMVP 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 EngineerMicrosoft Support Monday, March 22, 2010 3:43 PM Move to correct forum (From:Windows Update)
    Wednesday, March 17, 2010 1:25 PM

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 is not an accurate statement. The Windows Update Agent downloads ALL content to %windir%\SoftwareDistribution\Download. If you're downloading from the Microsoft Download Center, IE may be writing the temporary file into the cache before copying to the final destination. Windows Installer does create a temporary folder on the logical volume with the most free space, during the actual installation process, but that folder is be deleted after use.
    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.
    Correct, for use of Windows Installer this may not be desirable behavior. However, your issue here is with the Windows Installer application, and using the appropriate options (where available) to control the location of the installation directory on such systems when performing such installations is the solution. As Robear notes, it's really beyond the scope of this forum.
    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.
    No. But then, as noted, this is not the Update Service causing this scenario, but rather the Windows Installer.
    I have been searching the internet for an answer to this but so far drawn a blank.
    Possibly because you're lookin' up the wrong tree for the answer. :-)
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, March 22, 2010 4:24 PM
    Moderator

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/ 

    Possibly...

    File Services and Storage Forum
    http://social.technet.microsoft.com/Forums/en-US/winserverfiles/threads

    ~Robear Dyer (PA Bear) ~ MS MVP (IE, Mail, Security, Windows & Update Services) since 2002 ~ Disclaimer: MS MVPs neither represent nor work for Microsoft
    Thursday, March 18, 2010 8:33 PM
  • 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 statement. The Windows Update Agent downloads ALL content to %windir%\SoftwareDistribution\Download. If you're downloading from the Microsoft Download Center, IE may be writing the temporary file into the cache before copying to the final destination. Windows Installer does create a temporary folder on the logical volume with the most free space, during the actual installation process, but that folder is be deleted after use.
    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.
    Correct, for use of Windows Installer this may not be desirable behavior. However, your issue here is with the Windows Installer application, and using the appropriate options (where available) to control the location of the installation directory on such systems when performing such installations is the solution. As Robear notes, it's really beyond the scope of this forum.
    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.
    No. But then, as noted, this is not the Update Service causing this scenario, but rather the Windows Installer.
    I have been searching the internet for an answer to this but so far drawn a blank.
    Possibly because you're lookin' up the wrong tree for the answer. :-)
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, March 22, 2010 4:24 PM
    Moderator
  • 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.

    Thanks!
    Monday, March 29, 2010 6:28 AM
    Moderator
  • 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.


    FLMatt

    Thursday, July 18, 2013 5:24 PM
  • 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 ~\Download folder.

    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.

    Thursday, July 18, 2013 6:46 PM
    Moderator
  • This has been driving me insane too. Did you ever find a solution?
    Thursday, February 20, 2014 5:33 PM
  • 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.

    Thursday, February 20, 2014 7:22 PM
    Moderator
  • 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.
    Thursday, February 20, 2014 9:21 PM
  • 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.

    Friday, February 21, 2014 12:42 AM
    Moderator
  • 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.

    Monday, April 14, 2014 1:34 PM
  • So this is clearly caused by an MS "feature" of Windows Update.

    NO. It's not. It's caused by poor behavior of the INSTALLER of that particular update. The UPDATES are exclusively the responsibility of the Product Group that produces them. Updates are NOT produced by the Windows Update or WSUS teams. So, if you want to legitimately complain, figure out which *PRODUCT* and *UPDATE* the left over files are associated with, and then contact that particular Product Group.

    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.

    Monday, April 14, 2014 11:23 PM
    Moderator
  • 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:.

    • Edited by sarbis Wednesday, April 16, 2014 7:18 AM
    Wednesday, April 16, 2014 7:15 AM
  • 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.

    Friday, April 18, 2014 5:26 PM
    Moderator
  • 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.

    Saturday, April 19, 2014 1:54 PM
  • 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.

    18 hours 59 minutes ago
    Moderator