Symptoms
HTTPS to reporting services only working on prd-web01b, not on 01a. Checked all the config etc. and re imported certs from b to a. SChannell errors were our only clue, although William found some of these on the other server too. Even rebooted the server for good measure.
How we fixed it
This was the clue - https://support.microsoft.com/en-gb/help/956209/ssl-no-longer-works-after-you-remove-an-ssl-binding-from-sql-server-20
We added the cert into IIS (even though we are running in native mode) , removed it from IIS and rebound it to reporting services and everything now appears ok.
Explanation
Some months ago we upgraded all our certs – I think it was to 2056 bits or such like – as the old ones were becoming invalid.
My theory is on the a server we unbound the old cert – thus removing the crucial registry setting in the above link – and then bound in the new cert.
On the b server we probably just selected the new cert.
I’m not sure who did this work but since a good manager always takes the blame for their teams actions – it was probably me. (Lesson – sooner we go to scripted deploy the better).
However this did not fix the problem!
2’nd problem
The ever clever mr***suggested looking at the logs – and I found them – FYI there in d:\ Program Files\Microsoft SQL Server\MSRS12.MSSQLSERVER\Reporting Services\LogFiles on our servers.
Found the errors –
library!ReportServer_0-36!1050!09/05/2017-08:54:29:: e ERROR: Error rending control: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
http://go.microsoft.com/fwlink/?LinkID=314055 ---> System.Web.UI.ViewStateException: Invalid viewstate.
Client IP: *****
Port: 59222
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
ViewState: /wEPDwUKMTEzMjExOTUxNA9kFgQCAQ8WAh4EbGFuZwUFZW4tR0JkAgMPZBYEAgQPZBYEAgEPFgIeBVZhbHVlZGQCAw9kFgJmD2QWAmYPFgIfAWRkAgUPFCsABQ8WCh4UU2hvd1Byb21wdEFyZWFCdXR0b25oHgxTY3JvbGxUYXJnZXRkHhNQcm9tcHRBcmVhQ29sbGFwc2VkZx4QVjFTdHlsZVNoZWV0TmFtZWQeDlJlbmRlcmluZ1N0YXRlCymRAU1pY3Jvc29mdC5SZXBvcnRpbmcuV2ViRm9ybXMuUmVwb3J0UmVuZGVyaW5nU3RhdGUsIFJlcG9ydGluZ1NlcnZpY2VzV2ViU2VydmVyLCBWZXJzaW9uPTEyLjAuMC4wLCBDd
..
How we fixed it
This was easy for a web farm person like me – when you have a .net application in a web farm you need to add in encryption keys across the farm.
First I checked the instructions as I would have thought that SSRS might do this for me as you actually configure the thing for scale out but MS aren’t that bright – yes you do need to manually put in some keys (https://docs.microsoft.com/en-us/sql/reporting-services/report-server/configure-a-report-server-on-a-network-load-balancing-cluster).
So I generated some for each environment and did this.
Explanation
I always said the old load balancer was not load balancing. The new ones (F5) are.