CCA 2.1 forces you to disable User Account Control

Unanswered Question
Oct 13th, 2009
User Badges:
  • Silver, 250 points or more

CCA 2.1 actually fails to launch if User Account Control is enabled on Windows Vista. A program actually should not refuse to launch if User Account Control is enabled. This is actually incorrect behavior for the following reasons:

  • CCA 1.8, 1.9, and 2.0 will run correctly on Windows Vista with User Account Control enabled
  • CCA 2.1 will break on Windows 7 with its User Account Control detection code
  • Elevating the process (by right-clicking on the CCA icon, and selecting Run As Administrator) in an administrator user account will have the same effect as running the program with User Account Control disabled
  • The CCA installer can create folders that are writable by all users on the machine by having the appropriate entries in the access control list. This will ensure that CCA can write files to the special folders, even with User Account Control enabled.
  • The CCA executable should have the appropriate manifest added to it so that it will run correctly with User Account Control enabled and so that files are written to the correct locations.
  • It violates the software design guidelines for Windows Vista and Windows 7
  • Windows Logo guidelines for Windows Vista and Windows 7 require that applications run properly with User Account Control enabled
  • The user experience is not very good if you have to disable User Account Control just to get CCA running
  • Other Cisco applications, such as the Cisco VPN Client or the Cisco IP Communicator softphone, do not require you to enable you to disable User Account Control


The correct behavior on Windows Vista and later is not to detect if UAC is enabled, but to detect if elevation is necessary and to elevate the process if it is really necessary. A program should be designed such that it runs correctly with UAC enabled.


CCA 2.2 should be launchable with User Account Control enabled, and should behave correctly on Windows XP, Windows Vista (with the default UAC settings), and Windows 7 (with the default UAC settings). The UAC detection should really be removed in CCA 2.2, particularly because it breaks Windows 7 compatibility and provides a poor end user experience.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Saurabh Verma Tue, 10/13/2009 - 14:15
User Badges:
  • Silver, 250 points or more

I have provided the feedback to the CCA team. They will evaluate the feasibility of adding this on their roadmap.


Thanks,

Saurabh

David Trad Tue, 10/13/2009 - 15:30
User Badges:
  • Gold, 750 points or more
  • Cisco Designated VIP,

    2013 Small Business

Hi Saverma,



I have provided the feedback to the CCA team. They will evaluate the feasibility of adding this on their roadmap.



I would have thought this would be done by default and that no feasibility would need to be carried out? CCA requires the highest permissions to functions, this is because it resides in the Program Files directory which also requires permissions to write into, it is the same for all other programs that reside in there.



Right now for those who use Vista or Win-7, it is a must to right click on the file, go to properties and make sure that it runs as Administrator all the time, by not doing so, you run a pretty high risk of having issues arise and failed upgrades.



I think we all know that Vista is the new ME, where as Windows 7 so far in the 8 months of using it has shown that it is by far the most robust OS (Equal too or better then XP), so your dev team should realise that most users in a short window of time will be using Win-7.



Just my opinion.




Cheers,




David.

John Platts Tue, 10/13/2009 - 16:07
User Badges:
  • Silver, 250 points or more

Microsoft has actually described one solution for programs writing to the Program Files directory. This workaround is compatible with Windows XP, Windows Vista, and Windows 7.


The workaround is to:

  • Create a subdirectory below the program installation directory that is readable and writable by everyone. This is accomplished by creating a directory that is one level below the program directory (and at least two levels below the Program Files directory if the program directory is a subdirectory one or more levels below the Program Files directory), and then modifying the access control list of the subdirectory to make it both readable and writable by everyone. The access control list of this subdirectory is set in a manner that the read and write privileges apply to all files and folders within this subdirectory.
  • Make sure that the executables contain the requestedExecutionLevel element within their manifest


Advantages of the above workaround:

  • The subdirectory created in the workaround has the additional privileges granted so that the application can write to the subdirectory without requiring administrator privileges
  • The above workaround is compatible with User Account Control
  • The above workaround works with Windows XP, Windows Vista, and Windows 7
  • The Program Files directory or the program directory is not writable without administrator privileges, except for the subdirectory created by the workaround and the files and folders within that subdirectory
  • Eliminates errors caused by attempting to write files to a non-writable directory


I found this workaround on the MSDN web site.

Saurabh Verma Wed, 10/14/2009 - 05:48
User Badges:
  • Silver, 250 points or more

Thanks John. I have provided the feedback to the team. They are evaluating the changes required in software. I will updated the thread on the timeline for this fix.


Thanks for providing all the information.


-Saurabh

Saurabh Verma Fri, 10/23/2009 - 14:29
User Badges:
  • Silver, 250 points or more

Hi John,


There is an engineering fix available for User Account Control issue ... would like to verify the fix for us? If so, please send me a private message with your CCO userid, I will post the image for you.



Thanks,

Saurabh

Actions

This Discussion

Related Content