Cluster configuration not working

[guiguille]

Hello guys,

I'm trying to configure a high availability schema in our SN instance for orchestration. So I started looking into capabilities. The thing is that for themselves they don't seem to do anything. Then I read that capabilities work inside IP ranges, and that's something I don't want to use.

So I found clusters, that according to what I read, the configuration shouldn't be too difficult. So, this is the process I followed:

• I created two mid servers
• I added to both of them all the existing capabilities (we don't have any custom created ones)
• I set one of them as the default one
• I create two clusters, one failover and another one load balance with these two servers (I tried first with only failover that is what I want, but it failed so I created the other one)

According to what I read, this should be enough to have a cluster between these two servers, in case one is unavailable. So, my test was to stop the service of the default mid server, and run the workflow. When I do that, I get the error "The configured default MID Server (<DefaultServer>) is not available". When starting the default server's service, the workflow runs without problems (I'm just trying to get the ipconfig from the localhost in my test workflow).

I'm running a "Run Powershell" activity, so adding the Powershell capability should trigger this, right? I'm not sure if I'm missing something.

Thanks in advance, any feedback is appreciated.

Regards

[madygowtham]

If i'm making any clustered server as default and making another cluster server2 into down. and used clustered 2 ip in workflow. i'm getting this error

<error>

Authentication failure with the local MID server service credential.</error><error>Failed to access target system.   Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))Stack Trace:       at System.Management.ManagementScope.Initialize()at System.Management.ManagementObjectSearcher.Initialize()at System.Management.ManagementObjectSearcher.Get()at Microsoft.PowerShell.Commands.GetWmiObjectCommand.BeginProcessing()at System.Management.Automation.Cmdlet.DoBeginProcessing()at System.Management.Automation.CommandProcessorBase.DoBegin()</error>

[Mike Moody]

That error message sounds like the MID Server that is attempting to process your Orchestration action isn't using a service account with the appropriate permissions to execute whatever action your trying to execute with that Orchestration activity. Check the credentials that are set in the LogOn tab of the ServiceNow MID Server service on all your clustered MID servers to validate that it's an account that has the permissions to do what you are trying to do via Orchestration within your network. I typically use a service account with Domain Admin rights within our Active Directory.

[bernyalvarado]

It sounds like one of the MID servers is not properly setup.

Thanks,

Berny

[guiguille]

Hi Berny,

I don't thing there was a misconfiguration in the mid server, because each of them worked fine properly if they were set as default. And the load balancing worked when the two servers were up. The issue was when the default one was down. I'm not in working in that SN instance anymore, but I just wanted to give context.

I'm still in contact with the people in that company, so I'll keep you posted if there's a solution over there.

Thanks,

Regards

[bernyalvarado]

Btw... One note in case it adds value: often it's better to have the cluster as a Load Balance type since it will also fulfill the failover purpose. On the other hand a Failover one will not be able to fulfill the balance the work.

Thanks,

Berny