While setting up a test environment I was attempting to set up many different types of sites for testing various things when I ran into a strange bug in SharePoint.
I was creating a subsite under a blank site template and saw the option for "News Site" so I selected it and got an error saying that the Publishing Feature was not enabled at the site collection level.
Fine. So, I went and activated it and then attempted to create the site again and I got the error:
The Web site address "/mpsite/news" is already in use
Ok, so the site must have been created anyway so I try to visit the URL and get:
The webpage cannot be found
Fine. So, obviously it errored in the middle of the site creation so I'll just delete it via STSADM. Wrong:
There is no top-level Web site named "http://server/mpsite/news/".
So, the site is listed in the sites and workspaces list, but doesn't really exist and can't actually be deleted.
How do I get rid of it from the Sites and Workspaces listing?
You've run into one of the lovely undocumented "features" of SharePoint - site templates get applied after the site gets created in a seperate, descrete step. This means that potentially, a site can "exist" (as far as the content database is concerned) without template, which leaves you with a site you can't browse to, but still sorta "exists" in SharePoint purgatory (I've actually written a couple of hacks that involve relying on this "feature").
It looks to me like you may have run into one such situation - when you went to go create your site, I'm guessing that you got the error before the template was applied to your news site.
The way I've fixed similar problems in the past has been to use SharePoint Designer to delete the sites - since it looks straight into the content database for what does and doesn't exist, it might do the trick for deleting your rouge news site.
Hope this helps!
Have you tried http://server/mpsite/news/_layouts/deleteweb.aspx ?
Or maybe the "Content and structure" (http://server/mpsite/_layouts/sitemanager.aspx) link from site actions?
I know this is old, but it may help somebody. In SP2013 running the Remove-SPWeb Powershell command with the url of the corrupted web worked perfectly for me.
Related
I am trying to work out how to host multiple sites on one instance of Umbraco, which is hosted on Azure. I've added the second domain as a custom domain on the Azure Web App. I've created two Home pages at the root of my Umbraco and set each to the appropriate hostname in 'Culture and Hostnames'. I can still navigate to the original site, but when I try to go to the second site I get the following error:
The call is ambiguous between the following methods or properties: 'Umbraco.Web.UmbracoHelper.Media(params int[])' and 'Umbraco.Web.UmbracoHelper.Media(params string[])'
No offending source code is identified.
I don't really know what I'm doing with this and try as I might I can't find any answers by googling the issue.
Got it. I had a Partial View that allows you to add some logos to the bottom of the homepage and as I was only doing a test run I hadn't added the logos in. So Umbraco was looking for images that weren't there and threw the error. Thanks for your pointer Mark.
Not quite sure what I've done to screw up SPD2010 (was working), but it displayed
Sharepoint Designer cannot display the item
What you can try:
Click refresh ... blah
Most likely causes
The file has been deleted from the site
The site is encountering problems
I can't see anything related in event viewer. I think is web service related as I think the queries are made via a WS?
In my case it wasn’t a solution. So, I made a backup of the site collection before to try anything. After a lot of time and different problems I figured out that some lists were causing the missreading. I tried one more time to get the lists in SharePoint Designer 2010 just to cause some entries in the log. After that I opened the log file and looked for something like: “Failed to determine the setup path of the list schema for feature {GUID}, list template XXX.”. With the GUID I looked for a match here. http://sharepoint-geek.com/2010/10/08/sharepoint-2007-moss-features/
With the feature name I used this blog: http://aurramu.blogspot.com/2011/03/failed-determine-setup-path-of-list.html.
With the feature re-installed I went to SPD and it worked like a charm.
I hope it helps someone else.
It appears this was caused by a "phantom" list definition. I experienced a number of other problems (some in SP some in SPD), all generating variations of this error;
<nativehr>0x8107058a</nativehr><nativestack></nativestack>
The problem list definition was deployed and undeployed from VS2010, so I have no idea why it was still around! The Sharepoint UI wont allow you to remove it (errors as above), so the trick is to use the stsadm powershell command with forcedeletelist as detailed here
http://technet.microsoft.com/en-us/library/cc262609(office.12).aspx
Hope this helps someone else !
Does anybody know how to find offending web part which causes this error ?
“A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe.”
I have inherited an old SharePoint 2003 portal site which uses custom web parts.
I know what this error means. I also know that each web part must be installed and registred as safe in web.config. The problem is that I don't know which one is missing.
I get same error when I'm trying to open the page in FrontPage as well.
Use contents=1 in QueryString to disable/remove WebParts from page that causes errors.
stsadm.exe -o enumallwebs -includewebparts
http://sharepointreporter.wordpress.com/
Requires updating to Sp2 I believe, for this command to be available. Problematic web parts will appear as 'Missing' in the resultant list.
Go to Event Viewer of the machine and you shall be able to see Error entries. Out of tons of entries you have to find out the entries related to you and you shall be able to see the names of the webparts that the sharepoint site is trying to load but fails. If you shall read the complete description of the error entry in the Event Viewer, it will give you version and even PublicKey Token of the webpart as well.
I hope this helps!!!
Try reading this:
http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=189
It should give you some clues to solving the problem. Essentially you have a control that is not marked as safe and it is failing. You can most likely config it to work, but the link above has other possible solutions.
in your url just append content=1. This will give you the all the webparts that are deployed. Now, you can keep deleting each of the webpart to find which one is causing issue ( ensure that you know to add the web parts back).
For example: if Url is http://localhost:9000/default.aspx, try with http://localhost:9000?contents=1
Alternatively, try to create a new webpart page,add web parts that are there on your actual page and check which one is causing issue. This will avoid changes to the actual page.
Hope this helps.
I've just suggested this same answer on MSDN:
This stsadm helped me in finding where the webpart was referenced in any way:
stsadm -o enumallwebs -includewebparts > C:\temp\somelog.txt
Then you can see the web part is listed under some <Web Id=... Url=...> XML node, i.e. you know the "culprit" web site.
At that point, some reasons I've found for those forgotten references:
the webpart is used in some sub-site of the culprit website, and the sub site is hidden from the quick list or top bar
the webpart has been deleted from the culprit website, but it still is in the "site collection recycle bin". You can reach that by going to the normal website recycle bin, then look for its link on the top bar description ("Use this page to restore items that..."). By the way, this site collection recycle bin has two views itself: be sure to check them both.
In both cases, I got some help by browsing the culprit website with SharePoint Manager. With that I could easily spot the existence of a forgotten subsite, as well as the existence of this "second level recycle bin".
HTH
I'm trying to get crawl to work on two separate farms I have but can't get it to work on either one. They both have two WFE's with an additional WFE configured as an Index server. There is one more server dedicated for Query and two clustered SQL 2005 back end servers for the database. I have unsuccessfully tried at least 50 different websites that I found with solutions from a search engine. I have configured (extended) my Web App to use http://servername:12345 as the default zone and http://abc.companyname.com as the custom and intranet zones. When I enter each of those into the content source and then try to run a crawl, I get a couple of errors in the crawl log:
http://servername:12345 returns:
"Could not connect to the server. Please make sure the site is accessible."
http://abc.companyname.com returns:
"Deleted by the gatherer. (The start address or content source that contained this item was deleted and hence this item was deleted.)"
However, I can click both URL's and the page is accessible.
Any ideas?
More info:
I wiped the slate clean, so to speak, and ran another crawl to provide an updated sample.
My content sources are as such:
http://servername:33333
http://sharepoint.portal.fake.com
sps3://servername:33333
My current crawl log errors are:
sps3://servername:33333
Error in PortalCrawl Web Service.
http://servername:33333/mysites
Content for this URL is excluded by the server because a no-index attribute.
http://servername:33333/mysites
Crawled
sts3://servername:33333/contentdbid={62a647a...
Crawled
sts3://servername:33333
Crawled
http://servername:33333
Crawled
http://sharepoint.portal.fake.com
The Crawler could not communicate with the server. Check that the server is available and that the firewall access is configured correctly.
I double checked for typos above and I don't see any so this should be an accurate reflection.
One thing to remember is that crawling SharePoint sites is different from crawling file shares or non-SharePoint websites.
A few other quick pointers:
the sps3: protocol is for crawling user profiles for People Search. You can disregard anything the crawler says about it until you're ready for user profiles.
your crawl account is supposed to have access to your entire farm. If you see permissions errors, find the KB article that tells you the how to reset your crawl account (it's a specific stsadm.exe command). If you're trying to crawl another farm's content, then you'll have to work something else out to grant your crawl account access. I think this is your biggest issue presently.
The crawler (running from the index server) will attempt to visit the public URL. I've had inter-server communication issues before; make sure all three servers can ping each other, and make sure the index server can reach the public URL (open IE on the index server and check it out). If you have problems, it's time to dirty up your index server's hosts file. This is something SharePoint does for you anyway, so don't feel too bad doing it. If you've set up anything aside from Integrated Windows Authentication, you'll have to work harder to get your crawler working.
Anyway, there's been a lot of back and forth in the responses, so I'm just shotgunning a bunch of suggestions out there, maybe one of them is on target.
I'm a little confused about your farm topology. A machine installed as a just a WFE cannot be an indexer. A machine installed as "complete" can be an indexer, query and/or a wfe...
Also, instead of changing the default content access account, you may want to add a crawl rule instead (once everything is up and running)
Can you see if anything helpful is in the %commonprogramfiles%/microsoft shared/web server extensions/12/logs on your indexer?
The log file may be a bit verbose, you can search for "started" or "full" and that will usually get you to the line in the log where your crawl started.
Also, on your sql machine, you may be able to get more information from the MSScrawlurlhistory table.
Can you create a content source for http://www.cnn.com and start a full crawl? Do you get the same error(s)?
Also, we may want to take this offline, let me know if you want to do that.
I'm not sure if there is a way to send private messages via stackoverflow though.
Most of your issues are related to Kerberos, it sounds like. If you don't have the infrastructure update applied, then Sharepoint will not be able to use kerberos auth to web sites w/ non default (80/443) ports. That's also why (I would bet) that you cannot access CA from server 5 when it's on server 4. If you don't have the SPNs set up correctly, then CA will only be accessible from the machine it is installed on. If you had installed Sharepoint using port 80 as the default url you'd be able to do the local sharepoint crawl without any hitches. But by design the local sharepoint sites crawl uses the default url to access the sharepoint sites. Check out http://codefrob.spaces.live.com/blog/cns!7C69E7B2271B08F6!363.entry for a little more detail on how to get Kerberos & Sharepoint to work well together.
In the Services on Server section check the properties for the search crawl account to make sure it is set up, and that it has permissions to access those sites.
Thanks for the new input!
So I came back from my weekend and I wanted to go through your pointers and try every one and then report back about how they didn't work and then post the results that I got. Funny thing happened, though.
I went to my Indexer (servername5) and I tried to connect to Central Admin and the main portal from Internet Explorer. Neither worked. So I went into IIS on ther Indexer to try to browse to the main portal from within IIS. That didn't work either and I received an error telling me that something else was using that port. So I saw my old website from the previous build and I deleted it from IIS along with the corresponding Application Pool. Then I started the App Pool for the web site from the new build and browsed to the website. Success. Then I browsed to the website from the browser on my own PC. Success again. Then I ran a crawl by the full URL, not the servername, like so:
http://sharepoint.portal.fake.com
Success again. It crawled the entire portal including the subsites just like I wanted. The "Items in index" populated quickly and I could tell I was rolling.
I still cannot access the Central Admin site hosted on servername4 from servername5. I'm not sure why not but I don't know that it matters much at this point.
Where does this leave me? What was the fix?
I'm still not sure. Maybe it was the rebuild. Maybe as soon as I rebuilt the server farm I had everything I needed to get it to work but it just wouldn't work because of the previous website still in IIS. (It's funny how sloppy a SharePoint un-install can be. Manual deletion of content databases, web sites, and application pools seem necessary and that probably shouldn't be the case.)
In any event, it's working now on my "test" farm so the key is to get it working on the production farm. I'm hopeful that it won't be so difficult after this experience.
Thanks for the help from everyone!
I have some custom SharePoint site definitions that are deployed via SharePoint wsp solution packages. They appear to work fine. I can deploy them fine via the stsadm command line, and my C# code running in some features can also deploy sites based on them. My webtemp.*.xml files appear to be correctly placed in the 12\1033\XML folder when my solutions are deployed. My problem is that they just don't show up in the central admin app when I try to Create Site Collection. Why not? I don't even know where to look for this.
EDIT:
Hmmm.. About an hour later I happened to go back to the create site collection page and my templates were there. I'm not sure what was up... weird caching somewhere or something.
I also should have been more clear that these solution packages had been successfully deployed many times on my dev box, so I didn't expect there to be a problem (with the deployment aspect anyway) on this other server.
Many tasks in SharePoint are queued and then executed via timer job. An IISReset causes the web applicationt to be reloaded into memory and for configuration information for example the web.config to be reloaded.
To give SharePoint a "nudge" and cause jobs to execute you might try:
stsadm -o execadmsvcjobs
Do you have the publishing feature enabled? I read that content types can't be saved in templates, so they don't allow publishing sites to be made into templates. This is perhaps linked to why they won't show you the ones you already made.
Although I don't have access to a central admin to verify, this is the case from within my site collection.
Did you forget to run iisreset ?
This is needed for SharePoint to reload site templates.
If you use the Record Center as the template for your root website, templates (.stp files) in your template library will not show up when creating a new list.
There is some weird bug that makes this happen.
Here is code that you can try running in the SharePoint PowerShell. The return value for GetCustomListTemplates($web).Count will be zero if you have the root web made from the Record Center template.
$site = get-spsite("http://localhost")
$web = $site.RootWeb
$list = $web.Lists["TestDocLibrary"]
$list.SaveAsTemplate("MyListTemplate.stp", "MyListTemplate", "My List Template", $false)
$site.GetCustomListTemplates($web).Count
More information can be found at the following links:
http://social.msdn.microsoft.com/Forums/ar/sharepoint2010general/thread/c5455a27-360a-465c-91d5-f81beeac6789
http://sharepointrecordsmanagement.com/2011/02/