SQL's db_owner is not part of the Server role but within the database role, May I know if dbcreator is suffice on doing an upgrade to ePO 5.9?
both sysadmin and serveradmin role are powerful role which basically not a good choice. Thanks!
public and db_owner were already been granted under Database role however user permission error still occurring and that Server role in question, specifically the db_owner as described in KB, PG, IG on any McAfee documents don't exist in a Server role, and I know most of you will agree that we cannot grant sysadmin and serveradmin role to epo service account most specially in the SQL shared environment.
I have problems with SQL Permissions, too...
In an error log i get:
in wich way the installation needs to do that ?
Upgrade from ePo 5.3 to 5.9
Im doing a new install on a test box for 5.9 and I am getting the same issue and it rolls back at the very end with this being the only error I can find.
Installation guide doesnt not specify any further SQL permissions being required except the ones listed.
So what gives???
Was going to log a ticket online and send them the logs, but it appears the portal is currently down for submitting ticket or seeing current status.
Why is it that the installation wizard, cant be more informative on errors except that its rolling back (without going into the log files) or give the explanation of the top 10 issues with KB articles, etc.
Anyone solve this issue without giving sysadmin or possibly the alter server permission?
Support wasn't that helpful...
I've copied the database to my SQL test environment and gave the SQL user sysadmin permissions. So the installation was successful and I've copied the database back to the production server.
That's my solution. Hope that helps
I just used the SQLExpress and installed on the machine itself so I had full control over SQL - its only a test, see what is special about 5.9 - was told better dashboard, etc....so far...meh.
Beats asking the DB guys to log in on the weekend to give me a little extra boost to permissions for short period.
I dont believe this is a new issue either...why does the documentation not reflect the extra permissions is my concern.
Because during the upgrade of ePo is used SQL "DBCC freeproccache" function, it is needed to have the sysadmin permission.
McAfee updated KB. This permission is needed if upgrade to ePo 5.9
I am not a SQL DBA, but I find that requiring this absurd level of security privilege to install or upgrade ePO is quite untenable for enterprise environments. If this were not a SECURITY company we were talking about it, I would be far less annoyed at the ignorance that this shows. If Microsoft has a limitation, fine - work around it or use something else. For what the DB for ePO does, there are many free options that can work if they care to use them.
I had to get an insane level of access to a company's SQL Cluster to install ePO... .I was put at risk because of it, and the company had to accept risk that they should not. And if the ePO install is ever hacked or modified (NOTHING is really safe, so always prepare for the eventuality), then installing McAfee will possibly corrupt or destroy an entire company's database cluster?!?!?! Absurd to let this even POSSIBLY happen.