Dodged a bullet!

Ever get that feeling like everything is going to blow up, where you start thinking it's better to blow it all away and restore from backup, yada yada yada...but then you have a great idea and save the day?  Smells and feels and tastes SOOOO good, huh?

Here was the scenario:

Customer installs SQL Server on a server and later puts SharePoint 2013 on the same server to "test it out".  Later, SharePoint becomes a "critical" application and needs to be scaled out.  They add a front end and an application server to the farm and remove SharePoint from the SQL Server.  Incidentally, even though the SQL server no longer has SharePoint installed on it, it is still considered "part of the farm".  Now the client needs a third party application (Nintex) installed.  It fails.  Multiple times.  A call to their technical support and a marathon session of 3 hours tells us that "There is an orphaned server and our product is looking for it.  There is an entry in the Config DB referencing this server.  You can go in there and remove it and then try our installation again."    Right.

So when we ran Get-SPDatabase we got a list that looked like this:

Yeah...two different names for the SAME server.  Simply removing the server from Central Admin did not remove the names from the databases.  So going into each individual DB and removing the reference to this "other" server wasnt going to work.  So..What if we simply changed the name from one to the other?  In actuality it was the same machine and the databases were intact...so...hmmm?

So here is what we did:

After we ran it, we installed the Nintex workflow application and it worked like a charm!

Comments

• Anonymous
  November 06, 2017
  This is exactly why we ALWAYS recommend setting up an alias to the DB server.
  • Anonymous
    November 06, 2017
    Ah, but that is in the beginning...we got to it AFTER the fact. Too late at that point.