Re: [WiX-users] advertised install and user permissions
I would like to thank Phil (and others on this list) for the assistance in tracking down this problem. The core problem is related to the following attempt to write this registry value when the value of the SDA property is not an integer: RegistryValue Root=HKMU Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / It was introduced several weeks ago when I changed how the SDA property was initialized. I incorrectly assumed that my mba would initialize this property's value.However when the on-demand install kicks in after the initial install of the burn bundle, (with this msi marked to be published as an advertised feature), this property was not initialized and was blank. (This is why this problem only showed up when an on-demand, after a first-install of the bundle was done. In all other scenarios the mba provided a default value.). The msi error (reporting an access problem with the key location) was related to the attempt at runtime to resolve #[SDA] when SDA was an uninitialized string and not a valid integer. The permissions error did not relate to the location of where the registry value was to be created or the context of the user as implied in the message. Thanks again for your help in understanding this issue. Phill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594127.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
It's not that you want to violate security, but that the situation seems to be that now a limited user cannot create a HKLM key where previously it apparently worked. My point about other users and HKCU was that I couldn't tell if you were advertising a feature for the same user or you were advertising in the sense that a different user logs on and gets install on demand of missing items, but they would typically be user profile items and not HKLM items. Regardless of the elevation of the original install, it's not clear to me that a limited user is allowed to create HKLM items under any circumstances that aren't somehow blessed by an administrator. I don't exactly know the privileges of the actors in your scenarios of repair and advertisement, sorry if I missed that. There's also the logging policy option - if you're not getting logging for the advertise error the system-wide logging policy might tell you what's going on. If you still have the original MSI that worked ok you could reproduce the original working scenario with a log, or reverse engineer what's different by looking at the MSI files. Assuming the actors are limited users, the kind of thing that might have happened is that the old MSI worked accidently because of some issue that caused a repair to install that key. That's different from a situation where the new MSI is more explicitly trying to have a limited user create a HKLM item. I think that's the general are I'd look at based on that starting theory, and look for logs and other data that might support or disprove it, and at the keypaths and component/feature ownership of the items. --- Phil Wilson On Fri, Apr 11, 2014 at 4:06 PM, Phill Hogland phogl...@rimage.com wrote: I don't want to violate the security. The applications in the bundle were installed on the first install in a per-machine install. Burn was elevated at the UAC prompt. There are many other keys which are part of this app which are also written under HKLM. (I am not intending to do a per-user install.) However in one MSI package in my bundle chain, the only Feature had: Feature Id=QuickDisc Title=$(var.AppName) Level=1 InstallDefault=local TypicalDefault=advertise and there is a shortcut on the desktop which is advertised. So for some time now (testing on Windows 8) I run the bundle and all packages get installed, but the files related to this particular package do not get installed, until after the bundle completes and I click on the application's desktop shortcut. At which point msiexec launches the package to do what I am calling the 'advertised' install of the files, and then launches the application. (I did not realize that it is a 'repair' if that is the case.) So these registry keys that write to HKLM have been part of the package for some time, but only recently does this one fragment, which I moved from one wxs to another wxs file start displaying this error. The log for this package when Burn is running is verbose, but when the shortcut launches msiexec only the error line is displayed. I will work on this more next week. Since I want to install the application on a per-machine basis (and write config info to HKLM) it sounds like I should not allow the feature to be advertised (or go back to the application developer and get them to write the application so that interaction with HKLM is not needed, which I would prefer). I think I assumed that when Burn was run, and UAC was accepted to elevate the install, that the automatic invoking of msiexec by clicking on the advertised shortcut would either also run elevated (or that the elevated stuff had already been done when the package was launched by burn as a per-machine ALLUSER=1 package). So am a little confused wondering: 1) why it worked for so long and when I moved source code it stopped working? (I know, I should know what I changed more than others.) But I wonder if I am missing something in understanding this. 2) If the install of the application (by clicking on the advertised shortcut) is in a per user context, and this is a per-machine setup, should I disable advertising the feature? or do something else to prevent this? In the MSI package (on Win 7 and later, based on the MSDN ALLUSERS docs) should set the properties in my MSI of ALLUSERS and MSIINSTALLPERUSER to assure a per-machine installation? I'm just wondering what the best approach for a per-machine installation, and not trying to do something that would violate security. thanks for any advice. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594083.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test
Re: [WiX-users] advertised install and user permissions
Thank you for your time and comments. I am still digging through the verbose log captured during the on-demand install. I am also re-reading the sections in your book related to on-demand installs. One brief clarification is that I run the wix bundle (with multiple msi packages), which I compiled, for the first time on a Windows 8 x64 test system. After the bundle completes the advertised shortcut related to the msi package and Feature which writes this registry key is on the desktop (or in the (non-existent :) ) start menu ). Since the bundle did prompt for elevation, my initial assumption was that a later on-demand of the same user would be a managed install. So immediately after the first-install of the bundle has completed I click on the applications's shortcut which starts a on-demand install in the same Admin but not elevated context as when I initially launched the Bundle. Before the on-demand setup starts the registry looks like this: HKLM\SOFTWARE\Wow6432Node\Company (with a subkey related to another application which was also installed). Note the Company key was created by the first-install of the bundle on a clean system, or it may exist if another Company product has previously created it. During the on-demand install, toward the end I get this error message: MSI (s) (58:FC) [14:02:01:505]: Executing op: RegOpenKey(Root=-2147483646,Key=SOFTWARE\Classes\Applications\AppName\SupportedTypes,,BinaryType=0,,) MSI (s) (58:FC) [14:02:01:505]: Executing op: RegAddValue(Name=.qdd,,) MSI (s) (58:FC) [14:02:01:505]: Executing op: RegAddValue(Name=.qws,,) MSI (s) (58:FC) [14:02:01:505]: Executing op: RegOpenKey(Root=-2147483646,Key=SOFTWARE\Rimage,,BinaryType=0,,) MSI (s) (58:FC) [14:02:01:505]: Executing op: RegAddValue(Name=SDA,Value=#,) MSI (s) (58:FC) [14:02:01:505]: Note: 1: 1406 2: SDA 3: SOFTWARE\Company MSI (c) (C8:64) [14:02:01:536]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg MSI (c) (C8:08) [14:02:04:485]: Machine policy value 'DisableUserInstalls' is 0 Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:02:38:930]: Product: Company AppName -- Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:02:38:930]: Note: 1: 1406 2: SDA 3: SOFTWARE\Company MSI (c) (C8:64) [14:02:38:930]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:02:41:442]: Product: Company AppName -- Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:02:41:442]: Note: 1: 1406 2: SDA 3: SOFTWARE\Company MSI (c) (C8:64) [14:02:41:442]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:02:42:986]: Product: Company AppName -- Error 1406. Could not write value SDA to key \SOFTWARE\Rimage. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:02:42:986]: Note: 1: 1406 2: SDA 3: SOFTWARE\Company MSI (c) (C8:64) [14:02:42:986]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. MSI (s) (58:FC) [14:04:00:004]: Product: Company AppName -- Error 1406. Could not write value SDA to key \SOFTWARE\Company. System error . Verify that you have sufficient access to that key, or contact your support personnel. After the on-demand install the registry looks like this: HKLM\SOFTWARE\Wow6432Node\Company\AppName\SubKey many values in 'SubKey' The action which fails is trying to write a value to : HKLM\SOFTWARE\Wow6432Node\Company The registry permissions appear to be the same between the key which fails and the subkeys which are written to in the same on-demand install. But those keys are authored with HKMU and the key which fails is authored with HKLM. I plan to investigate this further tomorrow. I made a conscious distinction in authoring the root selection but may be the problem. The use of HKLM for this key which failed is driven by the application design, which I probably need to work out with that developer. The use of HKMU for the subkeys was because my setup controls the purpose for those
Re: [WiX-users] advertised install and user permissions
Is your MSI per-machine? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Thursday, April 10, 2014 4:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] advertised install and user permissions I have a bundle with a number of msi pacakges, one of which has a feature which is advertised. Recently (probably because I changed something in the authoring) I am noticing a behavior where if I install the bundle, then after that completes successfully, click on the advertised shortcut, then the advertised package is installed. But the change in behaviour is that one of the registry keys produces a warning that the user does not have the correct permissions to write to that key. (The key location is in HKLM.) If I run the bundle again selecting 'repair' (with a verbose log) there is no warning and the key is written successfully. When the bundle launches the package the ALLUSERS is 1. Even though I am using InstallerVersion='500' and testing on Windows 8 x64, when I have MsiLogging=v* I don't get any additional information from the log produced by the advertised portion of the install, which only indicates that it failed to write this specific key. Can someone help my understand the problem and advise on the best approach for a situation were I want the install to be per-machine and I need to write to HKLM. Should I just disallow the advertised feature, or is there something else I should do? Thanks for the assistance! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
Yes, the MSI package has the following: Package Platform=x86 Description=$(var.AppNameLong) InstallerVersion=500 Compressed=yes InstallScope=perMachine SummaryCodepage=!(loc.SummaryCodepage) / When this package is launched as part of the bundle chain the log indicates that ALLUSERS is 1. This package has been installing with the feature advertized, but without complaining about this registry value for some time. However I recently refactored some of the wxs files to make then more maintainable, and I moved this registry key to a different fragment, but also associated with the same advertised feature. This old code, which did not result in an error, and the key was written during the advertised portion of the install: Fragment ComponentGroup Id=QD_HKLM_SOFTWARE_RegKeys Component Directory=QuickDiscDir RegistryValue Root=HKLM Key=SOFTWARE\Company Name=SDA Value=0 Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment This is the current code which does result in the error (but only when being installed as result of advertised feature): Fragment ComponentGroup Id=$(var.ProductAbreviation).uniqueProperties Directory=$(var.ProductDir) Component RegistryValue Root=HKLM Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment I also found that I can add AllowAdvertise=no to the feature and avoid the problem, but I appreciate any advice so that I can understand this behavior and learn the best practices to avoid this problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
When you say it's advertised, I'm not sure whether you're referring to other users on the machine, and if some of the scenarios are about an administrator doing a repair but a limited user can't use the advertised feature correctly. If it's registry data intended for different users it typically goes into HKCU so that each new user gets the data when they use the feature. Windows Installer does not violate security rules, so if the basic situation is that a limited user is doing something that installs registry data to HKLM then I can't see that working without some administrator blessing somewhere (such as via group policy). You probably need logging policy set to get log for these spontaneous repair-type situations: http://support.microsoft.com/kb/223300 or the issue might be that you're using * in MsiLogging, which seems to like * so spell out the options: http://msdn.microsoft.com/en-us/library/aa370322(v=vs.85).aspx --- Phil Wilson On Fri, Apr 11, 2014 at 6:20 AM, Phill Hogland phogl...@rimage.com wrote: Yes, the MSI package has the following: Package Platform=x86 Description=$(var.AppNameLong) InstallerVersion=500 Compressed=yes InstallScope=perMachine SummaryCodepage=!(loc.SummaryCodepage) / When this package is launched as part of the bundle chain the log indicates that ALLUSERS is 1. This package has been installing with the feature advertized, but without complaining about this registry value for some time. However I recently refactored some of the wxs files to make then more maintainable, and I moved this registry key to a different fragment, but also associated with the same advertised feature. This old code, which did not result in an error, and the key was written during the advertised portion of the install: Fragment ComponentGroup Id=QD_HKLM_SOFTWARE_RegKeys Component Directory=QuickDiscDir RegistryValue Root=HKLM Key=SOFTWARE\Company Name=SDA Value=0 Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment This is the current code which does result in the error (but only when being installed as result of advertised feature): Fragment ComponentGroup Id=$(var.ProductAbreviation).uniqueProperties Directory=$(var.ProductDir) Component RegistryValue Root=HKLM Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment I also found that I can add AllowAdvertise=no to the feature and avoid the problem, but I appreciate any advice so that I can understand this behavior and learn the best practices to avoid this problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
...ooops MsiLogging, which seems NOT to like * so spell out the options.. --- Phil Wilson On Fri, Apr 11, 2014 at 12:01 PM, Phil Wilson phildgwil...@gmail.com wrote: When you say it's advertised, I'm not sure whether you're referring to other users on the machine, and if some of the scenarios are about an administrator doing a repair but a limited user can't use the advertised feature correctly. If it's registry data intended for different users it typically goes into HKCU so that each new user gets the data when they use the feature. Windows Installer does not violate security rules, so if the basic situation is that a limited user is doing something that installs registry data to HKLM then I can't see that working without some administrator blessing somewhere (such as via group policy). You probably need logging policy set to get log for these spontaneous repair-type situations: http://support.microsoft.com/kb/223300 or the issue might be that you're using * in MsiLogging, which seems to like * so spell out the options: http://msdn.microsoft.com/en-us/library/aa370322(v=vs.85).aspx --- Phil Wilson On Fri, Apr 11, 2014 at 6:20 AM, Phill Hogland phogl...@rimage.com wrote: Yes, the MSI package has the following: Package Platform=x86 Description=$(var.AppNameLong) InstallerVersion=500 Compressed=yes InstallScope=perMachine SummaryCodepage=!(loc.SummaryCodepage) / When this package is launched as part of the bundle chain the log indicates that ALLUSERS is 1. This package has been installing with the feature advertized, but without complaining about this registry value for some time. However I recently refactored some of the wxs files to make then more maintainable, and I moved this registry key to a different fragment, but also associated with the same advertised feature. This old code, which did not result in an error, and the key was written during the advertised portion of the install: Fragment ComponentGroup Id=QD_HKLM_SOFTWARE_RegKeys Component Directory=QuickDiscDir RegistryValue Root=HKLM Key=SOFTWARE\Company Name=SDA Value=0 Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment This is the current code which does result in the error (but only when being installed as result of advertised feature): Fragment ComponentGroup Id=$(var.ProductAbreviation).uniqueProperties Directory=$(var.ProductDir) Component RegistryValue Root=HKLM Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment I also found that I can add AllowAdvertise=no to the feature and avoid the problem, but I appreciate any advice so that I can understand this behavior and learn the best practices to avoid this problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
I don't want to violate the security. The applications in the bundle were installed on the first install in a per-machine install. Burn was elevated at the UAC prompt. There are many other keys which are part of this app which are also written under HKLM. (I am not intending to do a per-user install.) However in one MSI package in my bundle chain, the only Feature had: Feature Id=QuickDisc Title=$(var.AppName) Level=1 InstallDefault=local TypicalDefault=advertise and there is a shortcut on the desktop which is advertised. So for some time now (testing on Windows 8) I run the bundle and all packages get installed, but the files related to this particular package do not get installed, until after the bundle completes and I click on the application's desktop shortcut. At which point msiexec launches the package to do what I am calling the 'advertised' install of the files, and then launches the application. (I did not realize that it is a 'repair' if that is the case.) So these registry keys that write to HKLM have been part of the package for some time, but only recently does this one fragment, which I moved from one wxs to another wxs file start displaying this error. The log for this package when Burn is running is verbose, but when the shortcut launches msiexec only the error line is displayed. I will work on this more next week. Since I want to install the application on a per-machine basis (and write config info to HKLM) it sounds like I should not allow the feature to be advertised (or go back to the application developer and get them to write the application so that interaction with HKLM is not needed, which I would prefer). I think I assumed that when Burn was run, and UAC was accepted to elevate the install, that the automatic invoking of msiexec by clicking on the advertised shortcut would either also run elevated (or that the elevated stuff had already been done when the package was launched by burn as a per-machine ALLUSER=1 package). So am a little confused wondering: 1) why it worked for so long and when I moved source code it stopped working? (I know, I should know what I changed more than others.) But I wonder if I am missing something in understanding this. 2) If the install of the application (by clicking on the advertised shortcut) is in a per user context, and this is a per-machine setup, should I disable advertising the feature? or do something else to prevent this? In the MSI package (on Win 7 and later, based on the MSDN ALLUSERS docs) should set the properties in my MSI of ALLUSERS and MSIINSTALLPERUSER to assure a per-machine installation? I'm just wondering what the best approach for a per-machine installation, and not trying to do something that would violate security. thanks for any advice. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594083.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] advertised install and user permissions
I have a bundle with a number of msi pacakges, one of which has a feature which is advertised. Recently (probably because I changed something in the authoring) I am noticing a behavior where if I install the bundle, then after that completes successfully, click on the advertised shortcut, then the advertised package is installed. But the change in behaviour is that one of the registry keys produces a warning that the user does not have the correct permissions to write to that key. (The key location is in HKLM.) If I run the bundle again selecting 'repair' (with a verbose log) there is no warning and the key is written successfully. When the bundle launches the package the ALLUSERS is 1. Even though I am using InstallerVersion='500' and testing on Windows 8 x64, when I have MsiLogging=v* I don't get any additional information from the log produced by the advertised portion of the install, which only indicates that it failed to write this specific key. Can someone help my understand the problem and advise on the best approach for a situation were I want the install to be per-machine and I need to write to HKLM. Should I just disallow the advertised feature, or is there something else I should do? Thanks for the assistance! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
