On windows server we installed IIS 10 and an SSL license

We observe that if we have a page that contains a response.flush() the request is executed twice (Get or POST)

on FF every request is duplicated, on chrome, IE and Edge the first request is duplicated after that the other request are executed normally (once)

This bug can be reproduced with a simple page with only:

<!--- start asp classic--->
<%
response.flush
%>
<!--- end asp classic--->

This is problematic with every browser, FF because all the requests are duplicated, even form submissions, others because bug this can happen on the first page that contains a "response.flush()"

I am aware that disabling HTTP/2 can resolve this symptomes, but we need to keep HTTP/2 enabled.

Is there any solution for this issue ?

Thank you.

Relatively new to the PowerShell space and I apologize if this is a non-issue and just a user error.

Missing help from IISAdministration Module
OS: Microsoft Windows 10 Education (10.0.16299 N/A Build 16299)
Hotfixes Installed: [01]: KB4053577 [02]: KB4056887 [03]: KB4057247

                         [04]: KB4058043 [05]: KB4088785 [06]: KB4093110 

                         [07]: KB4054517

Repro for missing: Get-Command

       Import-Module .\IISAdministration.psm1

       Get-Command -Module IISAdministration

                                             Returns: Null

Repro for missing: Help

                          Save-Module -Name IISAdministration {$env:Path}

                          help *iis*

                                                                     Returns Null

                          cd into the saved locale. 

                          Invoke-Item .\IISAdministration_07640789-476a-4713-a091-f5b365129c32_HelpInfo.xml

The help URI returns error: This site can’t be reached

<HelpContentURI>http://go.microsoft.com/fwlink/?linkid=216321</HelpContentURI>

The other listed url in the helpinfo.xml file also returns error:

http://schemas.microsoft.com/powershell/help/2010/05

This is also detailed in the following Reddit post: https://www.reddit.com/r/PowerShell/comments/57bxzd/powershellandiissettingwebdav_rules/

Summary: Add-WebConfigurationProperty does not correctly add collections

Component: Powershell IIS Module, specifically Add-WebConfigurationProperty

Version: Powershell 5 (PSVersion 5.0.10586.117, BuildVersion 10.0.10586.117)

OS: Windows Server 2012 R2 Datacenter (OS Version: 6.3.9600 N/A Build 9600)

Description: When adding a configuration property that includes a collection, it does not add the element with the collection defined.

Steps to reproduce:
1. Install IIS role with WebDAV support
2. Create directory for testing on disk (e.g. c:\TestShare)
3. Create virtual directory pointing to folder under Default Web Site in IIS with same name (e.g. TestShare
4. Open elevated PowerShell prompt
5. Attempt to set WebDAV authoring rules to allow read/write/source access to all users using the following PowerShell:

$psPath = 'MACHINE/WEBROOT/APPHOST'

$filter = '/system.webServer/webdav/authoringRules' 

$location = 'Default Web Site/TestShare'

$accessRule = @{

  users  = '*'

  path   = '*'

  access = 'Read, Write, Source'

}


Add-WebConfigurationProperty -pspath $psPath -Filter $filter -Location $location -Name '.' -Value $accessRule -Verbose

Actual results:
1. Open IIS Manager, navigate to the TestShare virtual directory, and open the "WebDAV Authoring Rules" feature
2. Observe that the rule was created, but has only read access
3. Additionally, open up the configuration at %windir%\System32\inetsrv\config\applicationHost.config and note that the "Authoring Rules" section includes the following line: <add users="" path="" />
4. Test the WebDAV share and notice the user only has read access
5. Navigate back to the IIS Manager and manually set the WebDAV authoring rule to include read/write/source access
6. Observe that the configuration file now includes the following line under the "Authoring Rules" section for the virtual directory used for this test: <add users="" path="" access="Read, Write, Source" />

Expected results: After running the above PowerShell, the following should be true
1. The IIS Manager should note that the users have "read/write/source" access under WebDAV authoring rules for the virtual directory
2. The config file should include following line under the "Authoring Rules" section for the virtual directory used for this test: <add users="" path="" access="Read, Write, Source" />
3. The user should be able to read/write to the folder via WebDAV

First of all, the Web Deploy 3.0 PowerShell SnapIn is really good. it takes away the complexity of the msdeploy.exe tool and can be implemented in a PowerShell Tool very well. But i came across two Bugs which have to be fixed to make this tool really GREAT. First and most of all, the Sync-WDSite cmdlet accepts Publishsettings, either as -sourcesettings or -destinationsettings. But if the Publishsettingsfile is not on the Desktop, and doesn't have this name: Microsoft.Web.Deployment.PowerShell.PublishSettings, the cmdlet throws an error. so i had to workaround this issue by simply copying and renaming the correct publishsettingsfile to the desktop and delete it after the sync. not very beautiful. The other bug is that the cmdlet sometimes throws strange errors because of the "Web Application Path Parameter". it said to me for one site that this parameter is already defined, but I didn't define it anywhere. Take my article from stack overflow for reference: http://stackoverflow.com/questions/38991555/sync-wdsite-web-application-physical-path-parameter?noredirect=1#comment65535321_38991555 . when I tried to sync the same site via msdeploy.exe it worked without problems. Please fix these Problems and you tool will be perfect. I'm looking forward to creating a small GUI-Shell Script with this SnapIn/Module! Bye, Simon

PHP supports a command called syslog which writes to the Windows Event Viewer on Windows machines.

Can you support the following:

-Allow selecting the special value syslog in the php configuration manager
-When enabled (or upon install of PHP x.x.x version) auto-create the needed registry entry to make this work:

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\PHP-x.x.x]

"TypesSupported"=dword:00000007
"EventMessageFile"="%PROGRAMFILES(x86)%\PHP\PHPvxx\phpx.dll"

Adjust the event log permissions accordingly

extract current permissions on command line using: wevtutil gl application >temp.txt
edit line "channelAccess", e.g: channelAccess: O:BAG:[...]
Remove any brackets staring with (D;; and containing any of your SIDs
add the following at the end of the channelAccess line (A;;0x3;;;S-1-5-17)(A;;0x3;;;S-1-5-32-568)(A;;0x3;;;S-1-5-20)

grant permission by pasting your edited channelAccesson command line: wevtutil sl application /ca:O:BAG:[...]

Then syslogging (Windows Event Viewer logging) works as expected