Most Popular Posts

Oct 16, 2009

How to Build an Internet Identity with a Low Budget

This article is for people who are not willing to spend too much time or money on service hosting. If being present on the Web is part of your business, then sign up for a hosted virtual machine and install and maintain the services you need. This article won’t help you very much.

If you are still reading, I assume you are like myself – you want to have an essential web identity – intuitive web and email addresses. And you don’t want to monitor and maintain the background services. In addition to that, your spouse doesn’t really understand why you want pay to for a virtual computer when you have three real ones at home.

Here I present a procedure that allows you to build an essential web identity for $15 per year and no maintenance.

Step 1: Design your identity

Think what web site URL and email address you want to have. For instance, I prefer to keep it simple – if you can spell my name, it should be trivial to find me:

Following this guideline has an additional benefit – you can enable your entire family to build their web identities for free which you can use as an argument the next time you need a budget increase.

Step 2: Register a domain name

Make sure you are happy with the domain name you came up with in the previous step, because now you’ll have to purchase it. This is where my $15 per year go. It’s totally worth it. Owning a domain name independently of the services gives you the freedom to use different services from different providers and to change a service provider when you are not happy with the quality of service they provide.

There are many registrars. I’ve chosen http://godaddy.com – I have no complaint so far. The tools are pretty good and there are help topics dedicated to the most popular free service providers. Feel free to do your own research and chose the one you feel most comfortable with. That doesn’t deviate from this procedure.

We are done for now with the domain name. We’ll get back to configuring the DNS records once we open service accounts.

Step 3: Open an email account @ your domain

Microsoft (http://officelive.com) and Google (http://google.com/a) have free packages that allow you to have several email accounts @ your own domain. Those packages are intended for small businesses but there is no requirement to own a business in order to open a small business account. Yahoo (http://smallbusiness.yahoo.com) also offers a compatible package, but I cannot see a free option.

Choose the provider you are more comfortable with and open a service account with it. Or, you can open service accounts with multiple service providers and later drop those you don’t need.

During the account opening process you may be required to prove that you own your domain name by creating a temporary DNS record that maps a special name to one of the provider’s servers. Don’t worry, the instructions will be easy to follow.

At the end of the email account creation process, there should be a page where the service provider shows you the list of their mail server IP addresses. You should do the following:

  • Log into your DNS account (that you created in Step 2).
  • Find the section related to DNS record management.
  • Create a separate MX record for each server.

Once you commit the changes you should be able to send yourself an email.

Step 4: Open a web service account

Here you have a variety of choices. The fundamental categories are:

  • Blog
  • Wiki
  • Web site builder platform
  • Plain HTML

And there a multiple options within each category. The properties you should be looking for are:

  • The service is free of charge
  • The service provider allows you to have your own domain name at no extra cost

Again, you can create multiple service accounts that you can evaluate in parallel. My personal choice is blog as blogs require minimum effort to write and they don’t demand too much content. Wikies are also relatively easy to write, but a wiki demands lots of content that you are unlikely to have for a long while. I’m also looking at Drupal which is a web site builder platform. It offers a high degree of flexibility to you web site but you have to spend the time designing. And finally, plain HTML is the easiest way to get started, but the maintenance cost grows exponentially as the content grows. So I strongly vote against it.

Back to blogs. There are two big free blog service providers – WordPress and Blogger. WordPress offers more features and styles than Blogger. However, having your own domain name is not included in WordPress’s free package. I’ve found two limited workarounds:

  1. You can redirect your domain name to the WordPress domain name. So people can still find you but then they will have to deal with the “actual” WordPress URL which may confuse them.
  2. You can redirect your domain name to the WordPress domain masking the actual domain name. Technically, this is a web browser feature – the browser always shows you root domain name regardless of where the user navigates. That becomes problematic when someone wants to save or forward a direct link to a page.

After all, I’ve chosen to use Blogger to keep the user experience intuitive hoping that Blogger will catch up on features and styles.

Again, you have to create a DNS record that redirects your domain name to the web site:

  • Log into your DNS account (that you created in Step 2).
  • Find the section related to DNS record management.
  • Create an A record for the web server.

Conclusion

This is all you need to get started. You can continue searching for better email or web service providers. Whenever you decide to switch, migrate your content and update your DNS records. The people who interact with you online won’t have to update their links. And please let me know if you discover a cool service provider.

Oct 14, 2009

Public Specifications of SQL Server Protocols

Specifications of protocols used to communicate with SQL Server components are now publically available on MSDN. The Open Specification branch is available in the tree view at top level. What is not so obvious is where to find the core SQL Engine protocols.

[MS-TDS] Tabular Data Stream

This is the protocol that client data providers use to communicate with the SQL Server Engine. The current version of the protocol specification is located under Windows Protocols > Windows Server Protocols (WSPP).

[MC-SMP] Session Multiplex Protocol

This protocol is used when the MULTIPLE ACTIVE RESULT SETS connection option is requested. This protocol allows both the client data provider and the SQL Engine to split a single physical connection into multiple virtual connections in order to transfer multiple result sets simultaneously. The current version of the protocol specification is located under Windows Protocols > Application Services and .NET Framework Protocols.

[MC-SQLR] SQL Server Resolution Protocol

This protocols is implemented by the SQL Browser service and is used by client data providers to discover available SQL Engines as well as to resolve SQL Server instance names to protocol-specific settings. The current version of the protocol specification is located under Windows Protocols > Application Services and .NET Framework Protocols.

The Microsoft SQL Server Protocols Branch

Now you may be asking: What is under Microsoft SQL Server Protocols then? The answer is: every other protocol related to SQL Server.

Beware of the [MS-SSTDS] Tabular Data Stream Protocol Version 4.2 that you’ll find in this branch. It is the protocol that SQL Server 6.5 used. It is documented, because the SQL Engine can still speak it. But if you want the current TDS protocol, see [MS-TDS] above.

Oct 13, 2009

How to Troubleshoot Connectivity to a Named SQL Server Instance (part II)

This post is a continuation of How to Troubleshoot Connectivity to a Named SQL Server Instance (part I) where I touched on how data providers connect to SQL Server instances. Here I’ll discuss some common problems and how to troubleshoot them.

Actually, the problem I’ll be talking about is only one but it can affect two different services and it is troubleshot in two different ways. The problem I’m referring to is broken network connectivity.

Probing connectivity to a SQL Server instance

Since the TDS protocol (the protocol used by client data providers to communicate with SQL Server) is connection-oriented, it is TCP-based. That makes probing connectivity trivial. All you need to do is try to open a telnet connection:

>telnet example 1433

where “example” is the server name and 1433 is the port where the SQL Server instance is supposedly listening. If the command screen goes blank and you can’t type anything, then a connection has been established, i.e. you have connectivity. If connectivity is broken, you’ll see an error message that a connection cannot be established.

Note: since Vista, the telnet client program is not enabled by default. You have to enable it through: Control Panel > Programs and Features > Turn Windows features on or off.

Probing connectivity to SQL Browser

This is a more difficult task compared to probing a SQL Server instance, because the protocol SQL Browser “speaks” is UDP-based, i.e. there is no connection that ever gets established. The only way to probe connectivity is to send a correct protocol request message and to verify the received response.

Luckily there is a tool, portqry, freely available from Microsoft, that has a built-in knowledge about a number of protocols including the SQL Browser protocol. You can use it like this:

>portqry –n example –p UDP –e 1434 –cn !ms-SQL-m!

If the query reaches a SQL Browser service (and a response is received), portqry will show status of “LISTENING or FILTERED” and some result in the form of a name-value pair collection, e.g.:

ServerName example
InstanceName MSSQLSERVER
IsClustered No
Version 10.0.2531.0

Otherwise the status will be “NOT LISTENING”.

Common causes of broken connectivity

Before trying to change anything, check that the services are running and are listening on the ports you expect them to be listening on.

Other than that, the most common cause of broken connectivity is the Windows Firewall on the server machine. Unless explicitly allowed, incoming traffic to SQL Server instances and SQL Browser is blocked. To fix that, you need to create a custom rule on the Firewall to allow incoming traffic to all the SQL Server instances as well as to the SQL Browser. (I personally find using the program paths rather than the exact port numbers to be more maintainable.)

The second reason why connectivity may be broken is a router on the way that doesn’t have a rule to route SQL Server traffic. You can get the route using tracert on the client machine:

>tracert example

Then check with the administrator of each router whether SQL Server traffic is routed.

If you still have problems with connectivity, post a question on the SQL Server Data Access forum.

Oct 3, 2009

How to Troubleshoot Connectivity to a Named SQL Server Instance (part I)

A common issue I have observed at the SQL Server Data Access forum is troubleshooting connectivity to named SQL Server instances. IMO the troubleshooting difficulty is due to the correlation of multiple factors.

Spotting a Named SQL Server Instance

How do you know that you are connecting to a named SQL Server instance? If you reference your SERVER or Data Source as ‘foo\bar’, then you are trying to connect to a named instance ‘bar’ on machine ‘foo’.  The most typical example of a named instance is SQL Server Express that by default creates an instance named ‘SQLEXPRESS’.

Connecting to a SQL Server Instance

How do data providers find the right instance (especially when there are multiple instances on the same box)? For the sake of simplicity I’ll only discuss connectivity over TCP/IP. That could easily be applied to shared memory and named pipes.

In order for the data provider to establish a TCP connection to the target SQL Server instance, it needs: 1) a machine name/address, and 2) a port number. There are three ways for applications to reference a target SQL Server instance:

  1. Explicitly
  2. As a default instance
  3. As a named instance
Using Explicit Properties

An explicit reference looks like this: ‘tcp:foo, port’. That gives the data provider all the needed information. For the purpose of troubleshooting, you can use that notation to eliminate other factors from the picture.

Using Default Properties

The second way to reference a target instance is by not specifying the port (and protocol), i.e. ‘tcp:foo’ or just ‘foo’. In this case the data provider pulls settings from the Registry on the client machine to find what the default TCP port is. (In the latter case it also pulls information on what connectivity protocols are enabled.) That information is easily accessible through SQL Server Configuration Manager. Navigate to SQL Native Client 10.0 Configuration > Client Protocols. Right-click on TCP/IP and select Properties. You’ll see the Default Port property. In the Registry, that information is stored under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI10.0\tcp.

Using an Instance Name

The above notation doesn’t let you connect to different SQL Server instances on the same target machine. Therefore there is the server\instance notation that is as powerful as the explicit one but is much easier to manage. The mapping of instance names to port numbers (actually, to protocols and protocol-specific properties) is done by a separate service – SQL Server Browser a.k.a. SQL Browser. Since the application never references SQL Browser explicitly, the latter must be listening on a well-known port and protocol, and that is UDP port 1434. When the data provider sees a named instance reference, first it asks the SQL Browser service on the target server (at UDP port 1434) to resolve the instance name name to protocol-specific properties, and then uses those properties as they were provided explicitly.

(To be continued.)