I'm trying to use the following command to set uploadReadAheadSize in IIS 8.5 on Windows Server 2012 R2:
appcmd.exe set config -section:system.webServer/serverRuntime/uploadReadAheadSize:"491521" /commit:apphost
But I keep getting this error:
ERROR ( message:Can not set attribute "uploadReadAheadSize" to value "491521 "..
Reason: Not a valid unsigned integer . )
From this page the maximum should be 4GB so my integer is valid. (Admittedly this goes back to IIS 6.0 so not sure how relevant it is now.)
This page on the other hand suggests that the property may have been replaced/deprecated or something, but it's not clear from the error message or anything I can find on the Googles.
I'm no expert in IIS so there may be a simple/obvious answer to this, but I'd be grateful if anyone can share some more concrete info...
UPDATE: also posted in IIS forums
Open IIS
Navigate under Default Web Site
Scroll down to Management and open Configuration Editor
Select following section (drop down at the top) system.webServer and expand it, then locate serverRuntime
you'll find there the current value of uploadReadAheadSize value, which you can change
Four years later... The clue was in the error message: "491521 " is not a valid unsigned integer. Note the space at the end of the integer before the quote marks.
Turns out the command I was running had a double space between the value and the /commit. Change to a single space and the command works fine.
Interestingly it's the same command I've been using for years and I've just confirmed it still works fine with the double space in Server 2008 R2!
How to set the maxAllowedContentLength to 500MB while running on IIS7?
Try this. Looks like you need to set it below 4294967295(in bytes)
Try this:
appcmd.exe set config -section:system.webServer/serverRuntime /uploadReadAheadSize:"491521" /commit:apphost
There must be a space after -section:system.webServer/serverRuntime and before /uploadReadAheadSize .
WebServer Run Time
POWERSHELL Command
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.webServer/serverRuntime" -name "uploadReadAheadSize" -value 2147483647
uploadReadAheadSize Optional uint attribute.
Specifies the number of bytes that a Web server will read into a buffer and pass to an ISAPI extension or module. This occurs once per client request. The ISAPI extension or module receives any additional data directly from the client. The value must be between 0 and 2147483647.
The default value is 49152.
Related
While trying to create an application pool via appcmd
C:\Windows\System32\inetsrv>appcmd add apppool /name: testname /managedRuntimeVe
rsion: -v4.0 /managedPipelineMode: -Integrated
i get the folowing error
The identifier is not supported in the current command usage. You specified 'testname'.
So, what is wrong with that?
Brilliant.
Removed the extra space character from /name: testname to /name:testname
and it just works.
I have a VS2012 solution, containing 10 projects, and suddenly, I can no longer publish my Services project to any folder.
When I try to publish to D:\temp, I get this error:
The expression "[System.IO.Path]::GetFullPath(obj\Release%25252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528Prod%25252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529\)" cannot be evaluated. The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
Huh ?
VS2012 (with update 4) seems to have taken my configuration name "Release(Prod)" and completely messed it up, causing the GetFullPath to produce too long a path name.
How the heck can I fix this ?
Out of desperation, I tried to build and publish the same project in VS2013 - and it had the same error message.
One of my colleagues said he'd seen the same thing, but had fixed it by removing the spaces from his configuration name. I tried this, which is why my configuration name is now "Release(Prod)" rather than "Release (Prod)", but it made no difference.
I did also open the file which this error is suggesting is the cause of the error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
..and noticed that there's something in there concerning the AnyCPU platform name. I have tried getting my Services project to use "AnyCPU" and "Any CPU" (depressed sigh) but neither seems to make any difference.
<PropertyGroup Condition=" '$(IntermediateOutputPath)' == '' ">
<IntermediateOutputPath Condition=" '$(PlatformName)' == 'AnyCPU' Or '$(PlatformName)' == ''">$(BaseIntermediateOutputPath)$(Configuration)\</IntermediateOutputPath>
. . .
</PropertyGroup>
Has anyone else seen this issue ?
(A little bit later..)
This is so odd (and frustrating).
My Solution has 5 configurations - the default Debug and Release ones, plus extra configurations for Test, PreProduction and Production environments.
If I select any of these three configurations containing brackets, I get this ridiculous "The specified path is too long" error, as VS2012 corrupts the pathname (as shown in my first screenshot above).
I can't help wondering... is this some kind of VS2012 bug, handling spaces or brackets in the configuration name ?
I can deploy to a path directly with (, (, )) in the Target Location on tyhe Connection tab when publishing to the file system (i.e. not building a path from the configuration name) - but that is not a solution to targeting different locations based on the Configuration.
If you want to keep special characters in the configuration name, but specify a path to the deployment folder that will not cause and issue this post might help: Visual Studio: How to properly build and specify the configurations and platforms for x64 and x86
Specifically play with the settings in here:
In the project properties page, select the various permutations of
Debug/Release and x86/x64 in the solution dropdowns. Make sure the
target processor is set correctly (it should be, but I found instances
when they were not, probably because of my previous attempts). Also,
set the output directory. That should be okay and automatic
(/bin/x86/Debug, etc.). If not, fix.
Looking at what is actually seems to be going on is also potentially useful:
Looking at the numbers inserted:
%25 is an encoded %,
%28 is an encoded (
%29 is an encoded )
Looking at the path:
obj\Release%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525***28***Prod%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525***29***)
What I think is happening:
So that seems like a good clue that these are being URL or XML encoded. What appears to be happening is that the ( is being encoded as %28 and then the % is being recursively encoded as %25 - generating an infinite %252525252525252525....
A more interesting question is actually why it stops creating 25's from the %'s with this bug (both times it stops creating 25's at 214 characters including the % and the 28 / 29 - not a very interesting number).
Looking at the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets you reference - it makes sense that these strings are being encoded for XML. I would say this is definitely a bug... I have no suggestions for a fix.
Well, I'm going to accept Matthew's answer as the "Accepted Answer".
Thank you for your help.
This is a really odd problem though, and I'm amazed no one else has reported this elsewhere.
Summary of problem (in case Microsoft is interested, or if anyone tries to Google this issue in the coming years)
With a configuration name of "Release (Prod)", I could happily build my code, run it locally, but when I tried to publish it, even to a local drive, I'd get this message:
It's an odd exception, because the Build did create the "obj\Release (Prod)" folder, without any issues. It's just the Publish which seemed to be looking in the wrong place for it.
Following the advice given in this thread, today I attempted to create a new configuration, with the same settings, but without a space in the name: "Release(SecondProd)". Look what happens:
Interestingly, despite this error, it did create a new configuration with this name.
Anyway, I recreated a new configuration, called it ReleaseProduction, and it worked fine.
Of course, I needed to create new "web.config" Transformation for this name, as this doesn't get automatically copied when you create a new configuration based on an old one.
One last thought (just to confuse matters worse !)
When I posted this plea-for-help, the Services project in my Solution refused to publish to a local drive, but my web site would publish okay.
Today, two days since I last attempted a website Publish, I found that the website also now produces the same GetFullPath exception. Nothing's changed ! We use TFS, I have done a file compare with my project files today against two days ago, and they're identical !
It's a really bizarre bug in VS2012 & VS2013.
Btw, this solution & the projects in it, were originally a VS2010 project. They were upgraded to VS2012 over a year ago, but this Publish problem only started happening recently. I'm not sure if the problem is related to using upgraded VS projects.
Again, thanks for your help.
Now I have some Test, PreProd & Production configurations to recreate !
Maybe I'll grab a beer first..
Summarizing and completing Matthew's answer:
Cause: You have configurations with chars that require URI-encoding - in your case, '(' and ')'.
Workaround: Rename those configs.
What happens: Presumably web deploy URI-encodes the path, replacing % => %25, ( => %28, ) => %29. It does so over and over:
obj\Release(Prod)
obj\Release%28Prod%29
obj\Release%2528Prod%2529
obj\Release%252528Prod%252529
...
Until the path exceeds MAX_PATH=260.
I ran into the same thing and all though it does not resolve the issue I found that if I switch the solution configuration away from a build containing "(" or ")"
Then use the appropriate build in the publish dialog it will not error out.
I'm trying to use IIS Express with Visual Studio 2010 SP1.
I'm following this tutorial. When I run this command.
netsh http add urlacl url=https://Melnibone:443/ user=everyone
I get this message:
Create SDDL failed, Error: 1332
What's happening?
Well, I have found the problem.
I'm running Windows 7 in Spanish, so the right command is:
netsh http add urlacl url=https://Melnibone:443/ user=todos
Funny, isn't it?
UPDATE:
If you want, you can add a comment to this question telling us how it is in your language.
For me, this issue was caused because there was already an HTTP reservation for the address and port I was using when tried to add an HTTPS reservation.
I found out what was going on when I ran NETSH HTTP SHOW URLACL and saw that the address was already reserved with a different protocol.
I recently ran into this issue. The solution for me was to run the command prompt as an administrator.
I want to add that it might be the installation language.
I had to use the german word "jeder" though my system language was english.
I know this question was asked a long time ago, but as there is no general answer yet, so i thought i'll share my approach. There's an easy way to filter for this with a few batch commands.
for /f "skip=1delims=" %%a in (
'wmic sysaccount where "SID='S-1-1-0'" get name'
) do set "sid=%%a"&goto next
:next
The loop is necessary because the "get name" part gives the whole table with the heading so we filter for the second line. This code then stores the value of the SID according to your locale in the "sid" variable, so you only have to refer to this when you want to use it.
In this case the whole code would look like this:
for /f "skip=1delims=" %%a in (
'wmic sysaccount where "SID='S-1-1-0'" get name'
) do set "sid=%%a"&goto next
:next
netsh http add urlacl url=https://Melnibone:443/ user=%sid%
NOTE: How you filter for the second line is up to you, the real "magic" happens in this line:
wmic sysaccount where "SID='S-1-1-0'" get name
The command:
appcmd lock config -section:...
Will lock the specified config section. But I need to check if the config section is locked or not.
Is there any possible way to do that? Thanks for any reply!
I know this is a few years old now but I was searching for this for Puppet so here's what I came up with.
The command Get-WebConfigurationLock shows if any locks exist on the config section.
E.g. to check the IIS global config section for system.webServer/security/ipSecurity:
Get-WebConfigurationLock -PSPath "IIS:\" -Filter //system.webServer/security/ipSecurity
If the section is unlocked the above command will return null. e.g. to "unlock if locked":
if (Get-WebConfigurationLock -PSPath "IIS:\" -Filter //system.webServer/security/ipSecurity) {
%windir%/System32/inetsrv/appcmd.exe unlock config -section:system.webServer/security/ipSecurity
} else {
Write-Host "Already unlocked"
}
Remove-WebConfigurationLock can be used instead of appcmd, I favoured appcmd because you can pass lock/unlock as a parameter rather than changing the command itself.
Not sure what Chef looks like though here's the puppet define I've created to unlock/lock sections for reference:
https://gist.github.com/krutisfood/d59b3a5c62f6123bf553
For reference I found this Stack Overflow link Programmatically unlocking IIS configuration sections in Powershell though found that Get-WebConfigurationLock more accurately matched the locked state, even reloading the dll or the powershell window getting the attribute value often show IsLocked false when it was locked. ymmv.
I'm currently playing around with the Microsoft.Web.Administration (MWA) namespace in order to adjust our application to configure IIS 7.5 with the new API.
I understood that all IIS level changes should be expressed in the following file (I'm on Win2K8-R2):
%WINDIR%\System32\inetsrv\config\applicationHost.config
So, when I use the ServerManager object to commit the configuration changes the file should be updated accordingly.
After adding a new MIME type (programmatic with MWA) I did not see any changes in the applicationHost.config file, but I do see the new MIME type in the IIS manager window and IIS recognizes this MIME type without problems. Even after restating the OS - The config file does not contain the newly added MIME type, but the IIS manager window does list it.
Because my application pools are forced to 32-bit (Enable32BitAppOnWin64 = true), I thought that the related config file should be located under %WINDIR%\SysWOW64\inetsrv\Config, but (if it exists...) - it also does not change after the code commits the updates.
Can someone please explain this? Am I missing something (looking at the wrong file maybe?)? Can someone please shed some light on the SysWOW64\inetsrv\config directory?
This is my code for adding the MIME type:
ServerManager manager = new ServerManager();
ConfigurationElementCollection staticContentCollection = manager
.GetApplicationHostConfiguration()
.GetSection("system.webServer/staticContent")
.GetCollection();
//MIMETypes is a string[] array, each object is {FileExt},{MIMETypeStr}
foreach (string pair in MIMETypes)
{
string[] mimeProps = pair.Split(',');
ConfigurationElement mimeTypeEl = staticContentCollection
.Where(a =>
(string)a.Attributes["fileExtension"].Value == mimeProps[0])
.FirstOrDefault();
if (mimeTypeEl != null)
{
staticContentCollection.Remove(mimeTypeEl);
}
ConfigurationElement mimeMapElement =
staticContentCollection.CreateElement("mimeMap");
mimeMapElement["fileExtension"] = mimeProps[0];
mimeMapElement["mimeType"] = mimeProps[1];
staticContentCollection.Add(mimeMapElement);
}
manager.CommitChanges();
//At this point all is working but the config file does not reflect the change
I just tried your code and it works fine. You are aware that this mime type is being added to the global mime type collection and not to a site?
It also gets added to the end of the <staticContent> list, this list isn't re-sorted when you do ServerManager.CommitChanges().
Also on Windows 2008-R2 the correct location for applicationHost.config is at:
C:\Windows\System32\inetsrv\config
I'm guess you're either using notepad.exe or NotePad2 to open this file (32 bit editors can't open it). Notepad won't reload the file upon a change and NotePad2 needs to be told to display a file change notification (alt-F5), out of the box it won't.
Also try adding something unusual like .xxx, run your update then open the config file and do a search. I guarantee it'll be there.
Update:
Further to your comments below, I'm not sure how you're able to open applicationHost.config using NotePad++ or any 32-bit editor, I certainly can't. Can you download NotePad2 which is a 64-bit editor:
http://www.flos-freeware.ch/notepad2.html
The release candidate works just fine.
On a default install of any 64 bit Windows 2008 or Windows 7 there shouldn't be an applicationHost.config in the C:\Windows\SysWOW64\inetsrv\Config folder. I'm not sure why you'd be seeing one there.
As a workaround to open and edit the 64-bit IIS configuration files with your favorite 32-bit editor that is 64-bit compatible (i.e. Notepad++), you can create a Windows directory symbolic link which points to C:\Windows\System32\inetsrv\Config. With this method, you are replacing the 32-bit Config directory, located at C:\Windows\SysWOW64\inetsrv\Config to point to the 64-bit version. If, for example, you have an application which requires both 32-bit and 64-bit versions, this method won't work.
For more information, I strongly encourage you to visit this MSDN Blog.