I'm running DP6.11 (latest patches) with Cell Manager and Windows IS running on a W2k3 R2 server. The server is in WORKGROUP mode, not in any domain, which is intentional and won't change. So far, Client Upgrades for Windows clients did work flawlessly (some clients had to be installed manually by mounting the share and starting the correct setup.exe for the respective architecture, but after that, Upgrade from the Clients tree in the GUI always worked).
That started to break when W2k8 R2 clients entered the arena. Mounting the share and installing via setup.exe worked, but Upgrade never works with W2k8 R2 clients. It fails with
[Critical] <somebox.tld> Cannot start setup process from the Data Protector share on
your Installation Server, system error:
 The system cannot find the file specified.
(System error should give description of the problem.)
* Make sure that Data Protector share on your Installation Server is visible on the network
(in MS-DOS prompt on client type: dir \\<IS_COMPUTER_NAME>\OmniBack)
* Make sure that Data Protector Inet process is not running under a user account, which does
not have access to the Data Protector share on the Installation Server computer
(usually this is local account)
This has already been posted here several times by others, but threads always ended inconclusively and with no real solutions. The issue is clearly due to some change in 2008 R2 as I have a lot of other clients that still work flawlessly, up to and including 2008 64bit - it's just R2 that really fails. I've double-checked all the settings on the W2k3 R2 server are correct for the OmniBack share to be a true anonymous share (file system security, share security and it is in the list of shares allowed for anonymous access). Apparently, something in W2k8 R2 prevents it from mounting a W2k3 R2 anonymous share (probably some newfangled security mechanism), so the remote installation and the remote upgrade features no longer work. While I can live with missing out on remote install, I cannot stop upgrading those clients. So my questions are:
Does anyone know the reason for W2k8 R2 to fail to access anonymous shares from previous versions, and maybe even how to fix that (or at least where to look more closely)?
Is there any way to upgrade clients when remote upgrade doesn't work? Or maybe a way to change remote upgrade to use an in-band method for accessing the software depots, like is used on Unix style platforms, instead of relying on Windows SMB shares and their ilk?
I have to ask question 2 from above, as I have so far not found any way to work around the failing remote upgrade. When I go to one of the clients in question, manually mount the OmniBack share and start the setup.exe (of course the correct architecture one), I'm always getting a failure saying
Different build of the product is already installed.
Build-to-build upgrades are not supported.
Please deinstall the product first.
I assume this means setup.exe cannot upgrade the product to a newer build, but how is upgrade supposed to happen? I have verified that uninstalling and then installing the client components from scratch works in general - it is just an unmaintainably dangerous mess. You have to make notes of what components exactly had been installed. The uninstall removes the client from the Cell Manager without asking back a single time. If someone else is managing backup specifications at the wrong time (while the client is gone), it may easily be wiped from the backup spec as well. I'm not planning to retry this kind of open heart surgery ;)
So is there anyone with a registry spell to get the share mounted, the magic command line switch to setup.exe to perform an in-place client upgrade, or any other insight into this problem?
I noticed the same behaviour, with a standalone W2K3 CM and W2K8R2-clients.
Case with HP revealed that an InstallationServer is needed in every domain.
And yes, now everything works as expected.
Thanks for putting this to a case with HP. The answer is sad though - it essentially means you cannot use DP to provide backup services in a heterogenous multi-tenant environment. Relying on SMB is bad enough (why can't the Windows client funnel its updates through INET the same way the Unix clients can?) - but relying on domain authentication mechanisms is entirely out of discussion. The installation share is made anonymous for a reason, and it DID work up to 2003R2 without involving domain stuff - so that is simply a regression that should be fixed. Putting another IS on a 2008R2 box in one of the domains in question might ease some of the pain for that domain, but it doesn't scale - specifically not when it comes to patching.
I hope it all goes away when I take the plunge und upgrade to DP7.01 on 2008R2 (or maybe even 2012) on new hardware. Until then, the quite sta(b)le state that 6.11 has meanwhile reached is keeping the pain at bay - there have been no new patches for ages.
If you don't care about the security ... activate the guest account on your installation server.
That does indeed allow the upgrade to run - thanks a lot for finding that out. But given I care about security, I don't think this can be the solution. I also don't see why it actually works - the share is explicitely exported using the ANONYMOUS-LOGON which is independent of the Guest account. Do you have any further information on what makes this work (I assume Guest counts as a member of Everyone and thus the access bypasses the anonymous path entirely, and from what I see in the security event log, 2008R2 clients indeed connect the share using the Guest account)? Specifically, why is 2008R2 using the Guest account instead of even trying the Anonymous Logon, and could this be fixed on the 2008R2 side?