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.
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?
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 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 have to run command line operation from some legacy ASP application.
Here is my code:
<%
cmd = "%comspec% /c echo Hello"
set wsh = CreateObject("WScript.Shell")
ireturn = wsh.Run(cmd, 0, true)
set wsh = nothing
%>
And here is result I am receiving:
Microsoft VBScript runtime error
'800a0046'
Permission denied
/test.asp, line 6
Do you have any idea how to make IIS6 to run this code?
Note: Of course I don't have to run echo command but I want to exclude any additional causes of the problem.
Update: I tried most things tomalaks mention however nothing helped. Maybe I can alter question a little. How can I debug this problem?
ASP usually is denied access to anything potentially dangerous, such as cmd.exe. Check file permissions on cmd.exe to see if that is true for you (I suppose it is).
If you really must use cmd.exe to do part of the page processing, either change file permissions on cmd.exe (not recommended for an Internet-facing web-server), or make sure that the ASP page runs credentials that are not denied access to that file.
To achieve this, use the IIS management console to remove "anonymous access" to the ASP page and use Windows-integrated authentication instead (if feasible), or leave "anonymous access" on and enter a fixed set of credentials that should be used instead of the default "IUSR_...".
Alternatively, if you use cmd.exe just to start a program that outputs something to STDOUT, you can try starting the program directly, without wrapping it in a cmd.exe call. Again, the user the ASP page runs under needs access to that program's executable.