12 Nisan 2012 Perşembe 22:01
Hello, I am currently having an issue that cropped up after System Center 2012 was released. We have had SCOM 2007 R2 and SCSM 2010 SP1 coexisting for a long time in our environment. After System Center 2012 was released, we upgraded SCOM 2007 R2 to SCOM 2012. Once we upgraded the SCOM console on our desktops, our SCSM 2010 SP1 consoles all broke. We are still in the planning phase for SCSM 2012 upgrade and our SCOM users need to use SCSM in the meantime. Also, uninstalling the SCOM 2012 console doesn't fix the issue, nor does a reinstall of the SCSM 2010 SP1 console; once its broken we can't seem to fix it for that machine. Any thoughts on how to resolve this issue? Thanks! This is a major problem since a lot of our users can no longer access SCSM. The SCSM console gives the following error:
Failed to connect to server 'scsmserver'
The container could not find a component with name 'ConfigurationExtension'...
Date: 4/12/2012 4:47:43 PM
Application: System Center Service Manager Console
Application Version: 7.0.6555.128
Message: Failed to connect to server 'scsmserver'
Microsoft.EnterpriseManagement.ContainerException: The container could not find a component with name 'ConfigurationExtension' compatible with type 'Microsoft.EnterpriseManagement.Configuration.IExtensionRegistrationService, Microsoft.EnterpriseManagement.Core, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
at Microsoft.EnterpriseManagement.Container.GetService[T](String name)
at Microsoft.EnterpriseManagement.Configuration.ExtensionRegistry.GetExtensions(Boolean forceRefresh)
at Microsoft.EnterpriseManagement.Configuration.ExtensionRegistry.Initialize(IContainer container)
at Microsoft.EnterpriseManagement.EnterpriseManagementGroupInternal.Initialize(SdkDataLayerProxyCore sdkDataLayerProxy, EnterpriseManagementConnectionSettings connectionSettings)
at Microsoft.EnterpriseManagement.EnterpriseManagementGroupInternal.Create[T](SdkDataLayerProxyCore sdkDataLayerProxy, EnterpriseManagementConnectionSettings connectionSettings)
at Microsoft.EnterpriseManagement.Common.Internal.SdkDataLayerProxyCore.ConstructEnterpriseManagementGroupInternal[T,P](EnterpriseManagementConnectionSettings connectionSettings, ClientDataAccessCore clientCallback)
at Microsoft.EnterpriseManagement.Common.Internal.SdkDataLayerProxyCore.RetrieveEnterpriseManagementGroupInternal[T,P](EnterpriseManagementConnectionSettings connectionSettings, ClientDataAccessCore callbackDispatcherService)
at Microsoft.EnterpriseManagement.Common.Internal.SdkDataLayerProxyCore.Connect[T,P](EnterpriseManagementConnectionSettings connectionSettings, ClientDataAccessCore callbackDispatcherService)
at Microsoft.EnterpriseManagement.ServiceManagementGroup.InternalInitialize(EnterpriseManagementConnectionSettings connectionSettings, EnterpriseManagementGroupInternal internals)
at Microsoft.EnterpriseManagement.ServiceManagementGroup..ctor(ServiceManagementConnectionSettings connectionSettings)
at Microsoft.EnterpriseManagement.UI.SdkDataAccess.ManagementGroupSessionManager.Connect(String server)
at Microsoft.EnterpriseManagement.ServiceManager.UI.Console.Credentials.ManagementGroupConnection.TryConnectToManagementGroupJob(Object sender, ConsoleJobEventArgs args)
13 Nisan 2012 Cuma 09:17Moderatör
I think this is related to the assembly 'Microsoft.EnterpriseManagement.Core' in c:\windows\assembly. I had similar issues in the past where I needed to replace the 'Microsoft.EnterpriseManagement.Core' with the version copied from the SCSM mgmt. server.
In your case I would try to uninstall both OpsMgr2012 and SCSM2010, then uninstall the assembly file, then re-install the SCSM 2010 console. Try this on a lab machine first!
Anders Asp | Lumagate | www.lumagate.com | Sweden | My blog: www.scsm.se
- Yanıt Olarak İşaretleyen bcehr 03 Mayıs 2012 Perşembe 19:22
13 Nisan 2012 Cuma 15:07Anders, thanks for the great reply! It has fixed my issue in my lab, I'm going to try this on production machines now. It seems like SCOM 2012 and SCSM 2012 SP1 console's can't coexist together? Is that really possible? Seems like this will end up being a major problem, as it isn't very feesable to perform SCOM and SCSM upgrades at the same time? Have you found a way to get them to coexist? Thanks!
27 Mayıs 2012 Pazar 23:53
Just wanted to add that this fixed my issue as well.
Scenario: SCOM 2012 Console and SCSM 2010 SP1 Console installed on workstation. Above errors when trying to connect to management server.
Remove SCOM & SCSM and reinstall SCSM 2010 SP1 - success.
Will have to resort to SCOM Console from our RDS server :-(
- Düzenleyen Dan Apps 27 Mayıs 2012 Pazar 23:53
29 Haziran 2012 Cuma 12:38
Just to confirm, I've experienced the same issue. I am in the process of working through the suggestion above; however I am unsure how to uninstall the assembly file?
29 Haziran 2012 Cuma 12:56
Removed both, and reinstalled SCSM - worked like a charm. I guess there is no specific task to un-install the assembly file. Thanks for the great information, and I agree that this could become a bigger problem as companies end up in a fragmented 2010/2012 System Center environment. I'll confirm though, that it does not appear to interfere with 2007 clients (such as my Configuration Manager client).
29 Ocak 2013 Salı 17:23
I recently had this issue and needed both installed on the same machine. The issue is, indeed, 'Microsoft.EnterpriseManagement.Core' in the GAC. Both 2010 and 2012 supply a signed assembly with AssemblyVersion "7.0.5000.0", but they are not binary compatible. The 2010 version is "AssemblyFileVersion" "7.0.6555.0" and the 2012 version is "7.5.1527.0" The assemblies do not have the same structure and 'Microsoft.EnterpriseManagement.Configuration.IExtensionRegistrationService' is one of those differences.
To get both running side by side, you will need to install one of them, and copy the "Microsoft.EnterpriseManagement.Core.dll" file out of the GAC and place it into the respective local folder of the application (where you will find the other DLLs for the application). Then you will need to remove this file from the GAC, which may require modifying the registry to remove it as a shared assembly. Then install the second application, and repeat the process of copying the Core.dll from the GAC and placing it into the local folder of the respective application, and removing it from the GAC.
You must remove it from the GAC, at the end of the installs and after any future installs with this same problem, or when the assembly is bound, since it is strongly named and versioned, it will use the one in the GAC if it is loaded already by the other app from the GAC. It will attempt to share it. Even using binding redirection, etc., in the config file cannot change that, it's just how assembly resolution works, and unfortunately, two different versions of the file have been released with the same version code, and include breaking changes between them.
Some tools to help diagnose this are Sysinternals: Process Explorer (to see which DLLs are loaded by an application and where they are loaded from, in this case GAC vs local path) and Fusion Log Viewer to see how and why certain assemblies are resolved and loaded over others.