Hi Ben,

How many servers are involved?

Do you have specific Search only and or Mobile only servers?

Are you trying to load balance the Web services and have Search & Mobile point to the load balancing.address instead of directly to the server there are installed on?

What I typically do is have each service point to the server they are installed on and then load balance across the multiple servers for the search & mobile services.

The likelihood that web services would be down and search and/or mobile services still running is probably pretty rare and not worth the aggravation of maintaining that configuration.

Hi Gary,

The previous implementor has set the Loadbalancer URL for the Web Services name inside the Search setup.

Because this uses SSL and the local (self-signed) certificates were expired, this caused this error.

Although they implemented the Mobile Services installation, but they're on a Notes environment.

Depending on the Loadbalancer, you may be able to offload the SSL there and use non-SSL to connection to the servers.

You'll have the same issue if the loadbalancer SSL Cert is expired, of course.

Thanks for your advice Gary.

SourceOne continued working while the certificate was expired since april this year. We faced this issue as soon as we've tried to upgrade the Search Service to the latest version.

Exactly.

It won't get by the expired cert in the test connection during the installation.

The other way around it is to stop IIS and let the connection failed and chose to ignore it during the install.

I've had a similar problem when the customer has applied more restrictive permissions on the SourceOne install drive and the install test fails.