>>>>>In vfp3 I used to make a dummy setup consisting of one file in order to install the runtime module on machines here. We use Win NT 4. I have just tried to do the same thing now that I have vfp6. It's telling me I need admin priveledges. Why would it need them? What is it doing now that it didn't do before? I'm not aware that the permissions of ordinary users like me have been restricted lately, though I can ask the sysadmin tomorrow.
>>>>
>>>>Users that are not Adminiostrators are not guarenteed access to all registry keys, or to be able to update shared files. You can hack the .STF to bypass this check.
>>>
>>>I'll probably just go find an administrator, but how would I go about hacking the .STF? I found this line in SETUP.STF:
>>>
>>>12 Setup Message Installation of this product requires system administrator privileges. CustomAction "wizset32.dll, DetectAdminPrivileges"
>>>
>>>I didn't see any other lines that seemed pertinent. Thanks for the help.
>>
>>Look for a line with a Depend action that references that line (a Depend is a conditional execution). Simply find the Depend that contains the reference to the Setup Message line (in your case, 12) and blank out the 12 - do not delete the entire line. This will cause the line above to never be executed. For example, this is cut from an existing Setup Wizrd install:
>>
>>
37 Depend 30 ? 38 39 40 : 38 39 41 40 42
>>38 InstallSysFile """System"", ""Olepro32Dll"""
>>39 OLEPRO32.DLL SelfReg """System"", Olepro32Dll" %M
>>40 InstallSysFile """System"", ""Oleaut32Dll"""
>>41 Setup Message Installation of this product requires system administrator privileges. CustomAction "wizset32.dll, DetectAdminPrivileges"
>>
>>
>>to eliminate the test for Admin privileges, change line 37 above to read:
>>
>>
>>37 Depend 30 ? 38 39 40 : 38 39 40 42
>>
>>note that all I did was eliminate the reference; the line stayed in place.
>>
>>This modification is not documented by or approved by MS - if your install stops working reliabily, they'll tell you to put it back in and install as an Administrator.
>
>I have no "Depend" line that mentions line 12. I have two other lines that do. These are them:
>
>1 Search for previous versions. AppSearch """C:\DUMMYAPP"", """", """", 12, ""yes"", ""yes"","
>
>...and...
>
>7 Yes runtime only runtime only will be installed. Group 8 9 12 11 10 13 14
>
>Shall I just delete the 12 in each line and let'er rip? All our admins are AWOL at the moment. Furthermore, I will be distributing an app soon and I would rather not require the user to get her own admin.
>
I'd try removing the one from the Group command (line 7), not from the AppSearch line (line 1).
>It would be nice to know more about how this script works, in case my installation changes. Is it documented anywhere, if not by MS? Also, I'd like to know what I am risking if I somehow change it so that admin privileges are not required. My installations are pretty basic.
There is very little documentation on the ACMSetup that I've been able to locate - some stuff in th MS Office Administrator docs and scattered references in the MSDN.
What you're risking by not checking for Admin privileges is that some of the job steps may fail as a result of insufficient rights and privileges. It is not uncommon for a saavy NT administrator to block some users from writing to certain registry hives, or updating common files in system directories - and both are done during the install. Without a fair amount of programming at each job step to check user permissions on a task, the only 100% safe way to know that the user has the necessary rights is to check if the user is a local Administrtor equivalent, which is done by the CustomAcion callinto wizsetup.dll in the script.
