App-V: SFTMIME.EXE REFRESH SERVER
SFTMIME.EXE is one of the two primary command line utilities you will find yourself using to programattically control App-V. SFTTRAY.EXE being the other.
SFTMIME's main purpose is controlling the client, as where SFTTRAY's main purpose is launching applications. It goes beyond that but in a nutshell those are their jobs.
One problem you may see with SFTMIME is a lack of response. In this instance REFRESH SERVER, when when used with /log provides no response unless there is an error. Most people go into the Client Console and refresh to see if the server status changes to "Ongoing", and if it doesn't change assume it didn't work. The only way to ensure it kicked off a refresh is to check C:\ProgramData\Microsoft\Application Virtualizaton Client\sftlog.txt
If you see it cycling in the log, you know it worked. This doesn't do wonder for programattically checking, as even looking at the modified date of sftlo.txt doesn't tell you anything other than SOMETHING happened. You have to actually parse the log file to get a clear result.
If you intend to run SFTMIME via scripts or something like SCCM don't forget to specify /LOG <pathname> otherwise if it fails, you are left to scratch your head and wonder why.
App-V: Windows 7 locations.
Client Log File Location:
C:\ProgramData\Microsoft\Application Virtualization Client\sftlog.txt
Icon Cache:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\Icon Cache
OSD Cache:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache
Machine AppFS Storage:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage
User AppFS Non-Roaming:
C:\Users\fulbripd\AppData\Local\SoftGrid Client
User AppFS Roaming:
C:\Users\fulbripd\AppData\Roaming\SoftGrid Client
Why would I need or want to know these locations?
Well, the OSD cache is important if you want to, say, suite something in-place (i.e. suite two applications together just on the machine to test integration or to hotfix someone until you can update it on the backend), the icon cache is useful for determining whether or not Windows Icon database is corrupt or if the icons provided by App-V are corrupt. The log file location is...hopefully obvious.
My personal favorite however is the AppFS locations.
I wouldn't worry to much about WHAT files are in there. But these locations are where the user changes that are saved "to the bubble" are stored. They are broken down into basically three types. Changes that are global (say, an HKLM key), changes that only apply to the user but shouldn't roam (say, an HKCU key with the machine name in it), and changes that are user specific and are ok to roam (say, an .ini file with preferences stored in it).
Where knowing this comes in handy is when, for whatever reason, the client decides to not truly clear the AppFS when you tell it to. I've had more than one instance of clearing multiple times, clearing after log off, after reboot, and the client just isn't capable of deleting it, maybe something random locked the folder, maybe something got corrupted, either way the only solution at that point is to find the folder for the app you want to clear and manually delete it in all three locations.
Likewise if you ONLY want to clear a certain segment of the AppFS for a package you can do so manually as opposed to the client which does not give you any options.
And example of what the folders look like it: CTXAPPS-3E12E23B-2C95-4986
You will notice after looking at a few that they tend to have the 8.3 folder name you used when you sequenced them, followed by a semi-GUID (semi because the first block is user generated and not random, therefor not TRULY globally unique).