Locale differences within WSS 2.0

Posted on 27/06/2008 by Alistair Hunt

‘The language is not supported on the server’ and SharePoint development.

I have recently been developing a C# Console Application to automate the upload process of existing documents from a folder structure into WSS 2.0. My development and testing had been going well especially considering this was my first taste of developing against SharePoint. When I ran my application on a test server the documents, and the relevant folder structures were created and uploaded successfully. The problems started to occur when I ran the application on the client’s server.

The application would not even create the initial site required to store the Shared Documents and just returned an error – The language is not supported on the server. Having been burned by so called ‘language’ issues before I first checked the Regional Settings for the server and they were identical to my test machine. Plan B – surf the net for a fellow techie who had encountered the same problem and solution. Although this error was well documented on the net it was more to do with the installation of SharePoint rather than developing against it. However, it did lead me down the righ path, namely then InstalledLanguages registry entry.

I tweaked my console application to display the list of sites within a SharePoint web and the associated Locale ID and it highlighted the reason for my error. On my test server the sites were configured with a Locale ID of 1033 (English – United States) but on the live server they were configured to use 3081 (English – Australia). The question was, how can I convince SharePoint to use the locale id of 3081.

The answer comes in two parts;

first of all I updated the registry on the live server. The key HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions6.0InstalledLanguages already had a REG_SZ value for 1033 so I added a second one for 3081.
The next task was to create the relevant folders in the SharePoint virtual directory for the site templates. To do this I made the following changes;
- Make a copy of the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATE1033 folder including all its contents and rename it to 3081.
- Make a copy of the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATEADMIN1033 folder including all it contents and rename it to 3081.
- Make a copy of the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATELAYOUTS1033 folder including all of its contents and rename it to 3081.
Restart IIS.

This now provides SharePoint with the template structure it needs to create new sites using the Locale ID of 3081. When I ran my Console Application this time the sites were created successfully and my Shared Documents folders now contained the uploaded files.

The request failed with HTTP status 403: Forbidden.

Posted on 27/06/2008 by Alistair Hunt

The request failed with HTTP status 403: Forbidden.

Following an unsuccessful Windows Update to a client’s server (not performed by me I hasten to add Smile

) I started to get these 403 errors when trying to access the Report Server via the web client. The Micsoroft CRM application that was also sitting on the server and utilising the Report Server was also displaying errors when I tried to view the reports that are included in the system.

After doing some Googl-ing I found someone else who had encountered a similar problem and the following solution also worked for me;

Within IIS on the server hosting your Reporting Services website, right click the ReportServer virtual directory and select Properties…
On the Virtual Directory tab select the Configuration… button
On the Mappings tab of the Application Configuration dialog take a look at the box containing Wildcard application maps (order of implementation).
Mine was missing the c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll entry. I also compared this setting against a similar server which had a working Report Server.
I add the c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll entry to the list and then restarted IIS.

Thankfully, this was a successful solution and my access to the Report Server was restored. My reports view in Microsoft CRM had not quite been resolved because I was being shown a different error – Reports.config has invalid schema, and could not be loaded. This issue is discussed in this blog entry.

Error trying to view reports in Microsoft CRM 3.0

Posted on 27/06/2008 by Alistair Hunt

Reports.config has invalid schema, and could not be loaded.

It seems that a client’s server that had recently had an update applied to it (by someone else

) had caused some of the configuration settings to be changed on my Microsoft CRM website. Although my CRM system was operational there were two significant issues that required investigation;

Warning notifications were appearing in the application event log of the server for the Microsoft CRM web application. For some reason it was throwing unhandled exception errors for an event source of ASP.NET 2.0.50727.0 – this was my first clue to the problem.
When I tried to view the reports available within Microsoft CRM through the browser I was presented with an error dialog containing Reports.config has invalid schema, and could not be loaded.

After some research and comparison to my test server it soon became obvious that my CRM website had changed its ASP.NET settings from 1.1.4322 to 2.0.50727.0. To restore it to its original settings I ran the following commands from the command line;

C:WINDOWSMicrosoft.NETFrameworkv2.0.50727aspnet_regiis -k w3svc/5/root
C:WINDOWSMicrosoft.NETFrameworkv1.1.4322aspnet_regiis -s w3svc/5/root
Perform an IIS reset.

The first command line removes the script maps to all versions of ASP.NET from all ASP.NET applications at the specified application root path and its subdirectories. The second command installs the script maps pointing to the ASP.NET ISAPI version, in this case v.1.1.4322, at the specified application path root and its subdirectories.

This solution stopped my unhandled exceptions from being generated in the event log and allowed me to view my reports within CRM again.

A couple of FYI’s for this process;

to find your application root for a web site you can run aspnet_regiis -lk. For my server the Microsoft CRM website was located at w3svc/5/root.
For information on ASPNET_REGIIS for v2.0.50727 please select this link – ASP.NET IIS Registration Tool (Aspnet_regiis.exe).
For information on ASPNET_REGIIS for v1.1.4322 please select this link – ASP.NET IIS Registration Tool (Aspnet_regiis.exe).

CRM Custom Attributes

Posted on 27/06/2008 by Alistair Hunt

‘Wrong value type is passed to the control…’ for CRM 3.0 Custom Attribute

Microsoft Dynamics CRM 3.0 is one of those applications that is amazing in its flexibility and power but can be frustrating when you are challenged by unexpected issues. Whilst working on some custom attributes for a CRM form today I started to get error being raised when I was saving information to one of these custom attributes. After a little surfing I found that other people had come accross this problem and it seems to stem from reusing a schema name for custom attributes.

For example;

create a custom attribute with a schema name of new_fieldname and assign it a field type of nvarchar.
add the new attribute to a form and publish the form.
remove the field from the form and then delete the attribute from the list of attributes.
create a second custom attribute with the same schema name but assign it a different field type e.g. float.
add the custom attribute back onto the same form and publish the form.
When you try to save data to the form you get the ‘Wrong value type is passed to the control…’ error.

The solution, or the one that I have found to work for me, is to make sure that after you delete the original custom attribute from the form you publish the form before you create the second attribute with the same name but different type. This allows CRM to completely remove any references to the original custom attribute.