My pennyworths on Third Party Product Deploy in SharePoint – Where is the Documentation then?

My pennyworths on Third Party Product Deploy in SharePoint – Where is the Documentation then?

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.

(more…)

Import Failure – Parent Web Site does not Exist – A Possible Fix

Import Failure – Parent Web Site does not Exist – A Possible Fix

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.’

(more…)

Usage Data Import Job Fail 8075 and Execute Method SPUsageImportJobDefinition Fail 6398 – How to Fix

Usage Data Import Job Fail 8075 and Execute Method SPUsageImportJobDefinition Fail 6398 – How to Fix

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:

UsageData Error Picture 1

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:

Usage Data Error Picture 2

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:

  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
  3. In Windows Server 2008, the configuration cache is in the following location: Drive:\ProgramData\Microsoft\SharePoint\Config
  4. In Windows Server 2003, the configuration cache is in the following location: Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
  5. Locate the folder that has the file “Cache.ini”
  6. (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  7. Back up the Cache.ini file.
  8. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  9. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  10. Double-click the Cache.ini file.
  11. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  12. Start the Windows SharePoint Services Timer service

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.

How do you manage the size of your SharePoint sites?

How do you manage the size of your SharePoint sites?

Let’s start this article by putting into context the reasoning behind site quotas, and of course, this means a description of exactly why the feature is required.

Site Quotas, in a nutshell, allows you to define a limit on the storage capacity of a SharePoint site collection. A TechNet article describes a Quota as this:

The storage limit applies to the site collection as a whole. In other words, the storage limit applies to the total size of the content for the top-level site and for all sub-sites within the site collection. If versioning is enabled, the versions in a site and the content in the Recycle Bins count toward storage limits.

Without this feature, you would have SharePoint sites blossoming into an un-controlled; file ‘trough’ areas where content could be uploaded. So, I hear people cry, “Why is that bad? Shouldn’t we just allow people to store anything and not subject them to a storage limit”?

Storage costs money. And there are different types of storage. Some companies charge departments for storage allocation. For example, if you wanted to create your own website, you’d have to pay based on the capacity of that site as one of the key drivers. Also, you, and site owners would want to know how their site is growing, how much content is there and how soon they would hit a threshold before purchasing more site space (and as such, upping the quota)…

Managing SharePoint Site Size.

When quotas are defined, SharePoint provides out of the box reports which provides a list of all content in a SharePoint site, its size, the number of items, when last modified and the location of them. These are displayed for a Site Collection Administrator. Now, I’ve had many conversations on the nature of this report and whether the site owner, or designated people in the company should be able to see this type of report on demand. That is where there may be an issue in terms of managing the site size. Because the report is available to a site collection administrator only, that assumes that the person looking at the report must be a SharePoint lead admin with knowledge of the site collection features in a Site. Some people would say “So what? I’ll make anyone who wants to view this report a site collection administrator”. Looks of horror from the SharePoint community as someone hails, “Hey, 30% of my companies business end users are site collection admins in SharePoint”.

So what do we do instead in dealing with site size reporting? Here’s some options found on my travels; is your scenario is below? :

  • Print out or screenshot the quota screen and pushes it on to the relevant site owners. This may work in a small organization in say a couple of hundred sites. But what about sites where they are in the thousands or tens of thousands with site quotas set?
  • Use a third party application to automate output the Site Quota via XML and push it into Excel then put that as an Excel HTML page on a site. The owner looks at the size and requests an increase on demand.
  • Use a third party tool to monitor the site size and automatically set it to the next quota level and send out an email to the site owner and administrator. Ok, sounds cool? Maybe not I hear people say! I don’t sense anyone managing that site size and growth rate?

Am sure there are others, and probably more creative and more outlandish than the ones that I have listed above. I suspect that because of this, there is no ‘best practice’ out there concerning governance on site using site quotas. Instead, companies using SharePoint have gone down a road of choosing their own ways of managing site growth and size.

Here’s my stab at defining best practice for SharePoint Site Storage Governance.

  1. Identify the site in terms of its functionality, the kind of content that it will hold, what features and products may connect into it, the number of potential users.
  2. Related to the above. Understand the current organization model for storage requests. Are there costs associated and do these relate to SharePoint. If yes, then map the quota templates to the cost charges and ramp them up accordingly. If not, still apply quota templates at least to keep an eye on site growth and help site owners to manage site growth and monitoring.
  3. Find out who the owners are who need to know about site growth. No, you are not going to make them site collection administrators! You are doing this so that you know who potentially will need the information, and when they would need it (if you want to pass on monthly reports concerning site sizes).
  4. Work in a growth rate monitoring plan. This is very important. You should be proactive and monitoring sites which appear to be growing faster than expectation. This is with a view to investigating what is causing the site growth and what needs to be done to address any issues.
  5. Ensure there is governance put in place to ensure the site templates are set to a company standard, and that if there are any changes they can be applied easily. Remember that in doing this you are ensuring your site size roadmap connects into Disaster Recovery and site topology. This also paves the way for future migrations of the SharePoint platform.

In conclusion.

Whatever the way you apply your site templates, you must map this to some kind of governance that supports it. Whether that governance is defined by a SharePoint architect on behalf of an organization without yet a SharePoint governance board, or whether technology defines costing for storage, or whether the business can request more space at a drop of a hat, you will still need to manage and monitor the impact.

This article has concentrated on the concept of site quota management. There are of course many other articles describing how to implement and configure site quotas in SharePoint.

Create, edit, and delete quota templates in SharePoint 2013

http://technet.microsoft.com/en-us/library/cc263223.aspx

Managing Site Collection Storage Limits (SharePoint 2010)

http://technet.microsoft.com/en-us/library/cc263480.aspx

Plan Quota Management (SharePoint 2010)

http://technet.microsoft.com/en-us/library/cc891489.aspx

Create, edit and delete quota templates (SharePoint 2010)

http://technet.microsoft.com/en-us/library/cc263223.aspx