Read the Prescan log…CARFEFULLY!

I thought I would start putting my experiences from the field here when I encounter either a strange occurrence or when I pull my hair out trying to figure out something and it reveals something extraordinary.

I had one of “those” sessions—you know, the ones where you call Microsoft Premier Support and it lasts for a few days and you go through a couple of engineers…yeah, one of those sessions.  Here is how it started:

My client is currently on SharePoint Portal Server 2003 and wants to migrate to SharePoint 2007.  I created a project plan that called for a test environment and test migrations.  I was provided with a test environment with copies of old databases.  They were sufficient to perform the task of test migrations. 

I *thought* it would be straightforward:  run prescan, look at log file, detach database from SPS2003 and reattach in MOSS 2007 and fix the sites that were broken.  Prescan was run, but I missed a line in the error log which proved to be the whole reason for me calling MSFT support.  When I went to remove the content database from SPS2003, it wouldn’t drop.  “hmmmm, thought I….maybe I need to do some repair first”.  I run STSADM –o repairdatase and take a look—45,000 orphans…oh my.  -deletecorruption had to be run 4 times to get <OrphanCount=”0”/> to show up in the log. I still can’t get it to work. ARRRGGGGHH…

Screw it, I go to the SQL Server and drop all connections and then see if the database will remove from SPS2003.  NOPE.  WTF!!??  I attempt to attach the database to MOSS and receive this error:

Interesting….it thinks that prescan hasn’t been run.  I re-run it.  Re-try to attach it…same error.  This is really starting to bug me.  So I built another SPS 2003 server and was able to attach and detach the database with no issues.  That’s a relief.  I ran Prescan and received an error. After reviewing the log I saw the line that changed everything:

12/28/2009 18:16:18 Checking if any site has not yet been scanned in Server="MOSSDBSERVER";Database="blahDB_Site";Trusted_Connection=yes;App="prescan.exe".

12/28/2009 18:16:18 Error: The following site has not been scanned. Id = dfa72d8b-1f51-4266-bf37-4964fc8063dc and Url = /sites/RESTORE_Projects

HMMMMM…..let me go to SQL and see what is happening there….and I see this in the db.Sites table:

So prescan was iterating through the sites table and sees the BitFlag set to zero.  I figure if the sites whose BitFlag set to zero were deleted from the database, Prescan would finish completely—with errors, but completely.  That’s when MSFT support started ranting and raving…NO NO NO NO NO NO NO NO….OK Ok…I get it

So we spend three days straight (holidays in the mix) trying to get a workaround…no dice.

They acquiesce…OK…”Change the BitFlag value”.  Save the changes reboot for good measure.  Go to the original SPS2003 server and the database drops like it is supposed to when I click “Remove Content Database” in Central Admin.

I then go to the MOSS server and attach the database…it took four hours and two tries, but the sites came up (except for the home portal site) but it worked.

Now comes the task of the 458 unghosted sites….

BPOS – What is it?

A lot of people are asking about Business Productivity Online Services these days.  Microsoft is betting the farm on S+S/SaaS/Cloud Computing.

Software as a Service has long been a buzz word coming out of Redmond as well as the term “Cloud Computing”. SharePoint Online launched last year and now boasts one of the most robust SharePoint offerings worldwide.  Some of the biggest names:  Coca-Cola Enterprises, Nokia, and Energizer have taken the plunge into BPOS-D. 

D? Yeah, D as in DEDICATED.  The Online Services that you can sign up for a trial on the web is known as STANDARD.  DEDICATED is for the Enterprise customers who are willing to purchase 5000 seats of SharePoint, or Exchange, or OCS, or CRM, etc. 

As the reader may already know, I used to work for BPOS at Microsoft.  Good times!  Brilliant co-workers, wicked architectures and insane timelines.  Coca-Cola Enterprises was one that I worked on which required an amazing amount of work to bring to pass.  I learned more than I ever cared to know about how a flagship global company runs network and web services.  Coordinating with data centers in all parts of the world and making sure all the groundwork was in place before SharePoint even got installed was a sort of magnum opus for me.

Today on twitter someone asked me what the difference was between the BPOS Dedicated and BPOS Standard.  Big difference.  Let me walk you through it:

But wait!  There’s more!

Client Support 

• IE6+ and Firefox2.0+

Data Protection Service

• Self service document restore with a 30 day recycle bin recovery period

Business continuity and disaster recovery

Security

• Periodic Security Assessments
• Continuous Intrusion Monitoring and Detection

Service Level Agreements

• 99.9% scheduled uptime with financially backed SLA

Directory Synchronization Tool

• This tool allows you to keep the on-premise and the online Active Directories in sync

Admin Center

• Centralized, Web-based access for configuration and administration of SharePoint Online.
• Centralized location for tools download including: Directory Synchronization Tool, Migration Tools, and Sign-In Tools

You can sign up for a trial of this version at https://mocp.microsoftonline.com/site/default.aspx

BPOS Standard isn’t too expensive, at $7.25 per month per user.  Microsoft handles everything.

Bust out your wallet for this version.  Minimum of 5000 seats and your commitment is for a three years.  But you get what you want basically.  Customizations, Enterprise Features (including Excel Calculation Services, Business Data Catalog, Forms Services, etc)

Computing in the Cloud is big business and can definitely be a boon to enterprises as they try to mitigate IT costs.

MOSS Pre-Installation Health Check

I don’t know why I haven’t blogged on this before, but I think its of great value to those who install and configure SharePoint.

Yesterday @MossLover tweeted that the audit policy settings on a server had caused the installation of MOSS to fail during PSCONFIG.  I can totally understand where and why this happens.  Sometimes there are settings on servers that won’t cause MOSS to fail until after certain components are installed and configured.  This is why I recommend doing a “Health Check” or “Infrastructure Review” *before* installing MOSS to ensure your installation and configuration (and subsequent operations) goes smoothly. 

An “Infrastructure Review” would typically be something that I do PRIOR to deploying MOSS.  A “Health Check” would be something that I do AFTER MOSS is deployed.

I use a number of different tools to do my health checks. @JThake asked me what tools I use.

The following are the list of tools I use.

Physical Architecture and Network Infrastructure

MPSReports

Particularly the DCDIAG, DNSDIAG pieces are *very* helpful.  If you download the report tool, make sure you get the following editions:

• Directory Services Edition (Mpsrpt_dirsvc.exe): An edition that captures information that is relevant to Directory Services issues
• Network Edition (Mpsrpt_network.exe): An edition that captures information that is relevant to networking issues
• SQL Edition (Mpsrpt_sql.exe): An edition that captures information that is relevant to SQL.

MAP

Both these tools (MPSReports and MAP) will look at the physical architecture and give you reports on its structure and design.

SPSReports

If MOSS is already deployed, SPSReports can give you a good look into the health of their SharePoint infrastructure

Capacity Planning

Using the Capacity Planning tool, I create a report using the hardware, network connectivity, and portal usage the customer currently uses.  It will tell me where bottlenecks may exist.

Perfmon is a great tool to discover how the actual server is handling any load.  Doing a Perfmon baseline will also help in determining future growth and utilization.

The tools run very quickly, its the analysis of the data you get from these tools that is time consuming.  But if you know what you are looking for, you should be OK.

A Triple Double Upgrade – PART 1

As most know, SharePoint 2010 has reached a few fortunate people in the world for them to get an advanced preview of it.  The SharePoint Community is totally awash in buzz around it while trying to be true to their Non-Disclosure Agreement (NDA).  Some, however, have exhibited irrational exuberance which resulted in them breaking their NDA.  A lot of SharePoint experts are also “chomping at the bit” to get information out to the community to be the first to break the news about new features and best practices.  Sigh…it’s a jungle out there, I tell ya.

*SO*—without breaking NDA, I will show you what to watch out for in an upgrade to SharePoint 2010; not only from MOSS 2007, but *also* from Windows 2003.  Why?  Because there are a lot of enterprises out there that have not fully upgraded to Windows Server 2008.  I will venture to guess that most SharePoint farms are built on top of Windows Server 2003.  I will also say that there is a significant amount of businesses that will need to use current hardware and upgrade rather than purchase NET NEW hardware.  This means that they will need to not only upgrade SharePoint, but their operating system (OS) as well.  I call this a Double.  Small environments might have a three-server farm (2 Web Front Ends and 1 Application Server) and so there are three servers to be upgraded.  This makes it a Triple Double.

In order not to violate NDA, I can only demonstrate a portion of the upgrade (hence PART 1).  I will continue with PART 2 after other information has been released.  Everything I will show you is authorized and has been in the public domain for a while. 

I didn’t want to show you a perfect upgrade.  It never happens.  I hate going to conferences where the speaker shows you a demo and it goes flawlessly and the speaker doesn’t address issues that happen.  Don’t get me wrong, a flawless demo is GREAT, but spend some time talking about what REALLY happens in the REAL WORLD.

That is what I will attempt to show you here.  The issues I came across, and more importantly, the way that I fixed them.  Let’s begin.

First, let’s start out with what I’m dealing with:

It’s pretty self-explanatory, except MOSSPPS is the Performance Point Server, and MOSSMS is the Exchange Server (Mail Server).  The farm is MOSS 2007 SP1 sitting on top of Windows Server 2003 R2 x64.

First thing I want to do is see what I need to “fix” before I upgrade, right?  So—I want to use STSADM –O PREUPGRADECHECK.  BUT before I can use the preupgradecheck with STSADM, I will need to have SP2 installed.  OK, let’s do it.  I start the installation on all of the SharePoint servers.

Then I get to this point:

Now, typically you run this and stop right here for each server in the farm. You click 'OK' on the Application/Index server FIRST and THEN when its finished, you click 'OK' and do each individually.

And then I get this:

DOH!

OK, let’s take a look at the log and see what it says. 

The log says that the SPTimerV3 failed to start.

A HA! I think I've found the issue…I tried to manually start the service and got a LOGON FAILURE.

Let's try it AGAIN….

Huh…ran the executable on WFE1 and it says it's already installed. Hmmm. Go to Control Panel and see this:

So now I'm curious what WFE2 says. So I go check. HA..only SP1.  Rerun it on that server and…

NOW THAT’s MORE LIKE IT!!  I run the hotfix with no issues.  I check the license status to make sure it took, and I’m good.

So now the farm is running at SP2.  Now I want to run -preupgradecheck parameter of STSADM and I get 'Access denied'. I am running as administrator. I wonder if I have to run as FARM ADMIN? So I run as a different Admin account…it works:

As expected, the OSPrequisite failed, which is “normal”.  The resultant log file says:

OK, so let’s start an upgrade.  I will begin with the Application server.

OK, the upgrade check told me the following:

So I go to Control Panel to uninstall Powershell and don't see it. Hmmm, wait -- I see a couple of Hotfixes with the Powershell logo on them…that must be it.

I BING the KB numbers and find out that they are indeed the Powershell installation features, but whoa--it also says:

Note By default, if Windows Server 2003 Service Pack 2 is installed on the system, PowerShell 1.0 cannot be uninstalled.

To resolve this issue, follow these steps:

1. Follow the steps in the following Microsoft Knowledge Base (KB) article, 931941, to trust Windows PowerShell 1.0 that was introduced in KB926139:
   931941  The Oobmig.exe tool is available to restore trust to out-of-band updates after you install Windows Server 2003 Service Pack 2
   Note You may have to restart the computer.
2. Check whether the update can be uninstalled by using Control Panel. If the update cannot be uninstalled in this manner, uninstall PowerShell manually from the following location:
   C:\WINNT\$NtUninstallKB926139$\spuninst\spuninst.exe
   Note You may have to restart the computer.

OK, so let me try to uninstall the hotfixes. I cross my fingers...

Clicking on the Remove button brings up yet another warning dialog:

Fine, I'm going for it. I click YES.

SUCCESS! Now to deal with the other issues:

For this, I just need to stop the Search Service and I'm good. It's the next issue that puts the fear of God into me:

Great…HyperV issues…sigh….I'm going for it anyway.

OK, so this may take a while….I'll go do some other stuff while this churns.

Something to read *Before* you do an upgrade in the same reckless fashion I am doing it: http://technet.microsoft.com/en-us/library/cc755199(WS.10).aspx

So, after all of the servers are upgraded to Windows Server 2008, I attempt to open Central Admin and nothing happens. I mean, NOTHING. I go to IIS and receive this message:

OK, so I enable W3SVC and attempt again. It churns and churns and then gives me the "Cannot connect to the configuration database" message. OK…what's up NOW? I log on to the SQL server and see this:

DOH! OK, I'll wait…thanks.

OK..Now let me check and make sure Central Admin works. CHECK!

Shared Service Provider? FAIL!

Dang, NOW WHAT?

Hmmm, it works from the Application server, but not the WFE1, nor WFE2. hmmm…I'm getting the famous 401.1 error. Let me see if disabling LoopbackCheck does the trick. FAIL!

Hmmm… IIS 7 is *so* different….now where do I go to see where the issue. HEY! This is strange. I'm on the Application server and I see this:

WHERE IS THE SSP Web App???

Hmmm…now I go to the WFE:

Not only am I missing the SSP, but the Records Center, My Site, and Intranet web apps aren't there either! Ohhh..

Well…let's first find out what is going on with the 401.1 error.

So I go to the Advanced Settings for Windows Auth. Ahhh…this is the problem:

UNCHECK this box. Stupid IIS 7..

Do an IISRESET and…..

VOILA!!

Let me check WFE2

Same thing….ok…so for EACH web application you must DISABLE Kernel-mode authentication.

OK!! So, last thing…I will now run PREUPGRADECHECK on ALL of the servers in the farm. Here we go:

Nice…it finishes and I get this error

It's smoking dope…I find the file and open it up in a browser and everything is hunky dorey.

It tells me what options I have to upgrade:

OK.  That checks out.  This will be an Inplace Upgrade. 

Stay tuned for Part II, where I will go through the steps of a medium farm inplace upgrade.

Robust Home Network

Amazing the chatter that happens on Twitter these days.

Some colleagues of mine @Bfox11b, @andrewconnell, and @michaeltnoel were talking about their home networks to do testing, etc.  It is a wide known fact that I run a pretty nice network with which to run Exchange, SQL and SharePoint for my family.  All of my kids have their own laptop and submit homework via workflow on a SharePoint site. (ONe day I will blog about how that works).

I’m not saying “mine is bigger” by any means, but I thought I would show you, the reader, how @slkrck rolls.

My last project while a Microsoft Blue Badge

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

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.

Claims Based Authentication – An Overview

I thought I would discuss a little about what Claims Auth (ClaimsAuth) is and why its important for you to know.  In an article from Network World, it was stated that Claims Authentication is a new feature in SharePoint 2010 and understanding it will assist administrators in designing and maintaining robust infrastructures and help make implementing other functionality (such as PeoplePicker) a little easier.

The SharePoint Team blog stated that SharePoint will be a Claims aware application where users will present to it a list of “claims” and SharePoint will The gist is that there are claims (or assertions) that are made about an entity. 

So code name “Geneva” has been out for a little while and word has it that it plays an integral part in SharePoint 2010. Why is it important?

According to Microsoft: “Geneva” is Microsoft’s next generation identity and access management platform built on Active Directory® directory services. “Geneva” provides claims-based access and single sign-on for on-premises and cloud-based applications in the enterprise, across organizations, and on the Web. “Geneva” leverages claims which describe identity attributes and can be used to drive application and other system behaviors with an open architecture that implements the industry’s shared Identity Metasystem vision.”

There are several components to ClaimsAuth.  The STS is the component that issues tokens to entities and these tokens contain claims.  A security token service makes claims about entities. It issues security tokens containing claims.  A relying party is an application that accepts and consumes tokens. It makes decisions based on these claims.  It may also generate and issue managed information cards. (Remember Card Space?)

Another component is called the federation provider, which manages trusts for relying parties and translates claims into a way that the relying party understands.  Think of the Federation Provider as the “universal translator”.  (For example, a claim of ROOT would get translated to a claim of ADMIN.

Another component is the authorization provider, which makes decisions about how to render access control.  So the typical sequence is that the user agent authenticates with the identity provider and obtains tokens containing claims.  The user agent presents these claims to the federation provider, which returns a set of claims relevant to the relying party.  The client software then sends these claims in application message to the relying party.  The relying party uses these to make an access control decision with the help of authorization provider.

Figure 1 - Courtesy of Network World

Walk the walk that you talk - PART 2

Setting up a Pre-Production environment (PPE) takes a little planning; *IF* you want it to be robust.  Sure, anyone can purchase an extra box for "dev" and call that PPE, but I'm talking about REALLY have an environment that either mirrors production to a 'T' or comes very, very close.

In Part I we talked about the "What" and in this part we will talk about the "How".  Once you have all of your requirements, it is now time to build it. 

Below I will give an example of a PPE design that sits next to a production design to give you an idea of what I am talking about.

On the left is a representation of a typical SharePoint farm that could be a production environment.  On the right you see a representation of what a Pre-Production environment (PPE) could look like.  You will notice that the two are very similar, but not identical.  The point is that the environments are "functionally" identical.

Once you have determined what the logical design of your PPE should look like, then the next step is to figure out how it will be deployed.  You have two choices:  1) Physical or 2) Virtual.  There are Pros and Cons to both and below I have put them in a table:

In my own implementations, I have chosen virtual most of the time.  Now that we have chosen the type lets assume that you know how to install the operating system on the virtual machines and set up SharePoint.  Remember, treat the virtual machines just like they are regular servers.  Give them IPs in the same range as your production servers.  As far as the naming convention goes, use the same naming convention in PPE that you use in Production, with the exception that you should prepend the names with 'P' or 'PPE' to differentiate between them. 

Now we have to "seed" the virtual environment with data from Production.  I recommend that you only seed the environment with a *subset* of the information from Production.  Perhaps making a backup of your My Sites database would be good.  You could also use a third party backup and restore utility for MOSS that will even give you item level restores.  That is the way I recommend it.  Once the environment is seeded, you are ready to to conduct your tests.  There is also another option:  System Center Virtual Machine Manager.  If you need your PPE to be an EXACT copy of Production, and the PPE is virtual, you can utilize the P2V capability and accomplish your replica in that manner.

After you are satisfied with how your tests go in PPE, now comes the time to move it to Production.  There are two approaches:  a) use the same procedure that you used to install the pieces in PPE and repeat it in Production  or  b) use the same third party backup and restore utility to move it to Production.

There is no substitute for having a PPE to test your changes and for testing.  Spending the money on PPE will be well worth the cost.

Walk the walk that you talk - PART 1

So many times you hear "Don't do this in production!  Do this in your Dev or Test environment".  More times than not, the "Dev" or "Test" environment is the developer's laptop or some spare machine that they have lying around the office.  This might be OK if you are testing the functionality of code, but that is about it.  If you plan on deploying these things you should have an environment that closely mirrors or at least mimics your production environment.  Here's two reasons why:

A) What you deploy may act differently in production because of components that don't exist in your "Dev" or "Test" environment

B) What you deploy may act differently in production because of infrastructure constraints or design that do not exit in your "Dev" or "Test" environment

Talking about developing or testing in a "Dev" or "Test" environment (henceforth and forever called PPE (for Pre-Production)), is a little like riding in an airplane and listening to the safety message that the flight attendants give.  Everyone knows the rules, everyone understands, but how many really do it?

We all know that it is Best Practices to have a PPE, yet many (indeed, probably MOST) do not.  There are a myriad of excuses as to why a PPE does not exist in one's environment: costs for additional hardware, labor costs in maintaining the environment, space constraints, lack of expertise in setting up an environment...the list goes on.  In this first of two segments, I will address what it takes to set up a fully functional and robust PPE.  I will address an overall design, and its goals (the what and why).  In the second segment I will address the technical details (the how, where).

PART I

The current process for developing and launching custom solutions for the SharePoint platform is extremely inflexible. Developers are limited in their ability to test custom solutions in an environment that looks and feels like production. Instead, they test in an isolated environment built and maintained on their own platforms, are subject to an inflexible release cycle that doesn’t allow for quick corrections, and may be required to wait an extended period of time to for their solutions to be installed to production due to maintenance windows. All these items can lead to sub-standard code deliverables, introduction of risk to production, and an expensive and timely process. One step to mitigate these issues is to create a Pre-Production Environment (PPE).

The PPE provides an environment mirrors production without actually hitting production and introducing risk.  You should ensure that this environment meets the same standards as production and has the same network connectivity as production.  This environment, in essence, is the last quality gate prior to deploying any solutions to production by allowing the developer to:

• Validate functionality
• Verify solutions with simulated production data and data connections to ensure proper communication
• Providing actual users access to custom solutions
• Verify compatibility with their own existing custom solutions

This environment could be configured or supported for the actual development of customized code or the undertaking of functional testing, or it could be used for performance, scalability or stress testing.

When creating a PPE, you should come up with a design that answers the following questions:

• What are the goals/non-goals?
• How does the PPE get managed and by whom?
• Who will document its use?
• Who will maintain and monitor the PPE?
• Will the PPE scale?

Creating a Design document for your PPE is a good start.  It puts a plan on paper (or at least virtual paper) that can be followed.  We architects are notorious for not documenting...(what's wrong with us?)  The document should outline the answers to the questions above and the method in which they will be answered.  In the next segment I will include a sample of a document that outlines a design.

The first thing you need is an understanding of the importance of having a PPE.

The next thing you need is the documentation on how it will look and behave and how it will be managed.

The next thing is what we will talk about in PART II..."How to set it up" and the process of moving from PPE to Production.

The 5 Commandments of SharePoint Deployments

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. 

Why I haven't blogged

I had a discussion with a colleague from the Product Group last night as to why I don't blog often (or ever) concerning the technical aspects of SharePoint.  My angle was that I work with some talented folks who spend considerable amounts of time blogging about SharePoint and I choose to help the Community in other ways:  Speaking at conferences, answering questions via email or IM, participating in Ask The Experts (ATE), et al.  He countered that there needs to be a balance.  He asserted that I need to provide "collateral" to the Community that they could use that woud help them in their implementations and such.

Normally I would smile and just go my merry way, but this time his words had teeth.  I won't go into the specifics, but now I have a vested interest in doing so.  Hence, Starting today I will start blogging regularly here about SharePoint (MOSS, WSS, etc).  My *other* blog can be found at http://slickrickistheman.spaces.live.com which has every day stuff.

 RT

SharePoint Conference

I am an engineering technologist at Microsoft, for those who didn't already know.  My job entails creating designs and testing those designs for Microsoft's customers who choose to have Microsoft run their SharePoint infrastructures.  Two of our customers, Nokia and Coca-Cola Enterprises have pretty high expectations and have required us to do some incredible things to make their designs work.  Think of my job as being Scotty on the Starship Enterprise.  He integrates Romulan or Klingon technology into Federation technology and gets Warp Factor 10 or Cloaking ability.  That's us.  Sometimes we get "Scotty, I need warp factor 11 in 10 minutes or we're all dead!" And occasionally we shout back, "We canna change da laws of Physics Cap'n!!!"  Welcome to life as a Microsoft Architect/Engineer.

This coming week I will be participating in the Microsoft SharePoint Conference.  This is the first time I have ever known a Microsoft product conference to be SOLD OUT and to even reject requests from Microsoft employees on attending.  That underscores the impact that this product has had over its 7 year lifespan. 

Currently this product is closing in on 1 BILLION (that is a THOUSAND MILLION) dollars in revenue.  It is the fastest growing product in Microsoft history!  Even Microsoft Exchange (the email server) isn't a billion dollar business yet.  Fiscal Year 2009 will be the finish line between the two.  I'm betting SharePoint wins.

I will be participating in an Ask the Experts (ATE) panel at the SharePoint Conference.  I like speaking at conferences as it gives me a chance to share my knowledge with peers.  I have been very fortunate that I have been asked to speak on numerous occasions.  Sometimes that causes some...'angst' among my peers as it is generally desired to be "seen".  I do it because I like to present.  I don't have the need to thump my chest and pontificate as some have.  I'd rather play music in the background, put on my shades and sit down and have a roundtable discussion.  Maybe its the perception of the title "Speaker" that is so coveted....I don't know.

I'll take pics at the conference and post them here; probably will be plenty with people.  These guys/gals wear that title like Hugo Chavez does military medals on his uniform.  Don't mean anything negative about it--it's just an observation.  It's a cool club to belong to; knowledgeable, friendly, and look out for each other.  They've invited me to the SharePoint by Day, SharePoint by Night party.  I don't drink, so it would be pointless to go--except I do enjoy their company.  Bob Fox is a hoot and Andrew Connell Blog loves his drink.  If Lawrence Liu weren't sick with a cold, he'd probably be there too!

Going to the Edge

Documentation

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.