The icon cache
SoftGrid has two icon cache folders. Paul Freitas, Softricity Technical Support advises:
One location contains icons for the file extensions e.g.,
C:\Documents and Settings\username\Application Data\SoftGrid Client\Icon CacheOne location contains icons for the applications e.g.,
C:\Documents and Settings\All Users\Documents\SoftGrid Client\Icon Cache
Since our users' Application Data folder is redirected to H:\profile\Application Data, the SoftGrid client is accessing the file extension icon cache across the network.
An arbitrary sampling shows that the Softgrid Icon Cache accounts for an average of 82.9% of the users' space.
We would like this icon cache folder to be located on the local workstation and accessible by all users logging in. If the cache is redirected locally but inaccessible, it defeats the purpose of having a cache and the SoftGrid client will still need to pull icon files from the content share.
We would like to be able to roam the other SoftGrid client settings (application preferences, etc) but without this icon cache. Is this possible with SoftGrid without unredirecting Application Data?
Possible solutions
Excluding a folder from the roaming profile
Windows has a feature whereby specific folders can be kept local and not copied to the roaming profile at logoff. This will not work for our current setup because the Application Data folder is a redirected folder, not a roaming folder. SoftGrid writes directly to H:\profile\Application Data\SoftGrid Client\Icon cache while starting up during a logon session.
"Manually" unredirecting a portion of a redirected folder
SoftGridUserData.lua is a script called at logon and logoff. This script will copy the contents of the user's H:\profile\Application Data\SoftGrid Client folder to a local C:\SGU\SoftGrid Client directory at logon, and vice-versa at logoff. This enables the SoftGrid client to store its settings locally during a logon session, but also to have these settings roam with the user from one workstation to another.
The user settings stored in C:\SGU are purged at logoff and at logon just before the profile data is copied down. This is necessary so that one user's does not receive settings from another user.
The Icon Cache subfolder is not "roamed". Instead, it is left on the local workstation. If an Icon Cache subfolder is found in the user's profile, it is deleted.
 | This script is in effect only on workstations whose UserDataDirectory setting is C:\SGU. This setting can be enforced by startup.lua via \\gccaz.edu\netlogon\patches\sgu.lua. To manually create this directory with the proper permissions, use the following command at a command prompt: |
It also should be noted that if we choose this implementation, everyone's application profile will be reset to default for each application, so we need to alert the user population. Furthermore, this must be a "flash cut". Client computers with the c:\SGU change do not intermingle with the original configuration (%APPDATA%). Profile problems will result if both computer configurations are allowed to exist.
It appears that if the [UserDataDirectory] setting is changed to something other than %appdata%, that SoftGrid will actually take special pains to delete the H:\profile\Application Data\SoftGrid Client directory. A solution is to rename the directory to something like this: H:\profile\Application Data\SGC.
Additional problems
Research indicates that many of the eGCC computers also have the client DC server setting as dns name softgrid.gccaz.edu which is incorrect. The correct setting is softgrid.sg.local. This will allow for localized access to icons instead of carrying the icons over the Wan link to GCC North.
Icon files
Additionally, it was discovered that many of these icon files are actually executable images, and therefore larger than necessary. It is relatively easy to convert these files without resequencing. As far as I know, this procedure has not yet been tested.
How to convert an icon file
- Copy the icon file to whatever.exe
- Open whatever.exe with a resource editor such as the one in Visual Studio.
- Find the first (lowest-numbered) icon resource, and save it as a file, overwriting the original icon file.
- Make sure the icon file works
- Delete whatever.exe
In the future it would be a Good Idea when sequencing an application to ensure that the icon files placed in the content share are actually just the icon.