IIS: How to get the Metabase path? - iis

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.

Related

Server MapPath not working on remote server

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?

Sitecore 8.1 : Could not compute value for ComputedIndexField

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).

How do I modify the Site Collection in SharePoint 2013?

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

Cannot query Active Directory using ServerBind on non-domain computer in Windows PE

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

Serving .config files

We have a legacy (classic asp) CRM that I maintain in my organization. Users may upload files through the web front, they are stored on a network share and the filename, uploader, etc is saved to a database. Everything is well and good with the exception of .config files.
For some reason certain people can download these just fine, but other people recieve this error:
The type of page you have requested is not served because it has been explicitly forbidden. The extension '.config' may be incorrect.
it would seem that on some users computers the link for the file is "file://networkshare/filename" (which works) and on other machines it is "http://networkshare/filename". (which doesn't work)
I have the mime type for .config set to text/plain in iss6. All users are running IE8.
The code on the page creates a href links based on records returned from the database.
Why then is there there the difference in the way the link is rendered differently in the same browser on different pc's? How do I allow .config files allowing people to view the sites web.config?
The code that builds the link is:
function getlink(file_nm,path)
{
thisPage.navigate.CheckDocumentAttachedToRequest(file_nm, path)
var sDocLink = path.replace(/\//g,"\\") + "\\" + file_nm;
return "<A class=\"parislink2\" TARGET=\"_BLANK\" HREF=\"\\\\" + thisPage.get_sServerName() + "\\" + sDocLink + "\">" + file_nm + "</A>";
}
Weird.
I know that IIS 6 will return error 404.3 if a client request refers to a file name extension that is not defined in the MIME types.
However you do have it defined. You can try as a test using the wildcard () in your mime types. ( for the file extension and text/plain for the mime type.) The wildcard can be a security risk but if you are serving up configs..perhaps this application and server are internal to your network and it would be ok to use the wildcard.
I would also check your ISAPI extensions (not filters, but extensions) and make sure .config
is still in there. It should be by default.
Defining a mime type at the global level in IIS should filter down through and override any mime types set at the folder level.
An IIS reset is needed everytime you change mime types.
Perhaps it is a browser issue?
(an issue on the client side for the links that do not work..an issue like "browser control".)
It is almost as if some of the browsers are interpreting your function correctly when the link is built..and others are substituting "http" instead of "file" as the protocol when they render the HTML from the function call. Perhaps you could hardcode your function to us "file:" as a string that is placed at the begining of your link code. (trying to overide any "http" string that gets place in there by the HTML sent back by the server or rendered by IE8.)
The wildcard was filtered out for security purposes in the above post. (wildcard = "an asterisk")

Resources