Name Resolution and SharePoint

rickt287 — Fri, 05 Jun 2009 05:02:47 GMT

SharePoint uses name resolution to find other servers just like any other application. But what happens when your infrastructure uses different types of name resolution? Don’t think there would be a problem, right? That’s what I thought.

When you set up your server’s OS (operating system) you configure its network setting to get them from a DHCP server and your DHCP server is configured to hand out only the IP address of your DNS servers, you are OK. But if you are using both WINS and DNS and you have configured DHCP to hand out both—you may have an issue. Here is what I ran into at a client.

The client utilizes WINS (in addition to DNS) as a name resolution service, but which caused some unforeseen issues. There are known issues using WINS with SharePoint and if one were to follow the guidelines in http://support.microsoft.com/default.aspx/kb/308913 most of the issues can be avoided.

One issue is not mentioned in the article; it deals with the NetBIOS naming of servers. A NetBIOS name is combination of a 15 character (byte) name and a 16th character denoting the service compared to 255 or fewer characters for DNS host names. If you are running Windows Server 2003, the host name and the NetBIOS name on a computer are generated at the same time during installation. If the host name is more than 15 characters, the NetBIOS name is the first 15 characters of the host name, (which is better than it used to be, because it used to truncate the name to 13 characters and and a tilde and a number to the name).

In the case of SharePoint, if you are using both DNS and WINS, make *sure* that *both* names are registered in *BOTH* systems. If any servers have names longer than 15 characters, take both the long name *and* the short name and register the A Record names in DNS. If you don’t, SharePoint will use the truncated name from WINS and register that name in the configuration and content databases. If this happens, name resolution may not work properly unless the truncated name is also registered with DNS.

“Not work Properly” – this is what I mean:

Example:

Server1 (DNS) Name: PHX2-FILS-APP-01.company.com

Server2 (DNS) Name: PHX2-FILS-APP-02.company.com

Server1 (WINS) name: PHX2-FILS-APP-0 (This name gets registered in the Config DB)

Server2 (WINS) name: PHX2-FILS-APP~1 (This name gets registered in the Config DB)

If you register both the DNS and the WINS names you will be able to both access the server in the browser and you will have no issues with the databases.

Documentation

rickt287 — Sun, 23 Sep 2007 06:57:00 GMT

Is it so hard to document what we do? I think so. Otherwise there would be more information out there on stuff. I'm just talking about the stuff we know about. There is so much untapped knowledge that there probably isn't time to write down what we all know--now imagine what we could know if we would just take the time and write about it.

Our upcoming book is just a sliver of what the Engineering and Ops teams know; but it needs to get "out there". The working title is: "Microsoft Office SharePoint Server 2007 Engineering and Architecture Resource Kit".

This is a text that will be the prescriptive guide to architecting and engineering a successful, large-scale implementation of MOSS 2007--written by Microsoft Architects and Engineers. There are a number of books out there that speak to both WSS and MOSS. All of them are for *Administrators*, the emphasis being on Administration. This book will be a 'nuts-and-bolts' text of the "why" more than "how". The book will be similar to a "Notes from the Field" but from an Engineer's perspective, not an administrator; a book on “How Microsoft does IT.

We have a lot of SharePoint Engineers and Architects who have expressed a deep interest in participating; from all areas of the company, such as the Product Group, Engineering (IT), Engineering (MMS), Marketing, etc.

SharePoint; from an Engineer's Perspective : MOSS

Name Resolution and SharePoint

Documentation