I've been bouncing my head over the following issue the last couple of days

I currently have the following set up:

I have a windows server 2012 with microsoft exchange 2013 CAS Role, RD Gateway, RD Web roles.

When I assign my domain certificate to the RD Gateway role it adds a new binding to the "Exchange Back End" website port *:443. This conflicts with the "Defauly Web Site" and stops the "Exchange Back End" website.

If I keep the 443 binding on the "Exchange Back End  website, OWA/Active sync dont work, but the RD Gateway is reachable externally.

When I remove the 443 binding from the "Exchange Back End" website, OWA/Active sync works again but the gateway isnt reachable externally.

Does anybody know a solution to this problem, so that both my Exchange servers is reachable and my RD Gateway functions properly?

Cheers,

Danny

Hi

You cannot have 2 services bound to the same port on the same IP.  In this case you are trying to get 443 bound to both Exchange and RD.  Add a second IP to your NIC and bind one of the services to 443 on that IP.  Change the other service to use a specific IP instead of *.

Cheers, Steve

• Proposed as answer by Fiona_LiaoMicrosoft contingent staff, Moderator Friday, November 30, 2012 1:30 AM
• Marked as answer by Fiona_LiaoMicrosoft contingent staff, Moderator Tuesday, December 04, 2012 8:29 AM

Hi Danny,

It is not recommended to use Exchange server as a Web-Application server for other services since it might cause confusion.

I think steve is correct, you need to add NIC for the other two roles.

Or, I'd suggest you separate Exchange server and RD server.

Your understanding would be appreciated.

Hello,

Is there any update? If the issue is resolved please mark it as answered, thanks.

If you have any feedback on our support, please click here

I understand that normally a RD-Gateway server should not be installed on the same server as an Exchange server. This is currently a testing environment for a small customer that currently has his Exchange 2010 CAS + RD-Gateway on the same server aswell, which works fine.

The issue is that in the past Exchange used only used the "default web site" for the CAS, and that worked perfectly in combination with the RD-Gateway role

In exchange 2013 it uses both the "default web site" and the "Exchange Back End" website.

Now when I configure my RD-Gateway it changes the "Exchange Back End" website and ands a new port (443) to it, instead of changing the "Default Web site" which already has port 443 configured on it.

When I remove the binding 443 that the RD-Gateway role added to the "Exchange Back End" website, the RD-Gateway doesnt function trough RDWeb.

Im currently still trying to find a way that the RD-Gatewayrole uses the "default web site" instead of the "Exchange Back End" website.

If this is just testing environment can you add another IP to the same NIC (or another NIC if it is a VM would work too) and then you can use 443 on that IP/NIC for the RD-Gateway?

Steve

Did you ever find a solution to this?  Ran into the same problem where RD Gateway keeps binding 443 on the backend site causing the conflict.  I don't see how adding another IP will address the problem unless the customer also has a second public IP to forward (which they don't). 

Exchange 2010 CAS and RD worked just fine for customer.

I am also looking for a solution to this.

I have previously run the RD GW role and Exchange 2010 OWA from the same server without issue but ran into the problem described above when trying to re-create the same deployment for Exchange 2013 and RDS 2012.

One thing that puzzles me is why the RDS GW install makes changes to an IIS site that, as far as I know, is only used for Exchange.

Like the poster above, I do not have any additional externally public facing IPs to send traffic to.

David

DNA - Did you install RD before or after Ex'13?  We installed RD after EX and are going to try doing the opposite to see if that helps.  Just haven't had time yet.

DNA - Did you install RD before or after Ex'13?  We installed RD after EX and are going to try doing the opposite to see if that helps.  Just haven't had time yet.

I built the new Exchange 2013 server and got that working first and then added the RD Web role.

When I tested the RD Web access, it couldn't contact the RD Gateway server which was when I realised that on my original 2008 deployment, the RD Gateway role was also required on the Exchange server alongside the RD Web role so I added it to my Exch 2013 server and then ran into these issues.

David

• Edited by DNA1000 Wednesday, April 10, 2013 12:41 PM

cheapshot - I would be very interested in your findings if you get time to try the installation in the reverse order (RDS followed by Exchange).

The more I look at this, the more my feeling is that it is a bug and a scenario that hasn't been tested by MS as I don't see any reason why the RD GW installation should do anything with that 'Exchange Back End' site unless it is by accident because it isn't aware that two sites exist on the server.

I was wondering whether there would be a way of disabling or hiding the Exchange Back End site for the duration of the RD GW installation to try and force it into only being able to access the Default Website.  Obviously this would stop Exchange working for the duration of the RD GW installaion but this should be a very short amount of time.

David

Started working on the 'reversal' last night and will continue into today.  Initially RD GW seems to 'work' even after the EX 13 install.  The problems I see are that after EX is installed, the RDGW MMC believes that it no longer has a certificate configured.  Using the MMC to then configure a certificate breaks both RDGW and EX.  Regardless, I can still use the GW at this point. 

I still have more testing to do though as EX is not yet fully configured as it was before.  I also want to play around with the IIS Applications some as it appears that EX hijacks the RPCWithCert application and moves it from the Default Web Site to the BackEnd EX Site. 

I'm going to work on configuring EX today and stand up a virtual server that has just RDGW to compare the IIS settings with.  I should be able to provide an update today or early tomorrow. 

I wish there was a way to mark this as unanswered and also wished MSFT would chime in with something more concrete.

Well good news and bad.  Mostly bad.

RD GW before or after exchange doesn't really matter.  If you do RD GW after exchange you'll simply need to remove the bad bindings it adds onto the backend site.

Manually recreating an RPCWithCert application on the default site does not assist the matter.  Either Exchange or the restart of the RD Gateway (not sure which) automatically removes the application anyways.

My previous test that showed the gateway was working was not fully valid because I was testing from a W8 seat; not my normal W7.  My W7 seat still does not work (it does not have RDP 8 installed either).  After some more testing I can confirm this only effects the older RDP clients that depend on RPC of HTTP.  RDP 8 clients that can use pure HTTP are fine.  See the chart in this article if you have not already:

http://blogs.msdn.com/b/rds/archive/2013/03/14/what-s-new-in-windows-server-2012-remote-desktop-gateway.aspx

Still not happy with the situation as many of our clients do not have RDP 8 on their W7 seats simply because of other application incompatibilities.  Not really sure where to go from here unless MSFT chimes in.  I still believe this is a bug in that even though RDP 8 works, the RD GW still thinks it is not configured when homed with EX 13.

Just an update that this only appears to be an issue on a multi-role exchange server.  When RDGW is install on CA only boxes it seems to work fine.  EX still removes the RPCWithCert App but RD GW still believes it is fully configured and it does not add extra bindings...

Is there any progress yet on the fact that ''Exchange'? is removing the RPCWithCert to the IIS Exchange Back End-site? Is there a way to stop this progress? Or is this just a dead end and will RD Gateway never coexist with Exchange 2013? I've tryed a lot to get this working but unfortunately without any success.

No progress to my knowledge.  We have had to separate our CA from MX roles (and almost doubled the number of servers and $$$).  The CA can co-exist with RDGW just fine, but you cannot have the MX with RDGW which sucks.

FYI: No progress as far as I'm aware either. MS told me at the time it's not supported. Told them it worked fine with 2010 in previous setups but that didn't matter.

Doubt they're going to fix it unfortunately. SBS being dead doesn't mean our customers disappear (SBS did this by default which might very well be the reason they did make it work earlier - they no longer have to now) :/.

As far as i found out a possible (but not working) solution could be the following: Configure the Gateway through the gateway manager and change the new faulty binding in the exchange backend web application to use a hostheader on ssl. After this change you can start the exch backend web application again. But at this point I getting another problem. If I start the OWA in the browser all seems running but after switching to a new folder an error message appiers. Something like "At this time we cannot update the view". Btw the connection of the exchange management shell is working well.

Does anybody know why this happens? At my point of view I don't understand this. I add an additional binding and don't change any self configured Exchange bindings but it doesn't work.

Hopefully some other have another good idea to get this working?

it has to be possible to set up, Small Business Server does it with just a single IP address, and it has working OWA and TS GW on the same IP.  

And maybe... thats why they killed SBS, since you cant run them both on the same server?

• Edited by Jonathan Horne Wednesday, January 15, 2014 7:51 PM

Wow, I just went through this nightmare scenario with a production server. I had brand new Windows Server 2012 R2 VMs running a new DC and Exch 2013SP1. Everything worked great for three days until I installed the RD Gateway service on the Exchange server to support remote connections to PCs (it already had many of the roles/firewall rules required for the RD Gateway service, so I thought it would be the quickest one to setup). I tested an NLA RDP connection to the DC, and it worked fine. I thought I was done, until the client reported their internal Outlook clients stopped working a few minutes later.

I tested OWA; it presented me with the login page, but it loaded a blank page after entering the credentials. Remoted into the server. EAC did the same thing login but blank page. Launched EMS. It reported it couldnt find the internal FQDN of my Exchange server. Ive had tons of Exchange 07/10 servers also running the RD Gateway service for years, so I panicked/uninstalled the RD Gateway service/role.

The Exchange 2013 server was still jacked up. Found this forum post on my first search. Removed the 443 binding in IIS on the Exchange Back End. Nothing worked in Exchange! Panicked again and opened a case with MS.

After an hour on the phone with MS, it came down to two simple settings.

1. Remove the IIS 443 binding on the Exchange Back End web site (to remove the conflict that the RD Gateway service created). Start the Back End website.
2. Assign the correct SSL cert (In my case it was a public UCC cert) to the Default Web Site https 443 * binding. I should also mention that I had previously changed all of the Exchange internal FQDN entries to point at my external FQDN required for new public certs to avoid cert warning errors in the environment. DigiCert has a cool tool to generate these EMS commands if you dont know what Im talking about.

Tested everything, and asked myself why didnt I figure this out on my own. I didnt have another Exch 13 server to reference thats my excuse.

I really, really wish MS had some logic built into the RD Gateway role to warn me about this conflict before I installed it.

I have some other VPN clients available at this site, so well use them instead for now. Maybe Ill build up my nerve in a few days, and install the RD Gateway role on the DC instead. I have an un-used UCC entry/public IP address that would work fine for this.

Hope this helps someone else.

• Proposed as answer by Kenneth Risa Thursday, August 28, 2014 10:18 PM

Questions - have you gotten this to stay working?  Like tested rebooting and restarting services in different orders?  Like RDG after Exchange or vice versa...

Also, does the RDG MMC tell you that you are configured or not?  Does making any changes there undo all this or fail completely?

How about installing patches or CU's? Like CU5?

Hi.

I have an environment with a Server 2012 R2 with Exchange 2010 SP3. Everything worked fine until i installed the RD Gateway service. Then either RD GW would work or Exchange, but not both at the same time. The Default web site was stopped in IIS, and RD GW had indeed added another binding on 443 to my site in IIS. I removed that, ran IISRESET from a command prompt, went into services and took a restart on the Remote Desktop Gateway service and now i have Exchange and RD GW working.

Thank you! I had the same problem, and now it works!

So glad I found this tread. It means I am not along.

Please do not waste your time by trying to vary sequence of installation. It is not going to sort your problem.

Instead read below

Exactly same problem happened to us, with a production server (sorry MS we dont have extra finances to do lab testing to discover your bags).

We migrated from old SBS 2003 server to supposedly latest and greatest Windows 2012 and Exchange 2013 servers. To achieve migration we spent over 18K for new hardware and software licences. Our IT department done all due diligence by reading Exchange 2013 and RDP installation and configuration guides and etc. Of cause none of them mentioned incompatibilities between Exchange 2103 and RD Gateway software.

Everything went smoothly until RD Gateway role has been enabled where nightmare started. We spent around four months since January 2105, raised two support request tickets to both Exchange and RDP specialist teams. Both teams give up and left us with unacceptable solution as to install Exchange and RD Gateway on to two separate servers.

Here is exact quote by Exchange support specialist: As discussed with you, Exchange 2013 was not tested with RD Gateway installed, and it will not be supported by the Exchange. The only option here is to move the RD Gateway to another server.

It is easy to say, but who going to pay another 18K for such solution. Even if we are going to use Virtual server still we would require to outlay an extra 5K for licensing.

Now we raised another support ticket to upper management at Microsoft with request of refund for Exchange server 2103 or issue of free licences to implement Exchange and RD Gateway separation and they are playing soccer since start of April.

It is clearly a bag in Microsoft Exchange 2013 and/or RD Gateway products.

Below a sort of work around which works.

1. Install Exchange 2013 and enable RD Role (does not matter which one first)
   Important: do it then no users online, because until last steps below they would not be able to receive emails and etc.
2. Create and Install two separate SSL certificates for Exchange and RD on your server. Both can be self-signed (so you do not waste more money for third party ones).
3. Open RD Gateway Manager and right click on the server name to open property pages
4. Under Transport Settings tab change HTTPS Port from default 443 to any free port let say 888 will do.
5. Open SSL Certificate tab and select an option Select an existing certificate from RD Gateway ServerName.DomainName.com Certificates (Local Computer)/Personal store
6. Underneath click on <Import Certificate> button
7. In dialog box select RD Gateway SSL created in step 1 above and press <Import> button and OK it. This step will create new binding to port 888 in IIS server under Exchange Back End website and stop Exchange server from functioning. Do not worry it will be fixed by steps below
8. Open IIS Server and under Default Web Site\Bindings make sure that port 443 linked to Exchange SSL
9. In IIS Server under Exchange Back End\Bindings make sure that port 444 linked to Exchange SSL
10. In IIS Server under Exchange Back End\Bindings link newly created port 888 to RD Gateway SSL
11. Open command prompt and run IISRESET or restart server to reset IIS Server websites. The web site Stop/Restart does not going to do a trick as some settings kept in the memory.
12. Make sure you allow port 888 through your ADSL router
13. Add a rule to forward TCP external 888 port request to server 888 port for server IP address in ADSL router.
14. Update RDP for all remote users computer to version 8. It will allow use of non-standard port 888 in RD Gateway section of Remote Desktop Connection under Server Name
15. Instruct remote users to add :888 at the end of currently used FQDN Server Name in Remote Desktop Connection. E.g. rdp.microsoft.com to be rdp.mcrosoft.com:888

Now Exchange 2013 and RD Gateway will work on the same server, but you would not be able to access OWA and ECP.

1. OWA will comes with Error: Your request can't be completed right now. Please try again later.
2. ECP will comes with error -Your request couldn't be completed. Please try again in a few minutes.

The only way to make OWA and ECP work:

1. Stop RD Gateway server
2. Do whatever you need to do in ECP
3. Restart RD Gateway server
4. Run IISRESET from command prompt

Please let me know if you have a better solution over wise we all have to wait until Microsoft wakes up and sort this annoying bag. Alternatively we all unite and issue group action against Microsoft to force them to do so and reimburse us for productivity and time lost.

I have this working without all the workarounds.

I have two servers server-DC and server-TS. I access them remotely for maintenance. both servers are VM's

Server-DC is 2012 R2 with exchange 2013 CU9 both is just a standard default build.

I followed a step by step procedure to install rd gateway server except I made a few changes rather than install the services on a separate server I needed them to be on the DC with exchange. At first I could not start the default site as RD gateway setup created a binding to 443. I had to delete this binding then start the default site in IIS.

On the DC I install RD Connection broker, RD Gateway, RD Licensing and RD Web Access. on server-TS I installed RD Session Host. During the configuration of the certificates I used the exchange self signed certificate and applied it to the broker, web access and gateway.

After all this I still could not get the RDP working, so I decided to abandon the idea as plenty sources indicate exchange 2013 does not play nice with RD Gateway service on the same box. The following day I used VPN to the firewall to get access to internal servers, sometime whilst accessing a server in the network my vpn tunnel dropped, ( I didn't notice)  I was prompted for rd gateway credentials (I forgot to remove the RD gateway setting prior to VPN connection) without thinking I added the credentials and carried on working on the remote server. It was only when I tried to connect to the second server that I realised I was not connected through VPN, I entered the Gateway settings and was connecting to the server.