Tuesday, November 2, 2010

2010 In-place Upgrade & Service Application HTTP 404 Errors

Granted the In-place Upgrade process that Microsoft has released with 2010 is a HUGE improvement over what they provided us with for a 2003-2007 in-place, I still cannot say I head over heals for it...

Lets start by talking about what SharePoint 2010 In-place upgrade does very well… The obvious attraction to an in-place (assuming your hardware and software meets minimum requirements) is that it will upgrade your configdb, web.configs, contentdb, split up your ssp to corresponding service apps in one quick swoop. It will even upgrade some of those pesky FAB 40 and other solutions you deployed.

Sound too good to be true? It can be… Be wary! Things are not always as they may seem. Unfortunately there are some situations where you may have corruption in your Search DB or SSP DB that you are unaware of (and are not reported in the preupgradecheck report). This will allow the SSP to split into corresponding 2010 service application and not report  errors, but not provision properly. A good sign that you have fallen victim is to try to start and stop the service app service. I found that I could not stop/start a some of my services from CA, and I could only accomplish the task via command line. To make things worse, deleting the service app and recreating leads to the same problem.

After struggling with this phenomenon I finally gave in and uninstalled 2007, uninstalled 2010, cleaned by the SQL instance, performed a clean install of 2010,launched the grey wizard (psconfig wizard), and launched the white wizard (2010 config wizard), created new web applications, and attached my content databases. This resolved my issues

In summary, though an in-place upgrade has its advantages when dealing with custom solutions. I am still a proponent of standing up a clean environment and utilizing the database attach method regardless.

SharePoint 2010 Document Type Icon

I recently finished up a 2010 upgrade for a client whom relied heavily on using the document type icon to open their document in their document libraries. It appears that this functionality is no longer supported in 2010 (even though it explicitly says in the ViewEdit.aspx page “Title- (icon linked to document)”.

There is good news! The fine community @ CodePlex have released a solution called “DocIcon”. You can download it from the following link:

http://docicon.codeplex.com/

This solution should really only be a temporary fix and NOT utilized in the long-term. Hopefully MS addresses this problem, but in case they do not release a fix to this problem- I would suggest using this temporary fix until you get all of your views updated.

Wednesday, September 22, 2010

MOSS 2007: People Search & All Sites Scopes Missing

I ran into a situation where after creating a new web application, site collection, and configuring the crawler “People Search” and “All Sites” was missing from the search scope. They existed in the top-level site collection search scopes but the only option available was “This Site:Intranet”.

Solution:

Rename the default “Search Dropdown” to something else, and create a new search display group name “Search Dropdown” (assuming your using english language packs). Make sure you specify to include People and All Sites in the scope group, and set your default scope.

Once you have recreated the scope, head into search settings and specify a custom scope page (using the default _layouts/ossearchresults.aspx works fine).

Tuesday, September 7, 2010

Error installing SharePoint 2010 RTM after uninstall of Beta

I decided to save myself some time by installing SharePoint 2010 RTM on a server that was previously running 2010 beta. Lets just say that it was not so short and simple…

License upgrade in Central Administration. LICENSE UPDATE FAILED

Install RTM over Beta. PSCONFIG FAILED

Uninstall beta and install RTM. PSCONFIG FAILED

Ok… Now what? Lets take a look at the event viewer…

Description:
Failed to create the configuration database.
An exception of type System.InvalidCastException was thrown.  Additional exception information: Unable to cast object of type 'Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection' to type 'Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection'.

Seriously?! A .NET error… Gimmie a break. After reregistering .NET I ran across another blog that addressed the issue.

http://www.sharepointassist.com/2010/07/14/geneva-error-exception-system-invalidcastexception-unable-to-cast-object-of-type-microsoft-identitymodel-configuration-microsoftidentitymodelsection-to-type-microsoft-identitymodel-configura/

SOLUTION:

Open the web.config file (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\Root) and manually update your .NET version from 1.0.0.0 to 3.5.0.0.

<section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

Create a new ConfigDB next time you run PSCONFIG.

Orphaned Application Pool in ConfigDB

I ran across a new type of orphaned data in the config database while at a clients the other day. I was in the process of adding a new SSRS server to a MOSS 2007 farm when it started failing on step 2 with the following error:

09/02/2010 22:17:33  8  ERR                      An exception of type System.InvalidOperationException was thrown.  Additional exception information: 1387
System.InvalidOperationException: 1387
   at Microsoft.SharePoint.Win32.SPNetApi32.NetLocalGroupAddMember(String groupName, String userName)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.AddGroupMember(String username, Int32 group)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionProcessIdentity(String strUserName, SecureString secStrPassword, IdentityType identityType, Boolean isAdminProcess, Boolean isWindowsService, String strServiceName, Boolean dontRestartService)

(After banging my head against my desk for a few hours)I took a look and see if the PSCONFIG wizard added any of the application pool to IIS. I noticed that it was attempting to provision a app pool that doesn’t exist! This typically would not be a problem, except that the identity account it was using was local to their WFE server!

At this point, I attempted to simply change the account to the DOMAIN web application account and re-run the PSCONFIG wizard. Aaannnndddd it failed again as it simply attemped to provision the app pool again with the wrong account. So I returned to the drawing board…

SOLUTION:

If you are still reading this then you really must need to resolve this issue. I will give you two methods. The second method below is to be done at your own risk. Please read carefully and take your time (or you might get yourself into a worse situation).

Your FIRST choice to solving this problem is to disconnect your your contentdb(s) from any production web application, disconnect each SharePoint server from farm, create new configdb, add each SharePoint Server BACK to the farm, recreate your web applications, and connect your content databases to corresponding their web apps.

Unfortunately, there also might come a day when you do not have a proper maintenance window available and you need to resolve this without interuption to your users… Below are instructions that directly query your SharePoint ConfigDB.

Manually query your configdb to retrieve the guid of your orphaned app pool.

select *
from objects
where name is not null

Review the list that returned- under the Name column you will see you orphaned app pool along with. Pay close attention to grab the one that says “SPApplicationPool” and copy the GUID from the ID column.

<object type="Microsoft.SharePoint.Administration.SPApplicationPool, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">

Now that you have your GUID- we can get out of the DB! Lets head to one of the SharePoint Server’s in the farm and run the following STSADM command.

stsadm –o deleteconfigurationobject –id <guid>

Monday, April 5, 2010

Page Cannot Be Displayed: Add to My Links

Symptoms:

You are in a Document Library, and you find a document that you want to add to your My Links. When you click to add the document to your My Links, you suddenly are greeted with a “Page Cannot Be Displayed” error.



Resolution:

On the problem Site Collection, navigate to the top-level Site Settings page and select “Portal Site Connection”. You need to add a “/” to the end of the address listed in the Portal Web Address.

‘Link to Document’ Content Type wants me to upload?

Symptoms:

You have decided add the ‘Link to Document’ Content Type to your document library, but its asking you to upload a document and NOT to link to a document…



Resolution:

Go to your DocLib’s Settings > Link to Document Content Type > Advanced Settings > and in the “Existing Document Template” field type ‘/_layouts/NewLink.aspx’