SCOM Intergration Pack Failed to connect RRS feed

  • Question

  • Hello,


    I am trying to connect SCORCH to SCOM.  When ever I enter my credentials I get failed to connect error.  I have admin access on both servers and firewall is not being blocked.  Works fine with I connect to VMware using SCORCH.  Integration Pack version for SCOM I am using is 7.3. Attached is the error. 

    Any help would be appreciated. 

    Thank you.


    • Edited by ipatel18 Sunday, March 17, 2019 6:39 AM IP version
    Sunday, March 17, 2019 6:38 AM


  • I ended up running into this in my production environment today. I had to download the latest IP from here "" and reregister/reinstall it
    Sunday, August 4, 2019 8:34 PM

All replies

  • Hello Ishan,

    Which version of Orchestrator (SCORCH) and Operations Manager (SCOM) are you using?

    Best regards,

    Blog: LinkedIn:

    Sunday, March 17, 2019 10:16 AM
  • Hi,

    is the Operation Manager Console installed where you run Runbook Designer?

    If you don't want to install Operation Console check out:



    More and news about System Center at and .

    Sunday, March 17, 2019 3:06 PM
  • In addition to Stefan, if installing the Operations Console is not an issue, you can also refer to the documentation below on how to integrate Orchestrator with SCOM:

    Integration pack for System Center - Operations Manager

    Note the following:

    System requirements

    • System Center - Orchestrator
    • The integration pack version should match the System Center version.
    • System Center - Operations Manager

    Blog: LinkedIn:

    Sunday, March 17, 2019 3:14 PM
  • Have you added the account into to SCOM admin group?

    Also try to restart your SCO Server after installing SCOM Console.

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, March 18, 2019 7:38 AM
  • Ive experienced this issue before with admin rights

    If not down to your versions etc then what you'll need to do is check your SPN settings for your SCOM environment

    So if you are using a domain account as a service account for SCOM you will need to register its SPNs as MSOMSDKSVC

    Run a setspn.exe -L <ServiceAccountName> and make sure you see two entries both starting with MSOMSDKSVC and with the server name and fqdn

    If these are not there add them in using setspn.exe -A MSOMSDKSVC/Servername serviceaccountname and setspn.exe -A MSOMSDKSVC/FQDN serviceaccountname

    Then try it again in Orchestrator and the connection should work

    Website: Technical Blog: Personal Blog: Twitter: Dwalshampro

    Monday, March 18, 2019 9:59 AM
  • Leon,

    I am using SCORCH 1801 and SCOM 1807



    Saturday, March 23, 2019 6:34 AM
  • Hello Stefan,

    After reading your post I installed Operations Manager console on the same server but I am still getting the same error. 



    Saturday, March 23, 2019 6:54 AM
  • Hi Ishan,

    I tested in my lab just now and I was able to create a connection successfully.


    The connection worked both with and without the SCOM console.

    I also tested installing the SCOM 1801 console on the Orchestrator 1801 server (I was going to upgrade the SCOM console  to 1807, but it still worked with the SCOM 1801 console).

    I tested with firewalls disabled, (Domain, Public, Private) on both Orchestrator and Operations Manager servers and it was successful.

    I also tested with firewalls enabled, (Domain, Public, Private) on both Orchestrator and Operations Manager servers and it was successful

    I also tested creating a SCOM connection with a normal AD user who is not a member of the Operations Manager Administrators group in SCOM, and it worked.

    Make sure the Orchestrator server resolves the DNS (both Forward and Reverse) of the Operations Manager server.

    Blog: LinkedIn:

    Saturday, March 23, 2019 12:45 PM
  • Hi Ishan,

    is anything useful in the logs in dir C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookDesigner.exe\Logs ?



    More and news about System Center at and .

    Monday, March 25, 2019 8:48 PM
  • Sorry for not replying to some suggestions.  I was doing a lot of troubleshooting before I posted something on here.

    So over the weekend I somehow managed to get one of my test servers to show Connection Successful.  However, when I tried to replicate that to the actual test server I got the same error again where it says "Failed to connect.  Please verify your connection settings."  Lets call the non working server SRV-TST02 and the working server SRV-TST03

    Some of my troubleshooting steps:

    I created the same Windows 2016 Server.  I checked the registry for TLS settings.  I made sure I am using the same Integration Packs on both servers.  The service account has the same rights on both servers. SCORCH and SCOM versions are the exact same on both servers.  Re-installed SCORCH and SCOM to see if the issue resolves.  No firewalls are enabled on our server.  The network firewall does not affect this cause they both are on the same VLAN and I checked with our networking team that nothing is blocking it.

    The only thing that I can think of that is giving me that error is the TLS settings from somewhere.  I just cannot pinpoint it from where.  Reason I say this is cause when I do a test connection from the working server (SRV-TST03) it can connect to SCOM.  But when I go to the non-working server(SRV-TST02) and then connect to SRV-TST03 using the Runbook Designer console and then do the test connection it fails.

    Below are my logs from RunbookDesigner from the non-working server.  My next step is to use wireshark to see if that helps me somehow. 


    SCORCH: 1807

    SCOM: 1807

    Server OS: Server 2016


    Process ID: 5000
    Version   :
    Computer  : SRV-TST02
    User      : UTAD\ipatel-adm

    2019-03-26 17:35:50 [4996] 4 User preferred UI languages: "en-US\0\0"

    2019-03-26 17:35:51 [4996] 1 Exception caught in class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > __thiscall DllStringStorage::getString(const class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &) throw() const
    class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > __thiscall DllStringStorage::doGetString(const class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &) const
    <MsgCode>Cannot get string</MsgCode>
    class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > __cdecl `anonymous-namespace'::loadResourceString(struct HINSTANCE__ *,int)
    <MsgCode>Cannot load string</MsgCode>

    2019-03-26 17:35:54 [4996] 4 License: now is 2019-03-26T21:35:54

    2019-03-26 17:35:54 [4996] 4 License: never expires

    2019-03-26 17:35:54 [4996] 4 License: not expired yet

    2019-03-26 17:35:54 [5240] 4 [OrchestratorTraceLoggerHelper] ==>IsTelemetryEnabled

    2019-03-26 17:35:54 [5240] 4 [OrchestratorTraceLoggerHelper] Orchestrator Diagnostic and Usage Data collection is disabled in reg table


    • Edited by ipatel18 Tuesday, March 26, 2019 10:22 PM OS Info
    Tuesday, March 26, 2019 9:58 PM
  • Hi,

    here's a similiar message in the logs:

    I would reinstall the Integration Pack for SCOM and see if it works after that.



    More and news about System Center at and .

    Wednesday, March 27, 2019 7:33 AM
  • Try what Stefan mentioned, I alsohad to reinstall the Integration Pack once to get it working.

    Blog: LinkedIn:

    Wednesday, March 27, 2019 7:36 AM
  • I re-installed the Integration Pack for SCOM but that did not fix the issue.  However, when I compared my non-working server and the working server I am seeing that even though the version numbers are the same their size used in Programs and Features is different.  The non-working server is using less space for some reason.  Would any of you mind cross checking your space used please? Attaching screenshots on what I have.



    • Edited by ipatel18 Wednesday, March 27, 2019 2:10 PM Uploaded Working Server Screenshot
    Wednesday, March 27, 2019 2:09 PM
  • I don't think the slight different in the sizes will matter, did you make sure the SPNs are configured as Dwalsham mentioned earlier?

    Blog: LinkedIn:

    Wednesday, March 27, 2019 10:23 PM
  • After another week of troubleshooting and checking with other team members I was not able to find why its still not working.  I verified the SPNs according to Dwalsham but I am not finding issues their either.  The test server that currently works does not even have its name in the service account.  Attaching a screenshot below.  The test server that works is called SRV-TST03.  All the non working servers are in the screenshot.  Totally lost at this point :(


    Friday, April 5, 2019 9:10 PM
  • It's very strange indeed.. I can't really come up with something else other than trying to reinstall the Orchestrator management server (not the operating system, just Orchestrator).

    Blog: LinkedIn:

    Friday, April 5, 2019 9:20 PM
  • Ill try that again.  What OS are you running it on. Mine is server 2016

    My install steps in order:

    1. Install SQL Native Client 2012

    2. Install SCORCH 1801

    3. Update SCORCH to 1807

    4. Register SCOM Intergration Pack from System Center Integration Pack for System Center 1801 Operations Manager and future releases (Version 7.3) but looks like MS has removed that link now.

    5. Deploy SCOM IP to runbook server

    6. Test Connection to SCOM server.



    Friday, April 5, 2019 9:34 PM
  • I'm also running my Orchestrator 1807 & SCOM 1807 on Windows Server 2016.

    I installed in the following order:

    1. Install fresh Windows Server (2016).

    2. Install SQL Server (2016).

    3. Install Orchestrator 1801.

    4. Upgrade Orchestrator to 1807.

    5. Install SCOM 1807 console.

    6. Register the System Center Integration Pack for System Center 1801 Operations Manager and future releases

    7. Deploy the Integration Pack to the Orchestrator management server.

    8. Create the Orchestrator -> SCOM connection.

    9. Test the connection between Orchestrator -> SCOM.

    Blog: LinkedIn:

    Friday, April 5, 2019 9:40 PM
  • I am going to follow exactly your steps.  For SQL 2016 do you have SP2 as well or just SQL 2016?  Also, what features have you enabled during SQL install?


    Friday, April 5, 2019 9:58 PM
  • Here's my SQL Server setup:

    Operations Manager database

    SQL Server version: 13.0.1601.5 (RTM)

    SQL Server features:

    • Database Engine Services
    • Full-Text and Semantic Extractions for Search
    • Reporting Services - Native
    • SQL Client Connectivity SDK

    Orchestrator database

    SQL Server version: 13.0.1601.5 (RTM)

    SQL Server features:

    • Database Engine Services
    • SQL Client Connectivity SDK

    The SQL Server shouldn't really matter, as long as it is a supported version:

    Orchestrator 1807 supported SQL Server

    Operations Manager 1807 supported SQL Server

    Blog: LinkedIn:

    Saturday, April 6, 2019 9:43 AM
  • Hi,

    To fix this issue, follow these steps on Management servers/Runbook servers:

    1. Start Registry Editor.
    2. Locate the following registry subkey:

    3. Check whether the SystemDefaultTlsVersions value exists.
      • If the value exists, make sure that its data is set to 1
      • If the value does not exist, create a DWORD (32-bit) value, and specify the following values:
        Value data1
    4. Click OK.
    5. Reboot the server.

    Repeat the same steps (3 and 4) for following registry path as well.




    Also Please make sure Cumulative updates are installed as mentioned in the following article.



    Tuesday, April 16, 2019 3:31 AM
  • Leon,

    Apologies for the late reply cause I was on vacation. 

    However, I tried the steps that you mentioned and the same SQL server settings, I still ran into issues.  Your installation steps however did help me clear up the SCOM SDK issues that I was running into so that was very helpful.

    So, as another trial run what I did I installed SCORCH 2019 and used 2019 IP and it connected all fine without any issues.  I didnt have to make any changes to the TLS settings or any registry settings. 

    As of now I am able to connect to my SCOM 2012 R2 environment.  I am planning to upgrade that 2019 soon anyway so I will just use SCORCH 2019 for now. 

    I do appreciate your help and everyone who has chimed in to point me to the correct direction. 

    Thank you all.


    Tuesday, April 16, 2019 9:26 PM
  • That is great to hear Ishan, I'm glad you worked it out!

    (Please don't forget to vote as helpful & mark as answer so that the community can easily identify the solution!)

    Blog: LinkedIn:

    Tuesday, April 16, 2019 9:29 PM
  • Me too.  I did learn a lot just from this troubleshooting and with excellent suggestions from this community.  I could be wrong but I think my SCOM IP was corrupted even though I kept downloading a fresh copy from Microsoft website. 

    I am just very happy on how quickly this community has responded. 


    Tuesday, April 16, 2019 9:48 PM
  • I ended up running into this in my production environment today. I had to download the latest IP from here "" and reregister/reinstall it
    Sunday, August 4, 2019 8:34 PM