If you need to clear up space try looking for *.log files especially if IIS is installed on this machine.
On Mon, Sep 28, 2009 at 2:17 PM, Joseph Heaton <[email protected]> wrote: > I posted my original question before visiting Google (I know, I'm ashamed > of myself). I have since learned exactly what you guys are pointing out: > Don't touch that folder unless absolutely necessary, and even then, tread > lightly. We were looking at it on this specific machine because that folder > is upwards of 5GB in size. > > Thanks all! > > >>> <[email protected]> 9/28/2009 11:42 AM >>> > Well, if this is the case, I am very happy to be corrected! > > Most of those folders are pretty small. However, I did find > "$NTServicePackUninsatll$", from August, 2007, that is taking up 330 Mb > much needed space... > > Thanks! > -- > richard > > "Sam Cayze" <[email protected]> wrote on 09/28/2009 01:29:15 PM: > > > "It's best to not touch folders within the .\Windows directory to > > try to reclaim disk space." > > > > You can safely delete all the update install folders for Windows > > Update and Service Packs if your machine is running stable and you > > doubt you will ever need to uninstall them. > > > > Frees up a LOT of space. > > > > Sam > > > > From: [email protected] [mailto:[email protected]] > > Sent: Monday, September 28, 2009 1:17 PM > > To: NT System Admin Issues > > Subject: Re: Question about a folder under C:\Windows > > > > > As hinted, the Install Clean-up Tool is essentially MSIZAP with a > > GUI. It's best to use it by: > > > > 1. Use the Conrol Panel Add/Remove programs to unistall applications, > then > > > > 2. Run the Installer Clean-Up tool, and select any apps you believe > > should have been removed. (Add/Remove sometimes leaves pieces > > behihd, depending on how well written the app was.) > > > > 3. Check your file system - some pieces get left behind in the . > > \Program Files directory. > > > > Do NOT use the clean-up tool first in order to uninstall apps! That > > will do a great job of making the Add/Remove control panel applet > > unusable for that app. > > > > Back to the original "problem"... It's best to not touch folders > > within the .\Windows directory to try to reclaim disk space. (There > > is probably a .\Windows\temp folder, but I've never seen much in > > those folders.) Use something like WinTree, WinDirStat, etc to > > locate big files or folders. Some browser caches can get to be > > pretty big. If a machine has multiple users, some of those profiles > > (some of which are local caches of a roaming user) can approach Gbs > > in size. I've seen machines with several crash dump files in the > > root directory. (Some crash dump files also end up in an > > administrators local settings profile instead of the rood.) > > -- > > richard > > > > Ben Scott <[email protected]> wrote on 09/28/2009 01:05:59 PM: > > > > > On Mon, Sep 28, 2009 at 12:32 PM, Joseph Heaton <[email protected]> > wrote: > > > > The c:\windows\installer folder. On the system I'm looking at it > > > is a hidden system folder. Does anyone know the function of this > > > folder, and whether or not the contents can be cleared? > > > > > > That folder is part of the -- wait for it -- Windows Installer. > > > (Also called "Microsoft Installer" or MSI.) The folder gets used to > > > store a number of things, including database information about > > > installed packages, cached patches for (re)installation, program icons > > > (stored as .EXE files), temporary files during install, and other > > > mysterious stuff. It typically uses opaque IDs rather than > > > human-readable names. It's your classic Microsoft big-ball-of-mud. > > > > > > You don't want to go "pruning" in there without specific direction. > > > If you remove a file related to a currently-installed package, then > > > future attempts at upgrading, repairing, or removing that package may > > > fail. For example, patches are cached so they can be re-applied or > > > reversed during future operations, and database info tells MSI exactly > > > what to do during an uninstall. > > > > > > However, it is also quite possible for stale files to accumulate in > > > there. Unfortunately, since it's a rather opaque data store, it's > > > hard to know what's needed and what isn't. > > > > > > The MSIZAP utility has a command, G, to "remove orphaned cached > > > Windows Installer data files". Exactly how it determines what an > > > orphan is, I don't know, but it's supposedly safe as long as you don't > > > use the "!" modifier to force things. I don't know if it's > > > comprehensive -- I don't know if "MSIZAP G" will find all possible > > > stale/orphan files. I suspect not. > > > > > > The other options in MSIZAP generally remove information from the > > > MSI store without actually touching package files on your system. In > > > other words, indiscriminate use of MSIZAP will just remove the > > > *record* of an install, not the install itself. You have been warned. > > > > > > The MSIZAP tool comes with the "Windows Installer Cleanup Utility". > > > You can get it from MSKB 290301. > > > > > > -- Ben > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > > > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > -- Sherry Abercrombie "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
