We create all our site collections programatically with a custom site def/template. Everything works as expected, except for the crawler. It's apparently denied access to the sites. The crawl logs says:
http://server.localnetwork.lan/somesites/siteName
The object was not found. (The item
was deleted because it was either not
found or the crawler was denied access
to it.)
And in the log files I'm getting this:
08/11/2009 14:20:34.01 OWSTIMER.EXE
(0x0674)
0x1560 Search Server Common
MS Search Administration
7hmh High exception in
SearchUpgradeProvisioner Keyword
Config
System.InvalidOperationException:
jobServerSearchServiceInstance is null
at
Microsoft.Office.Server.Search.Administration.SearchUpgradeProvisioner..ctor(SearchServiceInstance
searchServiceInstance) at
Microsoft.Office.Server.Search.Administration.OSSPrimaryGathererProject.ProvisionContentSources()
If I create a site collection manually the crawler is able to access it. The same users/accounts have the same access on both sites, so that shouldn't be the issue.
The code we use to actually create the site collection looks a little like this:
SPWebApplication app = SPWebApplication.Lookup(new Uri("WebApplicationUrl"));
app.FormDigestSettings.Enabled = false;
app.Sites.Add("url", "title", "description", "language code", "SiteTemplateName", "Owner.Username", "Owner.Fullname", "Owner.Email");
app.FormDigestSettings.Enabled = true;
The code has been slightly altered to protect the innocent... ;)
Any idea what we're doing wrong?
(Please note, I'm not sure if this is a programming error or a config/setup error, so I'm cross-posting with Serverfault)
If you receive this error whilst the crawler account (the default content access account) has read permission to all your sites then you most likely need to disable the loopback check.
http://support.microsoft.com/kb/896861
http://koenvosters.wordpress.com/2009/06/15/access-denied-when-using-hostname-search-and-site-on-moss-2007/
Related
I have set up a SharePoint Online site and I have created a provider hosted app. One of the features of the app is to create subsites and there are times when a subsite needs to be renamed, including renaming the subsite URL. I can use the CSOM to create the subsite without any problems but when I try to rename the URL I get an access denied error. If I only change the title and description of the subsite there is no problem. If I log into SharePoint Online via the browser (using the same user account!) and I use the UI to rename the URL then it works without any problem. The page in SharePoint I use to rename the URL is https://tenant.sharepoint.com/testproject/_layouts/15/prjsetng.aspx
I have tried this on both a Microsoft 365 Developer subscription (where I am doing most of my development and testing) and the main SharePoint Online site where the solution will eventually be deployed to. I don't know much of the details for the main SPO site, other people set it up and I was provided an account to test renaming the subsite. To be clear, I am able to rename the subsite URL via the UI in both the developer and main SharePoint Online sites.
Is there something I'm doing wrong? Is there a limitation to renaming a subsite URL via code in SharePoint Online? Is there a bug in SharePoint Online that prevents renaming a subsite URL using code?
The exception thrown includes ServerErrorTypeName = "Microsoft.SharePoint.SPException". I can get the correlation id but from what I understand that's of no use in SharePoint Online. The exception Message is literally "Access denied." There is no inner exception.
Here is the code I'm using to rename the subsite:
SharePointContext spContext = SharePointContextProvider.Current.GetSharePointContext(HttpContext);
ClientContext clientContext = new ClientContext(spContext.SPHostUrl)
{
Credentials = new SharePointOnlineCredentials("SPUserName", "SPPassword".ToSecureString())
};
var webUrl = request.OldProjectUrl;
var subweb = clientContext.Site.OpenWeb(webUrl);
clientContext.Load(subweb);
clientContext.ExecuteQuery();
subweb.Title = request.ProjectName;
subweb.Description = request.ProjectName;
subweb.ServerRelativeUrl = "/HardcodedForTesting"; // <-- if I skip this line there is no error
subweb.Update();
clientContext.ExecuteQuery();
I was trying to achieve the same result but encountered the same error.
I was able to solve this by disabling the NoScriptSite setting of the site collection.
Using the PnP.PowerShell module:
Set-PnPSite -NoScriptSite:$false
Also the value you give to the ServerRelativeUrl property must be correctly constructed. I found two allowed format:
/sites/site-collection-path/new-subsite-path
new-subsite-path
Just did a test on my environment, I could rename the subsite URL via CSOM code normally. I use the same code as yours.
For your issue, you'd better create a service request with Microsoft.
I am an owner of a Sharepoint site and want to make sure all members of the site don't upload video files. Since SP doesn't have the ability to filter out files by Type - I want to use Microsoft Flow to do this task.
So I have created this flow which triggers on creation of new file in Documents folder of my SP site. Then it runs a Condition, which checkes the property of "File content type" - if it starts with "video/" - then it should delete the file uploaded. It looks like this:
#startsWith(triggerOutputs()['headers']['Content-Type'], 'video/')
But when I run this Flow, I then get this error:
BadRequest. The request failed. Error code: 'InvalidRequestContent'. Error Message: 'The request content was invalid and could not be deserialized: 'Unexpected character encountered while parsing value: {. Path 'details', line 1, position 455.'.'.
What am I doing wrong?
Unfortunately there is no OOTB way to configure these settings yet. Your workaround to create a flow is just what I would have suggested. Ofcourse you can also still create a workflow that does that but why old fashioned if you already made your experience with flow.
This is a known issue and I would encourage you to vote for that feature here.
In OneDrive you can restrict certain file types from syncing using the poweshell:
Set-SPOTenantSyncClientRestriction -ExcludedFileExtensions "wmf;mp4;mkv"
For your flow I would suggest to make an extra step "get file content" and use the content type you get there for your filter instead of the one from your "triggerOutputs"
If I use the GET statement:
https://graph.microsoft.com/beta/sites/root/sites/ then it correctly returns a list of sub sites under my main SharePoint site. But if I add a new Team Site sub-site to my main site and then run the same command it now returns
{
"error": {
"code": "itemNotFound",
"message": "The resource could not be found.",
"innerError": {
"request-id": "604af4de-b2b5-48cf-802b-1952a7d10b42",
"date": "2017-10-07T16:56:48"
}
}
}
When I delete the new sub-site the GET statement works again. I thought it was an issue with my SharePoint site so I reported it to Office 365 SharePoint support. They get the same error. It happens with Graph v1.0 and beta but is not in the Known Issues list.
I am trying to use this to get the Drive Id of a SharePoint library on a sub-sub site but cannot get past this issue on the problem sub-site. Is there any other way of getting a Drive Id of libraries on the sub-site that Graph at present seems unable to access?
Whilst the issue of Graph not being able to return a list of more than 7 sub-sites is still there, I have found a work around to enable me to get the Drive Ids of the Drives on the sub-sites. By using the /sites: /{sitepath} option (NB the colon) I was able to go directly to the required sub-sites and then get the relevant drive Ids.
I just wanted to follow up and say we have now made some improvements that should hopefully let these kinds of queries work past 7 subsites. So hopefully this issue is now resolved.
Workaround (v1.0 only) : use
https://graph.microsoft.com/v1.0/sites?search=*
as proposed here
I have an URL like https://crm.xxxx.com/XRMServices/2011/Discovery.svc and I want to discover an organisation with my client. But if I open this URL in a browser window, I will get an authorisation screen:
I get an exception, If I try to add this url on client to following method as parameter "url":
ServiceConfigurationFactory.CreateManagement<T>(new Uri(url));
Exception: Metadata contains a reference that cannot be resolved: "https://crm.xxxx.com/XRMServices/2011/Discovery.svc?wsdl".
or
Exception: Metadata contains a reference that cannot be resolved: "https://crm.xxxx.com/XRMServices/2011/Organisation.svc?wsdl".
How to pass through this authntication?
I don't think that's anything to do with CRM, but to do with the network setup. I would suggest speaking to the network administrators.
In the Site Collection level there is a Page library, which has been created along with the whole site. I didn't touch it for long time until recently I added new content types, modified some page layouts and master pages using a solution file. When accessing the home page using the site configured for anonymouse user it failed with "401 UNAUTHORIZED" error on the web page. I noticed the URL was /_layouts/AccessDenied.aspx?Source=...&Type=list&name={...} Then I copy this string to the site for authenticated user, it appears as "Error: Access Denied". I also checked the guid of name={...}. It's the page library list ID.
It seemed the page library permission is not correctly set. However the other page libraries of sub sites are all working well under anonymous user, using the same new content type, master page and page layouts. Their permission are identical on the settings page (all inherit from parent) and all have "allow anonymous" enabled.
I also tried create pages with other page layouts in that page library, clean up content types, all didn't help.
It's not the permission issue of the page library, rather it is related to the code I modified. SPContext.Current.Site.RootWeb is the the refernce by anonymous user. That user do not have privilege to access root folder. I assumed that SPContext.Current.Site.RootWeb.RootFolder.WelcomePage would work with elevated privilege, but after some reading I realized it's not elevate the privilege as I thought. Here's an explanation.
bool rtn = false;
SPWeb rootWeb = SPContext.Current.Site.RootWeb;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(rootWeb.Site.Url))
{
using (SPWeb web = site.OpenWeb())
{
rtn = web.Url + "/" + web.RootFolder.WelcomePage
== this.Page.Request.Url.AbsoluteUri;
}
}
});
return rtn;