This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Shared folder permissions for Vista & Server 2008
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 08, 2009
05:31 PM
Shared folder permissions for Vista & Server 2008
In my previous install, I would create a folder :
C:\Program Files\Company\Product\Data
This "Data" folder was shared with permissions on Everyone set to full, and NTFS permissions for Everyone set to modify. This allowed a client/server style installation where other pc's on the network could view and edit the shared "Data" folder. This "Data" folder contained such information as the database connection string for our app, as well as images that are stored in the database.
Since Vista and Server 2008 I am unsure on where to deploy this folder to achieve the same functionality. All installations are performed by a user with administrator rights, then the application launched by a standard user.
This is what I have tired thus far in my InstallScript MSI project:
FOLDER_COMMON_APPDATA ^ "Company\\Product\\Data";
Installs to C:\ProgramData\Company\Product\Data.
Standard user does not have access to Data unless specific shares are applied.
MSDN: This folder should be used for application data that is not user specific. For example, an application may store a spell check dictionary, a database of clip-art or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer. By default, this location is read-only for normal (non-admin, non-power) Users. If an application requires normal Users to have write access to an application specific subdirectory of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that sub-directory during application setup. The modified security must be documented in the Vendor Questionnaire.
After sharing the Data folder, the standard user has modify permissions and can access Data from within Product application, but cannot see "Data" folder in Windows Explorer. The user should be able to view this in Explorer.....
FOLDER_APPDATA ^ "Company\\Product\\Data";
Install to C:\Users\Admin\AppData\Roaming\Data
Standard user doesn't have access to the "Adminr" user AppData folder.
Standard user is prompted for the "Admin" user password to view this folder.
MSDN: As part of the User profile, this folder will roam. Use this folder to store all user-specific application preferences. For example, if a user can specify a custom dictionary to be used in your application, you should store it here. That way if the user roams from computer to computer, their dictionary will roam with them. This also allows other users to have their own individual custom dictionaries.
FOLDER_LOCAL_APPDATA ^ "Company\\Product\\Data";
Install to C:\Users\Admin\AppData\Local\Company\Product\Data
Standard user does not have access to the "Admin" user AppData folder.
Standard user is prompted for the "Admin" user password to view this folder.
MSDN: This folder is for application data that does not roam. It is still part of the User profile, so this is still per-user information. Application data that is machine-dependent, such as user specified monitor resolution, should be stored here. This data must not roam because different machines have different monitors. In addition, large blocks of data which can easily be re-created should be placed here to minimize download time that is incurred when roaming. For example, Internet Explorer keeps its cache of downloaded html/gif pages here so that they don't roam with the user. But the smaller cookie and history lists are stored in CSIDL_APPDATA so that they roam.
%PUBLIC% ^ "Company\\Product\\Data";
Install to C:\Users\Public\Company\Product\Data
Standard user does have access to the folder.
The Public folder in Windows Vista is used for sharing folders and files with people on the same computer or the same network. The normal location for the public folder is C:\Users\Public
I am presently using the last option which has thus far been working quite well.
Problem: When I use a server/client situation, the Server installation on Win 2008 requires that the Public Folder Sharing be manually turned on. This of course shares the entire Public folder on the network, which I am guessing is not desireable.
Where should I be deploying this kind of folder??? It appears if it was deployed to the root drive it all works fine, but of course, that would be very unprofessional.
C:\Program Files\Company\Product\Data
This "Data" folder was shared with permissions on Everyone set to full, and NTFS permissions for Everyone set to modify. This allowed a client/server style installation where other pc's on the network could view and edit the shared "Data" folder. This "Data" folder contained such information as the database connection string for our app, as well as images that are stored in the database.
Since Vista and Server 2008 I am unsure on where to deploy this folder to achieve the same functionality. All installations are performed by a user with administrator rights, then the application launched by a standard user.
This is what I have tired thus far in my InstallScript MSI project:
FOLDER_COMMON_APPDATA ^ "Company\\Product\\Data";
Installs to C:\ProgramData\Company\Product\Data.
Standard user does not have access to Data unless specific shares are applied.
MSDN: This folder should be used for application data that is not user specific. For example, an application may store a spell check dictionary, a database of clip-art or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer. By default, this location is read-only for normal (non-admin, non-power) Users. If an application requires normal Users to have write access to an application specific subdirectory of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that sub-directory during application setup. The modified security must be documented in the Vendor Questionnaire.
After sharing the Data folder, the standard user has modify permissions and can access Data from within Product application, but cannot see "Data" folder in Windows Explorer. The user should be able to view this in Explorer.....
FOLDER_APPDATA ^ "Company\\Product\\Data";
Install to C:\Users\Admin\AppData\Roaming\Data
Standard user doesn't have access to the "Adminr" user AppData folder.
Standard user is prompted for the "Admin" user password to view this folder.
MSDN: As part of the User profile, this folder will roam. Use this folder to store all user-specific application preferences. For example, if a user can specify a custom dictionary to be used in your application, you should store it here. That way if the user roams from computer to computer, their dictionary will roam with them. This also allows other users to have their own individual custom dictionaries.
FOLDER_LOCAL_APPDATA ^ "Company\\Product\\Data";
Install to C:\Users\Admin\AppData\Local\Company\Product\Data
Standard user does not have access to the "Admin" user AppData folder.
Standard user is prompted for the "Admin" user password to view this folder.
MSDN: This folder is for application data that does not roam. It is still part of the User profile, so this is still per-user information. Application data that is machine-dependent, such as user specified monitor resolution, should be stored here. This data must not roam because different machines have different monitors. In addition, large blocks of data which can easily be re-created should be placed here to minimize download time that is incurred when roaming. For example, Internet Explorer keeps its cache of downloaded html/gif pages here so that they don't roam with the user. But the smaller cookie and history lists are stored in CSIDL_APPDATA so that they roam.
%PUBLIC% ^ "Company\\Product\\Data";
Install to C:\Users\Public\Company\Product\Data
Standard user does have access to the folder.
The Public folder in Windows Vista is used for sharing folders and files with people on the same computer or the same network. The normal location for the public folder is C:\Users\Public
I am presently using the last option which has thus far been working quite well.
Problem: When I use a server/client situation, the Server installation on Win 2008 requires that the Public Folder Sharing be manually turned on. This of course shares the entire Public folder on the network, which I am guessing is not desireable.
Where should I be deploying this kind of folder??? It appears if it was deployed to the root drive it all works fine, but of course, that would be very unprofessional.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2009
10:33 PM
OK, a simpler question:
How can I check via InstallScript if Public Folder Sharing is enabled ?
How can I check via InstallScript if Public Folder Sharing is enabled ?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 23, 2010
01:07 AM
Option Explicit
Const FILE_SHARE = 0
Const MAXIMUM_CONNECTIONS = 25
Dim objShare
'Connect to WMI
Dim objWMIService: Set objWMIService = _
GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
'Query share names for existing share
Dim colShares: Set colShares = objWMIService.ExecQuery _
("Select * from Win32_Share Where Name = 'MyShare'")
'Check share if one exists with the same name already
For Each objShare in colShares
msgbox "ShareExists"
Next
Const FILE_SHARE = 0
Const MAXIMUM_CONNECTIONS = 25
Dim objShare
'Connect to WMI
Dim objWMIService: Set objWMIService = _
GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
'Query share names for existing share
Dim colShares: Set colShares = objWMIService.ExecQuery _
("Select * from Win32_Share Where Name = 'MyShare'")
'Check share if one exists with the same name already
For Each objShare in colShares
msgbox "ShareExists"
Next
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)