First, why would you use NETWORK SERVICE for the CRM Service Accounts when the install documentation says that for optimal security you should have unique domain accounts? At Cobalt we only use NETWORK SERVICE for development and internal test servers because it saves a small amount of time during deployment and administration. However, if your company writes a lot of custom code for client implementations like we do even this small amount of time if worth it. Currently at Cobalt we are running approximately 75 virtual machines for various testing purposes – various versions of CRM, various versions of our CRM products and custom work for various clients.
In CRM 2013 with SQL Server 2012 and in previous versions we have run this setup hundreds of times without any problems, but with CRM 2015 and SQL 2014 we have had scenarios where a basic CRM 2015 installation will seem to work – all databases are created, all files are created and IIS is configured properly, however when you try to access CRM from a browser you either get a 404 error or you get a authentication pop-up followed by a 404 error.
What Happened & The Solution
For some reason in this scenario NETWORK SERVICE was only given read permissions on the MSCRM_CONFIG and the organization MSCRM databases. To fix this go into SQL Server Management Studio and give the NETWORK SERVICE user db_owner privileges on the databases in question. After you add these rights reboot the server, an IIS reset will not recognize the SQL permission changes. Note – when you create new organization databases from CRM Deployment Manager these databases will also not have the correct permissions and you will need to update them as well. This fix is to help you with your development and testing environments, for production or public-facing deployments you should follow the steps in the CRM 2015 Deployment Guide and use minimally-privileged domain accounts.