Overview
I am observing a really strange behaviour with code which attempts to retrieve the TermStore from the TaxonomySession. The code looks like this:
using (SPSite mySite = new SPSite(url))
{
TaxonomySession session = new TaxonomySession(mySite);
// Get all the TermStores associated with the provided site.
TermStoreCollection stores = session.TermStores;
Console.WriteLine(stores.Count);
Here is the issue:
The above code does not return any TermStores, i.e. the count is zero
If I run the following PowerShell script from the same command prompt, I get 1 TermStore in the count.
$site = new-object Microsoft.SharePoint.SPSite("https://mysite")
$session = new-object Microsoft.SharePoint.Taxonomy.TaxonomySession($site)
$session.TermStores.Count
I have tried the following:
My Managed Metadata Application Proxy is a part of the default proxy group
The administrator for the Managed Metadata Service is configured correctly
The permissions for the Managed Metadata Service are configured correctly
The Managed Metadata application pool is running under the farm account
Modifying the code above to run under elevated privileges
The weird thing is that the first block of code above DOES NOT retrieve any TermStore(s) when compiled as an executable and invoked from a command window, which is running under the farm credentials. IN THE SAME window, I can copy and paste the second block of the equivalent PowerShell scripts and have it run!
Also, this issue is only happening on our Production environment. The same executable ran successfully on our DEV, TEST and Pre Prod environments.
Any help at this stage will be much appreciated.
We encountered exactly the same issue in our test environment. But, our development servers are working as expected. My colleague was able to narrow down the issue and resolve it by updating hotfix available in Microsoft support.
The following are the details of the hotfix and information he could come across while researching on that particular issue.
Support download link
For additional information:
http://chrisforbesblogs.net/2009/12/02/the-managed-metadata-service-or-connection-is-currently-not-available
http://expectedexception.wordpress.com/2011/06/15/the-managed-metadata-service-or-connection-is-currently-not-available-the-application-pool-or-managed-metadata-web-service-may-not-have-been-started-please-contact-your-administrator/
Please consult your system administrator before updating any hotfix to servers. Hope this help you to fix the issue in your production environment.
Related
I have a function that generates a PDF from a HTML page like this:
HtmlToPdf converter = new HtmlToPdf();
PdfDocument doc = converter.ConvertUrl(url);
var PdfArray = doc.Save();
doc.Close();
This works perfectly when I run it in VS 2017, However when I deploy to IIS it throws the following exception: "Conversion failure error 5."
According to my Googling this is related to the IIS not having the correct access to write. However I have as an attempt given that application access to every operation.
All suggestions would be greatly appreciated.
From the troubleshooting page on SelectPdf website:
https://selectpdf.com/docs/Troubleshooting.htm#item3
The error code is this:
ERROR_ACCESS_DENIED
5 (0x5)
Access is denied.
Enable execute permissions on Select.Html.dep.
You need to go to the bin folder of your deployment to IIS and set execute permissions for the Select.Html.dep file. If you do not know the app pool user, in the first place, just set permissions for Everyone to see if it works.
When I try to open a form published from InfoPath I now get this error:
"The following location is not accessible, because it is in a different site collection:
https//portal/sites/forms/Daily%20Activity/Forms/template.xsn?SaveLocation=https//portal.alamedacountyfire.org/sites/forms/Daily%20Activity/&Source=https//portal.alamedacountyfire.org/sites/forms/Daily%2520Activity/Forms/AllItems.aspx&ClientInstalled=false&OpenIn=Browser&NoRedirect=true&XsnLocation=https//PORTAL/sites/forms/Daily%20Activity/Forms/template.xsn."
Correlation ID:12c0ab9c-caff-80a8-f1b4-64d81dcfa6ea
Following are some options that you can try:
1) Save the form template (.xsn) as the source files in the publish options. Look at the manifest file in notepad and see if you can find a reference to the incorrect location. If so, correct it and Republish the form.
2) Clear the InfoPath cache on that machine. Start->Run "infopath /cache clearall"
3) See if the site collection has a managed path, if so, give the proper url while publishing. The XSN might be getting deployed on the root site and throws error since the intended list does'nt exist.
I found this worked for me. Got the answer from another post.
"I had a similar problem and found it was due to the request management service routing from my web application host header to the server name.
There was a routing rule in my request management settings. I just disabled routing and the problem went away. I used the following powershell to disable it. "
$w = Get-SPWebApplication "http://webapphostname"
$r = $w | Get-SPRequestManagementSettings
$r.RoutingEnabled = $false
$r.Update()
You may want to configure it rather than disable it. Here’s a good resource to get you started:
http://www.harbar.net/articles/sp2013rm1.aspx
I have a problem I hope someone might help me with.
I've created a custom action page where I among other things will scan a directory on a remote server for a set of directories, and inside those directories I am searching for a set of files.
However, when I execute the code on the production server I get an Access denied exception.
If I use the same code on my testserver (accessing the same remote server) it works just fine.
If I use powershell or explorer on the production server I can access the remote directory and files with no problems.
I am using the same account in all scenarios (if I print out Page.User.Identity.Name and SPContext.Current.Web.CurrentUser.LoginName they are the same and equal to the account I use on the test server and the one I am logged on with on the production server when accessing the remote server from command line or explorer).
The code looks like this:
string user = SPContext.Current.Web.CurrentUser.LoginName.Remove(0,7);
string user_path = "\\\\srv\\share1\\subdir\\dir\\" + user;
// The line below will raise an exception on the production server.
foreach (string board_path in Directory.GetDirectories(user_path, "Board*")) {
foreach (string board_file in Directory.GetFiles(board_path, "Board*.xml")) {
.
.
}
}
I cant figure out why the code runs on the testserver but not on the production machine. I am using SharePoint 2010 Standard.
Thanks in advance for any kind of help I can get.
/Fredrik
The problem was solved by using SPSecurity.RunWithElevatedPrivileges()!
/Fredrik
I have a simple PowerShell script that uses WMI to create a web site on a Vista box. Yes, I know PowerShell has an IIS provider for working with IIS 7, but this script must also support IIS 6.0, so that rules that out.
Anyway, the script was working just fine, but all of the sudden (and I mean that literally, I made zero code changes to the script) it started creating a second, broken site for every call to the CreateNewSite method. Below is the script. Anyone have any ideas?
$path = "C:\My Path\WebSite"
$site = "TestSite"
$hostHeader = "demo.blah.com"
$service = Get-WmiObject -namespace "root\MicrosoftIISv2" -class "IIsWebService"
$bindingClass = [wmiclass]'root\MicrosoftIISv2:ServerBinding'
$bindings = $bindingClass.CreateInstance()
$bindings.IP = ""
$bindings.Port = "80"
$bindings.Hostname = $hostHeader
$result = $service.CreateNewSite($site, $bindings, $path)
The above script was just creating a site named 'TestSite', but now it's also creating a site called 'SITE_1786339847' (the number changes, but it's always similar to that). I have stepped through the script executing one line at a time, and neither site is created until the CreateNewSite method is invoked. Is WMI just buggy?
Whoops, answered my own question. I checked the raw IIS 7.0 configuration file and found an orphaned virtual directory that was associated to a site with the ID 1786339847. When I removed that virtual directory from the configuration file, the script started working correctly again.
In case anyone runs into something similar, grab the site ID for the bad site from IIS Manager before deleting it, then open up C:\Windows\system32\inetsrv\config\applicationHost.config. Scan the file for that ID and look for any orphaned references to it. Be sure you have a backup first.
This is a question for a WSS/SharePoint guru.
Consider this scenario: I have an ASP.Net web service which links our corporate CRM system and WSS-based intranet together. What I am trying to do is provision a new WSS site collection whenever a new client is added to the CRM system. In order to make this work, I need to programmatically add the managed path to the new site collection. I know that this is possible via the Object Model, but when I try it in my own web service, it fails. Sample code extract below:
Dim _ClientSiteUrl As String = "http://myintranet/clients/sampleclient"
Using _RootWeb As SPSite = New SPSite("http://myintranet")
Dim _ManagedPaths As SPPrefixCollection = _RootWeb.WebApplication.Prefixes
If Not (_ManagedPaths.Contains(_ClientSiteUrl)) Then
_ManagedPaths.Add(_ClientSiteUrl, SPPrefixType.ExplicitInclusion)
End If
End Using
This code fails with a NullReferenceException on SPUtility.ValidateFormDigest(). Research suggested that this may be due to insufficient privileges, I tried running the code within an elevated privileges block using SPSecurity.RunWithElevatedPrivileges(AddressOf AddManagedPath), where AddManagedPath is a Sub procedure containing the above code sample.
This then fails with an InvalidOperationException, "Operation is not valid due to the current state of the object."
Where am I going wrong?
One workaround I have managed to do is to call out to STSADM.EXE via Process.Start(), supplying the requisite parameters, and this works.
Update: whilst developing the web service, I am running it using the built-in Visual Studio 2005 web server - what security context will this be running under? Can I change the security context by putting entries in web.config?
Update: I think the problem is definitely to do with not running the web service within the correct SharePoint security context. I decided to go with the workaround I suggested and shell out to STSADM, although to do this, the application pool identity that the web service runs under must be a member of the SharePoint administrators.
Update
I think you have proved that the issue is not with the code.
SPSecurity.RunWithElevatedPrivileges: Normally the code in the SharePoint web application executes with the privileges of the user taking the action. The RunWithElevatedPrivileges runs the code in the context of the SharePoint web application pools account (i think)
The description on MSDN could go into the details a tiny bit more.
The issue with the call may be that the web service is not actually running the code within a SharePoint process, so explaining why it cannot elevate (wild guess alert).
Have a crack at changing the user of your web services application pool and see if that gives any joy.
It is likely to be a permissions issue.
Maybe try:
Dim clientSiteUrl As String = "http://myintranet/clients/sampleclient"
Using SPSite = new SPSite(clientSiteUrl)
webApp As SPWebApplication = SPWebApplication.Lookup(new Uri(clientSiteUrl));
If Not (webApp.Prefixes.Contains(clientSiteUrl)) Then
webApp.Prefixes.Add(clientSiteUrl, SPPrefixType.ExplicitInclusion)
End If
End Using
This is not exact code.
Since the above code is not the exact code, here is the exact working code for a Web Application scopped feature in the Feature Activated event:
On feature activation at the Mange web application features page, activate feature will create a new Explicit managed path in the specified web application (I want to replace the hard coding, maybe with Properties.Feature.Parent, or something similar.)
using (SPSite site = new SPSite("http://dev-moss07-eric/PathHere")) {
SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://dev-moss07-eric"));
if (webApp.Prefixes.Contains("PathHere"))
{
//
}
else
{
webApp.Prefixes.Add("PathHere", SPPrefixType.ExplicitInclusion);
}
}
Code can probably be improved, but its my attempt at converting the above code.
If you want to create a managed path (explicit) and a site collection at that path, do the following:
using (SPSite site = new SPSite("http://dev-moss07-eric")) {
SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://dev-moss07-eric"));
if (webApp.Prefixes.Contains("ManagedPathHere"))
{
//
}
else
{
webApp.Prefixes.Add("ManagedPathHere", SPPrefixType.ExplicitInclusion);
}
using (SPWeb web = site.OpenWeb())
{
SPWebApplication webApplication = web.Site.WebApplication;
try
{
webApplication.Sites.Add("ManagedPathHere","Site Title Here","This site is used for hosting styling assets.", 1033, "STS#1", "6scdev\\eric.schrader", "Eric Schrader", "eric.schrader#6sc.com");
}
catch (Exception ex)
{
//ex.ToString;
}
}
}