SharePoint 2010 Certifications

Microsoft have listened and decided to make 2 professional level certifications available for SharePoint. In SharePoint 2010 you will now be able to get certified as an MCITP and MCPD for SharePoint as well as the usual MCTS certifications.

IT Pros: New on for IT Pros are 2 certifications. MCTS SharePoint 2010 Configuring and MCITP SharePoint 2010.

•70-667 : Microsoft SharePoint 2010, Configuring
Microsoft Official Curriculum: Will cover configuration of SharePoint 2010 including deployment, upgrade, management, and operation on a server farm.

•70-668 PRO: SharePoint 2010, Administrator
Microsoft Official Curriculum: Will cover advanced SharePoint 2010 topics including capacity planning, topology designing, and performance tuning.

For developers, check here..

Also for developers there will be 2 new certifications. MCTS SharePoint 2010 Application Development and MCPD SharePoint 2010.

•70-573 : Microsoft SharePoint 2010, Application Development
Microsoft Official Curriculum: Five-day instructor-led course designed for developers with six months or more of .NET development experience. Course covers what you need to know to be an effective member of a SharePoint development team using Visual Studio 2010.

•70-576 PRO: Designing and Developing Microsoft SharePoint 2010 Applications

Microsoft Official Curriculum: Five-day instructor-led training course designed for development team leads who have already passed the Developing on SharePoint 2010 technical specialist exam. The course covers choosing technologies for and scoping a SharePoint project, best practices for SharePoint development, configuring a SharePoint development environment, advanced use of SharePoint developer features, and debugging of code in a SharePoint project.

These new certifications also feed into the Microsoft Certified Master certification for SharePoint 2010. The MCM for SharePoint 2007 required 4 MCTS certifications whereas the 2010 version will require the MCPD and MCITP for SharePoint 2010. The experience requirements have not yet been release nor has the how the upgrade will work from MCM 2007 to MCM 2010.

There will be no upgrade path from the MCTS 2007 to MCITP/MCPD 2010 due to the fact that there are Pro level certifications for 2007 making the upgrade process redundant.

More information can be got on the MS Partners site HERE

Run database maintenance Health Analyzer rules.

SharePoint 2010 with the Health Analyzer rules framework. This rules framework is configured with a number of rules to monitor the health and well-being of a ShärePoint environment and in some instances takes action to correct certain types of issues.

SharePoint 2010 ships with several rules pertinent to content database maintenance. There are rules that automatically reduce index fragmentation for some SharePoint databases, and rules that check for outdated statistics, updating them if necessary. These Health Analyzer rules replace the updated Database Statistics timer job introduced in Service Pack 2 for SharePoint  Technologies.  By default, these rules are configured to execute on a schedule that varies from daily, weekly, to on-demand depending on the rule target.

All Health Analyzer rules that are configured to execute daily and associated with a particular SharePoint service are executed by the same timer job. Adjusting the scheduling of this timer job will adjust when Health Analyzer rules configured for daily execution and associated to that service will execute during the day. All rules discussed in this white paper are associated to the SharePoint Timer service.

Health Analyzer rules configured to execute on a different time interval ((such as weekly), depend upon your needs) or associated with a different service have distinct timer jobs. Configuring a Health Analyzer rule to execute weekly would mean that that Health Analyzer rule will execute with the timer job configured to execute weekly for the specific service that the Health Analyzer rule is associated to. This execution will occur on whatever schedule has been defined for that timer job.

Health Analyzer rules may be run manually by selecting ―”"” Run Now from the ribbon “”"” from within the Health Analyzer Rules page in Central Administration. Running these rules will cause the health of indexes and statistics to be evaluated, and cause index rebuilds and recalculations as appropriate.

Databases used by SharePoint have fragmented indices – When you run this rule, the following tasks are performed:

* The rule reports indexes as being fragmented. This is because evaluating index health is an expensive operation. As a result of the details of Health Analyzer rule execution, this rule will always reports indexes as being fragmented in order to trigger the corrective action.
* For each SharePoint database, the rule action looks for, and if found, executes the proc_DefragmentIndices stored procedure. During the execution of this stored procedure, a listing of all indexes within the database is built. Each index is evaluated as to its present level of fragmentation. Any indexes fragmented in excess of 30 percent are considered for rebuild.
* Assuming the edition of SQL Server supports online index rebuilds, an online index rebuild is attempted for each index. Should this fail, perhaps because the underlying index does not support online rebuilds due to the use of LOB columns, an offline index rebuild will be performed.

As noted above, not every database in a SharePoint environment is serviced by this rule. Certain databases use different rules to perform similar maintenance activities.

Search (Search engine is huge topic)- One or more crawl databases may have fragmented indices – This rule maintains the indexes within the SharePoint 2010 Enterprise Search Crawl Databases. This rule is configured by default to only execute on demand. When executed, it will execute from any server in the farm.

This rule, when executed, will always report indexes in the crawl databases as being fragmented. This is due to the expensive nature of checking for fragmentation within a database. As a result, simply disabling the ‗Repair‘ activity for this rule will result in all crawl databases being reported as unhealthy, even when the crawl databases have had their indexes recently rebuilt.

To manually manage the maintenance of indexes within crawl databases, you should disable the ‗Search – One or more crawl databases may have fragmented indices‘ rule in its entirety.
When you run the ‗Search – One or more crawl databases may have fragmented indices‘ the following tasks are performed:

* The rule confirms that the environment is in a state in which performing an index rebuild is safe.
* For each Crawl database configured for search applications within the local farm, the rule executes the proc_MSS_DefragGathererIndexes stored procedure.
* Each index within the Crawl database performance in the list is rebuilt. If the edition of SQL Server supports online index rebuilds, an önline index rebuild is performed. If an önline index rebuild is attempted, but fails, the index will be rebuilt offline.

It is important to note that the ‗Search – One or more crawl databases may have fragmented indices‘ rule will rebuild every index within all Crawl databases regardless of fragmentation level. It will also enable page level data compression, if supported by the edition of SQL Server that is hosting the Crawl database.

Due to the nature of the Crawl database, it is not anticipated that you will need to defragment this database frequently. Execute this rule after you have first performed a full crawl over your content. Afterwards, monitor the indexes within the Crawl database for fragmentation, and execute this rule whenever index fragmentation grows. This may occur as a result of the sudden addition or removal of a large amount of crawled content – for example, during content expulsion as a result of environmental cleanup, or after the onboarding of a new content source, such as a file share or large SharePoint Web application.

The following databases do not have an automated mechanism in place for their maintenance. These databases are not anticipated to encounter a great deal of fragmentation. Monitor these databases for fragmentation, and rebuild indexes within these databases when fragmentation exceeds 30%.

* Search Administration Database
* Secure Store Database
* State Service Database
* Profile Sync Database
* Usage Database
* Managed Metadata Database
* Business Connectivity Services Database
* PerformancePoint Services Database

Please visit för more information about the changes that are supported for SharePoint 2010 databases, see Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=110844&clcid=0×409) in the Microsoft Knowledge Base.

If the performance of a heavily fragmented database or table is not measurably improved by frequent defragmentation, you should check the performance of the I/O subsystem.

Reducing fragmentation for a specific table and its indexes: defragment an index associated with a particular table rather than an entire database, you can either reorganize or rebuild the index.

* Reorganizing an index specifies that the index leaf level will be reorganized. Index reorganization defragments and compacts clustered and nön-clustered indexes on tables and views and can significantly improve index scanning performance. Reorganizing an index makes use of the existing space allocated to the index. Reorganization is always performed online, so that the underlying table is available to users.
* Rebuilding an index specifies that an entirely new copy of the index will be rebuilt. This means that a rebuild operation requires enough extra space to build the new copy of the index before removing the old, fragmented index. Rebuilding improves the performance of index scans and seeks. You can rebuild the index with a table either önline or öffline.

The fragmentation level of an index determines the method you should use to defragment it, and whether it can remain online, or should be taken offline. The table describes the defragmentation method that is recommended for different fragmentation levels.

IMP: Using the DROP INDEX and CREATE INDEX commands is not supported on SharePoint 2010 databases.

The database maintenance tasks supported for SharePoint 2010.

The recommended maintenance tasks for SharePoint 2010 databases include:
* Checking database integrity.
* Defragmenting indexes by either reorganizing them or rebuilding them.
* Setting the fill factor for a server.

Database maintenance and not planning for capacity or performance. För information about capacity or capacity planning, see Storage and SQL Server capacity planning and configuration
(SharePoint Server 2010) http://go.microsoft.com/fwlink/?LinkId=217482.

SharePoint required manual intervention to perform index defragmentation and statistics maintenance, SharePoint 2010 automates this process for its databases. This is accomplished by several SharePoint Health Analyzer rules. These rules evaluate the health of database indexes and statistics daily, and will automatically address these items for these databases:

* Configuration Databases
* Content Databases
* User Profile Service Application Profile Databases
* User Profile Service Application Social Databases
* Web Analytics Service Application Reporting Databases
* Web Analytics Service Application Staging Databases
* Word Automation Services Databases

Database maintenance tasks can be also performed by either executing Transact-SQL commands, or running the Database Maintenance Wizard. We will initially present the Transact-SQL commands that you can use, and then explain how to create database maintenance plans by using the Microsoft SQL Server® Database Maintenance Wizard.

Check for consistency errors by using DBCC CHECKDB
Start your routine maintenance operations with consistency checks to ensure that your data and indexes are not corrupted. You can use the DBCC
CHECKDB statement to perform an internal consistency check of the data and index pages.
The most of database consistency problems are caused by I/O subsystem errors.

Database consistency checks should be performed at least once per week on your SharePoint 2010 databases, and whenever events such as database server or I/O subsystem failures occur.

DBCC CHECKDB:
DBCC CHECKDB checks the logical and physical integrity of all the objects in the specified database by performing the following operations:
1. Runs the equivalent of DBCC CHECKALLOC (http://go.microsoft.com/fwlink/?LinkId=110815&clcid=0×409) to verify the allocation structures in the database.
2. Runs the equivalent of DBCC CHECKTABLE (http://go.microsoft.com/fwlink/?LinkId=162093) on every table and view in the database to verify their logical and physical integrity.
3. Runs the equivalent of DBCC CHECKCATALOG (http://go.microsoft.com/fwlink/?LinkId=110834&clcid=0×409) on the database to verify its metadata consistency.

Running DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS is not supported. However, running DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD is supported, as these commands only update the indexes of the associated database.

DBCC CHECKDB and performance:
DBCC CHECKDB causes blocking” (http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx). by Paul S. Randal.
You may find that the resource overhead of running DBCC CHECKDB is too high for your production system. In that case, do not attempt to run consistency checks one table at a time as this will be more problematic overall. The best ways to reduce the integrity-checking overhead on the production system

 A man and his wife are lying in bed, just about to fall asleep.  The conversation goes like this:

Wife: ‘If I were to die, would you re-marry?’

Husband: ‘Of course not!’

Wife: ‘Why? Don’t you like being married?’

Husband: ‘Well, yes – I suppose I would re-marry’

Wife: ‘Would you take down all the pictures of me and replace them with her?’

Husband: ‘Well yes, that would be the proper thing to do’

Wife: ‘Would you let her use my golf-clubs?’

Husband: ‘No, she’s left handed… oh shit!’