For some reason, SharePoint is thinking that Office Web Apps is missing on one server and wants me to install Office Web Apps on that particular server. This is not true as I ensured that I installed Office Web Apps on all the servers in the farm. Clicking refresh did not help!

I have seen similar error while installing SP1, in fact it was known issue while installing SP1 and the fix was running a PowerShell cmdlet which refreshes the list of installed SharePoint products. Here is what I did

Opened up SharePoint PowerShell Management Console and ran the following command

Get-SPProduct -Local

After running this command and clicking refresh, the SharePoint Config Wizard went through successfully.

Notice there is no user information drop down, I was trying to “Sign in as Different User” but I could not the see the drop down for “Sign in as Different User”. I asked around to see if anybody else had the same issue and looked like it was only me and only on my machine.  This was only happening in IE 8 and It was working fine on Firefox or Safari. I tried restoring my browser to default,  but it did not help. After some digging on Bing, I found this KB article from Microsoft.

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

Looks like if you have IE zoomed out past 100%, the tabs will be break. The fix is pretty simple, click on View -> Zoom -> 100%. This fixed the issue for me.

The ribbon looks pretty again!

Guess What? You do not see a “New Usage and Health Data Collection Service Application”

So How do you do it? Well You can create it by following this Technet Article. You need to navigate to Monitoring, Click on Configure Usage and Health Data Collection, check the box for “Enable usage data collection”, select the Events to Log, Put in the log file location, SQL information and you are done. Now you have Health Data Collection Service Application but if you navigate back to Manage Service Application Section, you see that the Usage and Health Data Collection Proxy is Stopped.  How do we start? I will get there in a Minute.

You can also create Usage and Health Data Collection Service Application by using Power Shell, here is the Syntax for it. I love Power Shell, so this is my preferred method.

New-SPUsageApplication -Name “UsageAppName” -DatabaseServer “DBServerName” -DatabaseName “DBName”

Even if you use Power Shell to create the Usage and Health Data Collection Service Application, if you navigate back to Manage Service Application, you see that the Usage and Health Data Collection Proxy is Stopped.

So to Start the Usage and Health Data Collection Proxy, use the Power Shell Command below

$Usage = Get-SPServiceApplicationProxy | where {$_.TypeName -eq “Usage and Health Data Collection Proxy”}

$Usage.provision()

This should get your Usage and Health Data Collection Proxy started, hopefully you will find some peace!

Event ID: 2587

The following conditions are currently affecting index propagation to this server for search service application ‘ Search Service’: 1. Query 0 has been disabled so that crawls can continue. It may be recovered via the Restart-SPEnterpriseSearchQueryComponent command in PowerShell.

It indicates that SharePoint 2010 Search Query Component has been disabled and it needs to be restarted, this might occur due to index corruption.  You might also see errors/warnings with Event ID 2581 and Event ID 74. When you get on to central admin and navigate to the Search administration screen, you might notice that the query component is disabled.

So How do you restart it? You can do it using the Restart-SPEnterpriseSearchQueryComponet, here it the power shell powershell script to do it

Add-PSSnapin Microsoft.SharePoint.Powershell

$S = Get-SPEnterpriseSearchServiceApplication -Identity ” Search Service Name”

$Q =$S.QueryTopologies

$C =Get-SPEnterpriseSearchQueryComponent -QueryTopology $Q.ActiveTopology

$C | fl Name,State

$C[0] |  Restart-SPEnterpriseSearchQueryComponent

Once you run the script, if you go back to central admin and search administration page, you would see the status of the query component change to recovering and eventually the status should change to online.

With the introduction of tagging features in SharePoint 2010, Microsoft wants you to use this tagging feature rather than using the MY LINKS. So whenever you are on a page that you visit often, if you click on the Tags and Notes short cut on the top, this page link is added to Tags and Notes under My Site. Well this pretty cool but some users like the flexibility of having the MY LINKS shortcut on every page instead going to their My Site.

So, How do you get My Links back? Follow this post by Laura Rodgers and you should be able to access your MY LINKS. I followed the second method and I have a link to MY LINKS on the Top Bar in My Site.

In SharePoint 2007, MY LINKS are stored in the SSP Database not in My Site Content Database. So, If you upgraded to SharePoint 2010 using database attach to a new Environment and lost all your MY LINKS, here is post by Shane Young on how to retrieve them.

As always thanks to Laura Rodgers and Shane Young for their support to the SharePoint Community.

The syntax for it is

STSADM -o preupgradecheck

When you run the Pre Upgrade Checker, you will get a report like this

There is a log file associated with the pre-upgrade check which you find at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.

You can run the pre-upgrade check, any number of times and it will not make any changes to your farm. Even if you are not upgrading to SharePoint 2010, you should do this because it will give you nice report of your SharePoint including the size of farm,  any large lists etc. I think this is a great tool.

The report has all links to various KB  articles which will help you in troubleshooting a the various issues in the report.

So now, how to fix the errors shown in the pre-upgrade checker. Here we go

The first issue is the Missing server file or server configuration issue. You can read about this error here.

Part 1: Fixing Missing Web Part Issues

If you look at the first part of this issues, the pre-upgrade check is telling you that some web parts are being referenced but they are installed on the server. It should look something like this

The following web part(s) are referenced by the content, but they are not installed on the web server

• Id = GUID, Type = Unknown, Reference = 2, Status = Missing

How to fix it? You got jump a few hoops to fix this issue.

First run this STSADM Command

stsadm.exe -o enumallwebs -includewebparts > N:\enumwebs.txt

Note: includefeatures, includesetupfiles, includewebparts, includeeventreceivers, and includecustomlistview were the new parameters for enumallwebs command included in the October 09 Cumulative Update

This would give you list of your webs in your farm and all the web parts installed.  Use CTRL F and search for MISSING which should show you the missing web part. It should look like this

The URL parameter next to web ID should lead you the web where this web part is missing.  Now to fix this web part, I followed the steps.

Go to the web part maintainance page, to do this add ?Contents=1 end the url.

For example: http://sitename/sites/site/default.aspx?contents=1

Thank You Shane Young for short cut, you can read more about the Maintenance here

You should see something like this

If you see the error, Select the error web part and delete it, this fixed one of my web part id error in pre upgrade check report.

If you don’t see the error, then you got a follow a longer way.

Consider my scenario, I have two farms; Farm A and Farm B.

We had a custom web part installed in Farm A but we never installed this web part in Farm B. We often move data from Farm A to Farm B using Export/Import, so I assumed that the data was referencing the custom web part in Farm even though we never installed this web part in Farm B. To prove my theory, I used few tricks.

Using the custom web part type name and assembly name we had on the Farm A, I was able to generate the GUID for the web part which matched with web part ID error on pre-upgrade check. To generate GUID I followed this blog.

Then installed the custom web part on the Farm B and this resolved one web part ID issue. To make sure, I ran the pre-upgrade check and this web part error was gone.

Part 2: How to Fix Missing Feature(s) Issue

If your data is referencing a feature and if the feature is not installed on the server, the pre-upgrade check will throw an error like below.

The following feature(s) are referenced by the content, but they are not installed on the web server

Name = Unknown, Feature id = GUID, Reference count = 43, Scope = Web, Status = Missing

These errors occur if you have faulty features in your Farm. You can delete these feature from the farm using Feature Admin Tool found here. This is a very handy tool, make sure you test before you remove these faulty features. Removing these features should fix most of the errors on the pre-upgrade check.

Hopefully this can help someone!

I am working on couple of upgrade projects and I will post any new findings.

Leave a comment if you have question.

One of my client (SharePoint 2007 Farm) had multiple site collections in a single web application and each site collection had its own database. In other words the web application had multiple content databases.

I wanted to upgrade the SharePoint 2007 farm to SharePoint 2010.

So I installed a SharePoint 2010 test farm and sat down to do the upgrade using database attach upgrade method

1. I restored the content database containing the top-level site collection (http://sitename/).

2. I tested the content database using Test-SPContentDatabase – No Issues

3. I mounted the content database using Mount-SPContentDatabase – No Issues

4. I was able to browse the top-level site collection – No Issues

5. Now, I restored the content database with the second site collection (http://sitename/teams/HR)

6. Tested and Mounted it – No issues

7. When I tried to browse the site, I could not. I was getting a 401 page.

8. After some troubleshooting I noticed the SharePoint has added the managed path as “Teams/HR” instead of just “Teams”. I deleted the managed path (“Teams/HR”)  and added “Teams” as wild card managed path.

This fixed the issue. Turns out that when you have custom managed paths and you are doing a database attach upgrade, you need to add the custom managed path through central admin. If you don’t, you will receive 401 pages just like me.

So, if you are upgrading using database upgrade method and your web application has multiple content databases, follow the steps below:

1. Run pre-upgrade check,

2. Test your content databases using Test-SPContentdatabase powershell commandlet, make sure there are no upgrade blocking issues.

3. Create a new web application on your 2010 farm.

4. Create custom managed paths if you have any in your SharePoint 2010 central admin

5. Mount the content database containing the top-level site collection followed by other site collections.

Make sure to test the upgrade on a test farm before you start playing with a live environment! Happy Upgrading!

Thanks to @ToddKlindt for steering me in the right direction!

Faulting application devenv.exe, version 9.0.21022.8, faulting module 47317b3d, version msenv.dll, fault address 0×9.0.21022.8.

The problem was fixed by uninstalling WSP builder, Installing SP1 for Visual 2008 and Reinstalling WSP builder 1.06.

WSP Builder works like a charm now!

If you are creating a new SharePoint 2007 Sequential Workflow Project or SharePoint 2007 State Machine Workflow using Visual Studio 2008, it will result in the following error

“Object reference not set to an instance of an object”

or

SharePoint site location entered is not valid. The SharePoint site at http://<serverpath> could not be found. Verify that you have typed the URL correctly”.

If you are using Visual Studio 2008 Service Pack 1 (SP1), then you will get the following message

A 32-bit version of SharePoint Server is not installed.Please install a 32-bit version of SharePoint Server.

Well, isn’t that great. Microsoft wants all of us to move to 64 bit architecture but does not support workflow development for SharePoint 2007 using Visual Studio 2008 on a 64 bit environment.

If you read the actual Visual Studio 2008 read me file, it mentioned that 64 bit is not supported for VSTO. But who reads the read me file?????

So whats the work around?

You can build and debug your Workflow solutions on a 32 bit machine and deploy them on a 64 bit machine. The solutions will work absolutely fine.

But the downside is that you need to maintain both 32 bit and 64 bit machines. Microsoft is not planning on supporting 64 bit work flow development using Visual Studio 2008, you can read all about it here and here.

I am exploring to see if you can use Visual Studio 2010 to do develop Workflow Solutions for SharePoint 2007 on a 64 bit environment! Will post on it at a later time.

Our SharePoint servers were recently rebooted, after this I started having the following errors in the event log.

The Application Server Administration job failed due to the reason ” The underlying connection was closed: An unexpected error occurred on a send”

Also the crawl status was error on the ssp admin site and the server status was as below

Could not connect to server ServerName for application ‘SSP Name’. This error might occur if the server is not responding to client requests, the firewall or proxy configuration is preventing the server from being contacted, or the search administration Web service is not running on the server.

I could not get to search settings and there was an error next the default content access account.

After some research, I found the cause for this the problem.

As everyone know, SharePoint search works through the Office Server Web Service, this web service uses has both HTTP (running off port 56737) and HTTPS (Running off port 56738) Protocols. When SharePoint is installed, no certificate will be available on HTTPS Port and sometimes servers will refuse to talk to each other especially in Windows Server 2008 R2 which has more stringent secure features.

A simple test to see if the servers are communicating with each other is to open the browser and type in http://servername:56737/SSP_NAME/Search/SearchAdmin.ASMX and https://servername:56738/SSP_NAME/Search/SearchAdmin.ASMX.

If you get the SearchApplicationWebService Page, you are good or it means the servers are not communicating with each other.

In my case, the servers were not communicating due to the certificate error. So whats the solution, I had to get a self signed certificate and install it for the Office Server Web Services Website. How can you do it? Follow the steps below

1. Download SSLDiag.EXE and install it,

2. Open up a command prompt and navigate to C:\Program Files (x86)\IIS Resouces\SSLDiag,

3. Type the follow command

SSLDiag.exe /SeflSSL /S:SiteId /V:730 /K:1024 /N:”CN=ServerName”

(You can get the Site ID for Office Server Web Services from IIS),

4. Hit enter and The cursor simply moves to the next line and you have self signed certificate,

5. Repeat this on your index server followed by your query server(s).

That’s it, now your servers should be communicating with each other and everything should be ok. Shoot me an email if you have any questions.