I just finished attending the SharePoint Administration 2010 (Part I and II) and wanted to share some quick notes. Here are some highlights of things we learned!
Central Administration has been revamped with a focus on the UI and usability. There are more wizards and ISV’s will be able to create wizards that will be available from within Central Administration.
In SharePoint 2010, service accounts can be managed accord to Active Directory policies. Managed accounts will allow SharePoint to automatically change service account passwords automatically. Use PowerShell to manage them.
Farm Configuration Wizard
This wizard runs the first time you load Central Administration. You can specify the managed account to use and select which services you want the wizard to install. Looks like there are about 20 services.
A failover database can be specified in CA for mirrored databases once SQL mirroring has been configured.
In SharePoint 2010, PowerShell is the command line tool of choice and is fully supported as it does everything STSADM could do but does it better.
Todd Klindt reviewed some handy cmdlets useful for SharePoint IT Pros.
Get-command â€“noun SP*
- This will give you commands that have nouns that start with SP (for example Restore-SPSite).
Get-spsite | get-spweb | selec URL, webtemplate
- Returns all the Web Teamplates used by each site.
Backup and Restore
In SharePoint 2010, Farm backups are the same format as 2007 but now allow multiple threads. You can perform configuration only backups as well. Central Administration has granular backup, out of the box (Site Collection, Web or List). Additionally, it’ll backup unattached content databases. You could also use PowerShell to perform backups.
SharePoint 2010 will eliminate the “recovery farm” by allowing extraction of content from a unattached content database.
Throttling and Performance
In SharePoint 2010, the server monitors its own performance. The artificial limits used by administrators (such as 2000 list item limit) are no more. In his keynote, Microsoft CEO Steve Ballmer spoke about tens of millions of list items being handled easily with SharePoint. Large lists can support 50 million items per list.
Results are trimmed down so performance doesn’t suffer. Users and admins have different settings and admins can set time slots to change how many items are returned in results.
HTTP Request monitoring and Throttling protects the server during peak load. It checks RAM, CPU %, ASP.NET queue and wait time in queue every 5 seconds.
Administrators can use this dashboard to troubleshoot pages, load time of pages and broken web parts. It will show you the call stack, times to render the components on the page, webb part processing time, critical events and database query information. It can be toggled on and off via STSADM.
The Universal Logging System (ULS) is compressed by default and includes correlation IDs to better find information. There’s less “noise” and has event log flood protection. Repetitive log events are suppressed so that logs are filled up by the same event. There’s log aggregation via SQL Logging database which will bring in all the ULS logs from all your farms.
Best Practice Analyzer
The BPA in SharePoint 2010 uses “Health Rules” to check the server. The rules are extensible meaning that ISV’s can add rules for their products and you can even write your own rules.
In SharePoint 2007, timer jobs ran on a server and it was hard or impossible to tell which specific server they were running on. That would make troubleshooting a nightmare. In 2010 there’s server affinity which means that not only can you tell which server a job is running on but you can specify which one you want it to run on.
Timer jobs have come a long way as far as flexibility and reporting. For example, you could run them on demand if you wanted and see a progress bar. There’s a history section that details when they ran and gives you more information to troubleshoot failed jobs.
Patching and Upgrades
Ever wanted to patch just your Web Front Ends to plug a security hole but didn’t care to take down the entire farm? SharePoint 2010 lets you run different patch levels so you can do just that. Save patching the database servers for later when you have a maintenance window. The one catch is you much maintain patches within a compatibility boundry. This flexibility will even allow you to bring in an unattached content database (say from a backup) at a lower patch level and restore it, or just extract a specific site or list.
Don’t forget to check out the Live Blogger stream for instant updates to the events at SharePoint Conference 2009.