Upgrade Advisor 2012 won't accept port numbers - by Sean Gallardy

Status : 


Sign in
to vote
ID 776902 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 1/18/2013 7:46:41 AM
Access Restriction Public


When running the Upgrade Advisor for SQL Server 2012 the textbox that accepts the server name will not accept port numbers and will give an error on the bottom of the screen that says:

 "The specified server name contains invalid characters."

This creates a point of contention as we have instances of SQL Server that run on non-standard port numbers and DO NOT have the browser service enabled per our security requirements. Thus the port number lookup fails and will error.

Currently, the only work around is to create an alias with the correct port number - however I find this disturbing as the functionality should already exist given it's a normal part of connection strings.
Sign in to post a comment.
Posted by PatrickPurviance on 2/7/2013 at 7:53 AM
I'd like to add that the majority of the SQL Server instances that we need to run the 2012 UA for are running on Windows 2003 SP2 OS Platforms, which WILL NOT ALLOW SQL Server 2012 components to be installed. So the option of a local install to solve these issues is not an option.

This really should be fixed. I can't imagine everyone running out and upgrading the OS just to be able to run this tool locally when it should be designed to correctly run remotely against non-default port, named instances (can you say "cluster"?).
Posted by Sean Gallardy on 2/5/2013 at 9:33 AM

While I understand that it will not be fixed, some type of change for the next version to work such as the SSMS application does would be expected.

The tcp work around does not work as the error is the same mentioned, "the server name contains invalid characters". The only REAL work around is to use aliases. In my environment this mean a great deal of aliases.

I still find this to be an unreasonable solution and a huge oversight by MS.

Posted by Microsoft on 2/5/2013 at 9:26 AM
Hi!, thanks for writing in to Microsoft.

We took a look at this bug and triaged it against several others. Unfortunately, it did not meet the bar to be fixed and we are resolving as ‘won’t fix’. That said, you can try the workaround suggested below and tell us if it works for your scenario:

If your server is local then then use: “tcp:.,<your-custom-port-number>” (without quotes) for the server and leave instance blank. If your server is remote then use: “tcp:remoteServerName,<your-custom-port-number>” (without quotes).

If this does not work for your scenario then you can create an alias as described in http://msdn.microsoft.com/en-us/library/ms190445(v=sql.110).aspx. Type in a name for the server alias, select tcp-ip protocol and uncheck default port and put in <your-custom-port-number>. Also remember to change the server name to your target SQL Server. You can then run Upgrade Advisor and put in the server name you specified for your server earlier when you created the alias. If Upgrade Advisor asks for an instance after entering the alias with the named instance you can enter "default" to continue.

Sanjay Nagamangalam, SQL Server Manageability
Posted by Sean Gallardy on 1/24/2013 at 9:38 AM
I should follow up on the comment I made previously to make it less deceiving. While the UA DOES support named instances (which are on the screen after the servername I was pointing out) it will take a while to time out (on some) and on others it refuses to connect. What I am stating is that let us put the instance name in the servername box as we would normally instead of waiting for timeouts and failures. Since there is no way to create a queue of instances to check, adding up the 1-2 minutes lost running on each instance can add up to hours of time lost.
Posted by Sean Gallardy on 1/18/2013 at 7:59 AM

I should also add that it DOES NOT support NAMED INSTANCES. This has to be a huge oversight as named instances are certainly allowed and used often.