Documentation for JIRA 6.4 (This documentation includes the project navigation sidebar). Not using this? See below:
(JIRA 6.4 without sidebar documentation | JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

The content on this page relates to platforms which are not supported by JIRA. Consequently, Atlassian cannot guarantee providing any support for it. Please be aware that this material is provided for your information only and using it is done so at your own risk.

This page describes how to configure Microsoft's IIS web server and JIRA such that IIS forwards requests on to JIRA, and responses back to the user. This is useful if you already have IIS running serving web pages (e.g. http://mycompany.com), and wish to integrate JIRA as just another URL (e.g. http://mycompany.com/jira).

JIRA is written in Java, and needs a Java Application Server (servlet container) to run. As IIS does not provide services of a Java Application Server, it is not possible to deploy JIRA directly into IIS. It is possible, however, to configure IIS to proxy requests for JIRA to an application server where JIRA is deployed. Therefore, if your main website is running in IIS, it is possible to integrate JIRA into this website.

If you need to integrate JIRA with IIS, JIRA needs to be deployed into a Java application server (such as Apache Tomcat), which provides IIS integration capability.

If you are running JIRA against an application server other than Apache Tomcat, please consult that application server's documentation to determine whether it is possible (and how) to integrate the application server with IIS.

To integrate JIRA with IIS you will need to:

  1. Configure JIRA and test that it works on its own
  2. Configure Tomcat to accept proxied requests from IIS
  3. Configure IIS to forward JIRA requests to Tomcat
  4. (Optional) Configure IIS to forward Confluence requests to Tomcat (if you are using both Confluence and JIRA).

1. Configure JIRA

  1. Follow the JIRA installation guide to install and configure JIRA; or deploy the WAR distribution into Apache Tomcat. Note that JIRA can be installed on the same machine as IIS, but this is not necessary.
  2. Change the context path of the JIRA web application:
    To allow IIS to proxy requests to JIRA, JIRA web application must be deployed with a context path (e.g. the /jira in http://localhost:8080/jira (http://localhost:8080*/jira*)) in Tomcat. The context path must be set to the path in the URL that IIS will use to proxy requests. For example, if your website is running with address www.example.com in IIS, and you would like to make JIRA available under www.example.com/jira, you will need to set JIRA's context path to "/jira" in Tomcat.
    To do this, edit the conf/server.xml file (or the jira.xml file if you are using the WAR distribution of JIRA). Change the path attribute of the Context element to "/jira".

  3. Restart JIRA after changing the context path.
  4. Set the 'Base URL' to include the context path (see Configuring JIRA Options).
  5. Turn JIRA's GZip compression OFF (since there will be no benefit from GZip compression once proxying is implemented).
  6. Test that JIRA works correctly by pointing your web browser directly at Tomcat (e.g. http://localhost:8080/jira) and going through JIRA's Setup Wizard. If you have completed the Setup Wizard previously, try creating an issue or editing one. Please ensure that no errors occur.

2. Configure Tomcat to accept proxied requests

HTTP/1.1 Connector

If you are using the HTTP/1.1 Connector, you will need to add the following attributes to the Connector port in Tomcat's server.xml:

Please refer to the Integrating JIRA with Apache for reference.

  1. Enable AJP/1.3 Connector in Tomcat: To allow Tomcat to accept requests for JIRA from IIS, edit the conf/server.xml file and ensure that the AJP/1.3 Connector is enabled (i.e. not commented out). To enable the AJP/1.3 Connector in a JIRA remove the comment symbols around the following section in the conf/server.xml file:

    The above example configures Tomcat to listen for proxied IIS requests on port 8009. If this port is already in use on the machine where JIRA is running, please change to another port.

  2. Restart Tomcat and ensure that no errors regarding used ports appear in the logs or in the Tomcat Console.
  3. Ensure that the AJP Connector is listening on the specified port (8009 by default). One way to do this is to use the "netstat -na" command in the command window and see if port 8009 is listed in the output:

3. Configure IIS to forward requests to JIRA

On the machine where IIS is deployed:

  1. Download the ISAPI Redirect DLL from the Apache site. When downloading, choose the version of Windows that IIS is running on (either win32 or win64), and then choose the latest available jk version.

    The file to download is named isapi_redirect_X.X.X.dll, where 'X.X.X' is the version number. You will need to remove the version number from the DLL file (i.e. it needs to be named isapi_redirect.dll).

  2. Place the DLL and the associated properties files in an installation directory. For the purpose of this document, we will assume the directory is C:\tomcat_iis_connector. Place the isapi_redirect.dll in this directory. Then download the isapi_redirect.properties file and place this in the same directory as the isapi_redirect.dll file.
  3. Create a directory called 'conf' in your installation directory (C:\tomcat_iis_connector\conf). Download the files uriworkermap.properties and workers.properties.minimal and place them in the C:\tomcat_iis_connector\conf directory.
  4. Create a directory called 'logs' (C:\tomcat_iis_connector\logs). This is where the logs associated with the isapi_redirect.dll execution will be placed.
  5. In the "C:\tomcat_iis_connector" directory you may need to modify the isapi_redirect.properties file. The isapi_redirect.propertiesfile tells the connector where to find its configuration files and where the DLL can be found in relation to the IIS server. There are 5 properties in this file:
    1. extension_uri — the path to the virtual directory that contains the isapi_redirect.dll
    2. log_file — the path to write the log file to
    3. log_level — the level at which the logs should be generated
    4. worker_file — the path to your workers.properties.minimal file in your installation
    5. worker_mount_file — the path to your uriworkermap.propertiesl file in your installation.
      If you are installing the connector in C:\tomcat_iis_connector and you follow the instructions below about setting up the virtual directory for the isapi_redirect.dll, then you should not have to change any properties in the provided file.
  6. In the "C:\tomcat_iis_connector\conf" directory you may need to modify the uriworkermap.properties and the workers.properties.minimalfiles.

    The provided files contain the changes mentioned here and should work if you completely follow this document. If you have deviated from this document, then you will need to modify these files as described below.

    The workers.properties.minimal file tells IIS where (IP address and port) Tomcat is running. The uriworkermap.properties tells IIS what requests to proxy to Tomcat.
    To edit these files:

    1. Edit the uriworkermap.propertiesand ensure that it contains the following mapping for JIRA. You do not need any other mappings.

      The mapping (e.g. /jira/) *must be the same as the context path that JIRA has been deployed with in Tomcat as described in the Configure JIRA section of this document.

    2. Edit the workers.properties.minimal file and modify the worker.ajp13w.host property if necessary. This property should be set to the host name or the IP address of the machine where Tomcat (with JIRA) is running. If Tomcat is running on the same machine as IIS then you can leave the property set to localhost. If you have specified a host name as the value of this property, please ensure that the IIS machine can correctly resolve it to the appropriate IP address.
    3. If you have modified the port for the AJP Connector you will need to modify the worker.ajp13w.portproperty. Here is an example of the file with Tomcat running on the same machine as IIS and using the default port (8009) for AJP:

  7. Open Control Panel, then Administrative Tools and open Internet Information Services.
  8. IIS 7.0 only: If you are using IIS 7.0,you will need to install two required service roles, ISAPI Extensions and ISAPI Filters:
    1. Navigate to Start Menu > All Programs > Administration Tools > Service Manager.
    2. Select 'Web Server (IIS)' in Server Manager > Roles.
    3. Click 'Add Role Services' and follow the Wizard.
  9. Add an ISAPI Filterto IIS, as described below:
    • IIS 6.0 or earlier:
      1. Right-click on Default Web Site (or the Web Site that should be responsible for proxying requests to JIRA), and click on Properties.
      2. Click the ISAPI Filters tab.
      3. Check if there is a Filter that points to the isapi_redirect.dll file and that it is in the right location. If not, click Add and create one. Enter tomcat as the Filter Name and enter the location of the isapi_redirect.dll file for the executable.
      4. Click Apply and then OK.
    • IIS 7.0:
      1. Click the Default Web Site (or the Web Site that should be responsible for proxying requests to JIRA), and click on ISAPI Filters.
      2. Click the ISAPI Filters icon.
      3. Check if there is a Filter that points to the isapi_redirect.dll file and that it is in the right location. If not, click Add and create one. Enter tomcat as the Filter Name and enter the location of the isapi_redirect.dll file.
      4. Click OK.
  10. Create a virtual directoryfor JIRA in IIS.
    1. Right-click on Default Web Site (or the Web Site that should be responsible for proxying requests to JIRA), choose New and then Virtual Directory.
    2. Go through the creation wizard. Set the alias as the value of the Context Path (without slashes) that was set in the Configure JIRA section of this document (see above). In our example this is jira .
    3. This can point to any directory.
    4. Complete the wizard.

      The reason for creating a virtual directory is so that requests without the trailing slash still work. For example, if you are deploying JIRA under http://www.example.com/jira/ without the virtual directory, then requests to http://www.example.com/jira will fail.

  11. Create a virtual directory for access to the isapi_redirect.dllin IIS, as described below:
    • IIS 6.0 or earlier:
      1. Right-click on Default Web Site (or the Web Site that should be responsible for proxying requests to JIRA), choose New and then Virtual Directory.
      2. Go through the creation wizard. Set the alias to be jakarta .
      3. This must point to the directory in which the isapi_redirect.dll is installed. In our example this is C:\tomcat_iis_connector.
      4. Complete the wizard, making sure that you grant the 'Execute' permission for the Virtual Directory by checking the 'Execute' checkbox.
    • IIS 7.0:
      1. Right-click on Default Web Site (or the Web Site that should be responsible for proxying requests to JIRA), and choose Add Virtual Directory.
      2. Set the alias to be jakarta .
      3. Physical Path must point to the directory in which the isapi_redirect.dll is installed. In our example this is C:\tomcat_iis_connector.
      4. Click the 'jakarta' Virtual Directory and double-click 'Handler Mappings'.
      5. Click 'Edit Feature Permissions' in the Action panel on the right-hand side.
      6. Check the 'Execute' permission checkbox.

        This Virtual Directory is needed for the connector to work. The alias that you give the directory needs to be the same as the path set in the isapi_redirect.properties file, extension_uri property. In our example this value is: /jakarta/isapi_redirect.dll.

  12. If using IIS 6.0 or 7.0, you will need to add the dll as a Web Service Extension,as described below.
    • IIS 6.0:
      1. Right-click on Web Service Extensions and choose Add a new Web Service Extension...
      2. Enter tomcat for the Extension Name and then add the isapi_redirect.dll file to the required files.
      3. Select the Set extension status to Allowed check-box, then click OK.
    • IIS 7.0:
      1. Navigate to the servers and highlight your server.
      2. Navigate to 'ISAPI and CGI Restrictions'.
      3. Add and allow the isapi_redirect.dll extension.
  13. You will need to restart the IIS Service. To do this, browse to Control Panel, click Administrative Tools, click on Services, find the IIS Admin Service and click restart.
  14. You are done! To test the configuration, point your web browser at IIS and append JIRA's context path to the URL. For example, if your website is running under the address of http://www.example.com and you have deployed JIRA with the context path of jira, point your browser at http://www.example.com/jira.

4. Configure IIS to forward requests to Confluence as well as JIRA

You can configure IIS so that it forwards requests to both JIRA and Confluence.

The following instructions describe how to forward from IIS to separate instances of JIRA and Confluence, running in separate Tomcat servers. The instructions assume that you have already set up IIS to forward to JIRA as described in section 3 above. The instructions also assume that you have already installed Confluence as per the Confluence Installation Guide.

The instructions describe how to make JIRA available under www.example.com/jira as described above, and Confluence available under www.example.com/confluence.

  1. If JIRA and Confluence are running on the same machine, ensure that Confluence is listening on a different port to JIRA:
    1. Edit the conf/server.xml file (or the jira.xml file if you are using the WAR/EAR distribution of Confluence).
    2. At the top of the file, change the port attribute of the Server element to a different port to the value for JIRA. For example, change it from 8005 to 8006.
    3. Still in the Server element, Change the port attribute of the Connector sub-element to a different port to the value for JIRA. For example, change it from 8080 to 8090 .
  2. Change the Confluence context path:
    1. Edit the conf/server.xml file (or the jira.xml file if you are using the WAR/EAR distribution of Confluence).
    2. Change the path attribute of the Context element to "/confluence".
  3. Restart Confluence after changing the ports and the context path, and test that Confluence works correctly by pointing your web browser at http://localhost:8090/confluence.
  4. Configure Confluence to accept proxied requests: Remove the comments around the AJP/1.3 Connector section in the Confluence conf/server.xml or jira.xml file and change the port attribute to a value different to the value for JIRA. For example, change it from 8009 to 8010.
  5. Restart Confluence and ensure that no errors regarding used ports appear in the logs or in the Tomcat console.
  6. Edit the uriworkermap.properties file and add the following mapping:

    The file should now contain the following mappings:

  7. Edit the workers.properties.minimal file:
    Change the line starting with worker.listto the following:

    Add the following lines to the end of the file (assuming the host is on the same machine as IIS and you changed the AJP/1.3 Connector port for Confluence to 8010):

    The workers.properties.minimalfile should now look like the following:

  8. Create a virtual directory for Confluence in IIS. Set the alias to confluence. It can point to any directory.
  9. Restart the IIS Service.
  10. You are done! Confluence should now be available under www.example.com/confluence, and JIRA should still be available under www.example.com/jira.

Troubleshooting

  • Whenever I go to JIRA in my browser, a login panel pops up. I enter a valid username and password for JIRA, but the panel pops up again.Make sure that you have Anonymous Access set on the jiravirtual directory in IIS. It will be set to that if you have followed the above instructions.To check this:
    1. In 'Internet Information Services', right click the jira virtual directory and choose 'Properties'.
    2. Click the 'Directory Security' tab.
    3. Click the 'Edit...' button in the 'Anonymous access and authentication control' section.
    4. Make sure that the 'Anonymous access' tick box is selected, and make sure that nothing is selected in the 'Authenticated access' section. Do not select 'Basic authentication'. Do not select 'Integrated Windows authentication'.
  • Whenever I go to JIRA in Internet Explorer, a login panel pops up. I enter a valid username and password for JIRA, but the panel pops up again. This doesn't happen, however, in another browser such as Firefox or Safari. I can successfully log in to JIRA in those browsers.Make sure that you have Internet Explorer's User Authentication set to Anonymous login.To check this:
    1. In Internet Explorer, click the 'Tools' menu and select 'Internet Options'.
    2. Click the 'Security' tab.
    3. Select the security zone that the JIRA server is in.
    4. Click the 'Custom level...' button.
    5. Scroll right down to the bottom to the 'User Authentication' section.
    6. Select 'Anonymous logon' (if it is not already selected).
    7. Click the 'OK' button on this screen, and again on the next screen.
    8. Restart Internet Explorer.
  • When I try to navigate to my JIRA instance at http://localhost/jira in my browser, it prompts me to download a file with nonsensical information, rather than showing me my JIRA instance.Make sure that you have granted the 'Execute' permission to your Virtual Directory for JIRA in IIS. See step 11 of the '3. Configure IIS to forward requests to JIRA' section in this document for detailed instructions.

Known Issues

  • 64 bit IIS: If you are running a 64 bit OS, please use a 64 bit version of the Tomcat IIS connector.
  • Customer submitted solution: If you must use a 32 bit IIS connector, you can do so by clicking Application Pools > Advanced Settings > Allow 32bit applications.
  • Customer submitted solution: You need to set the ISAPI extension on the website.

37 Comments

  1. For those who want to host both websites at IIS and JIRA at Tomcat, on the same machine, on port 80, there is a solution - as follows.

    It should be obvious that both IIS and Tomcat cannot both listen on port 80 at the same time, over the same IP addresses. Therefore, those that want this must already understand that they need different IP addresses available.

    The problem is that IIS, by default, listens to "ANY" (all) IP address(es) available on the machine (0.0.0.0:80). If we want JIRA@Tomcat to also be available on port 80 (obviously at a different IP address) we need to somehow configure IIS to not bind to ANY IP address, but to only bind to those used by websites that it serves. Fortunately, there's a way to do just that.

    All credit goes to Steve Schofield: http://weblogs.asp.net/steveschofield/archive/2007/07/06/iis7-post-44-iis7-and-apache-on-the-same-machine.aspx

    1. Open command prompt
    2. Type netsh
    3. Type http
    4. Type sho iplisten; result should be blank
    5. Type add iplisten ipaddress=xxx.xxx.xxx.xxx; repeat this for all IP addresses used by websites hosted on IIS
    6. Type sho iplisten again to verify
    7. Iisreset

    Configure JIRA to listen on one exact IP address. That will mean a few changes to [JIRA install dir]\conf\server.xml, and it's documented at the following two pages:

    Hint:

    <Connector port="80" address="xxx.xxx.xxx.xxx"

    I hope that helps others. It helped me. On the same machine, I now have websites at IIS all listening on 80 (and 443), on dedicated IP addresses, and I have JIRA working on its own dedicated IP address over port 80. I hate port numbers in URLs (which motivated me for this research), and I didn't quite like the solution with forwarding (described above) and the part about the path (/jira).

    Edit: I just finished setting up confluence on the same machine, same port (80).

  2. You may also be experiencing problems with operations that trigger DELETE or POST operations. In this scenario, you can check the IIS logfile and see if you have errors with the routing of http request, especially with DELETE and POST. This will usually show a 405 Error: Method not allowed. This can be solved by removing of the "WebDAV Publishing" feature on IIS (http://forums.iis.net/t/1163441.aspx).

  3. Here are some notes about our experiences with the isapi_redirect.dll.

    We are using a quite heavy machine to run the Jira, Fisheye, Jama Contour and Inflektra SpiraTest as Application Lifecycle Management solution. For over a year this was installed in a Windows Server 2003 environment with an IIS 6 and isapi_redirect.dll version 1.2.28. Because more and more department in our company started to use these services, we run into memory problems. So we upgraded the OS to Windows Server 2008 R2 and added some memory bars.

    And then a number of problems appeared: Either the IIS 7.0 process crashed from time to time because of NPE inside the isapi_redirect.dll or Fisheye did not work at all. In detail, Fisheye did only run with isapi_redirect.dll version 1.2.28. I did not get any newer version to run. But this old version has at least one bug, that causes the IIS 7 to crash. So I stood in front of the problem that Fisheye only worked with the old version and Jira only with the new version. (Of course I used now the 64 bit versions of the DLL. I did not try to use the 32bit DLL as mentioned above.)

    Then I found in one of the Fisheye documentation pages a hint to use the IIS Application Request Routing. With a little help from this blog entry I was able to get all services run. On request I could add here a more detailed description.

    1. Anonymous

      Felix, I too am running into the exact same problems.  IIS crashes randomly with the latest isapi_redirect.dll and Fisheye doesn't work at all.  How did you get IIS to stop crashing?

      1. Didn't realize I wasn't logged in.

  4. If you are running IIS 7, you may see 404 errors when trying to download/view an attachment with spaces in the name.  Jira generates the link by encoding the spaces with a plus sign instead of the %20 hex code, which IIS will reject for security reasons.  You can get around this by creating a web.config file in the "jira" virtual directory you created in step 3.10.d with the following contents

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
        <system.webServer>
        <security>
            <requestFiltering allowDoubleEscaping="true" />
        </security>
        </system.webServer>
    </configuration>

    Note that this will make your Jira installation more vulnerable to malicious URLs.  For more information see #11 in the list of breaking changes in IIS 7

    1. Anonymous

      Great Chad, thanks for this tip. We experienced this problem when we started to use IIS in combination with ARR proxy (so page is accessible via port 80). Attachments with spaces would produce links with + instead of space. When I added:

          <security>
              <requestFiltering allowDoubleEscaping="true" />
          </security>

       

      to webpages web.config it started to work smoothly.

  5. Is there any solution/authenticator to get JIRA working behind IIS using Windows Integrated Authentication via IIS just like it's done for confluence?

    Thanks, Philipp

  6. Hi

    Is any function to find out the first date of month like beginofmonth , pls help us.

     

    thanks

    --------------

     

     

  7. Anonymous

    I was able to run JIRA on IIS via a subdomain (jira.example.com) using instructions from this post

    Basically: 

    • This is a general point - Ensure on the IIS Site you are told to create, the binding is mapped to port 80 with a host header of jira.yourdomain.com.
    • In your JIRA\conf\server.xml file leave the path empty for the <Context path=""...> attribute where the wiki documentation tells you to specify one. Only enter one such as /jira for eg. if you are using sub-directories.
    • Ensure your JIRA\conf\server.xml file port attribute of the <Connector...> element is set to something other than 80 which IIS will be running on. For instance the default I believe installs to 8080 so leave it at that.
    • Lastly, in your tomcat_iis_connector\conf\uriworkermap.properties file used for the ISAPI proxy filter, make sure your worker entry is listed as: /*=worker1 and not /jira/*=worker1 which the documentation suggests you do.

    That should be it, now run an iisreset (at the command prompt) and reboot of your JIRA service and you're good to go.

     

    1. I wasted a lot of time trying to get this to work using subdomains for JIRA, Confluence and Crucible.  I'm a newbie at IIS and could not configure IIS to forward requests to Confluence as well as JIRA using these instructions.  I was getting an error:  Duplicate key '/*' detected - previous value 'worker1' will be overwritten with 'worker2'.  I ended up posting on the forum to figure it out.

      https://answers.atlassian.com/questions/28873/configure-iis-to-forward-requests-to-confluence-along-with-jira-subdomain

      I'm posting the answer here to hopefully help someone else.  Tino Winkler suggested the following which worked for me:

      "I had a similar issue: How to use one IIS to redirect to several instances on the same host having the same context-path (in your case none ;)). Finally I got it working. Let's see if I get it together:

      • create a new IIS Site for every other application you have to deploy
      • create copies of the ISAPI-Connector (the whole stuff, including configuration) in new directories for each of those applications and configure the port there
      • the virtual directory you are creating in your IIS Site must point to the related ISAPI-Connector directories

      Hope that helps."

      (it did help (smile) )

  8. Anonymous

    This article is horribly out of date. If running the current version (7.5) of IIS, a much better approach is to use the Application Request Routing and URL Rewrite modules to implement proxying 100% within IIS.

    Atlassian clearly doesn't understand the Microsoft stack and someone there needs to take the time to learn how to do this properly. Like it or not, the majority of businesses run on the Microsoft stack and Atlassian's integration story needs to be better than it is. 'Head in the sand' approach doesn't cut it.

      1. Anonymous

        To Atlassian:  Please update your documentation!!!  It is horribly outdated.

        I struggled for several days trying to get this working using IIS 7.5.  Finally I came across the same instructions for using Application Request Routing.  It was soooo much easier to setup!  I was up and running in minutes.

    1. Anonymous

      The company that I work with has an integration that works with JIRA. I came here to figure out why its not working, and the problem is likely due to the way that IIS is handling the redirect. I was skimming through the comments, and I just had to respond to this:

      "Like it or not, the majority of businesses run on the Microsoft stack and Atlassian's integration story needs to be better than it is. 'Head in the sand' approach doesn't cut it."

      I'm sorry, but nothing irks me more than false statistics. Please make sure to have a full picture before making false statements much like the one above. Maybe in your world the above is true. If this was the year 2000 I would would agree with you, but its not. Technology is constantly evolving. Hell, if JIRA was written today, I would bet it would be written in either a Django or Ruby On Rails instead of JAVA.

      I did a 30 second google search and here are some quick statistics I found:

      http://www.focus.com/fyi/50-places-linux-running-you-might-not-expect/

      http://en.wikipedia.org/wiki/Linux#Servers.2C_mainframes_and_supercomputers

      Like it or not, Microsoft's servers business is dying. IIS is the third most popular webserver:

      https://en.wikipedia.org/wiki/Internet_Information_Services#Usage

      http://royal.pingdom.com/2012/01/11/forecasting-nginx-and-iis-web-server-software-growth-in-2012/

      I think Atlassian is doing what's best for them as a business, which is focusing support on where the largest (Apache) market is. Hopefully, they will start supporting Nginx, as that is quickly becoming the new leader.

       

      1. Anonymous

        That's all well and good, but it still doesn't change the fact this page is really outdated.  The point is that it needs to be updated for those that are having problems getting IIS working.

        1. Anonymous

          I totally agree that the page is outdated and could use some love. (smile) At the same time, Atlassian makes it clear at the top that they don't support this configuration.

          This is like buying a car. You purchase a base model that is the recommended configuration they design. Then the owner of the car decides to modify it. Is it the manufacturer's responsibility to document and support the car owner's modifications? It's almost like having the owner complain about the cars manual because it doesn't have information  covering the owners customizations. Now, there are auto shops (Customware, etc...) that you can contract out to that will support the customizations. I'd probably be best for the owner to reach out to them for support. That's all I am saying.

           

      2. Anonymous

        I have multiple problems with what you said.

        1. Your feelings have been hurt because somebody stated that IIS is the most used webserver in the world without backing it up - and, even if that is true, in the context of why JIRA isn't better integrated with it wouldn't be a sound request because there are still gazillion places using non-IIS systems. OK, good, fine. You are right! But you're missing the point. The point is that JIRA is advertized as "integratable" in IIS, and it should then be that. The statement that you're complaining about, whether true or not, is trying to convey that there is also gazillion MS/IIS shops out there, just like there may be gazillion UNIX shops out there.

         

        2. You're defending the choice of technology JIRA was built on, and you do that by stating that it actually became before IIS? Is that what I heard? Are you serious? I'm pretty convinced HTTP server was running on MS system before anywhere else, although backing up that statement of mine would be pointless and unworthy. Regardless, JIRA is not older than IIS. JIRA is probably not older than ASP or PHP. Their choice of JAVA is terrible. Their continuing to develop that product (and all other products) is a WTF in itself. JAVA is a horrible choice compared to pretty much anything else. JIRA running on my windows system takes over 500 MB of RAM without doing any work. It goes up to 600-700 with just one user spending an hour on it. I can't imagine what kind of servers corporations with 1000's of users need to have to run this thing. Its performance is horrible. Horrible! They should rewrite the server app in anything modern out there. So, stop defending it. It sucks in how it runs. Its features are good, and I like them. But, its performance can't be suckier. So, no, they're not doing their best.

         

        1. Anonymous

          "Your feelings have been hurt because somebody stated that IIS is the most used webserver in the world without backing it up - and, even if that is true, in the context of why JIRA isn't better integrated with it wouldn't be a sound request because there are still gazillion places using non-IIS systems. OK, good, fine. You are right! But you're missing the point. The point is that JIRA is advertized as "integratable" in IIS, and it should then be that. The statement that you're complaining about, whether true or not, is trying to convey that there is also gazillion MS/IIS shops out there, just like there may be gazillion UNIX shops out there."

          Where do they advertise that? Can you show me links and facts instead of providing obscure generalities? Last I checked IIS isn't covered:

          Supported Platforms

          I guess the argument I was making was:

            1. Add facts to backup why support for this is important to encourage Atlassian to change its policy.
            2. Find a fix and share it with everyone.
            3. If 1 or 2 aren't your cup of tea STFU and deal.

          "You're defending the choice of technology JIRA was built on, and you do that by stating that it actually became before IIS?"

          Is that english? I'm pretty sure I was stating that technology evolves, and had JIRA been written today, hypothetically whoever wrote it might have done so in another language. It's kind of irrelevant I guess.

          "Is that what I heard?"

          Nope. I honestly have no idea where you got that from. If anything, I might be a agreeing that JAVA is outdated like IIS, but at the time it was the best option available.

          "Are you serious?"

          Angry much? #nerd_rage

          "I'm pretty convinced HTTP server was running on MS system before anywhere else, although backing up that statement of mine would be pointless and unworthy. Regardless, JIRA is not older than IIS. JIRA is probably not older than ASP or PHP."

           WTF does that have to do with anything? Congratulations, IIS is 1 million years old! Want a cookie? It's still a POS. Since you are obsessed with the who came first argument, I will bite:

          https://en.wikipedia.org/wiki/JIRA_%28software%29#History vs. https://en.wikipedia.org/wiki/Internet_Information_Services#History

          "Their choice of JAVA is terrible. Their continuing to develop that product (and all other products) is a WTF in itself. JAVA is a horrible choice compared to pretty much anything else."

          Cool when you make your own billion plus dollar software company you can write it in VB.net. Don't forget to take advantage of Microsoft Silverlight.

          "JIRA running on my windows system takes over 500 MB of RAM without doing any work. It goes up to 600-700 with just one user spending an hour on it."

          Java is pretty *cough*GOOGLE*cough* scalable, and in 2002 it was in a similar position as Python, Ruby, etc...

          Try disabling your antivirus. I'm not sure if  64-bit Windows Server still has an issue of handle multiple tomcat instances yet, but is that why IIS is still required? JIRA while not perfect is much better than a lot of alternatives out there. Performance probably has less to do with JIRA and more to do with your setup. You should probably take advantages of these docs:

          Crashes and Performance Issues Troubleshooting

          Now, where could JIRA improve? If they allowed for load balancing that could ease a lot of people's problems. However, then they would have to rewrite the back end to deal with all the race conditions it would introduce.

          "I can't imagine what kind of servers corporations with 1000's of users need to have to run this thing. Its performance is horrible. Horrible! They should rewrite the server app in anything modern out there. So, stop defending it. It sucks in how it runs. Its features are good, and I like them. But, its performance can't be suckier. So, no, they're not doing their best."

          You just need to RTFM. There are plenty of docs out there:

          Test yourself: http://blogs.atlassian.com/2012/04/performance-scale-testing-data-generator-plugin/

          https://confluence.spartez.com/display/SPARTEZ/Million+Issues+JIRA+-+Performance

          http://toolsmiths.blogspot.com/2008/02/evaluating-jira-multisite.html

          http://blogs.onresolve.com/?p=95

           

  9. Anonymous

    I got the ARR working for one site so far, but it keeps telling me my username and password aren't working when I go through ARR, if I go directly to it I can login.  Also wouldn't I have to create a rule condition like this one <conditions>
                            <add input="{HTTP_HOST}" pattern="confluence.mydomain.com" /> to separate the different sites.

  10. Anonymous

    Yup, horribly outdated. This seems like a very typical scenario, so it seems worth doing properly. Maybe if everyone bugs them incessantly on tech support (they don't like supporting our server configurations), they will be motivated to update this page. Anyway, why not provide an installation script to do all of this automatically during the JIRA install? Ease of installation should be more of a priority.

    I'll add notes as I find them, though I am definitely a IIS newb.

    isapi_redirect_dll is located in tomcat-connectors-1.2.35-windows-x86_64-iis.zip (version number subject to change of course) at http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/windows/



  11. If you get 400 Bad Request exceptions from your JIRA installation when running behind IIS try adding a web.config to the JIRA IIS folder with the following:

    <system.webServer>
    <httpErrors errorMode="Detailed" />
    </system.webServer>

  12. Anonymous

    Create a virtual directoryfor JIRA in IIS.

    1. Right-click on Default Web Site (or the Web Site that should be responsible for proxying requests to JIRA), choose New and then Virtual Directory.
    2. Go through the creation wizard. Set the alias as the value of the Context Path (without slashes) that was set in the Configure JIRA section of this document (see above). In our example this is jira .
    3. This can point to any directory. - Could some please clarify this directory - what should be the actual
    4. Complete the wizard.

  13. Please go vote for this issue so hopefully it wil be ranked higher in priority:

    JRA-30562 - Improvement of IIS Documentation Open

     

  14. Step 3. This can point to any directory. - Could some please clarify this directory - what should be the actual

    Please make it clear.

    1. I did not follow these directions.  I used  http://will.hughesfamily.net.au/20100112/jira-fisheye-and-iis7-using-application-request-routing/.

      However I am assuming this step is instructing you to point to any directory in the installation path. Does it work with your installation path  (/jira)?

      If that does not work, I highly recommend contacting Atlassian support.

  15. Anyone experience this error after the configuration:

    Directory Listing Denied

    This Virtual Directory does not allow contents to be listed.

     I am using II6 to configure and isapi_redirect seems to be working. 

  16. Please note that if the IIS 7 role/feature "HTTP Errors" is installed, IIS does not forward the "custom" error pages from JIRA / Confluence and instead displays its own error page, e.g. on 401 (unauthorized) or 404 (not found) errors. This is a problem in particular when those custom errors are being processed by JavaScript (e.g. after clicking a button on a page), since the actual error reason is then obviously "being lost by IIS".

    To cut it short: If you don't need it for anything else, remove the "HTTP Errors" on IIS 7.

  17. Anonymous

    When I try to navigate to my JIRA instance at http://localhost/jira in my browser, it prompts me to download a file with nonsensical information

    • another thing that can be wrong is that your 'Handler Mappings' for ISAPI-dll say '*.dll' in the Path. There is supposed to be just a '*'.

    Regards,

    David Vonka

  18. These instructions above will not work with the current redirector...  at all...

    Instructions here: http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html

    specify registry entries which are required by the current redirector.   The following is what was required for the redirector configured as specified above to work on an IIS7 setup on a windows 2008 server:

    Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINESOFTWAREApache Software FoundationJakarta Isapi Redirector1.0]
    @=""
    "extension_uri"="/jakarta/isapi_redirect.dll"
    "log_file"="C:\tomcat_iis_connector\logs\isapi_redirect.log"
    "log_level"="error"
    "worker_file"="C:\tomcat_iis_connector\conf\workers.properties.minimal"
    "worker_mount_file"="C:\tomcat_iis_connector\conf\uriworkermap.properties"

    I had entered this into a text file, changed the extension to .reg and ran it to import the keys and values.

    Without these registry entries, no matter what you do, the above instructions will not work with the most recent iis redirector.

    Don't forget to restart iis.

  19. that registry file should have slashes in the path, here's the correct one

    Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0]
    @=""
    "extension_uri"="/jakarta/isapi_redirect.dll"
    "log_file"="C:\tomcat_iis_connector\logs\isapi_redirect.log"
    "log_level"="error"
    "worker_file"="C:\tomcat_iis_connector\conf\workers.properties.minimal"
    "worker_mount_file"="C:\tomcat_iis_connector\conf\uriworkermap.properties"
  20. This method is becoming more and more troublesome. We have been using the re director for years and as web technologies advance with more and more requests it feels like the isapi redirect is having trouble keeping up.

    For example in JIRA 6 if you enter a search wrong instead of 'The operator 'is' is not supported by the 'parent' field.' showing up it will display 'Error occurred communicating with the server. Please reload the page and try again.'.

    Also we had a problem on older jiras that every 100 page requests that it would send a bad file for css or something similar. Now it seems to be occuring much more frequently where only the header will display, css styling is lost, missing javascript which is not resolved until a ctrl+f5. 

     

    I am looking into new ways to approch this problem, the reason we used this isapi redirect was because we host some iis websites on port 80. We then would setup DNS addresses to the same server and have iis forward these new aliases to different tomcat ports.

    Is it possible to use multiple aliases on different tomcat instances (confluence, jira, crucible/fisheye) binding on port 80 so we dont need to specify ports? Would be keen to hear someones advice on this matter. Thanks.

  21. Anonymous

    This is a complete nightmare. We have been fighting with it for days to get it to work.  After following all the steps above to the T, we still get a 404.  The URL is trying to resolve to http://{domain}/secure/MyJiraHome.jspa.  Does this page even exist?

  22. I'm using IIS 7.5 and found that I needed to change localhost to 127.0.0.1 on the following line in workers.properties.minimal

    worker.worker1.host=127.0.0.1

  23. Awful experience setting this up. Internally everything works wonderfully. I have JIRA running on our public facing web server on port 8080 (mysite.com:8080). Our corporate website is on port 80 of the same server. I have followed the above instructions to a T several times, no success. I don't want to open port 8080 on our external firewall and would prefer JIRA users to hit our public website on port 80, but add /tasks and have it redirect internally to 8080 (mysite.com/tasks). I've tried ARR, URL Rewrites, Virtual Directories, etc...and I cannot get it to work. Running IIS 7.

    1. We have a similar set-up here, where people hit IIS on port 80. This then uses AJP via the Tomcat connector to talk with the back-end application server. We have an additional hurdle being that users have to authenticate against IIS before anything works. That actually works fine for Confluence, but I could not get it to work for JIRA. The additional level of authentication in IIS seems to break most of the JavaScript code used by JIRA (Confluence works, though).

  24. I got an issue with login dashboard via IIS Url Rewrite (ARR) and found solution after spending hours. I'd like to share it here for anybody who has the same issue with me.

    Situation: I'm setting up a reverse proxy under http://my.domain.name/jira and http://my.domain.name/confluence.

    Symptom:

    1. Go to .../jira, login via the dashboard gadget, leave "remember me" unchecked. It just redirects you to the same page as you never logged in before. However, you can still log in with "remember me" checked or via login page (by clicking Login at the top right corner).
    2. After logged in by clicking Login at the top right corner without check "remember me", if you navigate to the url ".../jira" (without ending slash), you will be logged out. Confluence has the same issue when you navigate to "../confluence" (without ending slash).

    Solution:

    Always redirect to ".../jira/" or ".../confluence/" before rewriting:

    Reason: The session cookie path is set to "/jira/" or "/confluence/". If you rewrite directly "/jira" to the Tomcat "/jira/{R:1}", the session will be lost.