Showing posts with label Error 404 SharePoint. Show all posts
Showing posts with label Error 404 SharePoint. Show all posts

Thursday, 1 August 2013

Error 404 with Calendar Overlay across 2 Web Applications (part 2)

Hi all,

This is the reply that I’ve received this morning from our Vendor concerning the Calendar Overlay issues between multiple Web Applications: “it’s by design”.
So, no fix can be expected for this at the moment.

Therefore, I recommend educating the end user to open the item in the correct Web Application when needed.


You can find hereunder the complete explanation:


--------------------------------------------------------------- 
Hello Marc

As I also could repro the issue, MSFT did further research and found that this behavior is ‘by design’.
The issue has been addressed by the product group earlier and this was their answer :


It turns out it is by design:
=====================

We have conducted a thorough investigation into this matter and have determined the issue is Design Change Request in a feature area of substantial complexity. This complexity precludes making changes in this area outside of a major release.

The SharePoint calendar aggregation feature was designed to aggregate calendars within a single web application.
The calendar can aggregate across alternate access mappings, but not across apps. The alternate access mapping support did, however, make it appear that calendars could be aggregated across multiple web apps, but that is not a supported scenario. Adding support for cross web application calendar aggregation would involve significant feature work and as such, is not possible in a QFE.

Microsoft carefully reviews all Hotfix requests, as each code change must maintain or improve both quality and stability of the product.
In this instance, the risks to product quality and potential for destabilization are too high to permit changes in this area outside of a major release.

We thank you for bringing this issue to our attention and continuing to work with us on improving our products for customers worldwide.


The response is actually coming from the product group and they have no ETA on this nor if it will be fixed or not in future releases.
--------------------------------------------------------------- 



Voilà.


Wednesday, 31 July 2013

Error 404 with Calendar Overlay across 2 Web Applications (part 1)

Hi all,

Last week, I received a mail asking me if there was an issue with SharePoint.
The reported problem was that the client got an “Error 404” page when opening an item in her Overlay Calendar.

So, first thing first, is to reproduce the issue;

The client is using a calendar in her SharePoint Site (let’s call it TT2013MMA from the shpTeamCalendar Web Application).
Then she added the calendar of another site (let’s call it WW2013MMA from the shpWorkCalendar Web Application).

All is working like a charm, as the items of both calendars are correctly added, named in the TT2013MMA Calendar.

The problem start when you click on one of the items.
If the item is from the same calendar (the TT2013MMA), the details of this item is opened and can be reviewed/modified.
If the item is from the calendar located on the other Web Application (WW2013MMA), we got a nice looking 404-Error page not found.

I made some research, and I notice that doing calendar overlay across multiple Web Application gave the same problem.




So, at the request of Microsoft, I’ve reproduce with success the issue in my Test Farm with 2 brand new Web Applications.


Server name : test.domain\TestServerName

Tests were done with in both sites: test.domain\MyLogin (Mathot Marc)

Calendar of the second Web App : http://shpTeamCalendar-test.domain/sites/TT2013MMA


And the item added from this calendar are in green.

The overlayed calendar (from the second Web Application), is on this site : http://shpTeamCalendar-test.domain/sites/TT2013MMA
The items from the TT2013MMA calendar are in yellow.


Calendar using the Overlay in the shpWorkCalendar Web Application:



 Calendar from the second Web Application : shpTeamCalendar






Now, let’s check the URL pointing to the different items in the shpWorkCalendar:
                The URL is correct :
-          Web Application of the Calendar : shpWorkCalendar
-          Site (WW2013MMA) is created on the shpWorkCalendar Web Application



The URL of the item is incorrect:
-          Web Application of the calendar is shpWorkCalendar
-          Site (TT2013MMA) is created on shpTeamCalendar and NOT on shpWorkCalendar.
SharePoint is pointing to the source Web Application (shpWorkCalendar) instead of the correct URL where the item was created.





Same fort his second item :
                The correct URL must be : http://shpTeamCalendar-test.domain/sites/TT2013MMA/Lists/Calendar/DispForm.aspx?ID=2








And also for the last one:



  
Result on clicking on the NOK item, is a Error-404 page.


My vendor already made testing, and had the same results as mine.
Now, waiting for the Microsoft specialist to make the same tests, and give his feedback.



So, as far as from now, I have no solution, nor workaround.


... to be continued...

Wednesday, 16 November 2011

IIS 7.0 & Special Caracters in path of filename

Who was not faced to the error 404 page in SharePoint 2007 ?
Specially when the End User explain that his site is no more working?

Little debug, shows that the EU had the wonderfull idea to create a new folder for his documents (or a document) containing a special caracter : "+" sign.

The workaround that I found, was to rename the folder/file, and ask the EU not to use anymore those special caracters.

Yesterday, I had a post from Fabrice Romelard's blog explaning how to solve this issue, and the root cause of this issue : IIS 7.0 replace the + sign by a space in the URL, but shows the correct URL in your navigator.

The solution is to add into each Web.Config field of each SharePoint Web App, this line :

<requestFiltering allowDoubleEscaping="true" />


Then, I was faced to another problem : where to add this command when the "requestFiltering" is already used for the "requestLimits maxAllowedContentLength" command.



Simply write the section like this :

  <system.webServer>
    <security>
      <requestFiltering allowDoubleEscaping="true">
        <requestLimits maxAllowedContentLength="524288000" />
      </requestFiltering>
    </security>
  </system.webServer>


Hope it'll help, as all found exemple on internet shows all commands one by one, but not in the same Web.Config


That's all folks

Wednesday, 15 June 2011

Unable to Upload files larger than 28Mb : Error 404


For an unknown reason, I'm unable to upload files larger than 28Mb on a Sharepoint Site, and I got an "Error 404 Page" after 5 to 10 seconds, depending of the file's size.


But the strange thing, is that I'm able to upload the same file (same extension, size) on another Site and located on another Web App.


I tested with multiple upload, without any success for the larger file :



Next step was to check the SharePoint configuration, and specially concerning the erroneous Web App.
-          Maximum Upload Size is correctly set
-          Web Page Security Validation expiration time is also correctly set.


Now, it remains the IIS, ASP to be checked.

To do so, I googled a little bit and after a little cleaning, I was able to point 3 specific Microsoft documents:

The first had the exact problem that I was facing, but their solution gave me error after an IISReset.


And the second document, gave me the correct file to change :


I simply added the "<requestLimits maxAllowedContentLenght="52428800" />" under the 
"<requestFiltering>" node:

  















 The third documents is requesting to add a parameter into the "web.config" files in two places on the server :

     - First path : in the 12-Hive folder, under Template => Layouts



 

     - Second path : in inetpub, in the Web App folder
 


A IISReset later, let's test again :

Et voilà !


The 2 largest files are now on my SharePoint Site:

Nb1: Do not forget to change also on all your WFE servers.
Nb2: The manipulation was completely successfull in our Test Environment, but not in Production...
  ==>> Update : all is working.
  Issue was due because I forgot the add "<requestLimits maxAllowedContentLenght="52428800" />" parameter to the "applicationHost.config" file on the 2 WFE Servers (it was done on the CA Server only in Production)

That's all folks