Problem: When checking in a document user receives the following error and is not able to check-in the document:

Additional details:

· Farms in separate domains.

· Able to authenticate to and view sites but we cannot open sites using SharePoint Designer.

· Prompted for authentication and are shown the initial site structure but when we click open, it throws several errors.

· Can duplicate this problem on multiple workstations.

· They are connecting to SharePoint via an IP address with port number

· Also happens when working on SP Designer on the actual Sharepoint server

· Customer able to browse to the problem list identified in the Fiddler output either by hitting the URL or by IP Address and port number in IE

· The one that works is in the same domain

· Test servers for Document center are Cross domain

· User is able to check in same exact files through the browser GUI just fine

· Web App is claims based authentication

· Customer was able to reproduce the error on an additional test farm with the exact AAM settings as the other test farm and in production

· If using FQDN in SPD, it prompts for authentication over and over again on author.dll…401 Challenge on proxy level, not applying URL rewrite does not even go to SharePoint

Resolution: Remove WEBDAV Publishing component from IIS 7.0 Windows 2008 R2.

The WEBDAV component has also been known to cause the following issues

· Office Clients not uploading/saving to SharePoint Sites.

· Explorer View not working on Document Libraries and Lists (Saw this while troubleshooting during live meeting)

· Using UNC paths to access SharePoint lists or libraries does not work.

· Syncing with OneNote to SharePoint Libraries does not work.

· Office Documents opening in Read only mode.

· The following KB articles covers a few of the above listed issues

http://support.microsoft.com/kb/2018958

http://support.microsoft.com/kb/2171959/

The reason is that SharePoint has it’s own WebDAV and the IIS7 WebDAV publishing interferes with it. Unless the WebDAV publishing Role has been added to the Server for a specific reason, SharePoint should not need it. Note that removing WebDAV does require the server to be rebooted afterwards.  If you do a network trace between the client and the SharePoint server you will most likely see 405 events coming back when Office fails to save the documents to the SharePoint site.

Fight Comparison:
Definitely a team effort, I was scratching my head on this one. I’d have to say Leonard vs. Hearns I. Once Leonard figured out the Hitman’s game, he took him out in the 14th.

Problem: Site owner receives the following error when trying to use the ‘Import Spreadsheet’ option to create a list from Excel within SharePoint. Same error when trying to export existing list to Excel.

Resolution:
Note: although this worked in this specific scenario, it may not work in others. There are a lot of variables that I did not have time to drill down into, but lucky for me, the issue was resolve

- Verified user was using Excel 2010 32bit

- User was on a 64-bit machine

- Had the user download and install 2007 Office Data Connectivity Components: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23734

- Problem was still happening

- Had the user to an Office Detect & Repair and that solved the problem

Fight Comparison:

Morales Vs. Barrera III, both got the best of each other, but Barrera finally figured him out and turned it up in the last round.

Problem:

1. User browses to Project Center (/projects.aspx) using FireFox 9.0.1 and 8

2. Browser displays “The Web Part requires at least Microsoft Internet Explorer 7.0”

 
Resolution:
By design, seems that the wording in the technet article: http://technet.microsoft.com/en-us/library/ff631137.aspx, is a little confusing. It says “the Project Server 2010 Service Pack 1 update provides support for additional web browsers to access Project Web App pages that are most frequently used by team members”.

The highlighted text is the key.
Troubleshooting steps:

1. Installed FireFox 9.0.1

2. Reproduced the error above by browsing to /projects.aspx

3. Browsed to ‘Tasks’ and was able to browse successfully.

4. Consulted with Project Server PFE and he verified the same.

5. He pointed out that a Team Member is a role in Project server that can only access certain pages using FireFox 3.6.8+ according to the technect article: http://technet.microsoft.com/en-us/library/ff631137.aspx,

6. The pages are:
Project Web App (PWA) main default page (default.aspx)

All pages in the "My Work" section in the Quick Launch. This includes the following:

· Tasks

· Timesheets

Issues and Risks

Fight comparison:
This was Trinidad vs Vargas…after Vargas almost got knocked out in the opening round, he reached out to his corner and regrouped. He almost took down Trinidad, unlike him, I came out on top.

Problem: User had a 4 server (2 WFE/2 APP) SharePoint 2010 farm and IIS 7.0. User was able to install and bind the VeriSign certificate on one WFE but could not see it available for binding in IIS Mgr on the other remaining servers.

Resolution: User followed these steps according to this article: https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=SO9071

1. In Windows Press the Start and type MMC
2. In MMC Choose File->Add/Remove Snap-ins
3. Select Certificates on the Available Snap-ins and click the 'Add >' button, and select Computer Account->Local Computer Click OK
4. Expand Certificates/Personal/Certificates and right click it and choose All Tasks->Import.

Fight Comparison: Leonard vs Hagler…Leonard stole that fight…lucky for me the user figured this one out and I was able to close this

Problem:
Search is not working on your WSS 3.0 farm. Customer was receiving "No results were returned'. They had one web application and several site collections under it.

Environment Details:

• WSS: build level: 12.0.0.6545
• Windows 2003 OS – SP2 –x86
• SQL Server Version: 2005 – SP3 – x86
• Search is running on 2 different servers on 2 different search databases

Resolution:

• This customer had a ton of data (almost 2 TB and thousands of site collections), so we changed the indexing schedule for the search service to run once daily, instead of every 10 minutes that they had set
• Stopped the crawl on both servers with the following command:
  stsadm –o spsearch –action fullcrawlstop
• Verify that the crawl stopped by looking at the msscrawlurl table, see that it is no longer being populated

• We found the following error codes on already running crawls on different documents:
  Error 3 - "Some parts of this document cannot be accessed"

  Error 4 - "Content for this URL is excluded by the server because a no-index attribute

  Error 7 - "The file reached the maximum download limit. Check that the full text of the document can be meaningfully crawled.

• Started another crawl by this command:
  stasadm –o spsearch –action fullcrawlstart
• Looked at the msscrawlurl table to see that it was being populated, which means that the crawl is running

Fight Comparison:
This was Larry Holmes vs Ernie Shavers…I got beat up and knocked down a bit, but pulled through

Problem:  Customer needed to copy a workflow from one list/document library on a site collection to another list on a separate site collection. The best way is to create a reusable workflow from the beginning, but in this case the customer had upgraded to SharePoint 2010 from 2007 and hoped to reuse some already existing workflows he had created in SharePoint 2007.

Solution:

1. Download this tool from CodePlex: http://spwflmigrator.codeplex.com/
2. Extract it to one of your SharePoint Servers (it has to be run from one of your servers with an account that has access to your farm/DB)
3. double-click on 'MigrateWorkflow' file

1. This console will appear. Type the name of your SOURCE site, click 'Connect'.
2. Choose the workflow from the 'Workflow' drop down list from the 'Workflow' menu. The Associated list, Associated task list details will self-populate
3. Type the TARGET site url under the Target site URL field, click Connect
4. Choose the the list/document library you wish to copy the workflow to under the 'Associated List' drop-down menu.
5. Choose a 'Task List' to associate with the workflow

6. Click Copy Workflow

   Note: An error appeared for me that it could not open a file but it still worked after I bypassed it

1. Open the TARGET site in Sharepoint designer and click on 'Workflows'

2. Click on the 'workflow' you just copied over
   

   

3. Click 'Publish'

1. It is now available to be used on your TARGET site

   

    

 Fight Comparison:

This was a typical Larry Holmes fight, very tactical and drawn out but pulled through in the end.

Problem: Customer migrated to new hardware/software, from a SharePoint 2010 NTLM authentication farm to a SharePoint 2010 Kerberos authentication farm. Upon testing the sites, they were continuously prompted for authentication. No account, not even the farm account, could get in. There was no prompt for the test URL only for a couple of Production URLs that were tied to a couple of web apps.

Resolution: It was the bottom of the ninth inning, after lots of troubleshooting with various team members, it was decided to TURN OFF the problem. So this is not really a resolution but it allowed the customer to go live. I’ll follow-up with an update to this post once we determine what the root cause was. The steps below suppressed the authentication prompts for the time being.

• Build a new non-Kerberos web application with a blank Content Database
• Detach that Content Database
• Detach Content databases from old Web App and reattach to this new Web App

Fight Comparison:
This was Leonard vs Duran II…No Mas!! No Mas!!

Hi everyone,

My name is Sal Rosales and I joined PFE (Premier Field Engineering) in August 2011. I am a dedicated SharePoint PFE and hope that this blog will serve as a way to help the rest of you SharePoint warriors with issues you may come across with this massive beast we all love called 'SharePoint'.

Let the games begin,

Sal