Clustering, virtual sql servers and client network aliases

I have a question regarding the nature of virtual sql servers, specificially what protocol is used to communicate to the server when a request is made by a client.

For example, if a scheduled job is run on the virtual sql server, what determines the protocol used (e.g. TCP/IP, named pipes etc.) by SQL Server agent? Is it the client network alias set up on the virtual server?

I am asking because currently the client aliases on some of our virtual sql servers are using named pipes and I think this is causing a problem with our backups.

Thanks,
Adrian.Sounds like a Windows 2003 cluster running SQL 2000. There is a problem on install that you have to make the named pipe aliases, or the install fails. It sounds like no one cleaned up after themselves after the install. You should be able to remove those aliases (but write down how they were set up, in case you do need them). Clients can talk to virtual SQL Servers on any of the regular protocols.|||Yes, a correct deduction! Thanks for your comments. I am trying to understand the specific role of the client network aliases set up on the virtual sql server. As its a virtual server (essentially a pointer to the active node) does the alias dictate the protocol used?|||When you create the alias, you also identify which of the active protocols (one to a customer) that alias will use.|||Thanks. What I'm trying to get at is the special situation of client network aliases on a virtual sql server. Are they responsible for dictating the protocol used for communication between the virtual server and actual node?|||The aliases are tied to the physical node. Most OS settings are tied only to the physical node, as well, so you have to be careful to keep them both at the same patch level, and with the same settings.

What process are you thinking of that is communicating from the physical node to the virtual server? Most backup packages have support for clusters that do not need to know the name of the physical node. In fact, it is better that they do not know the physical node name, because the physical node name is not actually guaranteed at any point in time.|||Thanks MCrowely. There are some regular SQL backups scheduled but they do not run. Backups can be run manually (through EM or t-sql) and are successful. But when the job is run (manually or automatically as scheduled) it fails.

Diagnosing the problem I have checked the usual things: permissions (e.g. users associated with the context have permission to write a backup file), disk space. Logically, the only factor that might explain it is client network aliases on the virtual server. For failing backups run from the job, aliases use named pipes. Other successful backups are using tcp/ip.

I'd like to fully understand the significance of the aliases on virtual server before I change them and investigate its affect.

Can you shed any additional light on this please?

Thanks.|||Not sure what else to say. Details of how each network protocol works is usually pretty transparent. Perhaps if you looked at step 5 in the workaround?

http://support.microsoft.com/kb/815431|||Thanks anyway MCrowley.

I'm going to go ahead with the change to remove the named pipe aliases and replace them with tcp/ip (making a note of original settings and performing it outside business hours!)