ARCserve r12.5 issues

[TheCrust]

I used Arcserve a good few years ago and had no problems with it, so it seemed an ideal product to replace Backup Exec and we have just purchased Arcserve r12.5

It has installed OK on the backup server, detects the LTO autoloader fine - but refuses to install client agents to remote machines.

Although I have applied the hotfix that provides support for 2008 R2, when I attempt to install a remote client agent onto the single R2 file server we brought Arcserve to backup, I get a stubborn message back insisting there are no default shares on the machine in question and arcserve cannot install the client agent as a result. WTF?!

Having checked, the default administrative shares (c$ and admin$) do exist in the target machine and are accessibly via explorer from the arcserve box so I cannot understand what the chuff it is winging about.

With other server 2008 hosts it is stubbornly refusing to install to because "windows does not allow you to connect to a server using multiple credentials"

After spending two days trying to sort to this, including trawling through CA's supposedly "improved" support site and talking to support agents based on the indian sub-continent who have about as good a grasp of english as I have on punjabi, I am feeling very.......... ........frustrated.

Has anyone got any suggestions? For fixing Arcserve, not dealing with my frustration (though I suppose deal with one, and the other sorts itself out!)

Thanks in advance

[teejay]

Install the agents on the servers manually, just run the Arcserve setup from the CD and select Custom Install.

[TheCrust]

That is a last resort for me - I want to be able to use the push deployment from the arcserve server itself so that all the clients are configured the same, and it will handle updates for me later.

Although using the media is OK, having tried it this late afternoon I discovered that you need to enter the licence number with every install (even if installing just one client agent - the agent does not pick the licence up from the server) and that even after that, I cannot connect the arcserve manager to the client agent on the remote server - it just winges about security information being wrong.

I am so fed up with this product already - at CA's request I reinstalled the product on the server from scratch, only the CA Licence service didn't remove itself properly and when I reinstalled it recognised the licence numbers I'd input from the first time around and refused to use them again saying they were already in use.

CA's response? Reinstall the operating system on the server.

Presumably because I obviously have nothing better to do than clean up after their lazy uninstall routine leaves stuff lying around that will trip up a subsequent installation.

I've let my reseller know: either I speak to a support operative who speaks english better than I do and has a grasp of the product that far exceeds what can be learned from a troubleshooting flowchart, or they can have the lot back and I'll find something else that works and meets my needs.


Sorry - bad day.

[teejay]

One thing you can try, which is what I had to do to get it to connect to our unified storage server, is to add an extra name record for each server in DNS which points to the same IP address and use that to connect, so that you are connecting using a different name.
Must admit, CA telephone support is rubbish, but once you get Arcserve working it really does work very well.

[TheCrust]

Let me see if I understood that: add a DNS entry pointing to a given server but under another name?

For example, our student file server is called HOMER but you're suggesting I add a dummy DNS record for something arbitrary like PANTS and point it at the same IP address as HOMER - then try to install the agent on PANTS?

Thanks - I'll give that a go on the basis that at the minute I'm clutching at straws but to be honest I can't see why the chuff I should need to do that if the product was well written to start off with!

[TheCrust]

Update: Nope, that didn't work either. Same winge about not being able to detect the default drive shares on the host - despite the fact I can open and view them happily in Explorer.

Earlier I tried installing the agent by hand on a host - although it installed, I couldn't get the arcserve instance on the backup server to recognise it - kept complaining that the username and password was bad.

[teejay]

At the command prompt if you type net use does it show any mapped drives that are connected to servers you are trying to backup?

Also, did you fix the issue of the reinstall not accepting your licence keys?

You could also try disabling the firewall temporarily, it might be blocking a port.

[technicaluser]

Hi
You may wish to check out this article regarding a session credential conflict.

This applies to all Windows systems.

Err Msg: The Credentials Supplied Conflict with an Existing...

CA also has a article regarding this as well

SupportConnect

Can you post the exact message you are recieving when you try to authenicate
the user in the agnet deployment screen.


Hope this helps
TU

[technicaluser]

Hi
I noticed you manually installed the client agent on a remote host and you cant login. Can you veirfy that the universal agent service is started and that port 6050 is opened in both directions between the servers involved.

Did you add the host object under windows system in the backup manager?
If so did you add it by hostname or IP address?

To work around the login failure you could try using password security in the agent admin gui, configuration, set a password and cycle the universal agent service. Then in the backup manager when promted for security enter the password in the username and password fields. see if this works , If it does then you verifed that ARCserve can make a connection and you can focus on the user account.
TU

[TheCrust]

Thanks for the suggestions - you don't happen to work for CA by any chance do you?

As an update to this problem, I spent a good few hours on the phone to CA's technical support team this morning. Despite me winging about them at the top of the thread, I found the agents I spoke to today genuinely helpful - though I am not sure if this is as a result of the rant I had at them and the reseller late on Friday or not! If nothing else, it alleviated some frustration and made me feel better anyway.

They resolved the licence issues first, apologizing profusely for the earlier agent's suggestion of a complete operating system reinstallation. A quick delve into the registry and the licence key problem was removed.

After a bit of investigative poking around, we identified between us that the servers we could not deploy the agent to using AgentDeploy were all DFS servers - it was the only consistent thing in the configuration between them.

It seems in our case that AgentDeploy has an issue talking to DFS servers to push the client down - it cannot see the default $ shares on servers hosting the DFS service - but they aren't sure what the issue is or why it has occurred. They have said they will "work on it".

For the moment, they installed the agents onto those machines by hand themselves and they appear to be communicating happily. The earlier security problems were to do with me being a dyslexic muppet when I applied the security settings to all the clients I installed by hand - that bloke Administartor gets everywhere.

As I type, I am running an overnight test backup of a significant amount of data to tape, having already successfully confirmed I can backup to our NAS box acting as a file system object - and restore from it too.

So thanks for the suggestions but I think I'm about 90% there now: just the Exchange, SQL and Sharepoint agents to deploy and configure and the DFS issue to get around - though that in itself isn't crucial for us now but may help someone else in the future.