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
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.
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
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.
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.
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.
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
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!
It's a new segment for EDGE, a sister channel to the famous Channel9 from Microsoft. My office mate Bill Baer and I were offered our own subchannel called the "RnB Show". It's a show targeted at ITPros who want to know more about SharePoint. We'll have plenty of content for Admins as well as Architects and Engineers. There will even be content for ITPros who have nothing to do with SharePoint. Our show will be different from the rest of the content you will find on that channel in that we will have "off the wall" humor and music and the like. One of our shows will be filmed in the Caribbean as we take our show on the road. We'll also film in Portland, OR next week and in Berlin in January.
I'm excited about the opportunity and the potential to make a difference in how Microsoft Corp is perceived and helping the SharePoint Community at large. We're going to make a HUGE difference and I'm excited about it!! Our first filming is this week where we will be talking about Forms Based Authentication in a hosted environment.
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.
Well, this is my first attempt to have a purely technical blog. I will cease putting technical content on my other blog at http://slickrickistheman.spaces.live.com.
If you read the 'About' you will see the purpose of my blog. I work in the Microsoft Managed Services (MMS) division as a SharePoint engineer. Our group not only manages the SharePoint infrastructure for the Microsoft Corp., but for external customers as well. When I say 'manage', I do not mean 'support', that is a different group. For example, the internal group at Microsoft called FinWeb is using our group to architect their infrastructue. We also host external customers' infrastructures like ENERGIZER.
We do a LOT of architecture and engineering....a LOT. And so we see a lot of different designs and have accumlated a ton of best practices in the process. I'd like to share of that with readers.
