I just completed an in place upgrade of SharePoint 2007 to SharePoint 2010. What a crazy experience! Just when you think the upgrade was successful, you run into lots of errors! It took me quite a few days to iron out all of the issues and spent countless hours searching the Internet to find solutions. Here are just a few of the issues that I ran into, in no particular order. Maybe this can be helpful for others.
Application Event log error: “Load control template file /_controltemplates/TaxonomyPicker.ascx failed”
- Solution: Rename the 14\templates\controltemplates\taxonomypicker.ascx file. It is no longer used and shouldn’t even be there.
- See: Help Wanted: Taxonomy Picker
SharePoint error: Some or all identity references could not be translated
- Don’t use an account name longer than 20 characters
- Don’t delete an account without being sure it’s no longer in use somewhere in SharePoint
I want to upgrade a Web site from ASP.NET 2.0 to 4.0 without resetting IIS because it is running on a production server. The tool to do this is the ASP.NET IIS registration tool, aspnet_regiis.exe, which comes with ASP.NET 2.0 and 4.0. This tool doesn’t come with ASP.NET 3.0 and 3.5 because they’re both based on CLR 2.0. In fact, you don’t set a Web site or application to use ASP.NET 3.0 or 3.5, as IIS only knows about CLR version. See Scott’s Hanselman’s article for an excellent explanation. The .NET Framework version 4.0 comes with the new CLR 4.0 and so a new version of the tool is available.
Since I want to upgrade the Web site to ASP.NET 4.0, I’d run the 4.0 version of aspnet_regiis.exe, which is found under %systemroot%\Microsoft.NET\Framework\v4.0.303319. According to MSDN, to avoid interrupting IIS, I should use the -s switch to specify only the desired site or application as well as the -norestart switch to inhibit a restart. The value for the -s switch should be the path to the site; however, it may not be clear what this value should be.
To get a list of the paths and their registered ASP.NET version, I executed aspnet_regiis -lk and got the the following: Continue reading
I ran into an issue today with how the IIS 7.0 admin GUI deals with SSL certificates when assigning bindings to web sites. I had two websites that I was binding to the same IP address, but I was using different ports for each (including different ports for SSL). Even though I was using a different SSL port for the second website, it was telling me that my certificate was already in use by another website and that changing the setting would affect the other site. The strange thing was, I was using two completely different certificates. Why in the world would it tell me my certificate was in use on the other website, when it clearly was not? Changing the SSL settings on one site would end up deleting the settings on the other site. After searching online, I found out that there are some known bugs with how the admin GUI deals with bindings and SSL in general. By settings the bindings on the command line, I was able to work around the issue.
Below are some useful command line commands that can assist in creating SSL bindings manually.
To list SSL certificates in use, with their bindings: Continue reading
||Although this configuration works on Windows Server 2008 R2, it is unsupported by Microsoft. Use at your own risk.
Use these steps to install ASP.NET 1.1 on either Windows Server 2008 x64 SP2, or Windows Server 2008 R2.
- Follow all of the steps in How to install ASP.NET 1.1 with IIS7 on Vista and Windows 2008
- Then implement this workaround for an acknowledged bug: Workaround: Running ASP.NET 1.1 on Vista SP2/WS08 SP2
- Ensure that the “IIS Metabase Compatibility” Role Feature is installed in IIS
- Download and install:
- Make sure ASP.NET 1.1 is enabled under ISAPI and CGI Restrictions
- In my experience, this has already been enabled after installation
- Add this IgnoreSection handler to the <configSections> element on the .NET 1.1 machine.config, located in %windir%\Microsoft.NET\Framework\v1.1.4322\CONFIG
<section name="system.webServer" type="System.Configuration.IgnoreSectionHandler,
System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
You can get an application to your BlackBerry in four different ways.
- (OTA -Over The Air) Host the application files on a web server and browse to them from the phone
- put the application files onto a SD card and load it on the device
- load the application onto the phone using the BlackBerry Desktop Manager
- push the application to the phone using the BES
There are three different types of files that you will use to install the application on your phone.
You will need one or the other depending on the deployment metheod you are going with. These files hold the information on how to install the application on your phone what files are going to be needed to do that. Continue reading