Introduction
I frequently see one specific question asked on distribution lists, Twitter, Yammer and other social networks: “How do I install Office Web Apps 2013 (WAC) on the same machine as SharePoint 2013”, very frequently also followed by “any hacks accepted”. Those who have tried have noticed that there is a hard block – SharePoint cannot be installed on an Office Web Apps machine and Office Web Apps cannot be installed on a SharePoint machine. This is purely by design and I will in this post show you why and why you shouldn’t try to hack it.
Office Web Apps 2013 owns IIS on the machines where it is installed
The heading says it all – on the machine where Office Web Apps 2013 is installed the IIS (Internet Information Services) is very much controlled by WAC. WAC creates two Websites (see image to the right) and numerous Application Pools in IIS. In order to be in good condition, and avoid people fiddling with it, WAC will actually recreate the Websites and Application Pools whenever it boots or the WAC service is restarted. One more time – WAC removes the Websites and Application Pools and creates new ones every time the machine is booted or the WAC service is restarted (Restart-Service WACSM).
The recreation of the Application Pools also prohibits any hacks to change the accounts of the Application Pools for Office Web Apps – something you never ever should do, it’s not supported and it is a security risk.
WAC Websites
The HTTP80 Website is the one that is used for all the WAC stuff (viewing, editing etc). Depending on your configuration that one is configured to listen on port 80 or 443 – for all IP addresses on the box. The other website, HTTP809, is the administration website using port 809 and 810 to synchronize settings within the farm. As you can see the HTTP80 Website will very much likely collide with a SharePoint Web Application (and any other Website for that matter). As you (might) know with SharePoint 2013, Apps and Host Named Site Collections we want a Web Application, without host header listening on port 80 or 443. There’s a collision right there. If we managed to get SharePoint installed on the WAC machine and try to fool WAC to use a host header, that would just be reset for every reboot or restart of the WAC service and our IIS Website would be removed for the SharePoint Web Application.
What if I add another Website/Web Application and uses host headers?
So you think you are smart now! What if you added a SharePoint Web Application, without host headers, and then go in and modify the bindings in IIS. Could work in a development environment, but never a good approach in production! Unfortunately this dog won’t hunt either. When you restart the WAC service it will actually not only remove the WAC Websites but also any IIS Website listening on port 80 or 443. Try it – just add a Website on port 80 in IIS, host header or no host headers, dedicated IP or not etc and restart the WACSM service – they will be removed. The only Websites that will remain in IIS are the ones created on ports other than 80, 443, 809 or 810.
Summary
I hope that this little blog post helped you explain why you cannot have both Office Web Apps 2013 and SharePoint 2013 or any other IIS application on the same machine. There’s no hack and there should not be one. If you ever get asked that question again – just send them here.