MOSS 2007 and .NET Framework 3.5 SP1

At one of our customers we had to faced with a very-very sneaky trouble.

The environment: Windows Server 2003 SP2 x64, with MOSS 2007 Enterprise, and of course .NET framework 2.0 and 3.0. The SQL Server 2005 is installed to a separated hardware. The farm is a test environment on the customer side, with almost 1 year on-time: this is the integration "bridge" between our dev environment and the customer's production one. Every solution is deployed to this server first, here are the user acceptance tests, and after the acceptance they'll be deployed to the production farm.

As we wanted to use Linq4SP in a new solution, we needed the .NET framework 3.5 too.In our developer environment everything was working well, so let's go to the customer. The administrator guy installed us the .NET framework 3.5 SP1. The solution was deployed successfully, so everything seemed to be going well and good. But during the testing we had to be faced that the Records Center wasn't working. The error message: "The DevRC Records Center could not be found or accessed."

I could exclude Records Center (RC) configuration errors, as it was working before. But I had to be sure that it's not an error on the RC side, so started to some tests:

  1. I changed the Records Center settings on the Central Administrations, and set one other RC to the default. Same error.
  2. During a former project we've developed a custom Records Center Web Service and changed the orginal one to that. So I installed it to this server as well and set it to the default instead of the OOTB one. Same error, and our web service haven't received any request.

These facts show me clearly: the error is occured during sending documents to the RC, and not on the receiving. But what the hell is the real cause?…

Let's uninstall the .NET framework 3.5, but don't do anything with 3.0 and 2.0 – Records Center error occured again. OK, that's not enough, but as we assumed that the RC error is occured by something around .NET frameworks. So go forward: uninstall .NET fw. 3.0, then .NET fw. 2.0, finally install them again (first the .NET fw. 2.0, then .NET fw. 3.0). – Oh yes, this is a very good idea, but this step is also attacking the SharePoint itself. It's not a big surprise that the MOSS was capitulated, the IIS can't handle the requests even after running Config Wizard.

First of all: Allow the ASP.NET 2.0 in the IIS. (The default setting is Prohibited after installation…)

Wow, Central Administration became accessible now! But unfortunately the content sites drop HTTP 403 error, even after IISRESET. So the sites are alive, but unavailable to access them because some authentication issue – moreover this happens in the backend, so something went wrong in the IIS or SQL. Well, at this customer we hadn't access to the SQL server directly, and the MOSS admin user is not permitted to create new databases – so we're unable to create new Web Application to the MOSS. Hmmmm… One more option to testing the issue is extend one of the existing Web Applications. Let's choose this option, and extend our existing (but unable to work) Web App on http://dev:80, for example in the Intranet zone, to the http://dev:12345 address. Yes, this new Web App is working!

And here is the surprise: the old http://dev:80 is working again!

I don't know exactly what happened, but I think the SharePoint ran into some configuration issue that occurs an inconsistency before the Web App extending. But after that step this "something" has been set to the corrent value.

Short test: yes, the Records Center works fine. After deleting http://dev:12345 we have the same environment as before the full game. Let's go to reproduce the issue!

But now I was trying a little modified scenario: first I installed the "plain" .NET framework 3.5, without SP1. Well, the Records Center works on. But just after installing SP1 for .NET 3.5, the RC immediately became dead.

Well, the conclusions: in x64 environment, the MOSS Enterprise and .NET framework 3.5 SP1 can be conflicted. As I have any further information about the status of this issue, or maybe about a hotfix to it, I'll inform you immediately!

Leave a Reply

Your email address will not be published. Required fields are marked *