Admin rights for basic users

Topics: User Forum
Jan 30, 2013 at 6:24 PM

I am trying to configure this software to run in an environment where users do not, and for the most part, will not receive admin rights.  
The host OS will be Windows 7 in an Enterprise environment.  UAC is activated, users are predominantly academics.  Standard users do not have the ability to escalate privilege, yet we want to enable them access to this software.  We do have the option to provide virtual machines with admin rights as a last resort, but this brings in potential usage hassles with camera/audio etc. 

Does anyone have experience using tools like the Application Compatibility Toolkit & RegMon/ProcMon to identify what the admin rights are required for?  Could one of the dev team perhaps shed some light on why this software has been written in this way, and if there is an intention to develop this in a fashion that is compatible with the security model that has been present in Windows for the past 8 years?


Many thanks in advance.

Jan 30, 2013 at 9:13 PM
Yes, I can shed some light on this. The bulk of the work on ConferenceXP was done pre-Vista as you might be able to guess by the name. In that era there was a movement to make software do installation on first run and thereby allow installation to be done simply by copying files around. For various reasons it later turned out that this was not such a great idea, but the admin requirement appears to be an artifact of this movement.

The only thing I know of that it does at launch that would require admin is to install the DirectShow filters used by the RTP code, but after this has been done once on a system I don't think it should require admin any more. This conclusion is just from memory and a few minutes of searching the source, and should be verified by testing before it's given credence.

The bottom line is I think it should be possible to do what you want without too much trouble. It looks like there's a manifest attached to the exe that makes it request elevation. You can probably remove that. I think you would also need to comment out the code that makes it quit if the admin check fails in MSR.LST.ConferenceXP\Conference\Installation.cs. You would still need to run once as admin to install the filters, but then it should work for non-admins after that.

In case you're not set up to build from source, let me know and I can give it a try.

Cheers, Fred
Jan 30, 2013 at 9:19 PM
Hi Fred, thanks for your quick response to my query.

What you've outlined certainly makes sense - both historically and as a fix.
I will try editing, recompiling then testing and report back with the outcome.

Cheers, James.
Feb 4, 2013 at 12:50 AM
I've installed visual studio 2010 express and tried escaping a set of code (that looks to me like it is the check you were meaning) in MSR.LST.ConferenceXP\Conference\Installation.cs (lines 106 to 170), also removed CXPClient.exe.manifest (MSR.LST.ConferenceXP\CXPClient\CXPClient.exe.manifest).

Recompiling using cxpbuild.bat release give me a large number of errors like the below example (but different .cs files referenced & different bracketed numbers):
frmAVDevices.cs(900,32): error CS0246: The type or namespace name 'FilterInfo' could not be found (are you missing a using directive or an assembly reference?) 
I have no idea what I'm actually doing here, if you are able to make good on the offer to have a go at rebuilding with your suggested changes, I would be massively appreciative.
Feb 4, 2013 at 8:46 PM

Actually I didn't change anything, other than removing the manifest to get rid of the elevation prompt. It looks like it won't hit the install code if the registry key exists HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft Research\ConferenceXP\ConferenceAPIInstalled with value True, and it should after it has been run once. The zip just contains the exe. Use it to replace the copy in your application directory once everything is working under the admin account. Let me know if that works or not..

Feb 5, 2013 at 12:19 AM
You're a legend, that works like a treat!

I'm running in x64, so the registry entry you mention is "HKEY_LOCAL_MACHINE\SOFTWARE\ Wow6432Node \Microsoft Research\ConferenceXP\ConferenceAPIInstalled". That is created on installation, as is the Windows firewall rule.

Our SCCM install package now simply completes a silent .msi install, then overwrites cxpclient.exe in Program Files (x86).
When users run it they receive no escalation prompt, and seem to have access to all features as expected.

Many thanks for the time and effort you have put in to assist us continuing to use the software.
Feb 5, 2013 at 6:14 PM
Ok, no problem. I'm glad to hear it's working.

As a side note, I've documented this in the ConferenceXP user guide:

Jul 23, 2013 at 9:09 PM
Nice workaround, Fred! As James said, "You're a legend!"