I've dealt with the whole issue of having to change the server name after it's created from an image, but I've run into something I've never dealt with before at my new gig.
Consider the following (sorry I cannot use real server names):
Server 1 (2012 SP2):
DNS Name: SomeServer
@@SERVERNAME: imagename
Environment: Production
Server 2 (2008 SP4):
DNS Name: SomeOtherServer
@@SERVERNAME: SomeServer - note this is the DNS name of Server 1
Environment: Test
So, yesterday I updated Server 2 from SP1 to SP4. Almost immediately, I got emailed that the Server 1 SSRS service wasn't working anymore:
The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is 164. The expected version is 162.
Remember - I was never even on Server 1.
When I open SSRS config on Server 1, the server name value that I connect to is SomeServer, as expected. I go ahead and connect and look at the database tab. SQL Server Name is SomeServer, as expected. Database Name is ReportServer, as expected.
When I open SSRS config on Server 2, the server name value that I connect to is SomeOtherServer, as expected. I go ahead and connect and look at the database tab. SQL Server Name is SomeOtherServer, as expected. Database Name is ReportServer, as expected. One oddity I do find here is that on the URL tabs, there are 2 possible URLs instead of just 1.
Web URL 1 - http://SomeOtherServer:80/ReportServer
Web URL 2 - http://Unknown:443/ReportServer
Manager URL 1 - http://SomeOtherServer:80/Reports
Manager URL 2 - http://WMSvc-SomeServer:443/Reports - Note the reference to the other server here
Based on the verbiage of the error, our initial thought was ok, we'll just have to update that prod server too. But then I realized the 2 servers aren't even the same version of SQL. The test box is 2008 and the prod box is 2012.
As I said before, I've dealt with the whole image name thing and renaming the server, but I've never dealt with the incorrect name being the real DNS name of another server and it actually impacts that other server.
I'm scared to correct the server names, for fear of just making things worse. How did updating the test server break ssrs on the production server? The only link between the 2 is the test server's @@SERVERNAME being left as the prod server's DNS name.
As an added good time, the company doesn't do database backups. Just whole-server snapshots. So I can't just restore the db from backup and wouldn't have an encryption key even if I did. Did I mention that I'm the 1st DBA the company has ever had?
Ultimately my question is how can I fix SSRS on the prod server? Fix the name on that test server? Would that cause other problems? I need some advice big time. The pressure to not fail here is extremely high, especially since it's already perceived as I broke it by doing the update on the test server. If I make things even worse... No - just no.
April 11, 2019 at 6:19 pm
For the version error on the 2012 instance, refer to the following article:
Sue
April 11, 2019 at 6:36 pm
Thanks Sue. I checked it out and will be updating the prod server tomorrow night off hours. Nonetheless, I don't understand how updating 1 server affected another. The only link between the 2 is that the test server's @@Servername is the same as the DNS name of the prod server. I cannot understand why they're linked this way.
Well, fix the prod server first and then work on untangling the mess. You could have been on the wrong server with the update - Check your Setup Bootstrap\Log files on the servers themselves to see what was updated on which server. And if that's what happened (understandably), all the more reason to get the computer names correct and things in sync.
Make sure sys.servers is correct for the local server name (server id = 0 for local server in sys.servers). If a key has never been generated for the SSRS servers, generate them and stash them somewhere safe. And I wouldn't worry about no backups - when you need one restore the server and let the business learn the hard way. Sometimes it's the only way things like that change.
Sue
April 12, 2019 at 1:54 am
"When I open SSRS config on Server 1, the server name value that I connect to is SomeServer, as expected. I go ahead and connect and look at the database tab. SQL Server Name is SomeServer, as expected. Database Name is ReportServer, as expected."
combined with
"The found version is 164. The expected version is 162"
This sounds suspiciously as if your SSRS database server "SomeServer" that you connect to from Server 1 is actually the database on Server 2 (the now patched 2008 server).
I recommend opening up the ReportServer databases on each of the two SQL Servers and checking what's in each of the catalog tables. You may be surprised at what you see. Also try stopping SQL Server on the 2008 instance, and seeing if Server 1 still gives the error message.
Note that the Web and Manager URLs are simply the server where the SSRS engine (service) is running, and don't impact on where the ReportServer database is. You need to determine exactly where Server 1 thinks it's database is, but you effectively have 2 servers called "SomeServer", one defined officially via DNS, and one defined at the SQL Server level. Definitely not good practice, and something I have avoided at all costs when doing upgrades. I don't think there are any guarantees around how your DB connection will be resolved in this situation.
Leo
Nothing in life is ever so complicated, that that with a little work it can't be made more complicated.
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
April 12, 2019 at 12:29 pm
Thanks for chiming in Leo.
I looked at the Catalog table on Server1 vs Server2. Both are populated, but with different things. However, this doesn't help me because neither ReportManager will load for me to look at what shows up in the interface.
I think 2 things are going to happen end of day today. I'm going to update the sp on the 2012 AND I'm going to fix the name on the 2008. If this doesn't fix it, or worse yet, makes things even worse, I'm at a loss.
This is what happens when a data-critical company thinks they don't need an actual DBA because they have a sys admin "that knows a few things".
April 12, 2019 at 2:12 pm
This is what happens when a data-critical company thinks
I think you identified the issues 🙂
Don't forget to check the reporting services logs, they can give you a lot of clues about any configuration issues. Good luck and post back on how it goes.
Sue
April 15, 2019 at 12:52 pm
The upgrade to the 2012 did the trick. I cannot wait to sever the inadvertent links between all these servers. I only described 2 in this scenario. There are so many more with this naming issue.
Sue & Leo, thank you so much for your help!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply