I had a developer uninstall\reinstall IIS and ASP.net on my production sql server.
Doing an uninstall and reinstall on a production server is a major step. I hope you did in-depth analysis of the problem before deciding this was the best way forward, rather than just a quick decision during a crisis.
Now I'm unable to get reporting services to operate.
IMHO there is no real excuse for not testing the IIS uninstall/reinstall on a non-production server before doing it on the production box. If you had done this, you would have known this would happen, and could plan for it.
At the very least the production box should have been imaged so that it could be reinstated if the 'fix' did not solve the problem.
BTW, did the IIS uninstall/reinstall fix the original problem, and do you now know what the problem was and how to avoid it in the future?
When you have a crisis, taking a decision to change the environment without knowing what the side effects will be can create what is called a 'rolling disaster'. Your IIS 'fix' broke SSRS. Fixing SSRS may break something else. At the very least you now have a production box with a mix of DLLs and registry settings that will be impossible to reproduce on a newly built box, so you will never know if any future problems are caused by your uninstall/reinstall activity or by underlying problems in the software.
When you have got things working, I strongly recommend you do a post-incident review where you and your management look at the sequence of events and decide what could be done better the next time you have a crisis.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara