Local Installation Source Tool (listool.exe) released to web.

K informed me yesterday that the Local Installation Source Tool (listool.exe) has been RTW (Released to Web).  Terri (my PM on LocalCache) always called this thing the "Cache Movin' Tool" in her specs.  Anyway, listool.exe was an intern project last summer that Terri and K pushed out the door.  Finally.

So what does it do?  The listool.exe does three very useful things that I wish we would have been able to ship on the Microsoft Office System 2003 CD from day one:

1.  Enable the LocalCache - this feature will direct the Office Source Engine (codenamed "injector") to ensure the products you choose are cached.  My suggestion is that if you are having any problems patching that you run this option for all your products. 

Note: listool does seem to require your original source media even if you already have everything cached.  K, why doesn't listool direct injector to only cache files that are missing or corrupt?  That seems unfortunate.

2.  Move the LocalCache - this feature will move all the cached files from one volume to another.  There was a lot of debate early in the LocalCache feature design whether the user should be prompted to pick the volume where files should be cached or not.  I'm not one for hiding behavior from users and suggested the user should be presented a combo box (or something, I don't do UI) that displayed the available volumes for caching.  However, Terri had a very good point that it is difficult to explain to novice users what to do when presented with such a combo box.  In the end, I was overruled but Terri added a section to one of the LocalCache specs (there were 8 or so, I had all kinds of crazy ideas) about the "Cache Movin' Tool".  So here we are.  

Note: you don't get the option of caching individual products to different volumes because the test team ran out of time to verify that LocalCache worked properly in those cases.  I can't tell you how frustrating it is to have a feature coded to completion and then have it get cut because testing can't get to it in time.  Anyway, injector supports caching to separate volumes but all of the tools (Office's setup.exe and now listool.exe) ensure all products are cached to the same volume.

3.  Disable the LocalCache - this feature obviously directs injector to uncache all of the files that were LocalCached and ensures they are never cached again.  If you turn off this feature then if the Windows Installer ever requires the original source media you will be prompted for your CD (for example, during patching).  I am admittedly biased, but I highly suggest you not disable the LocalCache.

Note:  Throughout this blog entry, I've referred to what the Office Resource Kit calls the Local Installation Source or LIS as LocalCache.

Comments (5)

  1. The reason the source media is needed to enable the cache is because the source media contains a metadata file (which is not cached) that contains all of the valid md5s and file sizes for each of the cached files in the product. As I added the enable feature to this tool we kept taking steps back as far as what we thought we could trust. Could we trust the data in injector’s store of information regarding LIS? Not necessarily. Could we trust that the LIS registry keys installed by the MSI to be valid? Not always. Could we trust the contents of the MSOCache folder to be valid? Not really.

    So when you choose to do an enable operation with the LISTool you get a full sweep, start to finish, of everything related to the LocalCache for that product. All of the values in the injector store are verified against those in the source metadata, all of the files in the cache are verified (not necessarily re-downloaded if indeed they were valid), and all of the installed registry keys are verified.

    No other answer was good enough given the amazingly weird states we’ve had reported and seen LocalCache get into (see Rob’s previous blog entries regarding LocalCache to get an small idea of what we’ve seen). This answer takes a machine with the LocalCache in pretty much <i>any</i> state and makes the LocalCache good and complete for the product in question. It does this by only trusting the original source (and more importantly the metadata at the source) when rebuilding the cache.

    WRT the multiple drive comments… I too was crushed when it was cut. It seemed like we’d run the marathon only to quit right before crossing the finish line. That said, keeping the LocalCache on only one drive ensures that users get the optimal cab sharing experience and don’t waste any space due to redundant caching.

    A little explanation… most Office products were shipped with multiple cabs containing files to be installed. The cabs were broken up in such a way that the same cab can appear in multiple products. For example, if you install OneNote and Professional, there are a few files that are common between them because they share some of the same underlying features. These files are grouped together into one or more shared cabs which are identical in both SKUs. The one good thing about forcing the LocalCache of all Office products to be on one drive is that there is only ever one instance of a shared cab no matter how many Office products you install.

    Now… if the LocalCache gets too big, you can use the new LISTool to move the cache to another, more appropriate drive.

  2. Brad Corob says:

    Before I start, let me say this is a fantastic utility that really should have made its way to the Office CD (or the ORK at least). Thanks for releasing it now. It seems to me the interface for this GREAT utility isn’t as optimal as it could be. The way I understand it is the listool has the following capabilities:

    – detect a current cache point

    – create a cache point

    – delete a cache point

    By aggregating some of this functionality, we gain the following capabilities:

    – move a cache point

    – repair a cache point (simple delete and create in place)

    Now, wouldn’t it be great if listool coule be smart about the options it presented to the user and organized the flow of execution? First of all, don’t show me things I can’t do. Upon running listool, I expect it to detect all current cache points and show them to me (along with good/damaged status). Once I can see those cache points (and relevant data like products and disk space used), then I should be able to choose whether to delete it, repair it (if damaged), or move it (if good). I want to be able to create new cache points (or add more products to a cache point) by inserting the CD.

    I’ll admit that I’m not much of a UI designer, but the current listool interface is a bit like opening Word and being presented with 3 options: Open, Spell Check, Close. If I select spell check, then I’m prompted to select a document to spell check. If I select Close, it closes the open document (whether one exists or not). Open of course works as we expect it, but as soon as you complete any of the 3 actions, Word closes, because you’ve done the one action you’ve come to do right?

  3. Brad,

    I agree. The UI flow of the tool is kinda’ whacky but I was willing to let some things go since I knew it started as an intern tool. <smile/> I’m just grateful to have something period.

    I do think your suggestions are good ideas and I know K is watching this thread so any good suggestions are sure to go back. Who knows, it is always possible that if there is time on K’s schedule or another intern shows up then *maybe* someone will improve the tool. But for now, IMHO, it’s better than what was available before (i.e. nothing).

  4. Anonymous Websurfer says:

    Very help tool! Certainly saved the day!

  5. Imagine a blog entry where I follow up on the request for help tracking down the Office source prompt for SKU011.CAB (and others).

Skip to main content