2. Agenda Active Directory Service Accounts Database Platform Windows Platform Data Storage Planning Virtualisation Farm Topologies
3. Introduction The trick is finding the right balance between: There are often many solutions to the same problem Not meant as prescriptive guidance, but these are examples of how I have got it to work Keen to hear about others’ experiences
5. Active Directory Corporate Intranet or Internal Only SharePoint Create Service Accounts in existing corporate domain Use a naming convention for easy identification Place accounts in Service Accounts OU Use strong passwords/password generator tool
6. Active Directory Internet Publishing or External Collaboration Consider setting up a separate DMZ Domain Results in increased security Adds to administrative overhead (slightly) Set up one way trust so that internal users can authenticate with their existing credentials DMZ domain trusts Internal domain
7. Service Accounts Administrator - Install Account Can be a domain admin, or in local administrators group on the box Setup can be run from your domain account Only used for the install and configuration of SharePoint SharePoint Service Account Requires DBCreator and SecurityAdmin roles on the SQL Server Should be a standard domain user, not an administrator This is the account you put into the Configuration Wizard Runs the Central Admin App Pool, and Farm Services Search Crawl Account This is the low privilege account used to crawl content on your web apps Needs no specific permissions, SharePoint will assign them for you Used for WSS Crawl and MOSS Crawl
8. Service Accounts Search Service Account Used to run the Search Services (not used to access content during crawls) Web Application Pool Accounts A separate account should be used for each SharePoint Web Application At a minimum, the main content application pool credential should be different to the one running the Central Admin application pool Shared Service Provider Service Account Used for the SSP specific services SQL Service Account Used to run the MSSQLSERVER Service on your Database Server
10. Database Platform Awesome! New Dedicated SQL Server or Cluster 64 bit Plenty of RAM (8GB +) Physical Server Either 2005 or 2008 Fast RAID 5 local disks or SAN attached DB Storage Maintenance Plans Well maintained Backups
11. Database Platform Good New SQL Instance, or underutilised shared SQL Server Preferably 64 bit, or 32 bit Adequate RAM (4GB +) or more if Shared Physical or Virtual 2005 or 2008 Fast mirrored local disks Or, if virtual, SAN attached DB Storage Maintenance Plans Backups
12. Database Platform Bad Old or over utilised shared SQL server 32 bit Heavy page file utilisation due to inadequate RAM Old Physical server, or under resourced Virtual SQL 2000 or MSDE/SSEE Slow local disks, no redundancy No maintenance plans/not maintained No backups HUGE log files, drives running out of space No one takes responsibility for maintenance
14. Patches and Service Packs Patch Windows! Make sure windows updates are running Test WSUS functionality Patch SQL Server SQL 2000 SP4 required for install Another good reason to have a dedicated SQL install Slipstream latest MOSS Service Pack SP2 patch has now been released Delete WSSSetup.dll from Updates directory
15. Partitioning SharePoint Servers System Partition C:br />Where the Windows, Program Files folders live 30GB+ Disk space usage can blow out during Service Pack installation Can be on a locally attached disk Data Partition D:br />Where everything else is, Logs, Indexes, Web Site Files Source/Install for storage of installed binaries Deployment folder for solution packages Should be on a SAN/RAID disk for performance
16. Partitioning Database Servers System Partition C:br />Where Windows, and SQL application files live 30GB+ Disk space usage can blow out during Service Pack installation Can be on a locally attached disk Data Partition D:br />Stores all the mdf files for SharePoint databases Ensure it is large enough to accommodate future growth Should be on SAN/RAID disk for redundancy
17. Partitioning Database Servers (continued) Logs Partition E:br />Stores all the ldf files for SharePoint databases Needs to be fast, put on SAN/RAID disk or dedicated spindle Backup Partition F:br />Stores backups from your SQL maintenance plans Optional, if you have a separate backup server/storage method Needs to be redundant, put on RAID or Mirrored Partition
19. Data Planning What is the SharePoint site going to be used for? Set initial database size for planned growth in the next year
20. Content Databases One For both Intranet Content and My Sites Easy to manage My Site content can cause database to expand If hosted in the same content DB Use quotas to manage site collection size
21. Content Databases Split My Sites and Business Content Business content can be backed up separately My Site content database size is less of a concern How: Create a new content database for my sites Set original content database to offline
22. Content Databases Purpose based Content Databases For large document migration projects Or for differing backup/restore needs Increases database flexibility/scalability New site collections need to be created by an administrator
23. Maintenance Plans Set up on the SQL Server Easy automated database maintenance Requirements vary based on environment Optional if 3rd party backup software used
24. Sample Maintenance Plans Backup User Databases Daily With clean up task .bak files should then be copied to secondary storage Backup System Databases Weekly As these don't change as often as user databases Backup Transaction Logs hourly If up to the hour restores are required Only for databases with full recovery model Reindex Databases Weekly Helps with performance Shrinking databases causes file system fragmentation
25. Virtualisation Decide what to Virtualise Web Front Ends Search Server Application Server Database Server Physical Infrastructure for Production Virtual for Test/Dev/Staging Backups are simplified, backup entire VHD/VMDK Restore as a group, at same point in time
27. Topology – Basic Intranet Best performance achieved on two servers: 1x Database Server 1x SharePoint Server Majority of my SharePoint installs have been in this configuration If database server is not well maintained, consider all in one server But not a 'stand-alone' install
28. Topology - Search Optimised Intranet Enables better performance for search and indexing 1x Database Server 1x Web Front End 1x Search Server Search Server hosts SSP, Central Admin and a Web Front End - Indexer can then be configured to crawl local web front end
29. Topology – Extranet Purpose: To collaborate with other organisations Host SharePoint Farm in DMZ Use forms based authentication Stand alone (windows service accounts) Or joined to DMZ Active Directory domain Publish through firewall with SSL
30. Topology – Extranet Purpose: Publish Intranet to Remote Workers Host one Web Front End in DMZ Use ISA for external user authentication Terminate SSL on ISA too Need to allow traffic through the firewall SQL Active Directory
31. Topology - Internet Publishing Two Farms: Firewall needs to be configured to allow deployment jobs between farms
32. Topology – Load Balancing Multiple Web Front Ends/Query Servers to handle large volumes of traffic Use System Centre Capacity Planner to work out how many you’ll need Web Front Ends can be easily built and added to the farm to handle extra load as needed
33. Topology – Load Balancing Methods DNS Round Robin Simply switches the between servers in a IP address pool Can cause problems with session state (if needed) Windows Load Balancing Good method for less sophisticated deployments Hardware Load Balancing Need specialised hardware Can determine load on each server and route requests appropriately Best in high load/mission critical Internet applications
34. Topology – High Availability Stretched Farm 1x SharePoint + 1x SQL Server located off site Needs to be connected via 1GB link Using standard tools, failover is manual Need to switch the SQL Alias DR Farm can also be used for load balancing
35. Topology – Disaster Recovery SQL Mirroring Second SQL box has 'mirror' of SharePoint data Should production SQL fail, mirror takes over Failover can be automatic with a witness SQL server Doubles SQL Hardware requirements
36. Topology Third Party Tools Disaster Recovery – NeverFail WAN Acceleration - Riverbed
37. Conclusion Many solutions to the same challenges Best practice is not to cut corners We want our users to have the best possible experience Lots of information available Twitter: @JoelOleson, @FlamerNZ, and many more Email Groups: OzMoss Blogs, Forums, Search Questions?
I have been working for Thomas Duryea in Melbourne for a year now and am keen to share the experience I have gained from my Australian projectsHave been working with SharePoint for 4 yearsStarted off as a developer on the 2003 versionNow I specialise in solution design and implementations
AD – use existing or create new domain?Service Accounts – how many are needed?DB Platform – The good, the bad and the unworkableWindows Platform – Patches and partitionsData planning – How much space will we need, and where should our data go?Virtualisation – Which roles are best to virtualise?Topologies – and which ones fit best with various situations
A fully secured Internet Publishing site is going to require a bit more work than a small IntranetThere is no one right way to deploy any SharePoint farm, with so many options and factors to take into account, it is probable that you will get different answers from different peopleThis is based on my experience, and I’m still learning things about SharePoint everyday!So let me know if you’ve got it working in a different way, or tried it my way and not had as much success as I have
A healthy domain makes a worthwhile SharePoint investment, as AD is the foundation on which a good SharePoint platform is builtMake sure you know what group policies are going to be applied to your SharePoint server
This is the typical scenario, where all SharePoint users are located on the local domainUsing local domain accounts also allows the people picker and profile imports to work with minimum hassleYou may need to also apply special group policy to these accounts, such as allowing ‘run as service’ which will be easier if they are all in the same OU
Yes, it can be a bit of a pain having to manage another AD domain, but you really don’t want your corporate domain to be compromisedOnce configured properly, users won’t be able to tell the differenceAlternatively, you could use stand alone servers and Forms Based Authentication for external users
At a minimum:Once the install and configuration has been completed, the account can be demoted to a user on the machineThe main SharePoint service accountFarm Services include things like the Timer Service, Administration ServiceThe crawl account needs to be separate, if not it will index draft and unpublished documents
For increased securityThese accounts are generally optionalIn my installs, I use a separate Search Service account, to isolate SharePoint’s functional areasExtra web application pool accounts provide increased security isolation, meaning that if one of your accounts is compromised by an attacker, there is less chance of them being able to access sensitive data on other sitesFor Internet facing SharePoint sites, architects should lean towards higher security best practicesUsing a separate SSP account allows for the further isolation of functional areasFinally, the SQL service account will be used to run the database services
SharePoint performance and stability is dictated primarily by the performance and stability of your database platformIf you are thrust into being a DBA as well as a SharePoint administrator, study up on SQL, lots of great info on the net and training courses available ** Previous Session?
Perfect world scenario, great for large corporate Intranets, but only really feasible for Internet publishing sitesAll 64 bit means that you will be ready for upgrade to 2010 too!Best in performance and manageability
The usual scenario, good for most SharePoint deploymentsDefine maximum page load time as an SLA, and then performance test SQL to make sure the platform will meet standardsAsk questions about who is maintaining it, and include in your governance plan
Sometimes the case if SharePoint deployment is not properly plannedOnce again, performance testing will tell you whether we need to look at an alternative solutionAvoid this at all costs, recently had to deal with this at a client site, and we deployed a new SQL instance on the SharePoint ServerCan even be better installing a local copy of SQL Server
Using a standard configuration and maintaining your windows servers should already be part of your organisational practicesThese are a few recommendations that will benefit your SharePoint environment
Keeping your Windows Server updated should be a standard practise anywayWho knows what WSUS is?Pays to monitor WSUS to ensure updates are being applied successfullyUsing a dedicated SQL server makes it easier to test and schedule outages for service pack upgradesRun the SharePoint service pack with the /extract switch to create a slip stream install
Having dedicated System and Data partitions ensures that Windows patches can always be appliedAlso, there can be performance gains from creating the partitions on separate disks, especially on the Index and Query rolesI like to make directories where all solutions and install binaries are placed before they are installed, in case they need to be reinstalled
Database servers can be set up similarly, with a system partition for Windows and Program FilesA data partition, where the actual SharePoint data will be stored, should be redundantKeep in mind that updates to the mdf file are made asynchronously
Your logs partition should be as fast as possible as this is where all the action happensYou can also improve performance by putting the tempdb on a fast disk as wellYou will probably only need a specific backup partition if you do not have a 3rd party backup solutionIf your backups are going to be archived off to another server, this partition will be used for temporary storage of your .bak files, and should be about 3 times the size of your data partitionCan be on less performant disks, as long as there is enough space
How many documents/how much content is your SharePoint installation going to hold?We need to predict uptake of SharePoint as a document storage location, and plan for future growth
Obviously, SharePoint’s various purposes are going to result in different storage needsKeeping unlimited numbers of old versions of documents can have a significant impact on content database size, so ensure that you limit the number of major and minor document versionsSetting initial database size reduces file system fragmentation of databasesYou can set this size in SQL management studio by pre-creating your databases, and then simply using your pre-created databases during web application configurationYou will need to use psconfig if you want to pre-create your admin content database, but this shouldn’t be necessary
This is not a best practice, but is the default, so is a common occurrenceNot as much of an issue if My Sites are hosted in their own web application
Create new content database from Central AdministrationSetting a content database to offline simply means that no new site collections can be created in it, existing site collections will still be accessibleIf new site collections are required within your business content database, they will need to be created by an administrator
Creating content databases for different types of content is a more advanced choice when you need different backup strategies for varying types of contentIf your document migration is going to result in content databases over 100GB in size, these should be split for performance reasonsI recently came across the need for this at a client where data storage gets charged back to the departmentUse this when your governance plan stipulates the need for a dedicated SharePoint Administrator
Who has created a SQL maintenance plan?SQL maintenance plans are a simple way to ensure that your databases are being backed up and maintained, especially if you don’t have a DBA looking after your database serversPlans are set up via a drag and drop design surface, built into SQL management console
The first plan will back up all your SharePoint content, configuration and search databasesThe system databases include model, master, and msdbOptionally, Transaction logs can be backed up to give point in time restores on databases with full recoveryAnd finally, a plan should be set up to run optimisations including re-indexingNote that shrinking your databases to claim space will only result in the files becoming fragmented when SQL server needs to allocate more space to the database
