I have a problem with the Agent Update of Backup Exec from 2010 R2 to R3.
During the update of the agents (including the installation of agents), I noticed the following:
I logged on the Backup Exec media server with my personal account that is no member of the domain admins and also has no access to some servers.
On the media servers this account has local admin priviledges and is also listed as user in Backup Exec
If I want to update the agents on the servers, I get the error: Error connecting to the remote registry of servers. Ensure that the current logged in accountis not blocked from accessing the remote registry and that the remote registry is available before trying again.
This would also seem logical as far as when I will not have a window to set the user credentials for the remote computer.
I entered the correct remote computer credentials in this window:
The account that I use is definitely a localadmin on all servers. With this account, the Backup Exec services run, too.
Interestingly, it is possible to update the agents when I login to the Backup Exec mediaserver with this account that is local admin on all servers and running the services.
I read this TechNote: http://www.symantec.com/docs/HOWTO22459, but why could I enter a valid Logon Account in this upper window that we no used?
Did anybody knows this behavoir and could tell me how I can fix this?
Might have something to do with the new security implemented in BE 2010 R3...check the TN below and see if this helps.
To be honest, I haven't had an issue updating my agents (on the servers I have migrated to R3 so far), but have seen the option to trust them (I haven't...haven't got failed backups either).
You can also make sure that the RAWS agent is actually running on those servers giving you hassles.
many thanks for your reply.
I had the problem with the R2, too.
So you can use the window remote computer credentials successful?
Or do you use the same login for the BE Server as for the Agent update too?
I am not sure why I only saw this now...apologies for that.
You'd use the same credentials to install/update the RAWS agent as you would to install the application...
It looks from the screenshot like you are performing a push install to update the remote agents. Your comments indicate that you have local admin permissions on the media server, but not on some other servers.
I have a few comments/questions about your scenario.
The Backup Exec Install requires admin level privledges on the remote systems in order to successfully install or update agents. This is required to launch the install, and make the necessary changes to the system during the install/update. During the install, we will attempt to read/write to the remote systems registry. From the error, it looks like the account specified, does not have the necessary permissions to do so.
Your other question
"but why could I enter a valid Logon Account in this upper window that we no used?"
We ask for credentials, but do not immediately use them. We use them later during our verification and the actual agent install. RAWS does not need a service account, as it runs as local system. However, the install requires an admin level account to do the necessary changes to the remote system to run the install, etc.
Hope this helps,
I've just experienced the same problem. To push the agents successfully i had to log into the media server as a domain admin, launch the BE console and push the remote agents.
Initially I was using my user account which does not have local admin rights on the remote hosts, to log onto the media server and launch the BE console to push the agents. Even specifying the domain admin credentials through the wizard for the RAWS installation account I was receiving the remote registry error.
Only when I logged into the media server and ran the console as a domain admin was i able to successfully push the agent.
I suspect there is a bug when the remote hosts are verifying the installation to check if you haves RAWS installed and what version you are running. During this check i believe it is using the logged in user account and not the specified one. After this phase when you start the installation then it uses the specified credentials. This is my theory anyway.
A co-worker happened to be looking at a similar problem today, and believes that he identified the issue you mentioned above. We will investigate and you should see it resolved for a future release. Thank you for your feedback!