Scripted Installation of 12.9 Agents

[Shocko]

Hi guys, I need to automate the deployment of the AM agent version 12.9 using scripting. Is there any guide for such? I have a mix of 12.5 SP1 and 12.8 FP1 agents installed so most installations would be upgrades. Previously I had used the following method:

 

1. Copy the binaries to a network share
2. Installed the primer using dmsetup.exe" /V"/qb ALLUSERS=1 /l*v mylog.log
3. Installed the agent using DeployWrapper.exe" /DPINST CopiedAgents AGENT_SERVER=%_SSERVER% ALLUSERS=1 ENSURE_CAF_STOPPED=1 CAF_COMMON_CONFIG=1 CAF_INSTALL_SERVICE=1 CAF_START_SERVICE=0 REINSTALL=ALL REINSTALLMODE=vomus /qb /l*v mylog.log

 

Note: I cannot use the deployment console for this purpose or dmsweep.

[Anon Anon]

HI Darragh

You can use this technical document link to script out the installation of 12.9 agents

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec537491.aspx

copy the install files off the 12.9 media and then use this command for the install as it will install the components in the correct order.

DeployWrapper.exe /INST CopiedAgents /qn AGENT_SERVER=scalability1.ca.com ALLUSERS=1 /l*v %temp%\ITRMAgentSetup.log

 

The document states it is for 12.56 but the procedure has not changed

Hope this is helpful

Joe

[Shocko]

Thanks Joseph, specifically though I am doing an upgrade. In the guide in doesn't mention upgrade but I have in my notes to add the following params when doing an agent upgrade:

• REINSTALL=ALL REINSTALLMODE=vomus

 

From MSDN we have:

• REINSTALLMODE property (Windows)
• REINSTALL property (Windows)

 

Just wondering if these are required.

[Shocko]

I wonder could anyone from CA comment here? I'm still having difficulty avoiding a reboot. I do the following in my script:

• run caf stop
• run camclose
• run caf kill all
• set all CA services to disabled

 

I then run the following command line to upgrade:

• "%_AGENTBINARIES%\DeployWrapper.exe" /DPINST CopiedAgents AGENT_SERVER=%_SSERVER% ALLUSERS=1 ENSURE_CAF_STOPPED=0 CAF_COMMON_CONFIG=1 CAF_INSTALL_SERVICE=1 CAF_START_SERVICE=0 REINSTALL=ALL REINSTALLMODE=vomus /qb /l*v !_AMAGTLOG!

 

The problem is this seems to set the Connection broker service back to automatic and start it

[mccst05]

Even though you are specifying CAF_START_SERVICE=0 in your install, CAF actually MUST be started during the install so the services it depends on must also be started. CAF_START_SERVICE=0 only sets the END STATE after the install so CAF is not running when the install completes.

 

To avoid a reboot however, all you need to do is specify ‘reboot=reallysuppress’. For those not familiar with this parameter it can be a little confusing. The ‘reboot’ argument (which is an MSI parameter which deploywrapper simply passes on to the MSI installers it calls) can have 3 values:

 

 

1.       FORCE – this one is obvious, force a reboot (even if the installer did not call for it or need it)

 

2.       SUPPRESS – When the MSI Installer calls for a reboot, ‘suppress’ causes it to prompt the user for permission to reboot instead of just rebooting (seems to me a value of ‘prompt’ would have been more appropriate, but this is what Microsoft in their infinite wisdom decided to go with)

 

3.       REALLYSUPPRESS – This option suppresses the prompt as well, so there is no reboot. (Again, if they had used ‘prompt’ they could have used just ‘suppress’ here, but Microsoft’s infinite wisdom once again prevails)

 

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

[e-mail]

<mailto:[e-mail]>

[Shocko]

Thanks Stephen but again, this only prevents a reboot if the installation requires a reboot. In this scenario files are pending update and I would have to reboot the server at some stage to ensure the agent is fully updated. I'm trying to avoid the need for any reboot whatsoever. On some servers I run the same script and no reboot is needed. On others a reboot is. I'm trying to determine why this is.

[mccst05]

Files pending rename are files which are in use during the installation and therefore cannot be updated while the install is occurring. The system then creates temporary copies of these files and inserts the details for them into a registry key which causes them to be renamed during the reboot. In some cases however, machines may already have the same or even newer versions of these files installed, especially when the files concerned are DLLs, and especially when they are not CA-specific DLLs (usually these are MS-provided DLLs). In these cases the DLL or file in question is not replaced by the installer and so no pending rename is required.

 

In my experience, it is almost always the case that the Agent remains fully functional when such a reboot is ‘required’ but suppressed, so it is usually quite acceptable to just leave the system running until its next scheduled reboot. If you are updating servers, I’m sure you have a scheduled maintenance window at some point, during which the server can be rebooted. I suggest you use reboot=reallysuppress and just leave it until its next reboot occurs. I’ve never had a problem doing that.

 

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

[e-mail]

<mailto:[e-mail]>

[Shocko]

Well, I have had other issue with that method as the fact that the system has registered that a reboot is required blocks other installations that check this.

[mccst05]

Yes, that is unfortunately true. There really is no way to avoid it entirely though, since once a DLL has been loaded it remains loaded even when no programs are using it. There are some tools which can explicitly unload them but that requires you know in advance which ones to unload, and they are not actually in use at the time you call the utility. This is unfortunately a ‘feature’ of the Windows DLL architecture and not something we can control. As I mentioned, you are really just getting lucky with the ones that don’t need a reboot since in those cases something else has already updated the DLL(s) in question to a version which is on par with or newer than the one included with our Agent, in which case the installer bypasses it.

 

You could automate the required reboot to occur at a specific time, by using an Asset Job to set a flag in inventory indicating a reboot is required, coupled with a software policy to push a reboot package at the proper time.

 

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

[e-mail]

<mailto:[e-mail]>

[Shocko]

Reboots not an option in my environment . The odd thing though is we deploy the agent upgrades to our desktop estate using DSM Explorer and they never request a reboot so something in that process seems to be able to avoid the reboot.

[mccst05]

Far more likely your desktop estate simply has more up to date versions of some 3rd party (probably Microsoft) DLLs that are used in the Agent, therefore the installer does not have to update them and the reboots are therefore avoided. Again, this is not a CA issue, this is a pretty standard issue related to the Windows DLL Architecture. This is the way MS designed Windows to cope with DLLs (and sometimes other files) which are updated while in use.

 

I understand ‘reboots are not desired’ or ‘reboots must be strictly controlled’, but to say ‘reboots are not an option’ in a Windows environment is almost impossible. At some point in a Windows environment, reboots are inevitable. It is not possible to apply most MS Patches without a reboot, for exactly the same reason. I suggest you coordinate your Agent deployments with scheduled patching cycles to minimize your reboots.

 

Obviously you are upgrading to 12.9 to stay current, but your existing Agent versions will still function, although they will not be able to take advantage of some new functionality. Even if you are upgrading from a release which is now unsupported, that will only become an issue if a problem arises with an unsupported agent before you can get it upgraded. My suggestion would be to coordinate your Agent upgrade with your other maintenance plans to minimize downtime, which as I mentioned is not possible to entirely avoid.

 

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

[e-mail]

<mailto:[e-mail]>

[Shocko]

I would agree with you in the general context of installations on windows but what I'm finding is these CA libraries are the ones in use that cannot be replaced without a reboot:

 

• CAWinExF.dll
• CAWinExN.dll
• CAWinXsF.dll
• CAWinXsN.dll

[mccst05]

These are the CA localization libraries, but in looking back through old versions as far back as 12.5 (base), these libraries have not been updated. The version delivered on 12.9 is 1.20.31.0 dated 1/28/2010, which is the same version and date as on 12.5. What version are you upgrading from?

 

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

[e-mail]

<mailto:[e-mail]>