64  CHAPTER 3 architectUre aNd caPacity PlaNNiNg focus just on using the power that is SharePoint. (While this might be great for the business, it does eliminate the need for a SharePoint administrator, so many of us will consider this license option the enemy.) There are actually two models to consider with SharePoint Online: shared and dedicated. The shared model provides you with a slice of a shared farm and enables you to use SharePoint out of the box. Server-deployed code and customizations are not permitted. The dedicated model enables you to run your own farm, and you are allowed to make approved customizations to the server. Any change must be packaged in a solution package and validated by Microsoft before being deployed to the server. All licenses are bought per user. This offering has also been expanded from previous versions to add some new licensing options. One of these is the concept of the “deskless worker.” These are users you can add at a lower price point, and they have mostly read-only access to SharePoint. There are also models available that can support hosting a partner collaboration site and public-facing Internet sites. This chapter covers SharePoint Online because it is an additional available SKU in this product cycle, but you have other notable options if you are looking at a hosted scenario. Companies such as RackSpace.com and Fpweb.net offer hosted SharePoint environments that you may fi nd a little more fl exible than SharePoint Online. Of course, hosting internally is still the best option, but it is good to know your enemies. OTHER SERVERS So you signed up to be a SharePoint administrator? Well, congratulations, you are also now respon- sible for a whole host of software. Since SharePoint isn’t an operating system (yet!), you need to have the right operating system in place in order to deploy SharePoint. Additionally, SharePoint stores 99% of the content and confi guration in a database, so SQL Server has to enter the conversation sooner, rather than later. Also, most deployments want to take advantage of SharePoint’s ability to send notifi cation e-mails, and some even take advantage of its ability to receive e-mails. Even though you may not directly be responsible for these products, they will affect your livelihood. Users don’t call to complain that SQL Server isn’t working; they call to complain that they cannot access SharePoint. It is your job to determine that it is because SQL Server is not responding. This section covers the ins and outs of these various pieces of this puzzle. Windows Server SharePoint is available only as 64-bit software, so by extension it can only be installed on servers with 64 bits or more. And don’t bother looking, there is no 32-bit “test” version hiding out there. Other Servers  65 The authors have looked under every rock on the Internet and inside Microsoft; and like unicorns, it doesn’t exist. For production deployments, you will be installing on either Windows Server 2008 SP2 and later or Windows Server 2008 R2 and later. The following editions of Windows Server are supported: Standard  Enterprise  Datacenter  Noticeably absent to some is the Server Core installation of Windows. Unfortunately, it does not allow all of the necessary components that are required for SharePoint to operate to be installed, so SharePoint will not install on Core. Also, the Web Edition is not supported, which is probably a good thing — thanks to its limited memory capacity, it would not perform very well. Required Additional Software After you have Windows installed, the server needs to be included as a member of an Active Directory (AD) domain. SharePoint does not support local machine accounts for any type of farm deployment, and the confi guration wizard will error out if you try to use a local account. Most administrators realize that something like IIS needs to be installed on the Windows Server in order for SharePoint to render web pages. They are often tempted to install this manually, which is safe to do but probably a waste of their time. The server also has roughly a dozen other prerequisite software packages that need to be installed, including the Web Server (IIS) Role. Thankfully, there is a SharePoint Products and Technologies Preparation Tool that will install and confi gure all of these for you when the time comes. That tool, and all of its intricate details, is covered in the next chapter. BUT I ALREADY DID “X” TO MY SERVER! If you already installed IIS, PowerShell, or one of the other prerequisites, don’t worry; all is not lost. The prerequisite installer tool will check up on you. If you did successfully install and confi gure one of the requirements, the tool will skip it and move on to the next one. In the case of IIS, if you enabled the role but didn’t confi gure it the way SharePoint needed, the prerequisite installer will just make the necessary changes. So keep that chin up; all is good. Another common mistake to avoid is adding the server to a domain, or even pro- moting it to a domain controller (typically only done on a test virtual machine) after adding programs to the server. Programs such as IIS and SQL Server don’t always take too well to these changes. Make any computer name changes (which adding to a domain does) as soon after installing Windows as possible. Then you can safely continue with getting it ready for SharePoint. 66  CHAPTER 3 architectUre aNd caPacity PlaNNiNg Windows Vista and 7 In order to appease your friend the developer, Microsoft has introduced the capability to install SharePoint using a standalone install, for development purposes, on certain versions of Windows Vista x64 and Windows 7 x64. These editions are as follows: Windows Vista SP1 and later.  Business edition  Enterprise edition  Ultimate edition  Windows 7 RTM and later.  Professional edition  Enterprise edition  Ultimate edition  The N and KN editions of the preceding software will also work.  It is absolutely not supported to use a Windows Vista or 7 installation for a production farm. They should only be used for developers who wish to do SharePoint development locally on their own machine. If development is done in these environments, then it is highly recommended that developers have a test environment to validate their solution before deploying to production. These types of deploy- ments are a little more tedious in the initial configuration and are discussed more in the next chapter. SQL Server Get used to it: SQL Server just became your best friend. Because everything inside of SharePoint, including all of your content, lives inside a SQL Server database, as SQL goes so does your farm. For example, do you know what the most common performance bottle neck is in SharePoint? SQL Server. Therefore, in order for you to be good at your job, at a minimum you need to understand what is going on in SQL Server. Ideally, you will start sucking up to your resident database administrator (DBA) to ensure that your SharePoint databases are well cared for. As with the Windows Server requirement, SharePoint also requires SQL Server to be 64-bit. 32-bit SQL Server is not supported. The 64-bit editions of SQL Server that are supported are SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2. SQL Server 2005 requires Service Pack 3 plus cumulative update package 3 for SQL Server 2005 Service Pack 3 (KB967909). SQL Server 2008 requires Service Pack 1 plus cumulative update package 2 for SQL Server 2008 with Service Pack 1 (KB970315). SQL Server 2008 R2 will be supported at its RTM build or later. E-mail Servers SharePoint comes with a handy piece of functionality that enables it to send e-mails. This is often used to notify users that they have been granted access to a particular site. Users can also subscribe to an alert whereby they are notified when items are modified on a particular list or library. And with a little extra work, SharePoint workflows can be configured to e-mail users as necessary. Other Servers  67 In order for SharePoint to send these e-mails, it needs to be configured with an outbound e-mail server. The SMTP server you point SharePoint at needs to allow anonymous relay from SharePoint. Unfortunately, SharePoint cannot be configured to provide authentication information when sending e-mails. In most environments, anonymous relay is not permitted, because for years evil spammers have used anonymous relays to avoid detection as they flood you with offers for low-cost medicines and opportunities to invest in dubious banks. In this case, you can ask the e-mail administrator to add the IP addresses of all SharePoint servers to the list of servers that are allowed to anonymously relay mail. If this is not acceptable, then your second option is to install the SMTP service on one of your SharePoint servers and then configure it as necessary. You will need to ensure that it can cor- rectly send outbound e-mail and that it allows all anonymous relay from all the SharePoint servers in the farm. Another requirement for outgoing e-mail is that port 25, the default SMTP port, is not blocked between your servers. Such a blockage can happen at the firewall level or at the local server level. Some antivirus vendors configure their software to block port 25 outbound on all machines. This will stop SharePoint from sending e-mail, so be on the lookout. Incoming E-mail A lesser-known feature of SharePoint is its ability to receive incoming e-mail and then route that e-mail to the appropriate list or library based on the To: address. This enables scenarios such as hav- ing salespeople in the field e-mail in their expense report to a special e-mail address. That e-mail would be routed to the SharePoint server and then the attachment could be extracted and uploaded to the appropriate document library. From there, whatever business process needs to take place could be invoked. A simpler scenario might be setting up an e-mail address for a discussion forum. Then, any time you send an e-mail to that address, the e-mail becomes a discussion item in the list. Once in SharePoint, it is easily indexed so it can be discovered later; and because it is now a normal list item, the discussion can continue. Configuring this functionality requires the help of the e-mail administrator, and it is worth noting that it does not require the use of Exchange. This is a multi-step, complex process that touches sev- eral pieces, but the core steps are as follows: 1. Install and configure one of your SharePoint servers to run the SMTP service. This server will then need to be set up to accept e-mail for the domain you define for SharePoint. Typically, it would be something like @sharepoint.company.com. 2. Configure your corporate e-mail server to route mail for the @sharepoint.company.com domain. The idea is that when your corporate e-mail server receives that e-mail, it just passes it over to the SharePoint server. 3. Go to SharePoint Central Administration and enable incoming e-mail. You will need to tell SharePoint that it is looking for e-mails in the @sharepoint.company.com domain. 4. Now someone with the manage list permission level can go into his or her list and associate an e-mail address with the list — for example, doclib1@sharepoint.company.com. 5. This associated e-mail address would now need to be configured as a valid contact on the e-mail server. 68  CHAPTER 3 architectUre aNd caPacity PlaNNiNg With this configured, e-mails will be sent to doclib1@sharepoint.company.com. Your corporate e-mail server will relay that mail to the SMTP service running on the SharePoint server. The SMTP service will then take that e-mail and put it in a maildrop folder. The SharePoint timer service checks that folder once a minute by default, looking for e-mail. When it finds an e-mail, it routes it to the appro- priate list or library based on the address. While that is a simple scenario, many configuration options are available. You can, for example, configure Exchange Server and Active Directory to allow users to create their own e-mail addresses. This is done through the creation of an additional Organization Unit in your domain. This is a more complex scenario, but it eliminates the administrative burden of having to set up e-mail contacts each time a new list or library requires mail functionality. You can find detailed configuration information, with multiple scenarios and troubleshooting steps, on TechNet ( http://technet.microsoft.com/en-us/library/cc262947(office.14).aspx). Text Message (SMS) Service Settings That is right — SharePoint has become so cool that it can even send text messages. And since SharePoint still isn’t old enough to drive, you don’t even have to worry about it texting and driving. Once the ser- vice is configured, users can choose to have alerts sent to e-mail or text message or to both. The service is pretty straightforward to set up from within Central Administration and can be scoped at either the farm or the web application level. You will need to provide the URL of an SMS sending service. If you don’t have one handy, you can click the link on the Mobile Account Settings page in Central Administration to find one based on your preferred wireless provider. Just watch out for this functionality: It can easily become a runaway cost. HARDWARE REQUIREMENTS Build it and they will come. Underpower it and they will complain. (No user has ever complained that SharePoint is too fast.) Of course, with budgets being very tight, you will feel the pressure to keep hardware costs as low as possible. This tension between functionality and cost creates a fine line to walk. Perhaps the easiest way to start thinking about hardware is to do a comparison of the minimum recommended requirements from MOSS 2007 and the minimums for SharePoint Server 2010 (see Table 3-1). TABLE 31 MOSS 2007 versus Server 2010 Recommended Minimum Hardware Requirements MOSS 2007 SERVER 2010 Processor 2 core / 3 GHz 4 core / 2.5 GHz RAM 2GB 8GB Hardware Requirements  69 Note that part of this discrepancy is that Microsoft has done a better job of setting the minimum bar this time. Despite these recommendations, it is not practical today to run a MOSS 2007 server with less than 4GB of RAM. Even taking that into account, it is safe to assume that SharePoint 2010 will require at least twice as much hardware as an existing SharePoint 2007 farm. This is assuming properly sized 2007 hardware today. Experience has shown that SharePoint farms tend to range from vastly undersized desktop-class machines running thousands of users, slowly, to super- computer-class machines that on their best day use 20 percent of their resources to serve 100 users. So if you are going to make hardware assumptions at least in part based on your 2007 environment, make sure you understand how that hardware is utilized today. The next few pages describe the dif- ferent server types and how the hardware considerations vary for each. Web Servers Often referred to as web front-end (WFE) servers, these are the machines ultimately responsible for the rendering of the SharePoint pages. They typically do not have a high CPU load because they attempt to cache as much content as possible to avoid doing the same work over and over. To do caching properly, the server does consume quite a bit of RAM, so be sure to dedicate a substantial portion of your spending on this server to RAM. A key consideration when determining how much memory you might need is the number of applica- tion pools you plan to have. In a nutshell, application pools are the various IIS processes that listen for incoming web traffi c and then handle it accordingly. In Task Manager, you will see each application pool as w3wp.exe. For example, when you create a new SharePoint web application and choose a new application pool, you get a new instance of this process running. Now when you access SharePoint, this process is actually receiving your request and coordinating with SharePoint to render your page. When SharePoint is caching content in memory, it is being stored in RAM associated with this process. Part of this consideration, though, is that every application pool has a certain amount of overhead associated with it, the process, and the memory it needs to do its job. Therefore, for each new appli- cation pool you create, your RAM requirements will increase, so plan accordingly. This role requires very little local storage and does not need to be optimized in any way. The only storage this machine is doing is the SharePoint root, all of the local ULS and IIS logs, and possibly some disk-based BLOB caching. In other words, don’t get carried away here and create a 10GB C: drive. SharePoint occasionally needs to have extra space for temporary fi les, maybe to unpack a solu- tion or to deploy a service pack, so an 80GB or 100GB C: drive is reasonable for your WFE. SharePoint root refers to a folder structure: C:\program files\common files\ Microsoft shared\web server extensions\14. In SharePoint v3, the \12 folder was called the 12 Hive, so you may hear some people refer to the SharePoint root as the “14 Hive.” If you do, try not to make fun of them. . 2007 and the minimums for SharePoint Server 2010 (see Table 3-1). TABLE 31 MOSS 2007 versus Server 2010 Recommended Minimum Hardware Requirements MOSS 2007 SERVER 2010 Processor 2 core / 3. assume that SharePoint 2010 will require at least twice as much hardware as an existing SharePoint 2007 farm. This is assuming properly sized 2007 hardware today. Experience has shown that SharePoint. with an outbound e-mail server. The SMTP server you point SharePoint at needs to allow anonymous relay from SharePoint. Unfortunately, SharePoint cannot be configured to provide authentication