locked
Failed to connect to server (SCSM Console error) RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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
    Severity: Error
    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)

    Thursday, April 12, 2012 10:01 PM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    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!

    Regards
    //Anders

    Anders Asp | Lumagate | www.lumagate.com | Sweden | My blog: www.scsm.se

    • Marked as answer by bcehr Thursday, May 3, 2012 7:22 PM
    Friday, April 13, 2012 9:17 AM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    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!

    Regards
    //Anders

    Anders Asp | Lumagate | www.lumagate.com | Sweden | My blog: www.scsm.se

    • Marked as answer by bcehr Thursday, May 3, 2012 7:22 PM
    Friday, April 13, 2012 9:17 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Anders, 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!
    Friday, April 13, 2012 3:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    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 :-(

    Cheers'

    Dan


    Sunday, May 27, 2012 11:53 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    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?

    Thanks,
    Jay

    Friday, June 29, 2012 12:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    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).

    Thanks,
    Jay

    Friday, June 29, 2012 12:56 PM
  • Question
    Sign in to vote
    2
    Sign in to vote

    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.


    • Proposed as answer by cwmillerjr Tuesday, January 29, 2013 5:23 PM
    • Edited by cwmillerjr Tuesday, January 29, 2013 5:24 PM
    Tuesday, January 29, 2013 5:23 PM