I stop default web site by powershell and it's stopped. But I find it started after reboot.
If I stop it manually in IIS7 manager, it will be stopped after rebooting machine.
It looks like stopping website by powershell is not so efficient.
anybody has any idea about it?
OS: Windows 2008 R2 SP1
IIS: 7
The current state and the "startup" state are two different controllable entities just as they are in the IIS Manager GUI. Set the startup state to Manual or Disabled like so:
Set-Service w3svc -StartupType Manual
Update: If you only want to affect the startup of one on several sites then try this:
PS> ipmo WebAdministration
PS> Get-ItemProperty 'IIS:\Sites\Default Web Site' ServerAutoStart
PSPath : WebAdministration::\\HILLR1\Sites\Default Web Site
PSParentPath : WebAdministration::\\HILLR1\Sites
PSChildName : Default Web Site
PSDrive : IIS
PSProvider : WebAdministration
IsInheritedFromDefaultValue : False
IsProtected : False
Name : serverAutoStart
TypeName : System.Boolean
Schema : Microsoft.IIs.PowerShell.Framework.ConfigurationAttributeSchema
Value : True
IsExtended : False
PS> Set-ItemProperty 'IIS:\Sites\Default Web Site' ServerAutoStart False
If you are trying to do this on Server 2012R2 ServerAutoStart is serverAutoStart (notice the lowercase "s" in serverAutoStart
Hooray for case sensitivity :)
Related
I need to change the physical path of a web site through command line via the appcmd.exe tool which I want to point to Amazon FSx, but I can't figure out why I have errors. Here is what I'm using in PowerShell as admin:
PS C:\Windows\system32> appcmd list app
APP "Test Services/" (applicationPool:Test Services)
APP "Test Simple Site/" (applicationPool:Test Simple Site)
APP "Test/" (applicationPool:Test)
PS C:\Windows\system32> appcmd list vdir
VDIR "Test Services/" (physicalPath:\amznfsxthjfzxec.test.local\share\Sites\TestServices)
VDIR "Test Simple Site/" (physicalPath:\amznfsxthjfzxec.test.local\share\Sites\TestSimple)
VDIR "Test/" (physicalPath:C:\inetpub\wwwroot)
PS C:\Windows\system32> appcmd set site /site.name:"Test" /application[path='Test/'].virtualDirectory[path='Test/'].physicalPath:"\\amznfsxthjfzxec.test.local\share\Sites\Test"
ERROR ( message:Malformed collection indexer; format is [#position,name='value',name2='value2',...]. The #position specifier
is optional, and be '#start', '#end', or '#N' where N is a numeric
index into the collection. )
Could you please advise me? Thank you!
If you want to replace physical path for the virtual directory under site level.
Please try this
appcmd.exe set config -section:system.applicationHost/sites /[name='Default Web Site'].[path='/'].[path='/myvir'].physicalPath:"\\WIN10\Share" /commit:apphost
If you also have an application under my site like "mysite/myapplication" and the virtual dirtory is "mysite/myapplication/my virtual.
Then you could try this
appcmd.exe set config -section:system.applicationHost/sites /[name='Mysite'].[path='/myapp'].[path='/myvir'].path:"\\WIN10" /commit:apphost
Please remember to run cmd as adminsitrator when you try this.
After trying multiple configuration changes, I cannot seem to get past this error. This is a fresh install of Windows Server 2012R2, with all of the options selected under the ASP.NET/IIS modules and features selected. I'm using Visual Studio 2013, and the target framework is 4.5
I have also executed the following commands:
%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/handlers
%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/security/ipSecurity
%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/modules
Try adding
-commit:apphost
to the command, like this
%windir%\system32\inetsrv\appcmd.exe unlock config section:system.webServer/security/ipSecurity -commit:apphost
so that the unlocking is applied at the topmost (applicationhost.config) level instead of the lower web.config levels
Is there any reliable way how to check whether ASP.NET 4.0 registered on IIS 7.5 programmatically? I need to test it in the installer as prerequisite, before ASP.NET application installation start.
If ASP.NET 4.0 not registered on the IIS, later during the installation just installed application cannot be run and returns 500 internal server error (and it is too late to solve the problem). Instead, I want to show some warning (and hint how to solve the issue) before any installation steps started. But no reliable solution found yet.
AFAIK, registry entries reading sometimes may not work correctly. So now, I run aspnet_regiis.exe -lv to list versions (as suggested here) and parse the output. But even if .NET not registered correctly my test (falsely) succeeds, because the output is (contains version 4.0):
2.0.50727.0 C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll
4.0.30319.0 C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll
(Win7 32bit)
Running aspnet_regiis.exe -ir can repair it in this case.
It's similar issue as this question, but I need test it programmatically.
Do you have any ideas or experiences?
Using your own answer as a basis, this can also be done using the command line (with elevation):
%WINDIR%\System32\inetsrv\appcmd.exe list apppool /managedRuntimeVersion:v4.0
If anything is returned, ASP.NET 4.0 is registered.
The issue with this approach is that it seems to be possible to create 4.0 application pools manually even if the filter is not installed, and then this method would not work.
EDIT:
I have ended up running these three checks:
aspnet_regiis.exe -lv (should return a line containing "c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll")
appcmd.exe list apppool /managedRuntimeVersion:v4.0 (should return a line containing "MgdVersion:v4.0")
appcmd.exe list config -section:system.webServer/isapiFilters (should return a line containing "c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll")
Note that I only care about 32bit versions.
If all three checks pass, it can be concluded that ASP.NET 4.0 is registered. Still not 100% false positive-proof though.
This is an old question, but I'm posting an answer because your question is one of the top results on google, and it's unanswered.
The registry key you are looking for is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0. If that key is present, then .Net 4 has been installed and is registered in IIS.
If you just want to check if .Net 4 is installed, you can check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full.
In Powershell it could be done like this:
# load the IIS-Commandlets
Import-Module WebAdministration
# get the isapi filters currently loaded
Get-WebConfigurationProperty -Filter "/system.webServer/isapiFilters/filter" -name *
An output could look like this:
name : ASP.Net_4.0_32bit<br/>
path : %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll<br/>
enabled : True<br/>
enableCache : True<br/>
preCondition : runtimeVersionv4.0,bitness32<br/>
ItemXPath : /system.webServer/isapiFilters/filter[#name='ASP.Net_4.0_32bit']<br/>
Attributes : {name, path, enabled, enableCache...}<br/>
ChildElements : {}<br/>
ElementTagName : filter<br/>
Methods :<br/>
Schema : Microsoft.IIs.PowerShell.Framework.ConfigurationElementSchema<br/>
name : ASP.Net_4.0_64bit<br/>
path ........
Based on that we could write this code to check and install .NET 4 if needed:
$DotNet4Missing = $true
# lets make sure we got .net 4 correctly setup
$isapiFilters = Get-WebConfigurationProperty -Filter "/system.webServer/isapiFilters/filter" -name *
"/system.webServer/isapiFilters/filter count: {0}" -f $isapiFilters.Count
foreach ($filter in $isapiFilters)
{
"filter.name: {0}" -f $filter.name
if ($filter.name -eq "ASP.Net_4.0_64bit")
{
"-> Found .NET 4 - GREAT!"
$DotNet4Missing = $false
}
}
if ($DotNet4Missing)
{
"Missing .NET 4 IIS integration - running aspnet_regiis.exe"
$pinfo = New-Object System.Diagnostics.ProcessStartInfo
$pinfo.FileName = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe"
$pinfo.RedirectStandardError = $true
$pinfo.RedirectStandardOutput = $true
$pinfo.UseShellExecute = $false
$pinfo.Arguments = "-iru"
$p = New-Object System.Diagnostics.Process
$p.StartInfo = $pinfo
$p.Start() | Out-Null
$p.WaitForExit()
$stdout = $p.StandardOutput.ReadToEnd()
$stderr = $p.StandardError.ReadToEnd()
"aspnet_regiis.exe stdout: {0}" -f $stdout
"aspnet_regiis.exe stderr: {0}" -f $stderr
"aspnet_regiis.exe ExitCode: {0}" -f $p.ExitCode
}
Summary: The problem described above occurs on non-server operating system (Win7). The .NET 4.0 is not registered on the IIS even if you install IIS before .NET 4.0 (and so .NET should be registered on IIS correctly). This causes unexpected problems during any ASP.NET application installation -- until aspnet_regiis.exe -ir is ran from the commandline. There is no problem with Win 2008 (i.e. when IIS installed before .NET 4.0 then .NET is registered correctly on IIS and everything works as expected).
So finally my colleague told me what possibly could be solution of the problem. I've verified that following solution works fine (also on Win7). ServerManager from Microsoft.Web.Administration namespace can be employed easily:
public static bool IsAspNetRegistered()
{
using (var mgr = new ServerManager())
{
return mgr.ApplicationPools.Any(pool => pool.ManagedRuntimeVersion == "v4.0");
}
}
In case of successful .NET registration on IIS, there is at least one application pool which runtime version is set to "v4.0" so this fact was used for the check.
Of course, if anybody deletes all application pools, this method can work incorrectly. But this is bit pathological situation I don't care. The main issue is to prevent that although everything is done according our installation recommendations, still not possible to install the application on the machine.
For the past few days I'm trying to deploy my package to IIS 7 but I'm getting nowhere.
Whenever I try to publish the package I receive an error saying that the destination folder doesn't exist - but in fact it WAS created on the remote server but was empty (just the folder structure) :/
I'm building my package with a following command:
msbuild.exe /t:CreateWebPackages /toolsversion:4.0 CRM.msbuild
and trying to deploy it with:
CRM.cmd /M:server /Y
Result is:
C:\...WebService.deploy.cmd /M:crm-web /y
=========================================================
SetParameters from:
"C:...WebService.SetParameters.xml"
You can change IIS Application Name, Physical path, connectionString
or other deploy parameters in the above file.
-------------------------------------------------------
Start executing msdeploy.exe
-------------------------------------------------------
"C:\Program Files\IIS\Microsoft Web Deploy\\msdeploy.exe"
-source:package='C:...WebService.zip' -dest:auto,computerName='crm-w
eb-new',includeAcls='False' -verb:sync -disableLink:AppPoolExtension -disableLin
k:ContentExtension -disableLink:CertificateExtension
-setParamFile:"C:...WebService.SetParameters.xml"
Info: Adding sitemanifest (sitemanifest).
Info: Updating createApp (Kruk CRM Web Service/2.0.65000.65000).
Info: Adding contentPath (Kruk CRM Web Service/2.0.65000.65000).
Info: Adding dirPath (Kruk CRM Web Service/2.0.65000.65000).
Info: Adding child dirPath (Kruk CRM Web Service/2.0.65000.65000\bin).
Info: Adding setAcl (Kruk CRM Web Service/2.0.65000.65000).
Error: (2011-10-27 11:07:59) An error occurred when the request was processed on
the remote computer.
Error: Could not find file '\\?\C:\inetpub\wwwroot\CRM\2.0.65000.65000'.
Error count: 1.
But when i edit the SetParameters.xml file and change
<setParameter name="IIS Web Application Name" value="Web Service/2.0.65000.65000" />
to
<setParameter name="IIS Web Application Name" value="Web Service" />
it works!
So is there some magic trick that I need to do in order to create new dirs under the site ?
Found it! After experimenting with almost all of the available options of msbuild, msdeploy, project settings, IIS etc, I've noticed that msdeploy couldn't create my application under site's application pool because apparently it's identity had not high enough privileges to do so.
What did the trick was changing the identity of the site pool to Local System.
OK so we have something that is currently using OpenExeConfiguration for reading a config file, however this doesn't work when running in the web context.
I've tried a variety of different ways of opening the web.config programmatically but I can't seem to get it to read the correct web.config file. In case it matters I am currently debugging it in VS 2008.
1. config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(System.Web.HttpContext.Current.Request.ApplicationPath);
2. config = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = "web.config" }, ConfigurationUserLevel.None);
3. config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
4. config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(null);
5. System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(System.Web.Hosting.HostingEnvironment.ApplicationVirtualPath);
It either opens up the wrong config file (either the machine config, or the VS /IDE/Web.config) or complains about the error:
{System.Configuration.ConfigurationErrorsException: An error occurred loading a configuration file: Failed to map the path '/'. ---> System.InvalidOperationException: Failed to map the path '/'.
Edit -
OK so a combination of
config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
AND running Visual Studio 2008 As Administrator worked. Am hoping we don't run into security/permission issues when we deploy to our web server / client environments!
So in the end I used this code (had to handle whether the web application was running, or if our unit test code was running).
System.Configuration.Configuration config = null;
if (System.Web.HttpContext.Current != null && !System.Web.HttpContext.Current.Request.PhysicalPath.Equals(string.Empty))
config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
else
config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
Also have to be running Visual Studio in Administrator mode - which I found out you can set as a property on your shortcut so you don't need to remember each time in Windows 7 to right click and run as administrator :)