Thanks to Jason Medero - TechEd Brain Dump #2 Moss 2007 Advanced-Capacity-Planning-Infrastructure-Deployment

TechEd Brain Dump #2 Moss 2007 Advanced-Capacity-Planning-Infrastructure-Deployment

Here are a few notes that I took from the Joel Oleson and John Nisi’s presentation on Moss 2007 Infrastructure topics and admin architecture.  Some good stuff I hope everyone can read my somewhat disorganized note taking!

 

 

• Shared services




• Grouped, high-value, resource intensive services


• One to many per farm


• Inter-farm capable

 

• NO MORE TOPOLOGY RESTRICTIONS!!




• Factors to consider:




• Data composition


• User load


• Long-running operations


• Performance


• Availability & reliability


• Network considerations

 

          Beta 2 Hardware Requirements:  (Will change come RTM)

o   Single box installation

§  CPU:  2.5 GHz

§  Memory:  2 GB recommended, 1 GB minimum

§  HDD:  Scenario dependent

o   Farm Deployment

§  Web server: 2.5 GHz, 2 GB RAM

§  App server: Dual proc 2.5 GHz, 2 GB RAM

§  SQL: Dual proc 2.5 GHz; 2gb RAM

§  Support both 32 & 64-bit

• MOSS 2007 Disaster Recovery




• Backup and Restore methods




• 2-Stage Recycle Bin for documents and lists


• Site-level backup/restore via STSADM


• Integrated backup/restore UI for web application and farm


• VSS writer for farm backup


• SQL Server backup/restore


• Mirror/failover farm




• Replicate primary farm on secondary system


• SQL log shipping transfers content DB data


• Must manually replicate configuration changes


• On disaster, router switches traffic in minutes

 

• Servers have roles




• WFE


• App server:  Indexing, Search, Excel Calc, Project


• Db server
  
  


• You can create a farm of any size of each Server Role


• Some guidelines:




• At least 1 server specified as Index


• No more than 8 WFE for each SQL Server

 

• Watch-Outs for Shared Services




• Farm:  SSP web app pool account CANNOT be Network Service (local accounts)


• 1 SSP admin site allowed in a single web application ---->  \admin\ssp


• Central admin operators == SSP site administrators


• Closely manage security when switching associations

 

• Use cases for multiple SSPs (Shared Service Providers)




• Secure isolation of services and service data




• Hosted environments


• Restricted sites


• Organizational / Political concerns

 

• Special Rights




• Central Admin SPADMIN must be LocalSystem on all servers




• DBO for all DBs


• DB Creator


• SQL Security Admin


• Shared Services :




• DBO for content DB


• R/W to SSP DBs


• Read from config DB


• R/W to SSP DBs


• R/W to content DBs


• Read from config DB

 

o    Site Rights

          DBO for content DB

          R/W to SSP DBs

          Read from config DB

 

• Security Best Practices




• Unique accounts for the following:




• Farm account


• SSP process account




• NOTE: Cannot be Network Service in a farm config.


• SSP shared web service account


• Content app pool


• Kerberos on (default = NTLM)




• Each process account must be a registered SPN to work


• SSL enabled (default = off*)




• Turn on for admin sites & server to server


• Warning provided on credentials pages if SSL is off


• SPAdmin service:




• Single server: Off (recommend â€�On’ for OSS)


• Farm: On

 

• Switch over to Kerberos for quicker authentication highly recommended to switch from NTLM and provide a SPN (Service Principal Name) for a more secure environment.

 

• Additional configuration




• Web load balancing (incl. static IP)


• SSL/Kerberos


• ASP. Net pluggable authN provider


• Caching – for performance

 

 

Cheers mates!