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.
Issues
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.
If you look in the event viewer you get a variety of errors:
- Event 17204 – MSCRMTracing
CrmTrace encountered an error. Additional Info:Error in LoadDeploymentSettings [Cannot open database "MSCRM_CONFIG" requested by the login. The login failed. Login failed for user 'NT AUTHORITYNETWORK SERVICE'.]
- Event 18945, MSCRMKeyGenerator
With details:
The CrmKeyGenerator encountered an error generating/monitoring key type System.Data.SqlClient.SqlException (0x80131904): The INSERT permission was denied on the object 'CrmKey', database 'MSCRM_CONFIG', schema 'dbo'.
- Event 17418, MSCRMAsyncService$maintenance
With details:
Host MachineName.MSCRMAsyncService$maintenance.05c692cc-7e3f-40b7-beb2-10e1cd75cec0: a config database error occured. Exception: System.Data.SqlClient.SqlException (0x80131904): The UPDATE permission was denied on the object 'ScaleGroupOrganizationMaintenanceJobs', database 'MSCRM_CONFIG', schema 'dbo'.
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.
