I added a webApplication Under Default website using powershell as follows:
function CreateWebApplication([string]$WebApplicationName,[string]$AppPoolName,[string]$PhysicalPath)
{
try
{
New-WebApplication -Name $WebApplicationName -Site 'Default Web Site' -PhysicalPath $PhysicalPath -ApplicationPool $AppPoolName
Write-Host "Created WebApplication :" $WebApplicationName
}
catch [Exception]
{
write-host $_.Exception.Message `n;
}
}
Its getting created fine,But when i am seeing this in IIS,it has only two section Names IIS and management.but if same thing i do from IIS console,three sections named ASP.net,IIS and management are added.Why i am not getting third section.Another thing if i am trying to enable directory browsing on same,its giving an error that unable to retrieve directory browsing giving some problem with applicationhost.config file.But when i am trying to find applicationhost.config file,its not there in the asked location "C:\Windows\System32\inetsrv".What is going wrong here i am not able to fin out.
Please help :)
The application pool is most likely not being created with a clr version.
If you open the application pool from IIS and look at the .NET version it will say
No managed code.
You can create the app pool and specify the managedRuntime version.
Related
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
Problem/Question
I'm test running a script for redgate deployment. At the last step it starts a website:
import-module WebAdministration
$website = get-website | where-object { $_.name -eq $RedGateWebSiteName }
#(re)write HostName#
$binding = Get-WebBinding -Name $RedGateWebSiteName
Set-WebBinding -Name $RedGateWebSiteName -BindingInformation "*:80:*" -PropertyName HostHeader -Value $HostName
if ($website) {
Start-Website "$RedGateWebSiteName"
}
It always worked but now on one of the last days I get this error
At D:\inetpub\Timeblockr-RedGate\Api\PostDeploy.ps1:15 char:15
+ Start-Website <<<< "$RedGateWebSiteName"
+ CategoryInfo : InvalidOperation: (:) [Start-Website], COMException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.IIs.PowerShell.Provider.StartWebsiteCommand
IIS error
The World Wide Web Publishing Service (WWW Service) did not register the URL prefix http://*:80/ for site 3. The necessary network binding may already be in use. The site has been disabled. The data field contains the error number.
This SO question "Cannot create a file" error when running Start-Website command in Powershell gives a pretty good clue what it can be.
Edit:
After viewing my event log and checking out the answers I found out that when Redgate automaticly tries to install/start the website i'm getting this IIS error:
The World Wide Web Publishing Service (WWW Service) did not register the URL prefix http://*:80/ for site 3. The necessary network binding may already be in use. The site has been disabled. The data field contains the error number.
In this Serverfault : https://serverfault.com/questions/456217/the-world-wide-web-publishing-service-www-service-did-not-register-the-url someone its mentioning that the cause of that is that a IIS website gets created without hostheader. I'm adding the hostheader after I try to start the website. Lets find the solution
Edit 2:
I was adding the hostname after I tried to start the website. This caused that the website has e empty hostname and that conflicts in IIS. (or somewhere else).
I've changed my script to get the website, add the hostname and then start the website.
Also added "$RedgateWebsiteName" instead of $RedGateWebSiteName. Works perfectly now!
Edit 3:
After a run of tests I seem to end up the same error. The one deploy has no problems, the other deploy does has.
Edit 4:
I've updated the script / Error / Post.
I deleted my site from IIS after that I clicked on install. Perfectly installed - No problems, automatic start.
Second run exactly the same, third run I get the error above!
I'm guessing the $RedGateWebSiteName variable had not been assigned a value, assuming the log message replaces the variable with its' value. From googling around, it looks like the IIS "file already exists" message may be erroneous as it happens because of anything from a missing IP address binding to an invalid virtual directory folder.
Why do you need a script to start the website? If you are using Red Gate Deployment Manager, it starts the website after the deploying a web package (any package with a web.config file it).
It could be that the value substitution for $RedGateWebSiteName is not taking place and it probably needs double quotes:
Start-Website "$RedGateWebSiteName"
I say this because your error message says this:
Start-Website <<<< $RedGateWebSiteName
while the error message here displays the substituted value:
start-website <<<< "MyWebsite"
I had the exact same problem, when starting the website with:
Start-Website -Name MyWebSiteName
and it would not start. When I tried to start it manually in IIS Manager, it wouldn't start either and I got this error message:
The World Wide Web Publishing Service (W3SVC) is stopped. Websites cannot be started unless the World Wide Web Publishing Service (W3SVC) is running.
This is pretty clear that the service is not started and it turned out to be true.
I want my MVC3 web application to access %APPDATA% (e.g. C:\Users\MyUsername\AppData\Roaming on Windows 7) because I store configuration files there. Therefore I created an application pool in IIS with the identity of the user "MyUsername", created that user's profile by logging in with the account, and turned on the option "Load User Profile" (was true by default anyway). Impersonation is turned off.
Now I have the problem that %APPDATA% (in C#):
appdataDir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
resolves to c:\windows\system32\inetsrv instead of C:\Users\MyUsername\AppData\Roaming.
UPDATE: More exactly, the above C# code returns an empty string, so that Path.GetFullPath(Path.Combine(appdataDir, "MyAppName")) prepends the current path to my application name, resulting in c:\windows\system32\inetsrv\MyAppName.
I know I made this work before with the same web application on a Windows Server 2008 R2, and now I'm getting this problem with the same major version 7.5 of IIS on my Windows 7.
I used the same procedure as before: Created a new user, logged in as that user to create the profile and APPDATA directories, then added the application pool with this identity and finally added the web application to this pool.
Any ideas?
Open your %WINDIR%\System32\inetsrv\config\applicationHost.config and look for <applicationPoolDefaults>. Under <processModel>, make sure you don't have setProfileEnvironment="false". If you do, set it to true.
Application Pools - Your application Pool - Advanced settings ...
Process Model - Load user Profile set True.
It Helps me.
Taken from
https://blogs.msdn.microsoft.com/vijaysk/2009/03/08/iis-7-tip-3-you-can-now-load-the-user-profile-of-the-application-pool-identity/
I experienced the same problem recently. As mentioned by Amit, the problem is that the user profile isn't loaded. The setting is for all application pools, and is in the applicationHost.config (typically C:\Windows\System32\inetsrv\config\applicationHost.config). If you update the applicationPoolDefaults elements as follows, it will work;
<applicationPoolDefaults managedRuntimeVersion="v4.0">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</applicationPoolDefaults>
We've tried this with IIS 7.5, and taken it through to production without problem.
You can automate this if you want;
appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.processModel.setProfileEnvironment:"true" /commit:apphost
or if you prefer powershell
Set-WebConfigurationProperty "/system.applicationHost/applicationPools/applicationPoolDefaults/processModel" -PSPath IIS:\ -Name "setProfileEnvironment" -Value "true"
Hope this helps
I am experiencing the same problem. Have you by chance installed the Visual Studio 11 beta? I did recently, and I've noticed a couple of differences in how the 4.0 compatible .dlls for that work with our code. I'm still trying to track down the problem for certain, but I didn't have this problem before that.
Edit:
After comparing the decompiled sources from 4.0 and 4.5 for GetFolderPath (and related), there are differences. Whether they are the source of the problem...I'm not sure yet.
Edit 2: Here are the relevant changes. I'm working on trying both to see if I get different results. [code removed]
Edit 3:
I've now tried calling SHGetFolderPath directly, which is what the .NET Framework ends up doing, anyway. It returns E_ACCESSDENIED (-2147024891 / 0x80070005). I don't know what has changed where I'm getting that in some specific cases, but not in others.
Edit 4:
Since you're getting a empty string, you may want to switch your code to use SHGetFolderPath so you can get the HResult and at least know what exactly is happening.
void Main() {
Console.WriteLine( GetFolderPath( Environment.SpecialFolder.ApplicationData ) );
}
[System.Runtime.InteropServices.DllImport("shell32.dll")]
static extern int SHGetFolderPath(IntPtr hwndOwner, int nFolder, IntPtr hToken, uint dwFlags, StringBuilder pszPath);
private string GetFolderPath( Environment.SpecialFolder folder ) {
var path = new StringBuilder( 260 );
var hresult = SHGetFolderPath( IntPtr.Zero, (int) folder, IntPtr.Zero, 0, path );
Console.WriteLine( hresult.ToString( "X" ) );
return ( (object) path ).ToString( );
}
The problem is with your IIS settings. The answer is here: Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) returns String.Empty
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;
}
}
}