Re: Upgrading W2k8 R2 Clients (1092 Views)
Reply
Honored Contributor
André Beck
Posts: 514
Registered: ‎06-23-2005
Message 1 of 9 (1,602 Views)

Upgrading W2k8 R2 Clients

Hi,

 

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:
	[2] The system cannot find the file specified. 
	(System error should give description of the problem.)
	
In general:
	* 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:

 

  1. 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)?
  2. 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?

 

TIA,

Andre.

Please use plain text.
Super Advisor
ThierryT
Posts: 304
Registered: ‎06-05-2009
Message 2 of 9 (1,141 Views)

Re: Upgrading W2k8 R2 Clients

Hi Andre

Having same issue...did you get this working?

Thanks

Please use plain text.
Respected Contributor
drpixel
Posts: 229
Registered: ‎06-11-2010
Message 3 of 9 (1,092 Views)

Re: Upgrading W2k8 R2 Clients

Hello,

 

If you don't care about the security ... activate the guest account on your installation server.

Regards,

Christophe
Please use plain text.
Advisor
SBT
Posts: 17
Registered: ‎07-01-2011
Message 4 of 9 (1,019 Views)

Re: Upgrading W2k8 R2 Clients

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.

 

Please use plain text.
Honored Contributor
André Beck
Posts: 514
Registered: ‎06-23-2005
Message 5 of 9 (947 Views)

Re: Upgrading W2k8 R2 Clients


SBT wrote:

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.

 

Thanks,

Andre.

Please use plain text.
Honored Contributor
André Beck
Posts: 514
Registered: ‎06-23-2005
Message 6 of 9 (946 Views)

Re: Upgrading W2k8 R2 Clients

[ Edited ]

drpixel wrote:

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?

 

Any pointers welcome,

TIA,

Andre.

Please use plain text.
Advisor
SBT
Posts: 17
Registered: ‎07-01-2011
Message 7 of 9 (838 Views)

Re: Upgrading W2k8 R2 Clients

We migrated to CM on W2K8R2, no change in behaviour. Sorry.
Please use plain text.
Respected Contributor
dcampregher
Posts: 194
Registered: ‎07-07-2011
Message 8 of 9 (833 Views)

Re: Upgrading W2k8 R2 Clients

HI Andre,

Did you tried disable the UAC in the IS ?  Try enable he share for everyone.

 

Regards

 

Diogo

-----------
Please assign Kudos
Please use plain text.
Respected Contributor
dcampregher
Posts: 194
Registered: ‎07-07-2011
Message 9 of 9 (832 Views)

Re: Upgrading W2k8 R2 Clients

Try this  in the IS:

>  omniinetpasswd.exe -add domain\user

 

Enter the password for this user. This user need access the IS Share remotely.

 

> omniinetpasswd.exe -inst_srv_user domain\user

 

Atfer do that, try again.

 

Diogo

-----------
Please assign Kudos
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation