How do i redirect a folder in user context?
I have this reg key directing Temp Cache files to a C:\Temp folder
I need to redirect this to Profiles\Local Settings\Temp in "HKLM\Software\Application\CacheFolder =C:\Temp" - How do i manage this in WPS?
I make a UserCache variable in the Directory table .:Profile|Local Settings|Temp but upon installation it just translates it as C:\Windows in the Cache Temp reg key and it seems whatever variable i throw at it in my regkey it just ends up in C:\Windows - i reckon when it can't translate it to anything else, it uses the Windows folder as default.
Bart [8|]
I need to redirect this to Profiles\Local Settings\Temp in "HKLM\Software\Application\CacheFolder =C:\Temp" - How do i manage this in WPS?
I make a UserCache variable in the Directory table .:Profile|Local Settings|Temp but upon installation it just translates it as C:\Windows in the Cache Temp reg key and it seems whatever variable i throw at it in my regkey it just ends up in C:\Windows - i reckon when it can't translate it to anything else, it uses the Windows folder as default.
Bart [8|]
0 Comments
[ + ] Show comments
Answers (7)
Please log in to answer
Posted by:
WiseUser
19 years ago
This is a bit of a pain because you want to write a user-specific value to a machine-specific key.
If your users always used their own PCs and never roamed, you wouldn't have a problem. But it's very unusual to be in a position whereby you can say that no user will ever use another users' PC!
Assuming the was a per-machine install, my personal approach would be to use the "TempFolder" property in the registry table.
I'd also include a vbscript in my application folder like this:
Const sHKLMKEY = "HKLM\Software\Application\CacheFolder"
Set oWsh = CreateObject("Wscript.Shell")
sTemp = LCase(oWsh.ExpandEnvironmentStrings("%Temp%"))
sRegVal = LCase(oWsh.RegRead(sHKLMKEY))
Set oWsh = Nothing
If Instr(sRegVal, sTemp) = 0 Then
sProdCode = WScript.Arguments(0)
Const sFeature = "NameOfFeatureContainingHKLMKeysGoesHere"
Const msiReinstallModeMachineData = 128
Const msiUILevelNone = 2
Set oInst = CreateObject("WindowsInstaller.Installer")
oInst.UILevel = msiUILevelNone
oInst.ReinstallFeature sProdCode, sFeature, msiReinstallModeMachineData
Set oInst = Nothing
End If
I haven't tested the script, so it's probably got bugs that need fixing.
Then I'd create a shortcut to the script in the "StartupFolder" so that it would run at each logon. The "Arguments" column of the "Shortcut" table would take the following data: "[ProductCode]". You could use a machine "run" registry key if you preferred.
There's definately easier ways of doing this, but in my humble opinion you'll struggle to find a neater one. This same technique can be used to do many other things, including running custom actions with "system" privileges at logon (assuming the install is managed). Notice that you could have written a simpler script to edit the registry key directly, but the user would need permissions to the key first.[;)]
If your users always used their own PCs and never roamed, you wouldn't have a problem. But it's very unusual to be in a position whereby you can say that no user will ever use another users' PC!
Assuming the was a per-machine install, my personal approach would be to use the "TempFolder" property in the registry table.
I'd also include a vbscript in my application folder like this:
Set oWsh = CreateObject("Wscript.Shell")
sTemp = LCase(oWsh.ExpandEnvironmentStrings("%Temp%"))
sRegVal = LCase(oWsh.RegRead(sHKLMKEY))
Set oWsh = Nothing
If Instr(sRegVal, sTemp) = 0 Then
sProdCode = WScript.Arguments(0)
Const sFeature = "NameOfFeatureContainingHKLMKeysGoesHere"
Const msiReinstallModeMachineData = 128
Const msiUILevelNone = 2
Set oInst = CreateObject("WindowsInstaller.Installer")
oInst.UILevel = msiUILevelNone
oInst.ReinstallFeature sProdCode, sFeature, msiReinstallModeMachineData
Set oInst = Nothing
End If
I haven't tested the script, so it's probably got bugs that need fixing.
Then I'd create a shortcut to the script in the "StartupFolder" so that it would run at each logon. The "Arguments" column of the "Shortcut" table would take the following data: "[ProductCode]". You could use a machine "run" registry key if you preferred.
There's definately easier ways of doing this, but in my humble opinion you'll struggle to find a neater one. This same technique can be used to do many other things, including running custom actions with "system" privileges at logon (assuming the install is managed). Notice that you could have written a simpler script to edit the registry key directly, but the user would need permissions to the key first.[;)]
Posted by:
Bartesque
19 years ago
Local Settings\Temp is not roamed
How to use the TempFolder property in registry table?
How to use the TempFolder property in registry table?
Posted by:
WiseUser
19 years ago
What made you think it did roam?
"HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs"
The issue caused by roaming is that the value of your "HKLM" key should be different for all users who might roam onto that machine. Therefore the vlue of the key must change every time a different user logs on to the PC. As long as the sae user logs on every day, there is no need for the value to change.
"[TempFolder]".
"HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs"
The issue caused by roaming is that the value of your "HKLM" key should be different for all users who might roam onto that machine. Therefore the vlue of the key must change every time a different user logs on to the PC. As long as the sae user logs on every day, there is no need for the value to change.
"[TempFolder]".
Posted by:
Bartesque
19 years ago
If your users always used their own PCs and never roamed, you wouldn't have a problem. But it's very unusual to be in a position whereby you can say that no user will ever use another users' PC!
maybe i misunderstood you ..
Posted by:
WiseUser
19 years ago
Like I said... there are easier ways of solving your problem. Unfortunately, many of them aren't always desirable or permissable.
Whilst your quick fix may be acceptable in your environment, it would be a definate "no no" in many other environments. For a start, you're potentially allowing users to write data to an undesirable location. Depending on what the application is you could also be compromising confidential information.
Even using the "TempFolder" may have been a bad option in the first place. If an application uses information from that folder from one session to another, it may be preferable to use a roaming or redirected folder.
Whilst your quick fix may be acceptable in your environment, it would be a definate "no no" in many other environments. For a start, you're potentially allowing users to write data to an undesirable location. Depending on what the application is you could also be compromising confidential information.
Even using the "TempFolder" may have been a bad option in the first place. If an application uses information from that folder from one session to another, it may be preferable to use a roaming or redirected folder.
Posted by:
Bartesque
19 years ago
"[TempFolder]".
Oh thats a property ;-)
Like I said... there are easier ways of solving your problem. Unfortunately, many of them aren't always desirable or permissable.
Well, i can't argue with your consideration for a secure invironment, as it may be different for every company, but was just looking for the techinal approach, as i realize that you have to change the HKLM key for every user - made me think if it would accept the key in HKCU, but also there is an issue how long you can spend on one package, considering this is small package for a low percentage of company users i made the easy choice
Thanks for your input!
Bart [8|]
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.