Well, its been sooo busy with me writing the MOS Study Sharepoint section for the MOS exam 77-886, and being inundated with queries concerning what is the best study guide to use for SharePoint, that I thought lets drop my thoughts in this short blog for you to mull over.
Got a query today concerning User Acceptancy Testing (UAT) on SharePoint. As a SharePoint implementator, we know that the client needs to test the provision (your deliverables) of the SharePoint environment, based on exactly what they requested (the scope).
However, some may think that simply carrying out testing on just what the scope entails covers a full UAT.
Take this scenerio – the client is brand new to SharePoint, wants the product and needs to make sure that the team sites can store compliance data.
Do you UAT just the team site in terms of storing compliance data? No – the client doesn’t know SharePoint!
Another scenerio – the client is upgrading from SharePoint 2007 to 2010, wants the product and needs to make sure the team sites can store compliance data.
Do you UAT just the team site in terms of storing compliance data? No – the client needs to understand the nature of SharePoint 2010 against 2007 – they are not the same beast!
Of course, it all depends on whether the UAT is solely technical, or business oriented; for example, the UAT may simply be part of handing over support of the product into Business As Usual (BAU).
In anycase, UAT is perceived as something that guarantees the using the product of the product – the client is comfortable and convinced that the product does what it says on the tin. When implementing SharePoint you push the features of SharePoint; hence, you have documented standard sharepoint functionality. That must be conveyed that it works from a demonstratable perspective. Therefore UAT is required for standard SharePoint functionality.
In my experience I always UAT standard sharepoint since remember the element of training locks into this and it gives you invaluable insight into what the client expects to do with the product in their workplace. You should remind your client of this as it will instill in them the importance of understanding the nature of the beast!
I have a customer who has third party developers enhancing their SharePoint platform; their questions surrounded the control of these developers from the perspective of how their products end up running in SharePoint. We all know that SharePoint is pretty ‘laissez-faire’ about any products on the servers it runs, whether they be SharePoint workflows, Visio workflows, Site Features, Automation and the list continues. SharePoint doesn’t care whether you have details about how the product is supported or managed. So, as a SharePoint manager, you will understand that SharePoint infrastructure requires protection of its integrity; particularly since there are levels of SharePoint applied (i.e. Production, Pre-Production and Disaster Recovery platforms are usually kept in sync). Not doing this or at least being proactive results in an uncontrolled, and chaotic environment where no-one really has a handle on what is installed, who did it, and why – worst case scenarios include not being able to even find the original developer who created the product now running on your company-wide SharePoint implementation.
If you carry out Exports and Imports using the good ole stsadm –o commands this will may be of interest if you run into the following error:
Content deployment job ‘Remote import job for job with sourceID = <id>’ failed.The exception thrown was ‘Microsoft.SharePoint.SPException’ : ‘The file Pages/Forms/Page Layout cannot be imported because its parent web /site does not exist.’
Scenario is a two front end, index and crawl server which had just been migrated into a new server group in a different datacentre. Following the migration and startup, Front End servers both show this message every 15 minutes:
The Usage Data Import timer job failed. You can rerun this job using the Timer Job Status page in the SharePoint Central Administration site
Looks like this:
Followed by a critical error in the very next second:
The Execute method of job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition (ID GUID) threw an exception. More information is included below.
An update conflict has occurred, and you must re-try this action. The object SPUsageServiceInstance was updated by domain\serviceaccoutn, in the OWSTIMER (ID) process, on machine SharePointFrontEndServer. View the tracing log for more information about the conflict.
Looks like this:
Noticed that the SharePoint cache had been recreated using a brand new guid, but, the file dates were all inconsistent. This could mean that there could be old instances being referred to in the jobs that no longer relate to the new farm Guid.
Resolution? – reset the SharePoint cache.
Do the following on every SharePoint server in the farm:
Note.
The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm. Make sure that the Cache.ini file in the GUID folder now contains its previous value; make sure that the value of the Cache.ini file is not 1.
