A SharePoint Contact list can be synchronized with Microsoft Outlook; so that features available in Microsoft Outlook contacts would be available to a SharePoint Contact list displayed in Outlook. Another benefit of this approach is that users would be able to see all their contacts in Outlook instead of having to visit many differing locations.
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.
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)…
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? :
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.
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
Best way to start is to show you those errors in the good ole event log:
Error 1001:
Fault bucket , type 0
Event Name: CLR20r3
Response: Not available
Cab Id: 0
Problem signature:
P1: owstimer.exe
P2: 14.0.5128.5000
P3: 4cace1f1
P4: mscorlib
P5: 2.0.0.0
P6: 4bebe8e2
P7: 420f
P8: 51
P9: DI4EQZGVCWKDLTHKQTZWPXE3YRFKN1I2
P10:
Attached files:
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_owstimer.exe_8e20523ad5db1439a93c757fe02d53f596a2ef32_435aa75b
Analysis symbol:
Rechecking for solution: 0
Report Id: 43b091e0-304b-11e0-b81c-005056932bb3
Error 8312:
SharePoint Web Services Round Robin Service Load Balancer Event: Initialization
Process Name: OWSTIMER
Process ID: 6160
AppDomain Name: DefaultDomain
AppDomain ID: 1
Service Application Uri: urn:schemas-microsoft-com:sharepoint:service:829500b757c944debc8e4e5da76e5b07#authority=urn:uuid:69453d27abe74895b8385be3dc9c2e35&authority=https://plonapdmps01:32844/Topology/topology.svc
Active Endpoints: 1
Failed Endpoints:0
Endpoint List:
http://sharepointindexserver:32843/829500b757c944debc8e4e5da76e5b07/ProfileService.svc
Error 6398:
Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation
Date: 04/02/2011 01:00:01
Event ID: 6398
Task Category: Timer
Level: Critical
Keywords:
User: SERVICEACCOUNT
Computer: sharepointindexserver.com
Description:
The Execute method of job definition Microsoft.Office.Server.UserProfiles.UserProfileImportJob (ID bee5da2c-0ec8-4dce-9f13-7116fdaa9256) threw an exception. More information is included below.
User profile import is in progress!Import could not be started. Please start import later or stop import now for new import to start.
Noticed that when attempting to run Sync jobs that the log was not being updated and a sync job would immediately go to Idle.
Noticed also that no profiles had been updated for over a week.
Tried to check the Sync Connections. Noticed that if Sync is running the Query on Sync Connections shows nothing (most confusing) and the only way you find out that everything is actually ok is to click ADD NEW CONNECTION – actually, I decided to check instead ForeFront in Services and this is what greeted me.
Forefront Identity Manager Service not started? Er – How? WT?
Seems that the ForeFront Identity Manager had stopped? [Shocked]
So, restarted ForeFront Identity Manager, and restarted the sync jobs.
Result? Success!
Now ‘why’ – am asking myself – can only imagine that:
1: If the Identify Manager is not working it seemed that no connections were displayed in Sync Connections, and if a new connection is attempted to be created then the Correlation Error MOSS MA was displayed – restarting Identity Manager fixed that.
2: If Forefront is configured to look at the Forest and not a specific domain in that forest then it is possible that the import will stop if the user id does not have access to that domain in the forest
3: Error 1001 showed that the job attempted to start then immediately failed, but did not indicate that ForeFront had anything to do with the job itself. I suppose the synchronisation job failed, but that would mean checking all other related jobs, and not any of the services (unless you decided to check Forefront first – as I did!)
4: Error 8312 showed an issue with the Profile Status service meaning that that job did not start or shutdown prematurely; again seems to relate to ForeFront and the Sync job
5: Finally, good old 6398 – showing that the import process could not be started – I suppose that means a fault in attempting to even start the sync process!
6: I have a very strong suspicion that the installation of the culmulative updates for Dec 2010 SharePoint affected the User Profiles sync and shut down ForeFront Identity Manager. In future for any culmulative update I will check that all those relevant services are running – in fact, a good idea is to note the state of services on the index box before applying the update. I know that sounds a bit over the top, but this kind of error completely threw me and I spent I think far too long attempting to get to the bottom of it!!
So, the upshot? Scratching Head Time but at least the problem has been corrected. So, am still investigating this one, but hope this little nugget helps you guys out there.
As a SharePoint Architect, it is crucially important that to create a robust SharePoint environment for your clients requires planning and considerations of opportunities and threats concerning SharePoint topologies.
All too often SharePoint is implemented without a true understanding of its premise, structure and components, potentially leading to SharePoint becoming a white elephant from a support and user perspective. However, if planning is carried out, and considered by you, your peers and the client and following a repeatable process then it ensures platform growth and future-proofing.
This article of two discusses my opinions in creating a detailed design for a SharePoint 2010 environment focusing on designing its topology, and covers these areas:
In addition, we must not forget areas that relate to planning SharePoint 2010 topologies, namely: Organisational Requirements; SLA requirements; Functional requirements and Licensing (but I’ll get around to that in Article 3 J ).
First, learn more about the areas that you will need to document as part of the topology planning exercise. Of course, you don’t have to throw your hands up yelling ‘how do I find that?’, since there is a wealth of information out there already – either hosted by Microsoft on TechNet or through other excellent sources (including my book J)
First – my book is the source for describing how to best implement SharePoint 2010 (everything and much, much more is in that book) – since there are significant pieces of work leading to designing your SharePoint environment:
Managing and Implementation of Microsoft SharePoint 2010 Projects – check out system specification, topology design and user requirements gathering.
Other good reads:
| Article | Location |
| System Requirements | http://technet.microsoft.com/en-us/library/cc262749.aspx |
| Server Farms and Topologies | http://go.microsoft.com/fwlink/?LinkID=167089 |
| Performance and Capacity | http://technet.microsoft.com/en-us/library/cc262971.aspx |
| Logical components | http://technet.microsoft.com/en-us/library/cc263121.aspx |
Also, it is important to be aware of the components that make up a SharePoint environment. And, the best way to appreciate and gather these properly is to start from the lowest level component; working your way up through increasingly complex and costly areas so a clear idea is known. For those used to SharePoint, these should come as no surprise – in order then:
Lists and Libraries > Sites > Site Collections > Content Databases > Web Applications > Servers > Farms > Datacentres.
Each of these areas will constrain your topology design for SharePoint and must be investigated.
First, document the customer base. Identify the number of users, the level of information held in their user profiles, how those profiles are stored, the physical location of the users and who manages the user profiles.
Second, gather the functional and availability requirements. What is the premise of the SharePoint environment – is it document management? Publishing? Application Workflow? Social Networking? A combination? Will it include Search and to what extent? Will users have personal spaces (Mysites) and if so what basic functionality will they require? Availability – if the SharePoint environment was subject to a disaster event, how long could the business afford to be without SharePoint? If a site became corrupted and had to be restored, how quickly do users need to be up and running with the restored environment? When SharePoint requires maintenance, when are these ‘windows of opportunity’ available and for how long?
Thirdly, plan capacity. Starting from the base, analyse document storage. This means sizing up the document type and sizing. Do this for all the document requirements for all the relevant sites gathered in the previous step, then, total. Factor in search requirements since this will give you a rough size of the search index, and include all service applications needed on day one (since that will also have a bearing on the content data sizes as well). Include storage requirements for the operating system. Other areas include size backups staging requirements (e.g. direct site backups and farm backups), logs and storage requirements for tools (e.g. third party applications).
Don’t forget that the storage type being used has a bearing since there is an associated cost – ensure that you discuss options with your storage teams as to the best requirements. Typically, you want fast access to content and maybe slower access to archival material so make sure you have choices set for those.
Again, going back to the components that make up the SharePoint environment, confirm each of them against the above and be prepared to go to the n’th degree to ensure you are clear on whether the planning meets the provision and limitations of those components. A very good place to understand these is here: http://technet.microsoft.com/en-us/library/cc262787.aspx
I hope this has been useful to you. The second article of this one will further discuss other key parts of this process, Performance and Design constraints.
This article explains how to install the PDF filtering ability in SharePoint 2010. As you may be aware, without this ability text within PDF files will not be included in any SharePoint index, and as such, only the PDF filename itself will be indexed.
As always with any third party application, make sure you deploy this first to a test platform, confirm it works through tests, and then through change process apply it to your production environment if successful.
1: Download the Adobe Filtering Package – called the Adobe PDF 64bit iFilter (at version 9 at the point of writing this document) from here:
http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025
2: Extract the PDFiFilter64installer to a location accessible from your SharePoint 2010 Farm.
3: Log into your Application Server
4: Run the PDFiFilter64installer:
4: Repeat process (3) for all servers in the Farm
5: Log into SharePoint 2010 Central Administration
6: In the Application Management section, click Manage Service Applications
7: In the Manage Service Application section, click your Search Service Application
8: In the Search Application, and within the Crawling section, click FILE TYPES
9: The File Types section is displayed. Now to create a PDF file type. Click NEW FILE TYPE
10: Enter .pdf then click OK
11: Use RegEdit to update the Search Filters
Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters
Right-click the Filters folder and select New Key. Enter “.pdf” for the key value.
Add the following values to this key:
<REG_SZ> Default = <value not set>
<REG_SZ> Extension = pdf
<REG_DWORD> FileTypeBucket = 1
<REG_SZ> MimeTypes = application/pdf
The key should look like this:
12: Use RegEdit to update the Common Filters Extension
Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension
Right-click the Filters folder and select New Key. Enter .pdf for the key value.
Set the “default” value to
{E8978DA6-047F-4E3D-9C78-CDBE46041603}
The key should look like this:
13: Find a PDF icon – this should be either a .GIF or .PNG, and copy this into the following location:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IMAGES
14: Access the following directory:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\XML
15: Copy DOCICON.XML to ZZDOCICON – Copy.XML (to ensure you have a backup copy)
16: Open DOCICON.XML using Notepad
17: Insert a blank line under <Mapping key = “onetoc2”, copy and paste the following into that blank line:
<Mapping Key=”pdf” Value=”pdf_icon.gif”/>
If done correctly that section of DOCICON.XML should look like this:
18: Save DOCICON.XML
19: Run IISRESET on the server
20: Restart services SharePoint Foundation Search V4 and SharePoint Server Search 1
21: Repeat steps 11 through to 20
That completes the process of installing the PDF iFilter for SharePoint 2010; run a re-crawl or wait for the next scheduled to start seeing your PDFs being indexed.
Note.
