Ben Curry, Microsoft MVP is leading the next session “SharePoint 2010 Employment Demofest”. Anyone who presents and manages to say things like “Argh” and “e i e i o” is someone I want to listen to.
He begins communicating the quick and most accurate way to transform SharePoint from a glorified file share to its full potential as a business critical system. These steps must be performed in the correct order.
- Gather requirements – from the business
- Create logical architecture – it helps to have an information taxonomy in place
- Design physical architecture – this is derived from the logical architecture
- Test and validate – one of the most important steps is often skipped
- Log and monitor – many administrators don’t even look at the logs, when they need to be experts here
- Adjust architecture as needed – the architecture will stabilize over time
He advises us to all STOP! Learn. Test. Implement. Stop and learn each application individually as a product. Before you can design the logical or technical architecture, you must understand all target applications. Each service application is implemented in a unique fashion to meet service requirements. There’s so much to learn. It took him 8 months to methodically understand the entire SharePoint 2010 stack.
The farm topology for SharePoint 2010 is very different from 2007. The basic footprint is doubled and database work is done outside of 2010. It’s a SQL activity. I believe that if you have a SharePoint 2007 deployment, you should just wait for it to EOL. Start over with 2010 and transform the way you use SP.
This is a demofest, so let’s feast. I expected actual SharePoint end solutions being demoed, but he is demonstrating how to configure SharePoint from the very beginning.
Advice: any time you see “server farm”, remember that this means “configuration database”. It has nothing to do with a farm. Weird. Hosting Central Admin on the configuration database doesn’t matter because you can manage the farm with PowerShell or CA.
Once a solution package is deployed to a SharePoint farm (.wsp file), SharePoint will manage all of this automatically. Don’t get bad juju by manually attempting to change or move these solutions. It will just make things out of synch if you have to change servers later.
He’s an expert administrator and he moves through the screens, folders, and demo effortlessly. It’s a bit hard to keep up. Remember that when you make a change in CA, you are ONLY chaging a field in the configuration database. Then, based on a timer job, the changes get cascaded out to the server / farms. Important.
He’s showing the foundational way to build out a server farm, but this same technique can also be used to build large server farms. It’s impossible for me to show you how to do this so I’ll just provide you a helpful link, but he’s giving us advice on each screen.
Kerberos is becoming the gold standard for security configuration over NTLM. Why? Most conventional network systems use password-based authentication schemes. When a user needs to authenticate to a service running on a network server, they type in their password for each service that requires authentication. Their password is sent over the network, and the server verifies their identity using the password.
Transmission of passwords in plaintext using this method, while commonly done, is a tremendous security risk. Any system cracker with access to the network and a packet analyzer (also known as a packet sniffer) can intercept any passwords sent this way.
The primary design goal of Kerberos is to ensure that passwords are never sent across a network unencrypted and are preferably never sent over the network at all. The proper use of Kerberos will eradicate the threat of packet sniffers intercepting passwords on your network.
If you wish to support mutual authentication under Kerberos, an instance of SQL Server must associate a Service Principal Name (SPN) with the account it will be running. You must register the SPN because the client must use a registered SPN to connect to the server instance. The SPN is composed by using the server’s computer name and the TCP/IP port. If you do not register the SPN, the SSPI cannot determine the account that is associated with the SPN. Therefore, Kerberos authentication will not be used.
To use Kerberos authentication, you must make sure that all the following conditions are true:
- Both the server and the client computers must be members of the same Windows domain or members of trusted domains.
- The server’s service principal name (SPN) must be registered in the Active Directory directory service.
- The instance of SQL Server 2005 must enable the TCP/IP protocol.
- The client must connect to the instance of SQL Server 2005 by using the TCP/IP protocol. For example, you can put the TCP/IP protocol at the top of the client’s protocol order. Or you can add the prefix “tcp:” in the connection string to specify that the connection will use the TCP/IP protocol.
Ok, this guy is good. There’s too much content to put in here now, but if I find his slides, I’ll include them later.