We just upgraded to Sitecore 8.1 from 7.2. Search engine is Lucene and xDB disabled. The solution is hosted in ms azure cloud services Web Apps.
We noticed that the CMS CA is quiet slow. While looking at logs noticed a number of error logged below:
13876 2015:12:18 05:21:44 ERROR Could not compute value for ComputedIndexField: _content for indexable: sitecore://web/{2E25F9D3-BBBF-4160-BAE1-1EE4E701BD9B}?lang=en&ver=1
Exception: System.UnauthorizedAccessException
Message: Access to the path 'D:\App_Data\data\mediaIndexing\b3cd2fa1-9671-498f-9534-a94ad5a21923-Mypolicy.pdf' is denied.
Source: mscorlib
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalDelete(String path, Boolean checkHost)
at System.IO.File.Delete(String path)
at Sitecore.ContentSearch.ComputedFields.MediaItemIFilterTextExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.ComputedFields.MediaItemContentExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.LuceneProvider.LuceneDocumentBuilder.AddComputedIndexFields()
Could someone please suggest why sitecore is looking for Web forms for marketing index which we don't need it?
Thanks
There is nothing about WFFM index in your error - it only says that it cannot compute value of the _content field for {2E25F9D3-BBBF-4160-BAE1-1EE4E701BD9B} item.
It even tells you the reason - cannot access path on the drive. You should check access rights for the D:\App_Data\data\mediaIndexing directory and make sure it can be access by you application user.
With Azure Web Apps you should have a full access in the file system to the webroot and its descendants. Ensure the MediaIndexingFolder setting is not set to absolute path and does not point to outside of the webroot where the application lives.
By default, if the MediaIndexingFolder setting is not specified, it points to the $(dataFolder)/mediaIndexing path, where the $(dataFolder) must point to the \App_Data under the webroot.
We recently had the same issue. Essentially, make sure that on an Azure WebApp the standard zzDataFolder.config file is used which contains:
<sc.variable name="dataFolder">
<patch:attribute name="value">D:\home\site\wwwroot\App_Data</patch:attribute>
</sc.variable>
Using the other config that is included (DataFolder.config, which sets it to "/data") or your own config file (pointing to anything other than the full drive path) will break the mediaIndexing folder path (even though all other parts of Sitecore which use App_Data like "diagnostics" or "MediaCache" work perfectly well with the "/data" setting).
Related
I am using Server.MapPath to find the path for a document uploaded to a remote server, so that I can then open it. However when using it, it is returning a relative path and so rather than searching the remote server it is searching the local machine instead.
What I am using to open the document is:
System.Diagnostics.Process.Start(Server.MapPath(Path.Combine("~/", document)));
Where "document" is the part of the path relative to the document itself, in this case "Files\2016\11\doc_name". So I want to take the path of this document, go to the top level of the site, and then find the document from there.
However I would hope that this would return a path similar to "server\inetpub\site\Files\2016\11\doc_name" but instead it is returning a path like "d:\inetpub\site\Files\2016\11\doc_name".
Can someone help me with what is the correct function to use to get the path I need?
EDIT
I have managed to fudge together the correct path using the following code:
string server = Environment.MachineName;
string path = Server.MapPath(Path.Combine("~/", documentpath));
System.Diagnostics.Process.Start(#"\\" + server + path.Substring(path.IndexOf(#"\")));
However, while I can get this to access the file when I'm running the project locally, it errors when I try to do it on the published site. As I can access it in one way, I'm assuming that it could be permissions (just to note the site is using windows authentication). Is this the most likely cause?
How do I get the Root/Home Directory of a website in IIS6 using a batch file??
My Scenario:
I am creating a tool to summarise and report of sites in IIS. I am using batch files and running iisweb /query to get all the sites then looping over the results and using iisvdir /query "Website Name" to get the virtual directories.
However it has to be backwards compatible with IIS6 and I am having trouble getting the Home Directory of the site.
I don't think you can do this directly from a batch file, but you should be able to do it from a vbscript which you can call from a batch file.
The trick is to use the IIS WMI provider which gives you access to the IIS metabase. For example, the script below should echo the name and path of every virtual directory on the local server.
set provider = GetObject("winmgmts://localhost/root/MicrosoftIISv2")
set results = provider.ExecQuery("SELECT Name,Path from IISWebVirtualDirSetting")
for each item in results
WScript.Echo item.Name
WScript.Echo item.Path
next
If you saved this script as iispaths.vbs (just as an example), you could then call it from a batch file with:
cscript //nologo iispaths.vbs
Unfortunately I don't have access to a machine with IIS6, so I am unable to test this at the moment, but if you have any problems getting it to work, feel free to let me know in the comments and I'll do my best to fix the issue.
I don't have a IIS6 server, however, through some searching, I found that:
IIS6 uses %SystemRoot%\system32\inetsrv\MetaBase.xml and %SystemRoot%\system32\inetsrv\MBSchema.xml for storing configuration (The IIS Metabase (IIS 6.0));
If your server isn't changing home-directories too often, those xml should be updated;
using a command line parser (like xmlstartlet), you can extract Path property from IIsWebVirtualDir node (according Metabase Structure), using XPath.
With xmlstartlet, a command like below, would output root path:
xml sel -t -v "//IIsWebVirtualDir[#Location='/LM/W3SVC/1/ROOT']/#Path" "%SystemRoot%\system32\inetsrv\MetaBase.xml"
Maybe schema needs to be corrected.
This can be a command line approach. I can't test it as I don't have any IIS6 server neither I can get any MetaBase.xml sample.
I have a need to write a .NET application which will query Active Directory while running in Windows PE on a computer which is not yet a member of the domain.
We are running this during a Microsoft Deployment Toolkit task sequence (note that MDT 2012 has been configured to load support for .NET into the WinPE environment - the .NET application is starting without any problems).
I am using the code below to bind to the domain:
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
I have tried a path both of the form:
LDAP://domainServer/dc=domain,dc=name
And also without a domain controller name as
LDAP://dc=domain,dc=name
I have also tried using a username both of the form domain\username and also just username.
The DirectoryEntry object seems to be constructed okay, but when I try to execute Console.Writeline(entry.Name) to confirm a valid connection has been made, I get the following exception:
System.Runtime.InteropServices.COMException (0x80005000): Unknown
error (0x80005000) at
System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_Name()
I have tried other variations on this code, trying to execute LDAP queries with various filters, trying to rewrite it in VBScript, etc... but the code posted above is the simplest example I could come up with which reproduces the problem.
From what I have read, in a scenario like this you would always need to use AuthenticationTypes.ServerBind and that is why I am trying to specify the code within the ADSI LDAP path. But what is wrong with the code above? To me, it looks like it is passing all needed information in the parameters to the DirectoryEntry constructor.
There is a way to get it work, but it's not supported by Microsoft. This post helped me a lot. It works, tested and approved for a deployment of new computers :)
Get the ADSIxXX.inf from the zip file to C:\ADSI
Copy the following files from a Windows/System32 to C:\ADSI. Carefull of Architecture
x86 x64 -
adsldp.dll
adsmsext.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll
Mount the bootimage.wim
No need to load Package (Your WinPE is already configured to load .NET API), juste add ADSI driver:
Dism /Image:C:\Mount /Add-Driver /Driver:C:\ADSI\ADSIxXX.inf /forceunsigned
No need to load his script
Unmount the bootimage.wim
Then it's done, if your .NET application is well implement ;)
I'm not sur the PIPE | is supported as an argument too, just set to AuthenticationTypes.Secure -
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
Link: http://www.deploymentresearch.com/Research/tabid/62/EntryId/74/ADSI-plugin-for-WinPE-4-0.aspx#AddComment
I'm trying to deploy to Azure (Silverlight application); I've migrated my DB, updated connection strings and published my application to Azure but when I click the service URL I get this:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
Any idea what I need to change?
Many thanks
If the name of your bundle matches the path in the file system then IIS on Azure will throw the 403 Forbidden error.
So if you have a path in your solution called /Content/css and you have a bundle name called bundles.Add(new StyleBundle("~/Content/css").Include( ... in BundleConfig.cs which is displayed like this #Styles.Render("~/Content/css") in your _Layout.cshtml file. Then you get that error.
I solved this by changing the name of my bundle from /Content/css to /Style/css
bundles.Add(new StyleBundle("~/Content/css").Include( ... in BundleConfig.cs becomes bundles.Add(new StyleBundle("~/Style/css").Include( ...
#Styles.Render("~/Content/css") in your _Layout.cshtml becomes #Styles.Render("~/Style/css") in your _Layout.cshtml
You can use any names you like there is no specific limitations. I imagine you can go ahead and rename the folders in your solution too and that should work.
NB: The name of the bundle turns into a virtual directory that the browser can request from. If it resembles a physical folder structure then it will throw back the 403.
I needed to use the full path to a page within the application as I hadn't set a default document in my web config e.g
<add value="Pages/Home.aspx"/>
I got the same error in my MVC project.
After some debugging I found that it was because I have removed all "default pages" in the Azure Portal.
I added a dummy "index.html"-record in the portal and then everything worked nicely again :)
i'm trying to get the list of mime types known to an IIS server (which you can see was asked and and answered by me 2 years ago). The copy-pasted answer involves:
GetObject("IIS://LocalHost/MimeMap") msdn
GetObject("IIS://localhost/mimemap") KB246068
GetObject("IIS://localhost/MimeMap") Scott Hanselman's Blog
new DirectoryEntry("IIS://Localhost/MimeMap")) Stack Overflow
new DirectoryEntry("IIS://Localhost/MimeMap")) Stack Overflow
New DirectoryServices.DirectoryEntry("IIS://localhost/MimeMap") Velocity Reviews
You get the idea. Everyone agrees that you use a magical path iis://localhost/mimemap. And this works great, except for the times when it doesn't.
The only clue i can find as to why it fails, is from an IIS MVP, Chris Crowe's, blog:
string ServerName = "LocalHost";
string MetabasePath = "IIS://" + ServerName + "/MimeMap";
// Note: This could also be something like
// string MetabasePath = "IIS://" + ServerName + "/w3svc/1/root";
DirectoryEntry MimeMap = new DirectoryEntry(MetabasePath);
There are two clues here:
He calls iis://localhost/mimemap the Metabase Path. Which sounds to me like it is some sort of "path" to a "metabase".
He says that the path to the metabase could be something else; and he gives an example of what it could be like.
Right now i, and the entire planet, are hardcoding the "MetabasePath" as
iis://localhost/MimeMap
What should it really be? What should the code be doing to construct a valid MetabasePath?
Note: i'm not getting an access denied error, the error is the same when you have an invalid MetabasePath, e.g. iis://localhost/SoTiredOfThis
If you're working with the IIS config of your local machine i.e. your code and IIS are on the same box then it's sufficient to specify:
IIS://Localhost/mimemap
The IIS: portion is also known as a moniker in OLE parlance.
If you open the IIS6 metabase file (C:\Windows\System32\inetsrv\metabase.xml) you'll find a large 'blob' of XML. This is in fact a flattened out tree structure.
Paths in the metabase are represented by Location attributes.
The moniker IIS://localhost maps to the Location path /LM which is effectively the tree root.
The moniker IIS://localhost/MimeMap maps to the Location path /LM/MimeMap.
If your code is accessing the metabase on remote machines then instead of specifiying IIS://localhost/[path], one would specify IIS://[RemoteMachineName]/[path]. This is what Chris Crowes comment means.
IIS://localhost/MimeMap is also the master Mime Type list. All sites inherit this list (the IIS Metabase relies heavily on inherited properties).
If you wanted to override the Mime types for a specific site then you'd modify:
IIS://localhost/W3SVC/[iisnumber]/ROOT/MimeMap
It's useful to open up the IIS metabase file and have a dig around to understand what's going on under the bonnet.
Update:
To answer your question about why you can create a DirectoryEntry object where the path is invalid, DirectoryEntry is a general purpose wrapper object used to bind against different types of ADSI providers such as IIS, LDAP and WinNT. It permits creation of DirectoryEntry objects where there may not necessarily be a matching object at the path specified. Some ADSI provider operations may require this capability.
There is a static method on DirectoryEntry called Exists that you can use to test for the existence of objects. For example:
// Does Default Website exist?
if(DirectoryEntry.Exists("IIS://localhost/w3svc/1"))
{
// Do work...
}
I was having a problem with getting 0x80005000 returned when trying to do this. The stupid cause of my problem was that I was using IIS7 and hadn't installed IIS6 metabase compatibility support.