Different path for Activate directory
Article ID: 33273
Updated On:
Products
CA Automation Suite for Data Centers - Configuration Automation
CA Client Automation - Asset Management
CA Client Automation - IT Client Manager
CA Client Automation
CA Client Automation - Remote Control
CA Client Automation - Asset Intelligence
CA Client Automation - Desktop Migration Manager
CA Client Automation - Patch Manager
Issue/Introduction
The installation of the same package is different for workstations reporting to two distinct scalability servers.
In the first case the activate directory is created locally as "C:\Program Files\CA\....", in the other case the directory is "Z:\activate\ ...."
What explanation is there for the activate path being local when installing a package via one scalability server while it is a mapped network drive when installing via another scalability server?
Environment
Client Automation All Versions
OS - Windows
OS - Windows
Resolution
The agent maps to the Z: drive if the download method is internal NOS and it is able to access the SDLIBRARY$ share on the scalability server.
This share points to the library on the Scalability Server and can be set by deploying the Scalability server's "Enable SDLIB share" procedure.
If the download method is not "internal NOS" but anything else, e.g. internal NOS-less, OR if the share has not been created or is not accessible because permissions have not been set correctly, the agent will not map the Z: drive.
The entire package will be transferred to the target first and executed from there, hence you will see the C:\Program Files (x86)\CA\DSM\SD\tmp\activate\... referred to in the logs.
Configuration policy may dictate another letter than Z is used to map the drive (ReservedMapDrive) or not to map a drive at all and use UNC path designations (MapDrive = false):
This share points to the library on the Scalability Server and can be set by deploying the Scalability server's "Enable SDLIB share" procedure.
<Please see attached file for image>
If the download method is not "internal NOS" but anything else, e.g. internal NOS-less, OR if the share has not been created or is not accessible because permissions have not been set correctly, the agent will not map the Z: drive.
The entire package will be transferred to the target first and executed from there, hence you will see the C:\Program Files (x86)\CA\DSM\SD\tmp\activate\... referred to in the logs.
Configuration policy may dictate another letter than Z is used to map the drive (ReservedMapDrive) or not to map a drive at all and use UNC path designations (MapDrive = false):
<Please see attached file for image>
Additional Information
Additional Information:
Here are some technical documents that further explain NOS and NOSLESS considerations:
KB000025058 How to change the default software delivery download method from Internal - NOS to NOSLESS?
KB000025661 I deliver the packages to Agents using NOS and they can access the packages from the Shared library from the SS but I can see that the package is compressed on the SS at every distribution.
KB000053802 How to change the NOS-less installation temporary directory on the Agents?
KB000050713 How to set the default SD download method as 'Internal - NOS' in an environment where the SS is on Windows and agents are Unix/Linux based?
Here are some technical documents that further explain NOS and NOSLESS considerations:
KB000025058 How to change the default software delivery download method from Internal - NOS to NOSLESS?
KB000025661 I deliver the packages to Agents using NOS and they can access the packages from the Shared library from the SS but I can see that the package is compressed on the SS at every distribution.
KB000053802 How to change the NOS-less installation temporary directory on the Agents?
KB000050713 How to set the default SD download method as 'Internal - NOS' in an environment where the SS is on Windows and agents are Unix/Linux based?
Attachments
Feedback
Yes
No
Powered by
