Feeds:
Posts
Comments

Posts Tagged ‘Hyper V’

While helping on a Sharepoint 2010 installation for a client, which was on a virtual server on Hyper V , I came upon a interesting error:

Cannot connect to database master at SQL server at {ServerName}. The database might not exist, or the current user does not have permission to connect to it.

We verified that the database account had the proper security requierements using this guide. No such luck.

Then we tried checking the firewall and implementing this (which is an excellent article). No luck either.

Hmmm. So, just to check on a hunch, I installed the SQL Server 2008 R2 Management Studio Express (No more licences for the management studio!) and tested to see if I could connect to the SQL box. Nope, no dice. Something told me to check if I could connect using Named Pipes. Voila! Then I tried to connect using TCP/IP and couldn’t (“Cannot create a SSPI Context”).

Using my best friend (Google), I found this KB, which truth te told, it did not apply to the client’s SQL version, but this line gave me an idea:

“To see if the Ping command-line utility resolves the fully qualified DNS of SQLServer1, run the following command:

ping -a IPAddress

For example:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\>

When the command ping -a IPAddress resolves to the correct fully qualified DNS of the computer that is running SQL Server, the client side resolution is also successful.”

I did the whole ping thing, but noticed that the name resolution was coming from IPv6, not IPv4. Hmmm.

So, I disabled IPv6 for a sec on the SQL, the Virtual and the host machines. Tried the ping again, still came with IPv6 data. Double interesting! Hey, Google; why is this happening?

 Found out that there is a little problem with IPv6 showing on HyperV, even thou you have it unselected. I know that SQL can use both IPv4 and IPv6, but it seems that the Sharepoint wizard uses IPv4 to connect to SQL. This article that I found told of a registry change, but those type of changes I try to avoid, so with a little file called hosts, I wrote the IPv4 address of the SQL box into the Virtual box and success!

No more error!

Advertisements

Read Full Post »