Any of the following sound familiar?
- I’m getting an error when viewing my calendar. The error says, “The Web application at [your URL] could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.”
- My calendar view gives the error, “Unable to find specified web in the given URL – [URL].”
- When I try to edit my calendar overlay, I get a “File Not Found.” error message.
You’ve probably become a victim of the Calendar Overlay’s propensity to use fully qualified URLs. You’ll likely notice when you see the first error I gave above that the domain name given in the URL does not match the domain name you are browsing the page from. Unfortunately, Calendar Overlay won’t take a relative URL. (From a development standpoint, this only makes sense when you consider that the developer short-cutted his/her code writing. Bad. Just bad. There’s plenty of people talking about this–people who have surely been listened to by Microsoft–but that’s not the point of this blog. So, moving on.)
If you’ve extended your SharePoint web application or changed your Default zone’s domain name at any time, you’ve likely become a victim of the Calendar Overlay fully qualified URLs.
Aside from the errors given above, how can I tell? Using SharePoint Management Shell, take a look at the CalendarSettings property of your views:
$w = Get-SPWeb [your site URL]
$l = $w.Lists["[your list name"]"]
$l.Views | ? { $_.CalendarSettings -ne $null } | % { $_.CalendarSettings }
CalendarSettings is a string object that contains a serialized object (i.e. the string is XML). Within that XML string is a WebUrl
property like WebUrl="http://sppaule/Lists/Calendar/calendar.aspx"
. If the protocol and domain (ex: “http://sppaule”) don’t match the protocol and domain you browse from, you’ve got a problem (which is why you’re here reading this). From what I’ve read, both the protocol and domain must match.
“Okay, so they got me? Now what?” It’s really quite easy to fix. If you understood the PowerShell code above, you’ve probably got a really good idea of how to do it. Following is a script you can save to a .ps1 file and execute to update all the views across your entire web application. Just be patient when running it: there could be a lot of views to iterate through!
[cmdletbinding(SupportsShouldProcess=$true,ConfirmImpact="High")]
Param(
[parameter(Mandatory=$True,Position=1)]
[String]
$currentWebApplicationURL,
[parameter(Mandatory=$True,Position=2)]
[String]
$oldWebApplicationURL
)
PROCESS {
[bool]$do = $pscmdlet.ShouldProcess($currentWebApplicationURL);
if((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null){
$ver = $host | select version
if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}
Add-PsSnapin Microsoft.SharePoint.PowerShell
Set-location $home
}
if($do){
write-host "Updating CalendarSettings..."
$gc = Start-SPAssignment
$views = $gc | get-spwebapplication $currentWebApplicationURL | get-spsite -limit all | get-spweb -limit all | % { $_.Lists | % { $_.Views | ? { $_.CalendarSettings -ne $null -and $_.CalendarSettings -like '*'+$oldWebApplicationURL+'*' } }}
$views | % { $_.CalendarSettings = $_.CalendarSettings.Replace($oldWebApplicationURL, $currentWebApplicationURL); $_.Update() }
write-host $views.Count "views updated.";
Stop-SPAssignment -SemiGlobal $gc
} else {
write-host "Operation cancelled."
}
}
(Notice I include the loading of the SharePoint snapin just in case the file gets executed from a regular PowerShell session or the Windows PowerShell ISE–which I like to use for writing and debugging scripts.)
I saved mine on my desktop as “Update-CalendarSettings.ps1”. Then, simply execute the script like the following:
PS C:\Users\sppaule\Desktop> Update-CalendarSettings.ps1 [currentWebAppUrl] [oldWebAppUrl]
Replace [currentWebAppUrl]
with your web app’s Default zone URL (ex: “http://sppaule”) and [oldWebAppUrl]
with the protocol and domain that is incorrect in the CalendarSettings (ex: “http://paule”).
Note: This will replace all occurences of [oldWebAppUrl]
with [currentWebAppUrl]
within your whole CalendarSettings. I couldn’t think of any case where this would be bad for us, but you may know of some for yourself. If so, be sure to modify the Replace(...)
as necessary.
A few other tidbits of learning to consider:
- If you are using a Microsoft Forefront Unified Access Gateway, you may be saying, “Well, my browser protocol and/or domain don’t match what is in CalendarSettings. Why don’t I have a problem?” I wondered the exact same. It’s because Forefront UAG translates the protocol and domain for you. Your browser may show “https://extranet.sppaule.me”, but the request from UAG to the SharePoint farm is most likely something like “http://sppaule”. When SharePoint responds back, the UAG translates any “http://sppaule” URLs to “https://extranet.sppaule.me”.
- It wasn’t until researching this that I realized that ListViewWebPart views are actually stored on the SPList. They’re stored as Hidden views. Makes updating the CalendarSettings WebUrl paths across the board a lot easier.
Thanks Paul, this post is terrific! It saved me a lot of time.
I hope you don’t mind that I rewrote your script to make it easier to maintain,
http://fangdahai.blogspot.com.au/2013/12/powershell-script-to-fix-sharepoint.html
Don’t mind at all, Eric. Happy to have given you a basis for something that you were able to make even better.
—PaulE—
I am getting the same error but the $_.CalendarSettings is always null in SP2013. please suggest if I’m missing anything else.
$_.CalendarSettings is null for any view except an overlay view. I wrote this article based on my experiences in SP2013 (and thereafter confirmed the same worked in SP2010). So, it’s definitely not an issue that you are in SP2013. I would suggest making sure $_ is referencing a calendar overlay view.
I am having an issue with calendar overlay between site collections, but don’t have access to SP management shell. How can i detect if these settings are causing my error?
Try watching the network traffic to see the fully qualified URL that is being called for the various overlain calendars. You can do this with the browser’s dev tools (F12 in Chrome or IE) or Fiddler. Without access to the SP Management Shell, you obviously can’t fix the issue as described here. My only suggestion would be to go to the List Settings, delete the overlay view, and recreate it.
I don’t believe calendar overlays can be used across site collections.
In SharePoint online, I do not see the property $_.CalendarSettings. Are Calendar Overlays controlled by a different property?
Sorry, Steve, I do not know.