Configuring JIRA with IIS directly causes errors

[Sean Metts]

I'm using IIS 7.5 to set up URL re-directs and I'm having issues.

This is the doc I'm trying to follow when it comes to instructions:

https://confluence.atlassian.com/display/JIRAKB/Integrating+JIRA+with+IIS+using+ARR?focusedCommentId=710837193&#comment-710837193

My port for JIRA is 8080 and my IIS port for the site is 80. I did get the URL to redirect when making an attempt. However, I get a HTTP Error 502.3 - Bad Gateway "the server name or address could not be resolved" error with the following information below:

Module	ApplicationRequestRouting
Notification	ExecuteRequestHandler
Handler	ApplicationRequestRoutingHandler
Error Code	0x80072ee7

Requested URL	http://jira.domain.net:80/secure/MyJiraHome.jspa
Physical Path	C:\inetpub\wwwroot\secure\MyJiraHome.jspa
Logon Method	Anonymous
Logon User	Anonymous

At some point, I'd like to get Confluence and Stash set up this way too but for now, I just want to make sure I can get JIRA working. If anyone wants my contact info, let me know, I'm willing to do what it takes to get this going asap.

[Nic Brough -Adaptavist- · Accepted solution]

Did you follow the actual document, or the comment you've posted which seems to be ignoring most of the document?

[Sean Metts]

I'm following the document. Did I miss some steps or something? Should I post screenshots?

[Nic Brough -Adaptavist-]

Check your url rewrite rule, and that the url you are rewriting can be reached on the network first, then we'll need the details.

[Sean Metts]

Sorry for the long wait but here is my info: I'm trying to incorporate three IIS sites. One each for confluence, stash, and jira. Each were configured with their own port before IIS. Conf is 8090, JIRA is 8080, and Stash is 7990. The IIS sites all use port 80. I can start all 3 sites at the same time but eventually, only one works. This is probably because of the port 80 conflict but I'm not 100% sure. I made a https binding on each with the certificate we have from the server. All 3 bindings are port 443. As far as the info you requested with URL rewrite for the inbound rule, here you go: Match URL: Requested URL matches the pattern using Regular Expressions. The pattern is (.*) and ignore case is checked. Action: Action type is rewrite and the URL is http://localhost:[insertportnumberhere]/{R:1}. Append query string is checked and stop processing of subsequent rules is checked. Request filtering has all defaults checked and the double escaping as well. I hope this info helps. If you need more info, feel free to let me know.

[Sean Metts]

To clarify the https binding creation part, I made host headers with the instructions on this page: http://blog.armgasys.com/?p=80

[Nic Brough -Adaptavist-]

You can only run one thing on a port at any time. The point of what you're trying to do is to get IIS to run on port 80 and then gather parts of your site from systems running on other ports. Could you run through the original documentation again to get one of the applications running and explain what you've done differently and additionally?

[Sean Metts]

Sure thing,

Using Confluence as my example since it's up right now:

Steps 1-7 from https://confluence.atlassian.com/display/JIRAKB/Integrating+JIRA+with+IIS+using+ARR?focusedCommentId=710837193&#comment-710837193 were implemented as the document said except for changing the port number.

I skipped step 8 because I thought that just adding proxyName and proxyPort to the connector would be better than just commenting it all out and copying and pasting the example one and modifying it. proxyName is conf.domain.net and proxyPort is 80

I went ahead and made the DNS A record using the IP address of the server and the host name as conf.domain.net.

I stopped the Confluence service and started it again.

I did the same thing for the other two but made slight modifications to match their host name and port number.

I made the host headers with port 443 after all this and restarted the sites.

[Nic Brough -Adaptavist-]

Right, you need to change the port number to avoid conflicts, so you need to do the bits you've skipped.

[Sean Metts]

I'm just a little confused because I thought that if you added host headers with port 443 that you could still have the http bindings all use port 80? Can you clarify that for me.

[Nic Brough -Adaptavist-]

The host headers don't change what ports the applications are trying to use or how. Could you go back and do the bits you skipped? Just for one of the applications for now - once we have one working, the others should be modeled on it.

[Sean Metts]

Right now, I have all 3 working. However, I'm not sure how long all 3 are going to be up at the same time.As far as steps I skipped, I really didn't skip any except for 8 which was commenting out Connector which I didn't need to do. If I change two of the sites to different ports besides 80, wouldn't it change the links to jira.domain.net:81 and conf.domain.net:82? If I have to change two of the ports in IIS, should I assume to do the same in the server.xml files for each app with the proxyPort object? Would I have to change two of the https bindings too since all 3 of those use 443?

[Nic Brough -Adaptavist-]

You said you'd skipped step 7 as well as 8. I'm not entirely sure what you've done with 8 - you need the existing connector out and your new one defined, but I think that's what you've done. As long as the old one is gone the route (commenting it out, replacing it with yours or deletion) doesn't matter. Your next step is spot on - you want your systems to run on different ports, so you need to adjust them to do so, and then tell IIS where to find them on the new ports.

[Sean Metts]

I looked at my older comments just to make sure I interpreted my thoughts right. I only said I skipped 8 but you're right about me not needing to comment the original code out. Currently all three IIS sites have an http of port 80 and so do all three server.xml files with the proxyPorts. So what you're saying is that all I have to do is pick two of them and change the port numbers in IIS and then do the same in the proxyPorts in the server.xml fiels? This confuses me because in the original documentation, the person who created it never mentioned changing those ports to different ones and his example picture shows port 80 in all 3 IIS sites.

[Nic Brough -Adaptavist-]

Sorry, I was unclear on that. You should run the internal systems on different ports - lets say Jira on 8080, Confluence on 8090 and Stash on 7990. You want IIS to listen and respond to port 80 for all three sites. Then when someone lands on the jira site, it talks to jira on 8080 internally.

[Sean Metts]

It's not a problem. The server.xml's connectors are those exact three ports you mentioned for those three apps. The proxyPort value for each is 80 and the IIS sites are all 80 for each with the https bindings to be 443 for each regarding host headers. However, after awhile, the sites just go down and I don't know why.

[Nic Brough -Adaptavist-]

I'm sorry, I seem to have missed something - you've got this working, but it stops working after it's been up for a while?

[Sean Metts]

Yeah, that's where we are at right now with it. This morning when I remoted into the server, I saw that someone tried accessing those sites and it went to Verizon pages. I went ahead and tried them myself and they failed. However, they worked on another computer on our domain. I went back again to try them on the server and they worked. I don't have any idea why that is.

[Nic Brough -Adaptavist-]

Ok, so that's actually a problem on your network - I assume you are not restarting the applications? The fact they work on one computer and not on another really does scream that there is something wrong with the network somewhere.

[Sean Metts]

It hasn't been down yet today after getting in. This only seems to happen now after we leave. I wonder if there is some kind of timeout issue or not.

[Sean Metts]

Ok, so back to this today. Just now, jira and confluence both randomly had Verizon ISP search errors but Stash was still up. This makes me believe that there is some sort of conflict still. I tried those two on another computer and the same thing happens. So back to our settings....all 3 IIS sites have port 80 for http bindings, host header https bindings of 443, jira's regular port is 8080, conf's is 8090, and stash is 7990. Does that seem right to you?

[Nic Brough -Adaptavist-]

The search errors you are getting are down to the network not reaching the services, not the services being down. If you had a port conflict, the Tomcats simply would not start - you'd only ever be running one of the three services at any time, the other two would not start

[Sean Metts]

An update, we noticed that when we click on the JIRA header link, it tires to take us to localhost:8080/secure/MyJiraHome.jspa instead of jira.domain.net. I've also noticed that sometimes when we click on manage in Application Navigator that it takes us to localhost instead of the domain.net link. I don't think I missed any steps either when it comes to that doc we discussed. Have you seen this before?

[Nic Brough -Adaptavist-]

Ok, can you check that the "base url" of each application is correct? Especially JIRA (Admin -> General Configuration -> Base url - should be set to the external location of the service, not localhost). You'll also need to check that that is what IIS is expecting too.

[Sean Metts]

In the Base URL section in each app link the app links area, there are a couple app links that you can't delete and those are the baseurls with the localhosts. If we change those to hidden and add the domain.net ones in, those seem to work. However, the JIRA header link still goes to localhost. Is there a way to change that? I also thought that we weren't supposed to change the base url in the application itself and the point of the URL redirects was to keep those as URLs and just have them redirect to the domain.net ones? In IIS, each URL rewrite for the inbound rule has http://localhost:appportnumber/{R:1}.

[Nic Brough -Adaptavist-]

Um, no. You could be right for the IIS rewrite - as long as IIS is running on the same machine as the services, localhost should be fine. But the base url for the applications must be set to the url you expose to the outside world.

[Sean Metts]

Ok, so we changed the base URLs in the applications to match the domain.net ones. That seemed to be ok but eventually the verizon search assist comes back again rejecting our URLS in the browsers on the server. We notice that a general computer on the domain can still access the web sites but can't make any changes or additions that cross between applications. That in itself is odd. Eventually it could restore itself but this isn't something that should be happening regardless.

[Nic Brough -Adaptavist-]

Ok, so it now seems like you have the applications set up right. So it must be your network that is failing now.

[Sean Metts]

I eventually found that Windows Firewall was on. I turned that off through group policy and made the changes but eventually the Verizon errors came back when we tried to load the sites. I'm at a loss here at this point.

[Nic Brough -Adaptavist-]

Thing is, you keep saying Verizon errors. That tells us that it's not the servers at fault, because they would return standard errors. The Verizon errors you get are down to Verizon intercepting network errors, and strongly implies the error is on the Verizon side. I don't know how to debug a network that's handled like that, I've always avoided them because they're not standard.

[Malik McClellan]

We actually found the solution this morning. Our router is used as an alternative DNS in the IPv4 settings. When we pinged the sites, they were going to a re-routed IP from the Verizon FiOS. We removed that as an alternative DNS from the server and then it started to ping and tracert to the right IP address. We haven't had any downtime since then. I appreciate all your help sir. I was also wondering if you knew where I could find documentation on configuring those three apps to work externally on the web. I heard that Apache would be necessary for that?

[Nic Brough -Adaptavist-]

Ah, well found, rogue DNS services can be a right pain to track down! You don't need Apache to do this - IIS can do the same job, and in fact, what you've been configuring above is what you need to do! The next step should be just to open your network so that your domain can be reached by the internet.

[Sean Metts]

What do you mean by "open your network"?

[Nic Brough -Adaptavist-]

You need to expose the server to the internet if you want the applications to "work externally on the web". Provide a route through your firewalls from the internet to the server.

[Sean Metts]

We have the server IP added to the DHCP table already. The IP is reserved for it as well. Would I need to create outbound rules in IIS with the same information as the inbound rules? Is there more that I have to do on the firewall?

[Nic Brough -Adaptavist-]

On the firewall, I think you need inbound and outbound access. I don't think IIS needs anything else though.

[Sean Metts]

We configured it on the firewall. However, for some reason, it can only work within our network itself. It doesn't just have to be on domain computers anymore though. Now as long as you're within our network itself, you can get to the sites. So I feel like we are one step closer to the ultimate solution of allowing anyone to view the sites from anywhere. Now I'm thinking...do we need another IP address, outbound rules, more firewall configs? I'm spinning in a circle now. I'm going to do more research though. If you have any opinions or tips then feel free to add.

[Sean Metts]

Final Update: We got it all fixed now. That bad IP address from before was still patrolling outside out of the domain so we had to change our FiOS DNS. After that, we created port forwarding from our external DNS to the app server IP and created a firewall rule to allow it. All is good now and has been for over a day. Nic, I thank you for your help. Everything has been much appreciated. Have a good day sir.