Home error codes software installation technical support troubleshooting

Troubleshooting Operations Manager: Resolving Installation/Upgrade Error 0xffffffff

Updated: • 0 • min read
Table of Contents

When deploying or upgrading System Center Operations Manager (SCOM) Reporting, encountering unexpected errors can significantly impede progress. This article delves into a specific and frequently encountered issue: Error 0xffffffff, which manifests during the installation or upgrade of System Center 2012 Operations Manager Reporting. Understanding the root cause and implementing the correct resolution steps is crucial for a successful SCOM deployment. This guide provides a comprehensive approach to diagnosing and resolving this stubborn error, ensuring your reporting services are configured correctly.

Troubleshooting Operations Manager Installation

Understanding the Context: System Center Operations Manager Reporting

System Center Operations Manager (SCOM) is a vital component of Microsoft’s System Center suite, offering robust monitoring capabilities for applications, services, and infrastructure. Integral to SCOM’s functionality are its reporting services, which are typically powered by SQL Server Reporting Services (SSRS). These reports provide invaluable insights into the health, performance, and availability of monitored entities, enabling IT professionals to make informed decisions and proactively address potential issues.

The installation or upgrade of SCOM Reporting involves complex interactions between the SCOM setup routines, SQL Server Reporting Services, and various .NET assemblies. These assemblies contain the compiled code necessary for SCOM components to function, including the logic for publishing and rendering reports. When this intricate process encounters an unexpected state, such as conflicting or corrupted assemblies, it can lead to critical failures, as indicated by the 0xffffffff error.

Symptoms of Error 0xffffffff

The presence of Error 0xffffffff during SCOM 2012 Operations Manager Reporting installation or upgrade is typically identified through specific entries in the OMReporting.log file. This log file is the primary diagnostic resource for SCOM Reporting setup failures, providing detailed insights into the point of failure and the underlying technical reasons. A thorough review of this log is the first step in troubleshooting.

Log Entries Indicating Failure

Upon failure, the OMReporting.log will contain distinct error messages. The most prominent indicators of this specific issue are:

ExecNetFx: Error: The specified assembly is not installed.
ExecNetFx: Error 0xffffffff: Command line returned an error.
ExecNetFx: failed to execute Ngen command (with error 0xffffffff): C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe uninstall "Microsoft.EnterpriseManagement.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35", continuing anyway

These lines indicate a problem with ngen.exe, the Native Image Generator, which is part of the .NET Framework. NGEN is used to improve the startup performance of applications and reduce memory footprint by pre-compiling .NET assemblies into native code. The error 0xffffffff combined with ExecNetFx and ngen.exe uninstall suggests that the setup routine is attempting to manage an existing .NET assembly (Microsoft.EnterpriseManagement.Core) but is encountering an unexpected state, leading to a fatal error.

Secondary Symptoms: Reporting Services Errors

In addition to the NGEN errors, the OMReporting.log may also display errors related to the reporting services publishing process itself. These errors typically manifest as SoapException messages, indicating issues during the communication between the SCOM setup and SQL Server Reporting Services.

An example of such an error segment includes:

Error: :Application Monitoring reports publishing failed.: Threw Exception.Type: System.Web.Services.Protocols.SoapException, Exception Error Code: 0x80131501, Exception.Message: System.Web.Services.Protocols.SoapException: There is an error on line 45 of custom code: [BC30002] Type 'Microsoft.EnterpriseManagement.Presentation.Util.AntiXssEncoder' is not defined.
at Microsoft.ReportingServices.WebServer.ReportingService2005Impl.CreateReport(String Report, String Parent, Boolean Overwrite, Byte[] Definition, Property[] Properties, Warning[]& Warnings)
at Microsoft.ReportingServices.WebServer.ReportingService2005.CreateReport(String Report, String Parent, Boolean Overwrite, Byte[] Definition, Property[] Properties, Warning[]& Warnings)
Error: :StackTrace: at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at Microsoft.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.Reporting.Setup.ReportService.ReportingService2005.CreateReport(String Report, String Parent, Boolean Overwrite, Byte[] Definition, Property[] Properties)
at Microsoft.EnterpriseManagement.OperationsManager.Setup.ReportServices.ApplicationDiagnostics.ReportManager.PublishReport(FileInfo reportFile, String parent)
at Microsoft.EnterpriseManagement.OperationsManager.Setup.ReportServices.ApplicationDiagnostics.ReportManager.PublishReports(DirectoryParameter directoryParam)
at Microsoft.EnterpriseManagement.OperationsManager.Setup.ReportServices.ApplicationDiagnostics.ReportManager.RunActionForDirectory(Predicate`1 action, DirectoryInfo directory, String currentPath)
at Microsoft.SystemCenter.Essentials.SetupFramework.InstallItemsDelegates.OMReportingProcessor.PublishAppDiagnosticsReports()
Error: :Error:Publishing App Diagnostics Reports failed.
Error: :FATAL ACTION: ConfigureReportingForInstall

This extended log output indicates that the SCOM setup failed specifically during the “Application Monitoring reports publishing” phase. The SoapException with the message “[BC30002] Type ‘Microsoft.EnterpriseManagement.Presentation.Util.AntiXssEncoder’ is not defined” points to a fundamental problem with type resolution or assembly loading within the context of the .NET framework. This typically occurs when a required assembly or a specific version of an assembly is missing, corrupted, or cannot be correctly loaded by the application (in this case, the reporting services component attempting to publish reports). The FATAL ACTION: ConfigureReportingForInstall confirms that the entire reporting configuration process has failed.

These symptoms collectively point towards a core issue involving the integrity and accessibility of critical .NET assemblies required by SCOM Reporting Services.

Cause: Conflicting Assembly in Global Assembly Cache (GAC)

The primary cause of this error is the unexpected presence of a conflicting or orphaned assembly within the Global Assembly Cache (GAC). Specifically, if the assembly Microsoft.EnterpriseManagement.Reporting.Code is present in C:\\Windows\\Assembly (which is the historical path for the GAC on certain Windows versions, though technically the GAC resides in C:\Windows\Microsoft.NET\assembly\), it can interfere with the SCOM installation or upgrade process.

The Global Assembly Cache (GAC) Explained

The Global Assembly Cache (GAC) is a machine-wide code cache for .NET assemblies. It’s designed to store assemblies that are intended to be shared by multiple applications on the system. When an application attempts to load an assembly, the .NET runtime first checks the GAC for the requested assembly. If found, the assembly from the GAC is loaded. This mechanism allows for side-by-side execution of different versions of the same assembly and ensures that shared components are readily available.

However, if an assembly, such as Microsoft.EnterpriseManagement.Reporting.Code, becomes corrupted, is an incorrect version, or is left over from a failed or partial uninstallation, it can create conflicts. During an SCOM installation or upgrade, the setup routine attempts to deploy or update its own versions of these assemblies. If a conflicting version is already present and registered in the GAC, it can lead to the NGEN command failing (as seen with 0xffffffff) and subsequent SoapException errors because the expected assembly cannot be correctly managed or loaded. The ngen.exe uninstall command failing specifically points to an issue with removing or updating a registered native image.

The presence of Microsoft.EnterpriseManagement.Reporting.Code in the GAC from a previous, potentially failed, installation or upgrade attempt, or from an unexpected source, is the core of the problem. The SCOM setup expects to either install this assembly clean or upgrade it seamlessly. An existing, problematic version disrupts this flow.

Resolution Steps

Resolving this error requires carefully managing the conflicting assembly within the Global Assembly Cache. Before proceeding with any steps, it is highly recommended to perform a full backup of your SCOM databases (OperationsManager and DataWarehouse) and the SQL Server Reporting Services configuration. This ensures that you have a recovery point in case of unforeseen issues.

Preliminary Steps: Preparation

  1. Backup SCOM Databases: Ensure your OperationsManager and DataWarehouse databases on your SQL Server instance are fully backed up.
  2. Backup SSRS Encryption Keys: For SQL Server Reporting Services, back up the encryption keys. This is critical for data recovery if SSRS configuration needs to be reset.
  3. Stop SCOM Services: On all SCOM management servers, stop all System Center Operations Manager services. This includes System Center Data Access Service, Microsoft Monitoring Agent, System Center Management and others related to SCOM.
  4. Stop IIS: On the server where you are performing the reporting component installation/upgrade, stop the Internet Information Services (IIS) to ensure no web applications are locking relevant files. You can do this by running iisreset /stop from an elevated Command Prompt.
  5. Identify the GAC Path: While C:\Windows\Assembly was the GAC path in older .NET versions (e.g., .NET Framework 1.1), for .NET Framework 4.0 and later, the GAC resides in C:\Windows\Microsoft.NET\assembly. You will likely need to navigate to this path or use the gacutil.exe utility.

Step-by-Step Resolution

The core of the resolution involves identifying and uninstalling the problematic assembly from the GAC using the gacutil.exe command-line utility.

  1. Open an Elevated Command Prompt: Navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319 (or the appropriate Framework version for your environment, typically the one used by SCOM 2012) and open an elevated Command Prompt. This directory contains gacutil.exe. If you cannot find it there, gacutil.exe is part of the Windows SDK, and you might need to install the SDK or locate gacutil.exe from a Visual Studio installation path. Alternatively, simply ensure gacutil.exe is in your system’s PATH.

  2. List Assemblies in GAC (Optional but Recommended): To confirm the presence of the Microsoft.EnterpriseManagement.Reporting.Code assembly, you can list all assemblies in the GAC. While visually inspecting C:\Windows\Microsoft.NET\assembly is possible, gacutil provides a more structured view.
    Run:
    gacutil /l > C:\gac_assemblies.txt
    Open gac_assemblies.txt and search for “Microsoft.EnterpriseManagement.Reporting.Code”. Note its full strong name, including version, culture, and public key token. For example, it might look like:
    Microsoft.EnterpriseManagement.Reporting.Code, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

  3. Uninstall the Conflicting Assembly: Once you have the full strong name of the assembly (from the error log or by listing the GAC contents), use the gacutil /u command to uninstall it. Replace the example with the exact strong name you found.

    For example, if the strong name is Microsoft.EnterpriseManagement.Reporting.Code, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35, the command would be:

    gacutil /u "Microsoft.EnterpriseManagement.Reporting.Code, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"

    You should receive a message indicating “Assembly successfully uninstalled from the cache” or similar confirmation. If it indicates the assembly is not found, it means it wasn’t registered in the GAC under that exact name, or it was already removed, in which case the issue might be more subtle or require checking a slightly different version/public key token.

  4. Clean Temporary Files: It’s good practice to clear temporary installation files that might be lingering. Navigate to %TEMP% and delete any folders related to SCOM or Microsoft installation logs if safe to do so.

  5. Restart IIS and SCOM Services: After attempting the resolution, restart IIS by running iisreset /start from an elevated Command Prompt. Then, restart all previously stopped SCOM services.

  6. Re-attempt Installation/Upgrade: With the conflicting assembly removed from the GAC, re-run the System Center 2012 Operations Manager Reporting installation or upgrade process. Monitor the OMReporting.log closely for success messages or new errors.

Post-Resolution Verification

After successfully re-running the installation or upgrade, it’s essential to verify that the reporting components are functioning as expected.

  1. Check OMReporting.log: Review the OMReporting.log file one last time. Look for messages indicating successful completion of all installation or upgrade actions, especially those related to “ConfigureReportingForInstall”.
  2. Verify SCOM Console Access: Open the SCOM Operations console and ensure that all management servers are connected and healthy.
  3. Test Reports: Navigate to the “Reporting” workspace in the SCOM console. Try to run a few default reports, such as “Performance” or “Alerts” reports, to confirm that they render correctly without errors.
  4. Check SSRS Web Portal: Access the SQL Server Reporting Services web portal (e.g., http://<YourReportingServer>/Reports or http://<YourReportingServer>/ReportServer) and verify that SCOM reports are published and accessible.
  5. Monitor Event Logs: Check the Application and System event logs on the SCOM management servers and the reporting server for any new errors or warnings related to SCOM or SQL Server Reporting Services.

Best Practices for SCOM Deployments

To minimize the likelihood of encountering installation or upgrade errors, adhere to the following best practices:

  • Comprehensive Planning: Before any installation or upgrade, thoroughly review the SCOM documentation for prerequisites, supported configurations, and upgrade paths.
  • System Requirements: Ensure all servers meet the minimum and recommended hardware and software requirements for SCOM, SQL Server, and Reporting Services.
  • Prerequisite Checks: Manually verify that all necessary roles and features are installed on the target servers, including specific versions of .NET Framework, Windows features, and SQL Server components.
  • Administrator Privileges: Always run SCOM setup executables with elevated administrator privileges.
  • Antivirus Exclusions: Configure appropriate antivirus exclusions for SCOM installation directories, databases, and operational files to prevent interference during setup and ongoing operations. Consult Microsoft documentation for specific exclusion lists.
  • Clean Environment: If possible, perform installations on clean, newly provisioned servers to avoid conflicts with pre-existing software or configurations. For upgrades, ensure the existing SCOM environment is stable and healthy.
  • Network Connectivity: Verify full network connectivity and name resolution between all SCOM components (management servers, database server, reporting server, gateway servers).
  • Log Analysis: Develop a habit of reviewing installation logs (OMReporting.log, OpsMgrSetupWizard.log, Installer.log, etc.) even for successful installations to understand the process and identify potential warnings.

By following these guidelines and understanding the underlying mechanics of SCOM Reporting, you can significantly improve the success rate of your SCOM deployments and efficiently resolve issues like Error 0xffffffff.

Conclusion

The 0xffffffff error during System Center 2012 Operations Manager Reporting installation or upgrade, while cryptic, typically points to a conflict within the Global Assembly Cache (GAC). By methodically identifying and removing the problematic Microsoft.EnterpriseManagement.Reporting.Code assembly using gacutil.exe, administrators can clear the path for a successful deployment. This detailed guide not only provides the resolution steps but also emphasizes the importance of understanding the underlying technologies and adhering to best practices for a stable SCOM environment.

We encourage you to share your experiences with this error or similar SCOM installation challenges in the comments section below. Your insights can help the community troubleshoot and optimize their SCOM deployments.

Post a Comment