Why would Windows credentials have anything to do with SQL or ePO? It seems to me that the Windows credentials are simply for authenticating to the OS and don't have anything to do with the communication once authenticated.
I will definitely try it, but if it's true, then why is it true? Those authentications are separate mechanisms.
Uh....Windows crendentials are not just OS authentication your windows login is used for every credential challange/response across your ENTIRE network.
SQL Server is a Microsoft product and therefore the same rules apply.
Yes you can set up local SA account password credentails for the DB but even the management connection from server to the server will use the windows login details (NTLM or Kerberos) at some point along the way.
Also are you "right clicking run as" on the patch exe? With 2008 R2 even though you might be logged in as the administrator you still won't be running the exe with admin privilages by just double clicking on the exe.
I don't know. My ePO and SQL server are not on the domain. While I understand how Kerberos and NTLM work, my local logon credentials are hashed by the OS and shouldn't have anything to do with issues installing a patch that needs credentials to a database on another system.
I tried it regardless, and it still doesn't work. :-(
Blow the box away....I put $1,000,000 down that the issue is with the User/Pass combination. I have done this umpteen million times. I bet if you were to stand up a new instance of front/back-end I guarantee that it will work. I (like you years ago) tried to dig through the haystack looking for the needle (culprit). It took me much less time to rebuild the darn thing. I bet that is what 99.9% of the users on this forum had to do.....that is why you are getting no responses.
Thanks Alex. Those are the credentials I'm using. I set up a new GA account with an extremely simple password and have also tried resetting the SQL DB credentials, and windows logon credentials. I even tried having them all be the same, and all be simple. There are no protections turned on on the ePO. I even tried reinstalling the agent on the ePO server just in case it was corrupt and wasn't processing the new policy (which happens sometimes on this network).
Nothing seems to be working. I have a phone con set up with platinum support for tomorrow. If I don't figure it out before then, I'll be sure to post what they say...
Okay after various checks in install log (EPO450-Install-MSI.LOG, I was able to see a line that looked something like this: SERVERNAME:8443 "" "" https post
I was racking my head against the wall to figure out why this would not work. I continually received the invalid credential error as everyone else that is having this problem. Based on this error, I am assuming it was trying to log onto the server via port 8443. We are using custom ports in our ePolicy configuration. So after configuring non complex passwords for accounts, then ensuring accounts had proper ownership to the db, to no avail, I figured I would try something else. These are the steps I did.
1. Back up server.xml file (c:\prog~\mcafee\epolic~\server\conf)
2. Modify server.xml where it states: "Define a SSL HTTP/1.1 Connector on port 8443" if the "port="####" " is anything different than 8443 then the upgrade will fail. So change the "####" to "8443".
3. Save the file.
4. You can either restart the services or restart the server (I restarted the server)
5. Run your setup.exe file again
6. Enter the credentials of your Global Administrator and it should run through perfectly.
7. After completion change your server.xml file back to the original
8. Restart your server.
This worked for me....