Along the same lines as removing items from the Windows component store to save space, we have recently seen a couple of questions come in about the Windows\Installer directory. This is a hidden system directory; it is used by the Windows Installer service to cache installer data files for various applications. Over time, this directory will grow and can eventually take up an amount of space that might cause pressure on thinly provisioned storage, such as virtual hard disks.
So, the question usually asked is: Can I safely remove the files in this directory? The answer is flatly: No. So let's talk about why this is a bad idea.
First, it is not supported. If you remove files from this directory and have issues, you may need to reinstall the application to get back to a good state. Therefore, that would suck for both you and the engineer that needs to deliver that message.
Second is the overall idea that you really should not remove items in the Windows directory. We build and test our software based on the existence of specific files and directories. When those files and directories dont exist, bad things can and will happen. However, that is a generalization that usually upsets many people so let's be more specific. This particular directories job is to act as a cache location for Windows installer based applications. It holds stripped down versions of the Windows installer data files. During application install, update of the application or application removal, this directory is used by the application to confirm the existence of previously installed items to determine the next steps the installer needs to take. The files are different from machine to machine, so if you expect to delete the files in the directory and then copy them over from another machine, that would be incorrect. Removing items from here could cause you to have application crashes, or worse, require the reinstallation and patching of the application.
The proper way to alleviate space pressure in this directory is to uninstall any unneeded applications.
I hope that this makes sense and you can see why removing files from this directory can cause you unneeded pain. Overall, this is similar to the advice I have given in the past when it comes to removing items from the component store...just don't do it. Plan your future space requirements based on your operating system and application needs and you can alleviate many of these types of issues before they occur.
Looks good Drew, I'll shoot this around internally and see what others think of the idea.
Thanks. I suppose the only field i've missed in the above list is something for subordinate updates (for want of a better term).
"Dates have been used incorrectly in servicing for years (since NT) and its always been a pet peeve of mine."
Could you elaborate on this? Who or what has used dates incorrectly? I actually like dates as version numbers, in general. For example, i would prefer if the Windows build number was a timestamp, and then for the full Windows version number to be formatted like this:
It would also be helpful if this became a machine environment variable, say 'OSVersion'. (The 'ver' command is not outputting anything that a single envar couldn't.)
What I mean by that statement is that the file date/date modified should never be used for determining the state of a file on the machine. Many things can change those dates. The file version is the only way to accurately determine the state of a file on the system because thats usually only something the OS is going to modify.
I have let XP go, I use Windows 7 but I will keep reminding Microsoft that they destroyed the speed, ease of use, simplicity and lightweightness of XP servicing in the redesign for "reliability" of Vista/7/8. I don't expect anything exciting from Windows 8 because MS has designed the servicing stack in a way that performance, disk space and ease of use are all last priorities. Even to slipstream hotfixes, the earlier simple /integrate switch is replaced by some zombie multi-step operation involving WAIK, extraction, learning of complex DISM syntax and what not.
I disagree almost entirely. Ok, so Vista/7/8 servicing is somewhat slow, but the ability to mount WIM images is invaluable. DISM syntax takes a bit of learning, but the steps to service an image are entirely intuitive - mount -> modify -> commit -> unmount. That's easy. I printed the DISM syntax and laminated it (seriously). Now i do the commands off the top of my head, mostly, but the printouts are still kept handy. You should think about doing the same - it's a much more productive way to use your time than complaining about disk space usage. I think the all-in-one nature of DISM is great, and will be even more so when the Imagex functionality is added (run 'dism /?' in Win8 to see the new imaging switches). Btw, here is a fascinating article about the WIM format and its development. technet.microsoft.com/.../2006.12.desktopfiles.aspx
could you at some stage do a post that does a brief overview of the %windir%\SoftwareDistribution directory?
@Drew; Sure, I'll do something on SoftwareDist here in the near future.
To both of you, I understand XPs point and I think he would counter that XP's ability to integrate service packs with a single switch was invaluable to him. You're actually both right. The new servicing model is not perfect. I would challenge that no piece of software is. That being said, I do prefer the new model and its not just because I work here. XP lacked the checks and balances that we now have in the current model and those balances provide for a lot more mutability and robustness when it comes to system stability
@Drewfus, I respect your opinion. I spent my valuable time learning pkgmgr, PEImg, and IntlConfg and suddenly with Windows 7, they were deprecated and replaced with DISM. I have no trust that DISM will stay and won't be replaced again by something else in Windows 8. Also, you can argue that reliability is somewhat increased by the new servicing stack (even that is questionable as I have seen hundreds of thousands of Vista and 7 system rendered unbootable and stuck in a state half across installing service pack 1 or patch tuesday updates. Before Windows 7, we didn't even have DISM /revertpendingactions but the average user doesn't know about such stuff. XP servicing was FAST and by FAST I mean really really fast. You could install entire service packs in 10-15 minutes and dozens of chained updates in less than 5 minutes. It gave you the option (because of its very design) to not waste disk space. 7/Vista servicing is slow as hell, requiring "configuration" as logoff and next restart, unnecessarily complicates things under WinSxS, and the foot print of the OS goes on increasing over time as you install more updates which is shockingly ridiculous. Tommorrow if I buy a Windows 8 tablet, I am very concerned that I may run out of disk space. Plus, you lose the ability to slipstream service packs and the integration of hotfixes into the base image is too cumbersome. So how many regressions now you can say just for sake of "reliability" and "robustness" which is also questionable as my own systems stopped working installing Vista SP1 and WIndows 7 SP1 would just reach stage 3 of 3 (99%) and then roll back. I won't say it's reliable at all. It is the reason the OS image is getting bloated and MS needs to do something urgent about it in Windows 8 or Windows 9. I wrote a blog post expressing my thoughts on the new servicing model: xpwasmyidea.blogspot.in/.../servicing-disaster-in-windows-vista-and.html You can see the nightmarish experiences many users are having with Vista/7 servicing.
"I respect your opinion."
"I spent my valuable time learning pkgmgr, PEImg, and IntlConfg and suddenly with Windows 7, they were deprecated and replaced with DISM. I have no trust that DISM will stay and won't be replaced again by something else in Windows 8."
DISM is still there in the Win8 DP, and apparently more capable than ever. I think DISM is here to stay. It seems to be a more robust tool than the tools it replaced, and MSFT are still adding functionality to it. It appears to be an integral part of the servicing stack - at least in the sense that other tools call down to it or it is called indirectly. However, you have a point that i can't explain away - MSFT should be giving advice on the likely lifetime of the tool, at least one OS release in advance. It would not be quite right to, for example, roll out Win9 and say, "btw, DISM is deprecated in favor of blah", without giving notice.
"Also, you can argue that reliability is somewhat increased by the new servicing stack (even that is questionable as I have seen hundreds of thousands of Vista and 7 system rendered unbootable and stuck in a state half across installing service pack 1 or patch tuesday updates."
Which as we found out last year, was at least partly due to the state of those systems at the time the service pack was applied, and not necessarily an issue with the servicing stack itself. The 'state of the systems' included unsupported deployment methods, i believe. Yeh, maybe the SP should have done more system checking/prepping before commencing the install, but again, that's not necessarily indicative of an underlying architechtural problem.
"XP servicing was FAST and by FAST I mean really really fast." "7/Vista servicing is slow as hell, requiring "configuration" as logoff and next restart..."
Yeh, the new stuff is slow, agreed. However, what is the issue with this? Most office workers are absent after 6pm until 8am the next day. That's 14 hours to get updates done. Not enough? At home, use your other computer and stagger the WU install time.
"...unnecessarily complicates things under WinSxS.."
Do you really believe file-based servicing is preferable to component-based? Btw, i reread the last hardlinks post here a few days back, and couldn't believe how amazingly simple (and clever) the whole hardlink concept was, and why it wasn't all obvious the first time through. That was a great post.
"Tommorrow if I buy a Windows 8 tablet, I am very concerned that I may run out of disk space."
I guess you mean if the tablet has an SSD? This may be your strongest point - one of the //build/ presentations notes that the new power saving mode (forget the name but it's like a combination of Away mode (monitor off) and S3 sleep + transient power-on for live data refreshing), specifically relies on an SSD. They don't want the spin-up time of an HDD to interfere. Fine, so we need an SSD to get the full benefit of Win8 power innovations. In that case an SSD stops being a luxury, and perhaps we can no longer say - "open your wallet and buy a bigger drive" - if one reason you need one is the OS doing things like keeping redundant component versions in WinSxS. There is also the issue of not being able to move hiberfil.sys to another drive. forum.sysinternals.com/change-location-of-hiberfilsys_topic26183.html
"Plus, you lose the ability to slipstream service packs..."
Not ideal, agreed. However, is installing the service pack online and then running a 'sysprep /generalize', followed by and image capture with Imagex (and soon DISM!) such a big deal? Can you slipstream IE8 into XP? No, so either way there is likely to be live servicing required when updating the OS source.
"...the integration of hotfixes into the base image is too cumbersome."
"I wrote a blog post expressing my thoughts on the new servicing model:"
Which was otherwise well written but you didn't give much analysis on why CBS had been introduced, nor why people like Joseph would argue for it, overall at least.
Let me ask a more general question (for anyone to answer, of course), and it relates to what Joseph said above about no software being perfect. My experience is that companies are generally doing one image or image-set build per OS release. Maybe this is not frequent enough. Considering how long Win7 SP1 takes to install (plus problems, in a few cases) must surely beg the question - why aren't systems being *reimaged* when service packs are released, rather than updated online? Sure, it's because there is too much app and user state to worry about. Ok, so why aren't efforts being made to deal with this issue, with the aim, partially, of making things like slow servicing a moot point? On one of the recent Win8 blog posts, i made the point that the OS should be staging classic app install sources, so that when reimaging needs to occur, this stuff can be included in the (hardlink-based) backup and restore process. Or consider already existing program staging like the \MSOCache (which might not exist or be or be up to date in the most recent image). I actually got a few-paragraph reply on this proposal by Steven Sinofsky (who didn't agree, but nor did i with him, although he did make me more aware of the issues involved in attempting to recreate the prior state of the OS). Disregarding application state issues, if we started staging install sources by default, then reimaging all systems at least once per service pack release, potentially becomes a much more practical and plausible exercise. You (we) could start putting time into learning unattended app install commands, rather than waiting for WU/MSU/SP packages to install.
Here is my point: The component-based servicing stack model is what it is, and probably will be until at least Win9. Given that, and what that implies, what alternate ways might there be for dealing with the issues that things like slow updates and non-ability to slipstream service packs is causing, and, what reasonable requests can we make to MSFT to include stuff like a /nobackup switch into DISM?
To each his own, I do not agree with any of your arguments but I hope a future version of Windows will be engineered for super fast, bloat free and simplified servicing. Speed, less disk space consumption over time and simple design will only benefit the product.
1. Effective and reliable
2. Fast and efficient
Your choice: Any two.
"I use Windows 7 but I will keep reminding Microsoft that they destroyed the speed, ease of use, simplicity and lightweightness of XP servicing in the redesign for "reliability" of Vista/7/8"
reliability is always better. Last month I installed the XPMode, installed an older SDK and 1 day later it was patchday. After installing the updates I tried to use the XPMode 1 day later it is was broken and I can't install other things (Windows Installer service and other things can't be started). And this happens on a 2 day old VM. I never had such thing in NT6.x ;)
And slipstreaming updates is still easy. 3 lines of code (mounting WIM, DISM App-Package, Unmount-Commit).
"XP servicing was FAST and by FAST I mean really really fast." - Fast , but buggy. See my XPmode VM test.
And you still don't understand or better are NOT WILLING to understand CBS. You still have the same wrong "arguments". Your blog post is written in a good style but with completely wrong arguments like this:
"Windows keeps multiple copies of the same file in WinSxS" - wrong, there are no copies of the SAME file. Each file exist once in the WinSxS folder and depending of which version is needed (LDR, GDR) the hardlink is generated.
" it still maintains the older backup of the previous versions of components in WinSxS so the user would be able to uninstall updates. " completely wrong and nonsense. What you write applies to XP servicing. Removing files from the C:\Windows\$Uninstall$KBxxxxxx breaks the ability to install updates.
If you want to remove the older files, uninstall the older superseded updates. This works fine. Here is the only part to criticize MSFT. They should give a command to detect and uninstall oder superseded updates. I do this everytime my own at patchday ad uninstall superseded Updates and my WinSxS folder is 7GB and I have over 200 updates (updates, seceurit fixes and hotfixes) installed.
Also superseded drivers can be uninstalled from Driverstore with pnputil. This reduces the C:\Windows\System32\DriverStore size.
So you really need to learn how CBS works first, your wrong "arguments" are really boring after repeating them 100th time again.
@topic of C:\Windows\Installer folder
in Windows 8 (ADK under Windows 7) some files are now stored in C:\ProgramData\Package Cache.
So the MSFT way to reduce the C:\Windows\Installer foldersize is to move them to a new location? This is a bit ugly.
Ideally, the way to reduce the foldersize is to increase your disk space. We really dont want people removing or manipulating items in that directory.
@Andre.Ziegler, by "same file" I obviously mean "same filename" but different version number. I may have worded it ambiguously. I have updated the blog post to reword the stuff that you intentionally misinterpret. But your deliberate misinterpretation of my wording and desperation to prove I am wrong doesn't affect the reality that NT 6.x servicing is an engineering disaster in performance and disk space consumption. Good luck NT 6 users freeing up space on your tablet with flash-based storage and uninstalling superseded updates while the battery runs out.
So much for "reliability": www.neowin.net/.../1059012-elevated-command-prompt-on-non-booting-pc People I have come across online and my friends around me with Windows 7/Vista PCs are constantly having such unbootable PC issues. Just last week, my friend's laptop became unbootable while installing W7 SP1 from Windows Update. Can't imagine how it got stuck in that state. Another friend just couldn't install SP1 which would fail at stage 3 or 3 configuring updates reaching 99% and rolling back. I have never had such problems on Windows XP systems so even the whole servicing stack engineered for reliability is laughable. This is one area Microsoft completely screwed up in Vista and wouldn't "fix" it any more in W7 or W8. So I am not complaining over nothing, it's from frustrating real-life experiences and time wasted.
I know you hate the servicing stack and CBS in general so I wont go too much into this, but....I can tell you for a fact that the number of issues we see that are update related are much smaller than we ever saw with XP. There are goods and bads to both systems and both systems have failed in some form or fashion. But, CBS is more reliable that update.exe.