Usability Question - Storing a local profile on a non system partition...

Status
Not open for further replies.

Devcon

Posts: 16   +0
The situation is as follows. I have a number of computers running XP SP3 with Deep Freeze installed. For those who don't know, Deep Freeze 'erases' any changes to the selected partition(s) on each reboot. I would like users to be able to safely use and save their local files but not have the ability to edit anything on the system partition. Now, roaming profiles come to mind, but I do not want to load the entirety of each profile everytime a user logs in. Both our server and network in general are not up to the task. I have created a secondary partition on each computer to enable users to save their data to the second partition.

However, users often make many errors or forget causing them to complain down the line. And, of course, it should be more streamlined. My current methodology is to relocate system folders "Desktop" and "My Documents" in the registry, so in most cases, users do not risk losing any data. This usually does work, but one problem remains. For ease of deployment, we also use a number of virtual applications prepared by Vmware ThinApp. The virtual sandboxes are often automatically saved to %appdata%. This parameter can be changed to the same directory or a specific directory, but that does not suit my needs.

Some of these virtual programs are rather large and stored on a central server. If set to 'usb mode' only one user will be allowed to use the program at a time, or the virtual sandbox will throw up an error. So, every computer needs to be able to save the sandbox locally to %appdata%. However, this will always be erased while running deep freeze on the user workstations. This brings us full circle. Even if I cannot save the entirety of a user profile to a local secondary partition, can I move appdata with the same ease as common system folders such as My Documents? I have tried many times and failed because the environmental variable %appdata% always refers to the local system partition. Thus, the sandbox is created and deleted on reboot. I have tried creating different environmental variables such as %sandbox% directing it to the second partition. This works fine in windows, but now each ThinApp compile refuses and saves the sandbox in 'USB Mode' in a folder named %sandbox%. It does not see the environmental variable. Using a custom environmental variable is actually the ideal situation, as I do not want the entirety of %appdata% saved; however, I don't see another solution for the time being.

In short, is it possible to relocate the entire profile folder or just %appdata% to a secondary local partition?

Sorry, that may be a bit confusing. There must be a way to do it, as it is just a snap of the fingers in linux.
 
Can't you just set %appdata% to another location, in System Variables screen? (properties of My Computer) similar to how Set tmp=%temp% That type of thing.

You know if you were using a Domain Server, all computers could be set up properly to save to the Server through the Active Directory, this is where you'd really need to be at I feel.
 
I know that I am pushing XP to its limits beyond moving to an Active Directory setup, but they are not ready to move to Windows Server. I know that sounds odd, and I have been trying to convince them for some time, but things move slowly in Africa. I have actually not tried relocating %appdata% through the environmental variable tool, but I have edited every registry entry pertaining to %appdata% with no worthwhile results. I have tried making my my own variable, %sandbox%, but for some reason, it is not read as a variable by ThinApp. Let me load up a virtual machine real quick and try. As I said before, it would be ideal for me to use a custom environmental variable, but ThinApp seems to be bugged.
 
Please try the "custom environmental variable"
I am now interested if it will work
By the way, doing this will change everything!! in %appdata% to the new location, that may be a concern :confused:

The other option, is checking the "Start in" or "work in" locations of your certain programs right click properties
 
That is a no go. I redefined the %appdata% variable for both users and the system with the same result. It still refers to %userprofile%\application data.

I question my syntax in ThinApp when defining the environment location, but haven't found anything different on the internet. I input, SANDBOXPATH=%sandbox%\appname but it never uses the environmental variable.



The custom variable works with no problems in windows. It is just that ThinApp now cannot see the variable. Example, I add the user variable %sandbox% to open D:\SandBox. If I type that in the run command, it directly opens the folder on the second partition. Everything works great to this point, but when I input %sandbox% into my ThinApped application, the sandbox is saved locally and not the desired environmental variable.

I know, bizarre
 
It must be using a direct path
Now these things can be edited too ;)
But it means decompiling the executable and I'm not sure if that would be lawful :cool:
I use tools such as Winhex or a program called Restorator
I wonder if it would be best to contact the programs home site, there may even be a switch ! :rolleyes:
 
It is using a direct path, but it states explicitly in the documentation that it can use custom environmental variables. The process is:

1) Take base snapshot
2) Create the custom variable so the changes are made to the registry
3) Install and configure the program
4) 2nd snapshot
5) Insert the %variable% path as SANDBOXPATH.

Perhaps this is more of a ThinApp issue, but the internet community over there at Vmware is not yet numerous.
 
Status
Not open for further replies.
Back