Vista, Windows 7 & Windows 8 Issues

With the introduction of Windows Vista and subsequently the releases of Windows 7 and Windows 8, Microsoft added a significant amount of additional security to these operating systems.

Generally referred to as UAC (User Account Control), the sum of these changes dramatically affect named users who might be categorized as "standard" or "general" users. Areas that previously had been quite open, allowing these users to modify, create and delete items like files and registry entries are now protected as default. Users with standard rights and privileges on these systems are now as a default prevented from making changes in such areas as the Program Files folder, the Windows folder and in the Windows registry area known as HKEY_LOCAL_MACHINE.

In addition, Microsoft published numerous guidelines and usage information regarding these changes. Some of the guidelines would cause applications who require the end-user to be able to modify preference settings, etc., to place files in several locations on the PC. While these changes do enhance the overall security of the operating system, having files and information for a specific application spread all over the system in places not intuitive or easy to find creates a significant support burden for the application vendor.

Over the years, we have chosen to try to keep all of our application's files, including those that store preferences, files containing run-time information like exception logging and activity detail, and small database files, in one location for ease in troubleshooting and housekeeping.

For these reasons, our applications are generally placed in a folder other than the Microsoft-recommended Program Files folder. As a default, these other folders historically have been "wide open" in the sense that any user could read, write and modify files.

However, depending on how tightly-secured a system is when running Vista or Windows 7, issues may arise that relate to user rights. The following points may assist you in locating problems with iDAF when running one of these operating systems and the user reporting issues does not have administrative privileges.

1.Make sure that user having trouble with iDAF has read, write, modify and delete privileges in the folder in which iDAF is installed. These privileges might be assigned to an individual user but more commonly are assigned to a user group of which the user is a member.

2.If you are placing files in a location other than the iDAF folder, ensure that the named user has read, write, modify and delete privileges in that folder location.

3.One way that some issues can be overcome is to modify any iDAF shortcuts to cause the application to be run under administrator privileges. [Right-Click] on the shortcut and select the menu item "Run as Administrator". A negative of this approach is that the end-user will more than likely have to enter an administrative password, which defeats the concept of administrative security as you'd have to provide the user with the password.
 
Another approach some people use is to disable UAC. While this action more or less returns user accounts to the sort of status they had in previous versions of Windows, this too defeats the idea of enhanced operating system security.

 

---