I recently upgraded a SharePoint 2007 server to SharePoint 2010. As part of our solution we store files, for instance email (.msg) files on the SharePoint server. Once the migration was doen I tried to open a .docx, a .txt and a .png file from the SharePoint. All of those worked fine. However when I tried to open a .msg file the file wouldn't open. I was precented with the option to save the file or to cancel. Saving the file localy and then opening the file resulted in the mail opening.
Apparently there is a new security feature in SharePoint 2010. To enable opening of .msg files, and I asume other file types, you need to do the following:
1) Open Central Admin
2) Go to Manage Web Applications
3) Pick your Web Application
4) Choose General Settings
5) Find "Change Browser File Handling"
6) Change it from "strict" to "permissive"
Done.
Wednesday, June 1, 2011
SharePoint Compatibility range mismatch
We have a project where I'm going to migrate a SharePoint 2007 server application to a SharePoint 2010. We had done the content db migration 3 times for test purposes and we have had compleete success all those 3 times.
The other day we did the real migration. From and to the same servers we had done during our tests. No settings where changed between the test migrations and the production migration.
The migration gave no error messages, it reported success. All content was migrated. However, we could not browse to the application. The error message we got from the event log was:
"There is a compatibility range mismatch between the Web server and database "WSS_Content", and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range."
A search in google gave us a few possible solutions:
1) We checked that the correct patches (SharePoint 2007 SP2) was installed.
2) We where not running a beta version of SharePoint 2010.
3) We hade the correct rights to the WSS_Content db for the administrative user we where using
None of these solved our problem. We tride the migration 2 more times with the same result. We created a new site collection and tried the migration again with not much more luck. We got to the point where we where prompted for authentication three times then the page would fail to load.
After 3 hours of trying to solve the issue we browsed to the site not using Internet Explorer but instead using Chrome. using Chrome worked. We could browse our application. We quickly figured that the difference between IE 9 and Chrome must be Kerberos. Shutting down Kerberos in SharePoint alowed us to browse with IE 9 as well. So for some reason something had happend to the Kerberos settings during this migration.
We did not find anything amiss with our Kerberos settings in Sharepoint. Looking att the Kerberos settings outside of SharePoint we found out that Windows 2008 R2 uses an implementation called: SPNEGO2 this requires a SPN for the web application. This was however not the problem. Another article on the net told us that enabling kernel-mode authentication shouldn't be done since there are compatability problems with Internet Explorer 8. On a whim however we did enable kernel-mode authentication. All of a sudden everything worked.
The other day we did the real migration. From and to the same servers we had done during our tests. No settings where changed between the test migrations and the production migration.
The migration gave no error messages, it reported success. All content was migrated. However, we could not browse to the application. The error message we got from the event log was:
"There is a compatibility range mismatch between the Web server and database "WSS_Content", and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range."
A search in google gave us a few possible solutions:
1) We checked that the correct patches (SharePoint 2007 SP2) was installed.
2) We where not running a beta version of SharePoint 2010.
3) We hade the correct rights to the WSS_Content db for the administrative user we where using
None of these solved our problem. We tride the migration 2 more times with the same result. We created a new site collection and tried the migration again with not much more luck. We got to the point where we where prompted for authentication three times then the page would fail to load.
After 3 hours of trying to solve the issue we browsed to the site not using Internet Explorer but instead using Chrome. using Chrome worked. We could browse our application. We quickly figured that the difference between IE 9 and Chrome must be Kerberos. Shutting down Kerberos in SharePoint alowed us to browse with IE 9 as well. So for some reason something had happend to the Kerberos settings during this migration.
We did not find anything amiss with our Kerberos settings in Sharepoint. Looking att the Kerberos settings outside of SharePoint we found out that Windows 2008 R2 uses an implementation called: SPNEGO2 this requires a SPN for the web application. This was however not the problem. Another article on the net told us that enabling kernel-mode authentication shouldn't be done since there are compatability problems with Internet Explorer 8. On a whim however we did enable kernel-mode authentication. All of a sudden everything worked.
Subscribe to:
Posts (Atom)