SharePoint; from an Engineer's Perspective : SharePoint

My last project while a Microsoft Blue Badge

rickt287 — Wed, 24 Jun 2009 05:04:00 GMT

My former team-mate Bill Baer posted this link today and I thought I would do the same.

This was an incredible project to work on. What a headache, but at the same time--it was doing something NO ONE IN THE WORLD was doing yet.

http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000004609

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.

The 5 Commandments of SharePoint Deployments

rickt287 — Wed, 05 Mar 2008 10:50:00 GMT

At Microsoft, one would think that Best Practices are the Rule of Law. So one would think.

Being young to the team and to the company I see that things are not as they seem. Not as bad as it seems, nor as orderly as it seems. In my former pre-Microsoft life I was SharePoint consultant and saw the same mistakes being made over and over again. It still hasn't changed. ;)

I had published in REDMOND magazine, what are known as the 5 Commandments of SharePoint Deployments. There are 10, but no one would deploy the thing if I revealed the other 5! So, without further ado, I post the 5 Commandments for MOSS (with an eye forward to O14).

The 5 Commandments of SharePoint Deployments

A successful SharePoint deployment must be built with a solid understanding of information architecture and the organization's needs. Here are some of the most common things you should take into account before (or as) you design your SharePoint infrastructure.

1. Thou shalt not put all documents into SharePoint. This is a common mistake. SharePoint is a good document repository, but it should not replace your file servers. Keep non-collaborative documents on your file servers and point SharePoint to the file server to use as a content source. Dropping all documents into SharePoint unnecessarily grows your SQL database and makes a backup and restore more cumbersome, especially for a file-level restore. The cry that the File Server was dead, was pre-mature and did not take into account the value proposition of the collaborative nature of SharePoint versus the archival purposes of the file server.

2. Thou shalt put processing power on the Web front-end (WFE)/Query Server. Architects often place the biggest, most powerful piece of hardware at the back-end with SQL. But if that database is dedicated to SharePoint, you are off course -- the "hoss" should be placed at the front-end with the WFE. That's the end that gets busy with crawling content and serving up user requests. For designs that break out the Indexer from the WFE/Query it gets a little trickier. If you are crawling over 500GB of content, put the RAM in the indexer and add a proc to the WFE. For designs that use Enterprise features such as Excel Calculation Services or Business Data Catalog, add more RAM. And then add some more. All on the Front End. For the BDC, make sure that your external data source is tuned correctly for the entities that your application definition specifies. Latency will greatly affect performance probably more than any other single factor.

3. Thou shalt not underestimate cost requirements. There are many costs associated with MOSS. Hardware, software licenses, storage, and Human. Don't worry about overbudgeting MOSS; you won't. Let's take the human factor first. You should invest man-hours to make MOSS work right. Expect to budget 0.5 FTE (Full Time Employee) for every 100 content sources you have. Now, storage costs: Obey the Golden Rule of SharePoint -- for every 1GB of data, set aside 5GB to 6GB of storage capacity somewhere for that data. If you don't adequately size your disk space, you'll be forever adding space at inconvenient times. Hardware costs: Get a SAN. Now. I mean it. Did you just say DAS? You owe me a new keyboard! I am purposely avoiding the licensing issue. I've said enough.

4. Thou shalt not scrimp on user training. What if you built a killer app and no one used it? Fail to train your users, and you'll find out. Develop an internal training program or pay for competent external training, but do not let your investment go down the drain. User adoption is key to a successful deployment. There are a number of competent training companies out there; such as Mindsharp, SharePoint Experts, The Ted Pattison Group, SharePoint Solutions, among others.

5. Thou shalt respect the Master Page. Default.master should be protected and not "monkey'd with" unless you absolutely, positively know what you are doing. Master pages provide the look and feel for all of the pages in your sites. Follow the rule of B. (Back it up first) However, if you do make changes directly to Default.master and you messed it up with changes that you made, try resetting Default.master to the site definition. If that fails, go to your backup.

As I said before, there are another 5, but first ye must crawl before ye run.

On another note, I will be writing another article for REDMOND magazine soon and speaking at the TechMentor Conference in both San Francisco and Orlando.