Troubleshooting 'Server Failure' Error When Modifying Users in Dynamics GP

Table of Contents

Microsoft Management Reporter (MR) is a powerful financial reporting tool integrated with various Microsoft Dynamics products, including Dynamics GP, Dynamics AX, and Dynamics SL. It allows organizations to create custom financial statements and reports based on data from their ERP system. A critical aspect of managing Management Reporter is controlling user access and permissions, which is typically handled within the application’s security settings. However, administrators occasionally encounter issues when attempting to modify existing users or add new ones. One common error message reported during these operations is:

The operation could not be completed due to a failure on the server

This error message is generic and indicates a problem on the server side that prevents the user modification from completing successfully. It doesn’t point directly to the root cause, making troubleshooting challenging. Understanding the potential reasons behind this failure is the first step toward a resolution. This article delves into the common causes of this “Server Failure” error when managing users in Management Reporter and provides detailed steps to address them.

Symptoms¶

The primary symptom is the inability to successfully save changes when editing an existing user or adding a new user within the Management Reporter application or its associated configuration console. Specifically, when an administrator attempts to perform actions such as:

• Adding a new domain user to Management Reporter security.
• Assigning or changing security roles for an existing user (e.g., Viewer, Generator, Administrator).
• Deleting a user account from Management Reporter security.
• Modifying any user-specific settings within the MR security configuration.

Upon attempting to save or apply these changes, the user interface presents the aforementioned error message: “The operation could not be completed due to a failure on the server.” This prevents any user security updates from being committed to the Management Reporter database. The error might occur immediately upon clicking ‘Save’ or ‘OK’, or after a brief delay. It’s important to note that other functions within Management Reporter, such as generating reports, might continue to work for existing users, indicating that the issue is specific to the user management function rather than a complete service outage. However, depending on the underlying cause, other functionalities could also be impacted.

Investigating the Management Reporter server logs can sometimes provide more detailed information about the nature of the failure, although the error message displayed to the user is often unspecific. These logs are typically found in the Windows Event Viewer on the server hosting the Management Reporter services, under “Applications and Services Logs” -> “Microsoft” -> “Dynamics” -> “Management Reporter”. Filtering these logs for errors or warnings around the time the user modification attempt failed can yield valuable clues, although the exact error within the logs might still require interpretation.

Understanding the context in which this error occurs – the specific action being performed (add, modify, delete user), the environment (Dynamics GP, AX, SL), and the version of Management Reporter – can help narrow down the potential causes. The error message itself strongly suggests an issue with the Management Reporter Application Service or Process Service interacting with other necessary components, such as Active Directory or the Management Reporter database, during the security update process.

Causes¶

Based on common occurrences and troubleshooting efforts, there are primary causes identified for the ‘Server Failure’ error when managing users in Management Reporter. These causes relate to how Management Reporter integrates with the underlying identity management system (Active Directory) and how its own services are configured.

Cause 1: Missing Active Directory Display Name¶

One of the most frequent reasons for this error is related to the user account in Active Directory itself. Management Reporter relies on information retrieved from Active Directory to identify and authenticate users, especially when adding new users based on their domain accounts. A specific attribute that Management Reporter expects is the user’s Display Name.

The Display Name is a standard attribute for user objects in Active Directory. It typically represents the user’s full name (e.g., “John Doe”) and is used by various applications for presenting user information in a readable format. If the Active Directory user account that you are attempting to add or modify in Management Reporter does not have a Display Name populated, Management Reporter’s security component may fail when trying to process this user’s information. The process of adding or modifying the user triggers a lookup and validation against Active Directory, and the absence of this expected attribute can lead to an exception on the server side, manifesting as the generic ‘Server Failure’ error.

This cause is applicable across different versions of Management Reporter and the Dynamics products it integrates with, as it stems from the fundamental interaction between MR security and Active Directory. Ensure that the user account in question has all standard attributes, particularly the Display Name, properly filled out in Active Directory Users and Computers.

Cause 2: Incorrect Service Account Configuration (Management Reporter 2012)¶

This cause is more specific and primarily affects Management Reporter 2012 installations. Management Reporter 2012 runs several services on the server, typically the Application Service and the Process Service. These services are responsible for core functionalities, including user authentication and authorization, report generation, and data processing. The identity under which these services run is critical for their ability to interact with other systems, such as the Active Directory domain controller and the SQL Server hosting the Management Reporter database.

A common configuration issue that can lead to the ‘Server Failure’ error when managing users is when the Management Reporter services are configured to run under the Local System account. The Local System account is a built-in Windows account with high privileges on the local machine but limited or no access to network resources, including Active Directory or network shares, under its own identity.

While the Local System account might seem convenient or have sufficient local privileges, it often lacks the necessary permissions or network identity to perform operations that require interacting with domain resources, such as querying Active Directory for user information or validating domain credentials in a domain environment. When you attempt to add or modify a domain user in Management Reporter, the Application Service (running under the Local System account) needs to communicate with the Active Directory server to retrieve user details (like the Display Name, as mentioned in Cause 1) and potentially validate credentials or group memberships. Since the Local System account cannot authenticate against Active Directory as a domain user, this interaction fails, resulting in the ‘Server Failure’ error.

For proper functioning, especially in a domain environment where users are managed via Active Directory, the Management Reporter services should be configured to run under a dedicated domain user account. This domain user account must have appropriate permissions to read from Active Directory and interact with the SQL Server hosting the MR database. Using a domain account ensures that the MR services have a valid network identity when performing operations that span across different servers, like user management interacting with the domain controller.

This cause is particularly relevant for Management Reporter 2012 as it’s been a noted point of failure in its service architecture when improperly configured with the Local System account in domain environments. Earlier versions or specific standalone configurations might behave differently, but using a dedicated service account is generally best practice.

Resolution¶

Resolving the ‘Server Failure’ error when modifying users in Management Reporter involves addressing the identified causes. The steps below outline how to troubleshoot and correct the Active Directory user properties and the Management Reporter service configuration.

Resolution 1: Ensure Active Directory User Has a Display Name¶

This resolution addresses Cause 1 where the Active Directory user account lacks a Display Name.

1. Access Active Directory Users and Computers: Log in to a server or workstation that has the Active Directory Users and Computers (ADUC) management console installed and access to your domain. You will need appropriate permissions (e.g., Domain Admin or sufficient rights to edit user properties) to perform these steps.
2. Locate the User Account: Navigate through the organizational units (OUs) to find the specific user account that you are trying to add or modify in Management Reporter.
3. Open User Properties: Right-click on the user account and select Properties.
4. Check the General Tab: In the user’s Properties window, go to the General tab.
5. Populate the Display Name Field: Look for the field labeled Display name. If this field is empty, it is likely the source of the problem.
6. Enter the Display Name: Enter the user’s full name (or preferred display format) into the Display name field. It’s good practice to also ensure the First name, Last name, and Full name fields are correctly populated, as the Display Name is often generated from or related to these fields.
7. Apply Changes: Click Apply and then OK to save the changes to the user object in Active Directory.
8. Wait for Replication: In a domain environment with multiple domain controllers, Active Directory changes need to replicate across the domain. Depending on your replication topology and schedule, this can take some time (from a few minutes to potentially longer in complex or remote sites). While you can often test immediately, if the issue persists, wait for replication to complete.
9. Test in Management Reporter: Once the Display Name is populated in Active Directory and sufficient time has passed for replication, attempt to add or modify the user in Management Reporter again.

If the missing Display Name was the issue, the operation should now complete successfully without the ‘Server Failure’ error. It’s a good practice to ensure all user accounts intended for use with domain-integrated applications like Management Reporter have their standard Active Directory attributes, including Display Name, fully populated upon creation.

Resolution 2: Change Management Reporter Service Account (Management Reporter 2012 Specific)¶

This resolution addresses Cause 2 related to the Management Reporter services running under the Local System account.

1. Identify the Management Reporter Server: Determine which server(s) host the Management Reporter Application Service and Process Service.
2. Access Services Console: Log in to the Management Reporter server with an administrator account that has permissions to manage Windows services. Open the Services console by typing services.msc in the Run dialog or search bar and pressing Enter.
3. Locate Management Reporter Services: In the Services list, find the services related to Management Reporter. They are typically named Microsoft Dynamics Management Reporter 2012 Application Service and Microsoft Dynamics Management Reporter 2012 Process Service.
4. Check Service Properties: For each Management Reporter service, right-click on it and select Properties.
5. Go to the Log On Tab: In the Properties window, go to the Log On tab.
6. Verify Current Account: Check which account the service is currently configured to use. If Local System account is selected, this is likely the problem.
7. Switch to ‘This account’: Select the This account radio button.
8. Specify a Domain User Account: Click the Browse… button. In the Select User dialog, enter the name of a dedicated domain user account that you intend to use for running the MR services. This account should be a standard domain user (not an administrator account unless absolutely necessary) created specifically for running services. Enter the domain and user name in the format DOMAIN\Username.
9. Enter Password: Once the account is selected, enter the password for this domain user account in both the Password and Confirm password fields.
10. Grant Necessary Permissions: The domain user account needs specific permissions:
    • Log on as a service: This right is typically granted automatically when you configure a service to run under an account, but verify it in the Local Security Policy or Group Policy if issues arise.
    • Read access to Active Directory: The account needs permissions to query user information from Active Directory. Standard domain users usually have this permission by default.
    • Read and Write access to the Management Reporter database: The account needs permissions to connect to and interact with the SQL Server database where the Management Reporter data is stored. Grant this account appropriate database roles (e.g., db_datareader, db_datawriter, and potentially db_ddladmin during updates or specific maintenance, but usually less is better for daily operation - consult Microsoft documentation for precise requirements, but often custom roles or ownership of the MR database is needed).
    • Read access to the Management Reporter installation folders: The account needs read permissions on the file system where Management Reporter is installed.
11. Apply Changes and Restart Service: Click Apply and then OK. You will be prompted that the service needs to be restarted for the change to take effect. Click OK.
12. Restart Both Services: Repeat steps 4-11 for the other Management Reporter service (Application or Process Service, whichever you haven’t changed yet). After changing the log on account for both services, restart both the Application Service and the Process Service from the Services console. Ensure they start successfully. If they fail to start, double-check the username and password entered, and verify the ‘Log on as a service’ right.
13. Test in Management Reporter: Once both services are running under the specified domain user account, attempt to add or modify the user in Management Reporter again.

Using a properly configured domain user account for the Management Reporter services resolves issues related to network resource access, including interactions with Active Directory for user management. This is the recommended configuration for MR 2012 in a domain environment.

Additional Troubleshooting Steps¶

If the above resolutions do not immediately fix the issue, consider these additional checks:

• Firewall: Ensure there are no firewall rules (either Windows Firewall on the MR server, domain controller, or SQL server, or hardware firewalls) blocking necessary communication between the MR server and the domain controller (ports for LDAP, Kerberos, etc.) or the SQL Server (default port 1433, or a dynamic/specific port if configured).
• Network Connectivity: Verify network connectivity between the MR server, the domain controller, and the SQL Server. Simple ping tests or testing TCP ports can help rule out basic network problems.
• SQL Server Permissions: Double-check that the service account (if changed) or the account used for SQL authentication by MR has sufficient permissions on the Management Reporter database.
• Management Reporter Version: Ensure you are on a supported version and build of Management Reporter. Check for any known issues or hotfixes related to user management on the Microsoft Dynamics support site.
• Active Directory Health: Confirm that Active Directory itself is healthy and replication is functioning correctly. Issues with AD can indirectly affect applications that rely on it.
• Restart Server: As a last resort, and if possible within your environment, consider restarting the Management Reporter server after implementing the service account changes.

By systematically checking the Active Directory user properties and the Management Reporter service configuration, administrators can effectively troubleshoot and resolve the ‘Server Failure’ error encountered when managing users in Microsoft Management Reporter. Proper setup of both the user accounts and the service accounts is crucial for the stable operation of MR security features.

What other troubleshooting steps have you found helpful when dealing with Management Reporter user management issues? Share your experiences and tips in the comments below!