[policy, no patch] Drop support for IIS in Drupal 11

+1 - as nobody who contributes to core actually seems to use IIS, I don't think we can hope to continue supporting it this way, so moving the docs to drupal.org where they can be updated more freely makes sense.

We could actually start doing this now, by creating the docs page on d.o, and adding a comment to web.config in Drupal 10.1/10.2 noting that this file is deprecated and pointing to the new docs for anyone that does still use it. That might also mean we can move some of the .htaccess issues forward without having to keep web.config in sync any more.

smustgrave → credited andregp → .

Closed 🐛 Extend IIS web.config to allow colons in URLs Closed: won't fix

Speaking as someone who has managed an IIS server for a D7 site, +1 for this.

I have tried reaching out to people who care about IIS / Windows servers in the past to get feedback/reviews without a response.

If there were a "Maintainers.txt" entry for a Windows person who would be available that seems like a potential alternate path, but without that...I'm in favor of this change.

Updating title, tags and version number based on recent announcement at https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →

I think if we're going to unsupport Windows, we should explicitly unsupport Windows. Otherwise, I think we should continue to maintain web.config. And I would want usage stats before making a decision.

We should also compare said usage stats for the usage stats to postgres and keep that in mind for the decision.

Windows can run Apache though so we wouldn't be dropping support for that.

We could possibly drop support for 'Windows in production' - which would mean we'd still let you run Windows + Apache (or Windows + IIS) locally, but no security support for running it in production/any issues reported publicly.

Another issue where 🌱 Telemetry initiative Needs review would help - would love to be able to get stats for OS and web server sent back to d.o and collated.

re: #13, one difference between postgres and windows is that there seems to be an active community of testers and automated testing for it. While with windows, we have to depend on a non-existent community with no automated testing.

I'd be in favor of non-production support for Windows. Also, Windows supports WLS2; which is the recommendation I see recommended more and more these days.

With postgresql, quite a long time ago, we couldn't run core tests on it because they failed, and it was nearly unsupported in core, and then we basically created a 'use it or lose it' ultimatum. If we could get it to the point where tests were 100% pass, it would stay in, but if not, it would be moved to contrib. In the end people actually helped to fix the bugs, we got to 100% postgresql pass rate, enabled on-commit testing and it's still in and is now actively maintained.

However, even if we had maintainers for IIS support, I don't think we're going to add windows server support to DrupalCI, maybe if Microsoft paid for it (and the engineering time) in perpetuity, but potentially not even then?

Re-titling to reflect discussion.

This would also mean that security issues that affect only windows, or are more severe on windows would likely not be handled in the private security process.

I believe that is an improvement to the current process where we have had some issues that required core contributor and security team attention in private, but could have been fixed in public by the people who are interested in Windows-related issues.

Is there a tag to use to associate all these issues in the public queue? I think we would ideally tag them "Windows, Security" or something to make them easier to find for people who care about them.

Updating the proposed resolution to reflect this.

Moving this to needs review since I think we have a better idea of what's being proposed now.

Drop support for Windows in production

Why only production? why not also for development as well? Leaving for development maintains a requirement to maintain support for Windows inside core, which leads to possible deployments still occurring on Windows and a need to still write tests cases for Windows. To me I would expect such a decision to be an 'all or nothing'.

As a Contrib maintainer, of course I would love having one less environment to keep track of when developing and try and fire up when a bug-report comes in. As a sysadmin I have no plans to deploy production on Windows (not even Docker or WSL) in any of my deployments.

I will however repeat the notions given above that it is vastly different to not provide an IIS config, vs not supporting the Windows platform. As noted in #14 a site deploying Drupal on Windows does not mean they have deployed with IIS, that makes this a fairly big jump from the original request that is at least worth

Actual manual configuration of apache for local development is very optional these days.

I'll note that the Apache Foundation documentation recommends against using .htaccess files if you have access to the main httpd.conf file. The .htaccess overrides are not even enabled by default in a stock Apache configuration, site owners still have to take action to validate their site is 'protected' though there are at least attempts to validate .htaccess files are present on disk. I contend these are more 'best effort' files and shouldn't themselves be considered the limitations of what platforms are supported.

The fact that there is no routine Windows testing is a valid point, of course I could say similar about any of the *nix type platforms except the one basic Linux that is used for the DrupalCi images. Its not uncommon for a platform agnostic technology to be tested only on a small subset of platforms. The lack of Windows usage however doesn't mean it shouldn't also be supported at a 'best effort' level.

This would also mean that security issues that affect only windows, or are more severe on windows would likely not be handled in the private security process.

I'm actually more concerned about how this will be implemented if we keep Windows as a supported development environment but not a supported production environment.

It seems reasonable for a researcher to do development work on a development platform. If a vulnerability report comes in from a researcher on Windows using Windows syntax how will the DST respond to the report? Will the DST dig into it deeper creating their own test case and lab on *nix looking how it could be exploited or will they approve the vulnerability for publication based solely on the report being made against a Windows deployment? If they do investigate how much time will they give it trying to create a *nix confirmation? Security issues are a notoriously complex situation, in my opinion we shouldn't generally be limiting what is considered a security issue we should be expanding it.

Addtionaly a public disclosure of a a vulnerability report, even if it only impacts non production system, still can impact how Drupal is viewed in the public eye, especially if it happens to be made with by the reporter with the inclusion of a fix that the DST declined to implement privately.

If this is to be adopted I would think that to avoid the scenarios above one would want to drop Dev support and combine with a crippling commit preventing the site bootstraping to avoid those sorts of concerns and make it abundantly clear that Drupal should not be executed on Windows. That of course would later be followed by removing all Windows support code from Core.

If a vulnerability report comes in from a researcher on Windows using Windows syntax how will the DST respond to the report?

If the vulnerability affects *nix / Apache then the security team would handle it in private with a security advisory.

If it affects windows only then we would make it a public hardening in this queue with Issue tag for "Security".

If it affects windows at a higher severity than *nix then there would be a judgment call and if we determine it can be public for the *nix case then it would move public.

Would this affect Wampserver? With apologies to for stating the obvious: Acronym -wise this stands for Windows, Apache, Mysql and PHP. I use it locally to test new Drupal releases and to learn and practice with Composer commands before updating a site on shared Linux Hosting.

While I could climb the learning curve and use the WSL I have installed, Wampserver currently works just fine and one less learning curve to climb would be great.

The proposed changes are:

• Add documentation in the security team handbook saying we don't cover Windows-only issues
• Remove the shipped web.config file from core, move the contents to a page on Drupal.org similar to nginx examples [needs issue]

I think the scenario described in #24 is unaffected by those 2 current proposed changes.

@greggles

I believe commenting #12 and #19 changed the scope to be ALL
Windows, otherwise we would still be discussing un-supporting IIS not “Windows”

I think if we're going to unsupport Windows, we should explicitly unsupport Windows. Otherwise, I think we should continue to maintain web.config. And I would want usage stats before making a decision.

One thing is dropping the security support and removing the IIS config, but dropping the whole Windows support (and probably someday introducing some incompatible changes) could make the situation worse for all existing Windows + Apache installations..

And that leads to #12:

And I would want usage stats before making a decision.

This clearly says "WIndows in production", mainly for security issues. It isn't about entirely dropping Windows support. If an incompatible change occurred for Windows and Apache or some other Windows setup for _development_ purposes, it would still be supported. What this is proposing is that we remove the shipped IIS config and put it on par w/ Nginx. We've never shipped Nginx, but it is still supported. And we remove explicit security support, meaning you wouldn't want to run this in a production environment.

Since we don't have any test coverage for Windows and very little production installs of Windows/Drupal, what is proposed here is making reality in line with actuality.

I agree, but @catch also said:

we'd still let you run Windows + Apache (or Windows + IIS) locally, but no security support for running it in production/any issues reported publicly.

For me this means, that if there will be some incompatible change introduced in the future, then existing sites running for example Windows + Apache (I do not know the numbers) will be stuck, because no public issues will be supported. Please correct me, if I am wrong. The issue summary update will definitelly help.

I am 100% for dropping IIS support as I have personal experience with some sites on this configuration and it was pain. But cannot say the same about Win + Apache (especially without usage stats).

any issues reported publicly.

I think what this means is, that any security issues that only affect Windows will be reported (and potentially dealt with) in the public issue queue. So if you are on Windows and you want to work on the (hypothetical) future incompatibility/get the issue to RTBC, that's fine, go ahead. As long as you're only running Windows in development, you should be fine. It doesn't mean that we don't care about an issue a user might have on Windows + Apache for example, it just means that if it's a security issue, the issue will be filed in the public queue, where it would otherwise have been dealt with in the private issue queue.

While Windows support wont be as bad as #29, I would note, I believe technically any Windows bug would likely be no more than a priority Normal because it has "no significant impact" and is by community consensuses is "not important". That absolutely applies to Windows + Apache in the current scenario of dropping all production Windows support. That can indeed lead to incompatibilities given time as it receives less and less targeted support. I can't speak to most core dev's, but I can say I know I wouldn't focus on Windows issues if its not a supported production environment platform.

I'm still more concerned about a scenario similar to as follows:

Say I discover a vulnerability, for sake of argument something like say SA-CORE-2023-005. I report it using ONLY Windows examples because I only developed and tested on a Windows machine. Ultimately *nix is also vulnerable, but all the examples I provide are Windows and I make no acknowledgment of *nix because either I didn't test it at all or I couldn't think of how to use the same vulnerability in *nix. How sure are we the DST will see that the root cause actually impacts *nix and Windows and insist on a private disclosure vs immediately saying "this is a Windows vulnerability as such it may be publicly disclosed"?

The real issue here is that moment the DST says "we will not fix that in private" a security reporter is generally seen as entitled to publicly disclose and analyze the issue, no matter where it takes them, and the public is generally free to discuss the issues and evaluate what larger concerns they may raise. The DST can't stop this from occurring at that point and now may have to respond retroactively, without support of the original reporter.

It is is not always easy to see how a small vulnerability can snowball into a much more expansive issue until you have spent significant time investigating them. This is why I tend to generally lean to fix any security vulnerabilities in private, and to fix them quickly, you never know when one apparently small isolated vulnerability is exactly what is needed for a larger exploit.

How sure are we the DST will see that the root cause actually impacts *nix and Windows and insist on a private disclosure vs immediately saying "this is a Windows vulnerability as such it may be publicly disclosed"

Thanks for voicing this concern. I am quite certain the security team attempts to replicate issues on a variety of environments and respectfully seeks additional information where needed.

While Windows support wont be as bad as #29, I would note, I believe technically any Windows bug would likely be no more than a priority Normal because it has "no significant impact" and is by community consensuses is "not important". That absolutely applies to Windows + Apache in the current scenario of dropping all production Windows support. That can indeed lead to incompatibilities given time as it receives less and less targeted support. I can't speak to most core dev's, but I can say I know I wouldn't focus on Windows issues if its not a supported production environment platform.

While this is probably true, I think this is already the current state of affairs. It was already noted previously in this issue, that there is no test coverage for Windows and not a lot of Windows users are involved in the issue queue, so an issue affecting only Windows is not likely to get a lot of attention, which is one of the reasons why it was proposed to drop support in the first place. If however a serious compatibility issue would arise and enough Windows users worked on a fix or were available to test fixes and RTBC the issue, a fix would probably still be committed.

Say I discover a vulnerability, for sake of argument something like say SA-CORE-2023-005. I report it using ONLY Windows examples because I only developed and tested on a Windows machine. Ultimately *nix is also vulnerable, but all the examples I provide are Windows and I make no acknowledgment of *nix because either I didn't test it at all or I couldn't think of how to use the same vulnerability in *nix.

This is probably a scenario that we would have to trust the security team will catch during triage and I'm willing to do that. I think looking at how a Windows issue might affect *nix is most likely a lot easier than looking at how a *nix issue might affect Windows given the current composition of the team. I'm certain the team can and will handle that.

This is why I tend to generally lean to fix any security vulnerabilities in private, and to fix them quickly

I'm not going to comment on the private vs public issue, I think you know my opinion on that one and in the end that is a related but different discussion that is already going on elsewhere in the queue. But fixing issues more quickly is also one of the reasons that were mentioned here for making this change. From following the comments here I get the impression that in the past some fixes for *nix were delayed because there was not sufficient resources to look into how an issue affected Windows or to validate a proposed fix on Windows. Given the current involvement of Windows users in the issue queue (just based on my personal impressions and what has been said here previously, not based on hard numbers of course) this isn't likely to change anytime soon, especially if we're also looking for security experts.

Isn't it then ultimately better and more honest to our users and community to acknowledge that we just don't have the resources to support Windows at the moment instead of keeping the status quo?

I think what this means is, that any security issues that only affect Windows will be reported (and potentially dealt with) in the public issue queue.

Yes this is what I mean/meant. If we drop Windows support on production, then we'd still accept bug reports on windows (based on using it for development), but security issues that only affect windows (or are only notable on windows) would move to the public queue. Part of deciding whether something moves to the public queue or not is figuring out whether the implications are wider than the original report.

I agree with #35 and think that this should become a [policy, no patch] issue to drop support for Windows in production, where we decide on an implementation date and then the security team issue a PSA to inform the wider community. After that I think we should have two followup issues: one to add a deprecation notice to web.config and add a warning to the status report for users who are on Windows, and a second to finally remove the production web.config and any other remnants in Drupal 11.

I also agree with #33 in that if a security report is received that is Windows-only, it should still go through the normal triage process and the team should either try to reproduce in *nix or ask for further information instead of just dismissing it - as stated Windows issues already take longer to process and effectively nothing will change there, but at least we are more upfront about the true situation.

Re-titling since we'll have 10.x things to do and per #36.

I'll add one more note:

If the DST modifies the policy to permit the public disclosure of Windows vulnerabilities without the prior review of the DST (the same we have for reporting username leaks and similar) a vulnerability that impacts *nix may never be reported before publication. Significant care should be used when updating the DST policy to ensure such broad permission to disclose is not granted and at the same time putting no expectation on the vulnerability discover to perform additional research before publication.

@FeyP
I did want to at least acknowledge that I agree with you that it is important to be honest with the users about how a platform is developed and amount of testing it undergoes.

I think the D7 EOL notice and the other posts here signals the DST has already settled on a hard stance that Windows is going no longer be covered going forward, as such I won't provide any counter opinions to the previous comments.

Thanks for #38. Updating the issue summary to be more specific about whether the reporter should go to private or public - the answer is private at first as you point out.

Spotted this in the Azure docs at https://github.com/Azure/app-service-linux-docs/blob/master/Runtime_Supp...

If you are currently targeting Windows for PHP development, we advise to plan for migrating development to target Linux. After November 28 2022, Linux will be the only OS supported by future versions of PHP and continued feature, quality and security updates.

Not sure if this means the PHP project itself are dropping support, or just Azure, but it's another datapoint that Linux is the primary platform for PHP.

I read the issue summary and comments. I found that all questions were answered, they were mostly about how security issues were to addressed. However, there was a suggestion Drupal should drop support for Windows explicitly. There were replies to this which provide perspectives on supporting development on Windows. xjm would like usage stats before making a decision. In the 7 months since then there have been no comments sharing usage stats. Overall, there is support for the change.

I have updated the IS a bit and added Drupal 11 to the title.

I also support the change and changing to RTBC.

Should we open a child page of Web Server Requirements → and add a link at the Microsoft IIS section → ? Or is there some better place to put the example web.config page?

p.s. Also found https://www.drupal.org/docs/user_guide/en/install-requirements.html → referencing IIS.

@dww, thanks for thinking ahead on this. The suggestions seem reasonable. I read the User Guide page and while I don't think the page needs changing we should inform the maintainers of the change, when it is approved.

And, more importantly, I forgot to say that this issue is now in a 14 day confirmation window being used by the core committers. It is rather new and we are still getting used to it. The method can be read in the Issue Summary of #3389468: Document how the core committers reach agreement → .

@xjm asked for usage stats in #12, I did look for these and didn't find them anywhere - i.e. you can find the percentage of sites using Drupal, using IIS, using windows server, but not the intersection of them. I should have documented the research I did here even though it didn't get far , but looks like I didn't...

I've updated the issue summary with the overall trends: IIS, Windows Server, and Microsoft's support for PHP on windows server (via Azure) are all in dramatic decline.

Another way we could get data would be to do a survey, but I think that's unlikely to get us reliable data in this case:

If 100/100 host on non-windows. this doesn't tell us that no-one hosts on windows, just that no-one responded.

if 1/100 host on windows, this doesn't tell us that 1% of sites host on windows, it could be a lone windows server hold-out who would also be 1/1000 or 1/10000 if the sample size was bigger.

If 10/100 or 20/100 host on windows, that would be a shock and a sign we should reconsider, but I don't think that 's ever going to happen because anecdotally we just do not get any contributors talking about windows in production so for it to be such a high percentage would be unheard of. We'd have to have an outsize windows server usage well above the popularity of windows server itself.

@lauriii brought up the idea of doing an RFC, and that might be a good option:

i.e. a core blog announcement that we want to do this, with x amount of time for feedback - this will have the widest reach we can do without just announcing it.

If we get a sudden outcry we'd know there are some secret Windows server users out there (but I would still want to drop support unless someone is going to pay for a windows gitlab test runner and all the work necessary to support it), if there's no outcry, we can be pretty confident then. But I would also be happy (in both the emotional and level of confidence senses) to go ahead without that stage too based on the overall trends both in the issue queue and from w3tech, and that we've never had automated tests on it.

There's also PSA way which looks more direct then core blog

xjm → credited lauriii → .

Adding credits for Slack discussion about how to handle getting at least some data or feedback from the community on the decision.

I might prefer to deprecate Windows support in D10 and remove it in D12 if these options are too inconclusive or show more Windows than we expect.

Oh, and this is NW until we sort our RFC etc.

A discussion on Reddit where one user mentions they "manage 60+ small to medium Drupal sites running on Windows servers with IIS without any issues whatsoever": https://www.reddit.com/r/drupal/comments/18kuewv/windows_server_in_produ...

Updated the IS with the task of creating the RFC and started a doc for that.

Posted an RFC → for community discussion.

From database perspective I have had clients using Azure SQL as researchers are often working there. No issues using contrib https://www.drupal.org/project/sqlsrv → though and I asked platform.sh just a couple weeks back and they were happy to update driver support in php to 8.3 (was previously 8.1) so for those hitting this issue worried about connecting to such a database hopefully that helps.

From a development environment perspective: as mentioned earlier WSL2 is a good option for Windows users. If you come across this issue and are worried if you can continue using Windows I would encourage you to try out https://ddev.readthedocs.io/en/latest/users/install/ddev-installation/#_... - I have had colleagues successfully use it fine across multiple big projects and Randy has a good test suite set up to make sure it continues to be supported there (https://ddev.com/blog/ddev-local-automated-testing/).

I have not encountered ISS yet in my professional carreer. However I did work on a few projects which used MS Azure and must say the process was not fun at all. Besides that performance was very poor and it took a lot of time and effort to get it to run somewhat well without slapping a huge amount of resources on the server. Azure itself also still has to my knowledge it's issues (DB level), but that's off topic here.

In my opinion it perfectly makes sense to only allow linux environments. With the more modern approaches of Docker images and Kubernetes clusters I really don't see any problems with that. I think if this decision lands, this would even push "Windows only" clients into a more open source street, which is a positive side effect 😉

Hi all, I'm one of the maintainers of the the sqlsrv module https://www.drupal.org/project/sqlsrv → and from what I can see this change shouldn't change anything with respect to that module for sites using SQL Server either as the primary database or as an auxilliary database. I suspect most users of the module are hosting in a Linux env and just using SQL Server for database (which is my own situation), however I'm guessing we're more likely to have above average Windows + ISS users versus the rest of the community, so I've posted in the #sql-server Slack channel to publicise this RFC.

I have, in the past, supported a D7 site on Windows/IIS, and I've had inquiries about the possibility of running a corporate-internal D10 site on Windows. This is to say, there are still a few organizations out there who run Windows server networks internally, but still have an interest in using Drupal and other open source software.

I think it's fine to drop IIS support. However, I think we need to distinguish that from "Windows" support. For example (and I haven't tried this), I've read it should be possible to use a Docker-based solution to run Linux with Apache or Nginx and PHP on a Windows host. In such a scenario, Drupal may not be relying directly on Windows, but it would still be running on a Windows server.

• What I'd like to see is a conclusive statement about what is or is not being supported by the security team. Is it IIS, or anything where Windows is involved? I'm seeing allusions to both of these in the previous comments.
• If possible, if anyone has experience/expertise and can share, I'd like to see the documentation updated for "Best practices when running Drupal on Windows using Docker" or something along those lines. If my situation ever gets beyond inquiries and I have to figure it out, I'd be glad to contribute to such documentation, but I hope I'm not the first to even think about trying this.
• Overall, I think I am more concerned about community support rather than security support, if that distinction makes sense. I know Windows is an edge case, and I'm unconcerned if the DST needs to exclude IIS and the Windows OS from security support. In a Docker-based scenario, chances are, any security issue would be more related to the architecture within Docker rather than the host anyway. What I would like to see is sharing of best practices by those who have had to support this use case. And to avoid a blanket "We don't support Windows" statement, but a more nuanced, "If you must use Windows, here is an approach that works."

Thanks to the DST, core maintainers, and everyone else who has put so much thought into this. I'm writing this to share my limited experience with this scenario. If there is more I can do to help, let me know.

I've read it should be possible to use a Docker-based solution to run Linux with Apache or Nginx and PHP on a Windows host. In such a scenario, Drupal may not be relying directly on Windows, but it would still be running on a Windows server.

This would still be supported more or less by default because we support running Drupal on linux in docker, and what exactly docker runs is not usually taken into account. As you say:

In a Docker-based scenario, chances are, any security issue would be more related to the architecture within Docker rather than the host anyway.

Agreed with this - I can't think of a situation where there'd be an issue, especially a security issue, specific to Drupal on docker on windows, as opposed to a generic Drupal issue or a generic Docker issue.

However dropping support for directly running on Windows in production also means dropping support for apache on windows, not just IIS on windows - just to make that clear. We'd still accept bug reports from people using windows + apache (or even IIS) for local development, but any security issue would be made public as long as it's really windows-only, and we'd stop shipping the IIS file.

I tried to update the issue summary to make this a bit clearer, although the wording probably needs improvement.

My guess is that the organizations that use Drupal in a purely Windows environment are in the government or education sectors. I say this because I work in the education sector that is nearly exclusively a Windows environment. We have a 70+ site multisite running in IIS.

Something I think that is overlooked in your stats above is sites that don't "phone home". After the issues with SolarWinds, our organization decided to prevent traffic like this on our servers. Updates are done on other computers via composer and uploaded to the web servers. I'm guessing that my organization isn't the only one that does something similar.

I realize that my organization is in the minority here, but it's only because the post in the sqlsrv driver Slack channel that I was even aware of this RFC. My personal opinion is that this RFC isn't allowing enough time for the affected organizations to find out about it in time to make comments on it. I believe this RFC should have come out when Drupal 10 was first started to be worked on if it was going to go away in Drupal 11.

I'd recommend allowing more time for comment by "advertising" it in all the Drupal 11 updates and then remove it in Drupal 12. This would allow organizations like mine more time to work on accommodations for this change.

Either way we'll figure it out. 3 weeks time to discuss this seems a bit too hasty.

Apologies to the community for not returning to this around the due date, 2024-03-08. I was occupied by family needs, a holiday and DrupalSouth.

Thank you to the 5 folks who commented on this post the RFC. All of those supported this change. Following is a summary of points I took from those comments.

• There is https://www.drupal.org/project/sqlsrv → which is used by 2,030 sites. A maintainers of sqlsrv supports the change.
• platform.sh responded promptly to a request to update driver support.
• Windows users can use ddev for development, https://ddev.readthedocs.io/en/latest/users/install/ddev-installation/#_...
• This may encourage more 'Windows only' clients to a more open source solution
• 3 weeks was not sufficient consultation time for the RFC.

And in #57 suggested some followup work.

1. Conclusive statement about what is or is not being supported by the security team.
2. Update documentation for "Best practices when running Drupal on Windows using Docker"
3. Overall, I think I am more concerned about community support rather than "If you must use Windows, here is an approach that works."

I'll respond to those in the next comment. For now, I am changing this to a child of 🌱 [11.x] [meta] Set Drupal 11 platform and browser requirements at least six months before the release Active

3 weeks was not sufficient consultation time for the RFC.

The consultation time is determined by common sense and what is considered appropriate for the topic. There is also no core change policy for this point. Because this is specific to platform requirements I've added consideration of consultation time for any RFC to the parent issue. And since that issue will be used as a template for the similar issue for Drupal 12, the concern about time will be preserved. If a better place for this info, it can always be changed.

As for the 3 points in the 'summary' from #57.
1. This is already in the proposed summary but I have added it as a remaining tasks with the text from #37.
2. The best practice for local development is to use DDEV. This is approved in core ideas issue, ✨ Recommend DDEV as the default Drupal local development environment Active .
3. The documentation for local development is being updated for DDEV in #3398293: Consolidate local development environment documentation to recommend DDEV → and that issue summary lists the page for Windows as one to be updated. So, that is the place where contributions can be made for improving the documentation for users for Windows.

That should address concerns from the comments post the RFC.

I've updated the remaining tasks. I reviewed the earlier comments and again see support for this change. Therefor I am setting to RTBC for signoffs.

For an additional data point, I've had to deliver and/or evolve/support Drupal on Windows servers, always as part of global company policy in "sensitive" intranet situations; but I always got agreement to run those on Apache, not IIS: even their internal IT and datasec people agreed to that setup.

My point here is, since we want to drop "windows" in production, does it have to be Windows stricto sensu or just IIS as most of the discussion mentioned: since the IS mentions that we intend to maintain Windows as a dev environment, is there anything specific that pertains to running in production besides IIS ?

The issue summary only really mentions IIS as the problem; given we obviously support Apache on Linux then perhaps we should continue to support Apache on Windows, and explicitly drop support only for IIS? Bumping back to NR as this is a very important distinction to make, and perhaps deserves retitling the issue and policy.

Add link to the RFC to the issue summary.

I originally just opened this to drop support for IIS, so that we could stop shipping web.config. For an example of web.config making things complicated, see 📌 Add .user.ini Needs review where it's causing extra work this week.

Where dropping windows support in production would probably make a difference is if we had a directory traversal attack or similar that was worse for windows than it was on linux, then if people aren't hosting on windows, they wouldn't be affected by it, and the severity of an issued SA would be lower etc. There might be other situations where something is specific to windows like this. Can't think of specific examples and we deliberately don't give too many details of vulnerabilities in SAs so it's hard to go through to try to find one. This is why the scope got expanded around #11-#15.

Expanding the scope definitely means this is getting harder to land though, maybe we could open a spin-off issue to drop support for IIS and leave this open to discuss windows support more generally, or the other way 'round?

If the question is about the web.config file, then I wonder why we have no config for the most popular webserver - nginx (>30%} but IIS (3-4%) is preserved

re #67, that is ✨ Provide documentation/default server block for Nginx server. Needs work . It's an interesting question and I think could help us decide that we should cut IIS and windows support to help us focus on more popular platform combinations.

Thanks for the input @andypost and @greggles, it makes sense to focus our ressources on open source solutions such as Apache and Nginx, and dropping Windows support.

Based on #66 I will make a new issue with the expanded scope and restrict this one to IIS.

The issue with the expanded scope is 🌱 [policy, no patch] Drop support for Windows in production in Drupal 11 Active .

Are the proposed text changes suitable?

I think we need to drop IIS support in Drupal 11, not at a specific date, because Drupal 10 still ships with web.config. This also gives sites on IIS time to switch.

Also, IIS sites don't *have* to switch, just they are on their own as far as writing their config files and debugging environment specific issues go (for the latter they were before, realistically).

Updated the issue summary a bit more to remove more about general Windows support, and changed the dropped version to 11.x instead of April 2024.

I am still wondering about whether we want to put the IIS config onto Drupal.org or just discourage using it altogether, but I think what we've got is enough to mark this RTBC, that's more of an implementation issue than a policy one and only affects d.o docs, not core.

Also opened 📌 Remove web.config from 11.x Active .

Removing the release manager review tag - all of us are in favour of dropping IIS, and we deferred windows support in general for now to a follow-up.

Updated Web server requirements for IIS, https://www.drupal.org/docs/getting-started/system-requirements/web-serv... →
Issue made for the User Guide per #44, 📌 Support for Microsoft IIS changed for Drupal 11 Active

I was about to update the security doc pagea listed in the Issue Summary but that doesn't really make sense. That section refers to what version of Drupal are supported not Web servers.

Thanks for opening the followups. Added this as parent of 📌 Support for Microsoft IIS changed for Drupal 11 Active .

Issue summary still has "Update security docs with a conclusive statement about what is or is not being supported by the security team.", I think that still has merit. https://www.drupal.org/drupal-security-team/general-information#s-which-... → is the page I think? That itself is quite outdated. I think it would make sense to clarify that only supported environments get security releases?

All in all I agree with this change and as a core product manager I am removing the tag.

Adjusting credits.

@Gábor Hojtsy, thanks.

I have updated the security team docs with the suggested text in #78. I think that completes that task in the Summary so this is all done now.

I meant to close this as well.

Automatically closed - issue fixed for 2 weeks with no activity.