Dynamics GP: Resolving VBA Permission Errors for Non-Admin Users

Table of Contents

When working with Microsoft Dynamics GP, integrating customizations through Microsoft Visual Basic for Applications (VBA) is a common practice to tailor the system to specific business needs. However, users who do not possess local administrative rights on their workstations or domain-level administrative credentials may encounter significant obstacles when attempting to utilize VBA functionality. These permission-related issues can manifest in various ways, hindering the ability to customize windows, add custom logic, or even run existing VBA code deployed within the Dynamics GP environment. Understanding the root cause of these problems and applying the appropriate resolutions is crucial for ensuring a smooth and functional Dynamics GP experience for all users, regardless of their administrative privilege level. This guide provides detailed methods to address these persistent VBA permission challenges for non-administrator users within Microsoft Dynamics GP.

Symptoms¶

Users operating Microsoft Dynamics GP without sufficient administrative privileges may observe one or a combination of the following issues related to VBA integration. These symptoms typically occur without explicit error messages during the initial Microsoft Dynamics GP installation process, making troubleshooting potentially more challenging. The absence of clear error prompts often leads users to believe there might be an installation defect or a configuration problem unrelated to permissions, when in reality, it stems from restrictions imposed by the operating system’s security model on standard user accounts.

• Microsoft Dynamics GP does not link to Microsoft Visual Basic for Applications (VBA) Editor: When attempting to access the VBA Editor from within Dynamics GP, the editor window may fail to launch. This prevents users from writing, editing, or even viewing existing VBA code associated with Dynamics GP objects. The system behaves as if the link or integration point between Dynamics GP and the VBA environment is broken or inaccessible, effectively blocking any interactive development or debugging efforts directly from the application interface.
• Microsoft Dynamics GP does not copy windows or fields from Microsoft Dynamics GP to the Microsoft Dynamics GP project in VBA: A core functionality of VBA customization in Dynamics GP is the ability to drag and drop windows and fields from the Dynamics GP interface onto the VBA project explorer. This action transfers metadata about the selected object, allowing developers to write code that interacts with specific controls or events within those windows. When permissions are insufficient, this drag-and-drop functionality fails. The system does not register the attempted action, and the selected window or field does not appear in the VBA project hierarchy, making it impossible to reference and customize user interface elements programmatically.
• Microsoft Dynamics GP does not run existing VBA code: Perhaps the most critical symptom is the inability to execute pre-existing VBA code customizations. If a Dynamics GP installation has been enhanced with VBA scripts designed to automate tasks, enforce business rules, or modify behavior, these scripts will simply not run for non-administrator users. This can lead to unexpected application behavior, missing functionality, or errors, potentially disrupting workflows that rely on these customizations. This issue is particularly prevalent in multi-user environments, including those utilizing Terminal Server or Citrix, where user sessions often run with restricted permissions.

These symptoms collectively indicate that the standard user account lacks the necessary rights to interact correctly with the components or files that facilitate the Dynamics GP-VBA integration. The underlying cause is deeply tied to how Windows manages permissions for accessing system resources, particularly COM components and temporary files required by the VBA engine and Dynamics GP’s customization layers.

Cause¶

The primary reason behind these VBA permission issues for non-administrator users in Microsoft Dynamics GP is the lack of appropriate security credentials. Microsoft Dynamics GP’s interaction with the VBA environment, particularly when loading the editor, copying objects, or executing code, relies on the operating system’s mechanisms for managing component registration and file system access. When a user logs on without administrative rights, their access to certain critical system resources, such as specific registry keys or temporary directories used by the VBA engine, is restricted by default Windows security policies.

The VBA editor and runtime engine often need to interact with COM objects that are registered in the Windows Registry under keys like HKEY_CLASSES_ROOT\Clsid. They may also need to create or access temporary files, often with extensions like .exd, in user-specific temporary directories. Standard users, by default, may not have the necessary read, write, or execute permissions on all required registry paths or the appropriate rights to register or utilize certain cached control definitions stored in temporary files. This lack of permission prevents the Dynamics GP application, running under the user’s context, from successfully initializing the VBA environment, accessing object metadata, or executing compiled VBA code. Even if the Dynamics GP application files themselves are accessible, the necessary underlying operating system interactions required by VBA are blocked by insufficient user privileges.

Resolution¶

To effectively address the VBA permission problems experienced by non-administrator users in Microsoft Dynamics GP, two primary methods can be employed. Each method approaches the problem from a different angle – one focusing on relaxing registry permissions, and the other on pre-registering necessary components using administrator rights so standard users can utilize them. Choosing the most appropriate method depends on your organization’s security policies, technical expertise, and the specific environment configuration. It is generally recommended to evaluate Method 2 first, as it is often considered less intrusive from a system security perspective compared to granting broad registry access.

Method 1: Modifying Registry Permissions¶

This method involves granting non-administrator users explicit permissions to critical registry keys that the VBA environment interacts with. By modifying the Access Control Lists (ACLs) for these keys, you allow standard users to read and potentially modify the registry entries necessary for VBA functionality within Dynamics GP. This approach requires careful execution and an understanding of the potential security implications of modifying registry permissions. While effective, granting Full Control as suggested can be overly permissive; however, according to the original guidance, this level of access is indicated as a potential resolution path.

To grant necessary permissions to the relevant registry keys, follow these detailed steps:

1. Log on as an Administrator: You must log in to the computer experiencing the issue using an account that has local administrator privileges. This is necessary because modifying registry permissions for system-wide keys requires elevated rights.
2. Start Registry Editor: Access the Windows Registry Editor, the tool used to view and modify the system’s registry. Click the Start button, then click Run. In the “Run” dialog box, type regedt32.exe (or regedit.exe in modern Windows versions; regedt32.exe is the older tool often preferred for setting permissions explicitly on certain keys) and click OK. You may need to confirm the action through User Account Control (UAC) if it is enabled.
3. Locate the Target Registry Key: Navigate through the registry hierarchy to find the key identified as problematic for VBA permissions. The primary key often cited is HKEY_CLASSES_ROOT\Clsid. This key contains entries for COM Class IDs, which are identifiers used by Windows to locate and activate registered COM components, including many used by VBA and ActiveX controls. Accessing or instantiating these components requires appropriate permissions on their corresponding registry entries.
4. Open Permissions Settings: Once the HKEY_CLASSES_ROOT\Clsid key is selected, access its security settings. In the Registry Editor menu (specifically in regedt32.exe), click the Security menu, and then select Permissions. In newer versions of regedit.exe, you would right-click the key, select “Permissions…”, and then click the “Advanced” button to access ACLs. The “Registry Key Permissions” window will appear, displaying the current users and groups with access to this key and their respective permission levels.
5. Add Users or Groups and Grant Permissions: Click the Add button within the Permissions window. Search for and select the specific user accounts or security groups that need to be granted VBA access. It is generally better practice to add a group containing the relevant users rather than adding individual user accounts, as this simplifies management. Once the user or group is added, select their entry in the list. Then, locate the Full Control check box and click to select it. Granting Full Control provides the user/group with the most extensive permissions, including reading, writing, and modifying the key and its subkeys. While the original guidance suggests Full Control, in a production environment, it might be prudent to test with less permissive options like “Read” and “Special Permissions” that grant specific rights required for COM activation, though identifying these minimal rights can be complex.
6. Apply Permissions: Click OK in the “Registry Key Permissions” window to apply the changes. Windows will update the security descriptors for the selected registry key. Depending on the version of Windows and the specific key, you might be prompted about applying permissions to subkeys. Applying permissions to subkeys (making the permissions “inherit”) is often necessary for this fix to work completely, as the Clsid key contains numerous subkeys for individual COM components.
7. Repeat for Other Keys: The original guidance only explicitly lists HKEY_CLASSES_ROOT\Clsid. However, other registry keys might potentially be involved depending on the specific ActiveX controls or COM components used by the VBA customization. While not specified, other common areas VBA interacts with could include parts of HKEY_CLASSES_ROOT\TypeLib or temporary locations. If the issue persists after modifying Clsid, further investigation into COM registration requirements might be needed, but sticking to the documented fix, only HKEY_CLASSES_ROOT\Clsid is mentioned.
8. Exit Registry Editor: Once all necessary permission modifications have been made, close the Registry Editor.

After performing these steps, non-administrator users should log off and then log back on to the computer for the new registry permissions to take full effect. This method directly addresses the inability of standard users to access the necessary COM registration information within the registry. However, it’s important to consider the security implications of granting Full Control to a potentially broad group of users on such a fundamental registry key.

Method 2: Registering VBA Component Cache Files¶

This method offers an alternative approach that attempts to circumvent the need for direct registry permission modification by ensuring that the cached definitions of necessary ActiveX controls (.exd files) are registered in a way accessible to all users. ActiveX controls, which are often used within VBA user forms or by objects integrated into Dynamics GP windows, cache licensing and property information in .exd files within the user’s temporary directories. When a non-admin user runs Dynamics GP and attempts to use a VBA customization relying on these controls, they may lack permissions to access or process these .exd files generated under an administrator’s profile or to generate their own. This method involves copying the .exd files generated by an administrator and registering them globally using a command-line utility.

To enable VBA functionality using .exd files without modifying registry permissions, follow these steps:

1. Log on as an Administrator: Start by logging in to the computer using an account that has administrative privileges. This is necessary to generate the initial .exd files with appropriate permissions and to run the registration tool.
2. Generate .exd Files: Launch Microsoft Dynamics GP while logged in as the administrator. Open the VBA Editor from within Dynamics GP (Tools > Customize > Add Current Window to Visual Basic, or similar navigation depending on the GP version and context). Simply opening the editor is often enough to trigger the generation or update of relevant .exd files. If your VBA project uses user forms or reports with ActiveX controls, opening those specific forms or reports within Dynamics GP might also help ensure their corresponding .exd files are generated. After opening the editor and potentially interacting with relevant forms/reports, exit Microsoft Dynamics GP completely. This ensures the files are saved to disk.
3. Locate and Copy Controls.exd: Search the administrator’s temporary directory for the Controls.exd file. The typical location for this file, especially on older Windows systems like those contemporary to Dynamics GP 9.0 (mentioned in the original KB), is C:\Documents and Settings\username\Local Settings\Temp\Dynamics9.0. The exact path may vary slightly depending on the Windows version (C:\Users\username\AppData\Local\Temp is common on newer systems) and the specific Dynamics GP version. Replace username with the administrator’s login name. Once found, copy this Controls.exd file to a shared location that all users of the computer can access. A common and recommended location is C:\Documents and Settings\All Users\DynamicsVBA (again, adjust for modern Windows versions, e.g., C:\Users\Public\DynamicsVBA). Create the DynamicsVBA folder if it does not exist.
4. Register Controls.exd: Open a Command Prompt with administrator privileges. Navigate to the location where you copied the Controls.exd file. Then, execute the regtlib.exe utility to register the type library information contained within the .exd file. The command syntax is:
   

   regtlib.exe "C:\Documents and Settings\All Users\DynamicsVBA\Controls.exd"
   

   
   (Adjust the path as per your Windows version and chosen shared location). The regtlib.exe tool registers the controls described in the .exd file, making them available system-wide or in a manner accessible to other users.
5. Repeat for RptControls.exd (If Applicable): If your VBA project includes customizations on Dynamics GP reports that utilize ActiveX controls, an additional file named RptControls.exd might exist in the same temporary directory (C:\Documents and Settings\username\Local Settings\Temp\Dynamics9.0 or equivalent). This file caches information for controls specifically used in report modifications. Locate this file, copy it to the same shared location (e.g., C:\Documents and Settings\All Users\DynamicsVBA), and register it using regtlib.exe:
   

   regtlib.exe "C:\Documents and Settings\All Users\DynamicsVBA\RptControls.exd"
   

   
   Note that this step is only necessary if you have VBA report modifications involving controls.
6. Repeat for MSForms.exd (If Applicable): If your VBA project includes custom user forms (dialog boxes created within the VBA editor) that utilize standard Microsoft Forms 2.0 controls (like CommandButton, TextBox, etc.), a file named MSForms.exd might be generated. This file is typically found in a different temporary location, often specific to the VBA editor itself, such as C:\Documents and Settings\username\Local Settings\Temp\VBE (or C:\Users\username\AppData\Local\Temp\VBE on newer systems). If this file exists, copy it to the shared location (C:\Documents and Settings\All Users\DynamicsVBA) and register it using regtlib.exe:
   

   regtlib.exe "C:\Documents and Settings\All Users\DynamicsVBA\MSForms.exd"
   

   
   This step is only required if your VBA project contains user forms.

After completing these steps, non-administrator users should now be able to run existing VBA code and potentially interact with the VBA editor (though the ability to copy/paste might still be restricted depending on other system permissions). This method essentially pre-caches and registers the necessary control information for all users. In some cases, users may need to clear their own temporary .exd files before testing, as their potentially inaccessible versions might conflict with the globally registered ones. Deleting Controls.exd, RptControls.exd, and MSForms.exd from the non-admin user’s temporary directories (C:\Documents and Settings\username\Local Settings\Temp\Dynamics9.0, C:\Documents and Settings\username\Local Settings\Temp\VBE, etc.) might be a necessary preliminary step.

Comparison of Methods¶

Feature	Method 1: Registry Permissions	Method 2: Registering .exd Files
Complexity	Moderate (requires registry editing)	Moderate (requires file copying & command line)
Security Impact	High (Modifies system-wide registry ACLs)	Lower (Registers cached control info)
Requires Admin?	Yes (for steps 1-8)	Yes (for steps 1-6)
Persistent?	Yes (permissions are set on the key)	Yes (registration is persistent)
Scope	Broad (affects access to all COM objects under the key)	Specific (affects controls cached in the .exd files)
Ideal Use Case	When Method 2 fails, or minimal impact is verified	Preferred; addresses caching/registration issues without broad registry changes
Potential Pitfalls	Risk of system instability if incorrect keys/permissions are modified; grants overly broad access	Requires re-registration if new controls are used; path variability; user temp file conflicts

Troubleshooting and Best Practices¶

• Verify Permissions: After applying either method, especially Method 1, double-check that the permissions were applied correctly for the target users or groups.
• Test Thoroughly: Test all aspects of VBA functionality that were previously failing while logged in as a non-administrator user. This includes opening the editor, attempting to copy windows/fields (if applicable), and running existing VBA code.
• Log Off/On: Always have the affected user log off and then log back on after implementing a resolution method. This ensures that their user profile loads with the updated permissions or system registrations.
• User Account Control (UAC): If UAC is enabled, ensure that administrative actions (like running regedt32.exe or regtlib.exe) are explicitly elevated. UAC can sometimes interfere if not handled correctly.
• Environmental Differences: Be mindful that paths and specific behaviors can vary slightly between different versions of Windows (XP, Vista, 7, 8, 10, Server versions) and different versions of Microsoft Dynamics GP. Adjust file paths and registry tool usage accordingly.
• Principle of Least Privilege: If using Method 1, explore if less than “Full Control” permissions are sufficient. Granting only the specific permissions required for COM activation and usage is a more secure practice, though difficult to determine precisely without detailed tracing.
• Alternative Customization: Consider whether VBA is the only or best tool for the required customization. Dynamics GP offers other customization options like Modifier, Report Writer, and Dexterity, which might have different permission requirements and could be more suitable for standard users depending on the need.

Resolving VBA permission errors for non-administrator users in Dynamics GP often requires addressing how the operating system’s security interacts with the application’s need to access registered components and temporary files. By carefully applying the steps outlined in Method 1 or Method 2, administrators can enable full VBA functionality for their users, allowing them to benefit from tailored customizations within their Dynamics GP environment.

Have you encountered similar VBA permission issues in Dynamics GP? Which method did you find most effective, or did you use a different approach? Share your experiences and tips in the comments below!