I'm new to the forums so I'm not sure I've posted this in the right subsection.
Our company is rather new in using Client Automation for deployment of software and patches, so far we're doing fine with the product and we're quite happy with its performance.
I have a question about changing a package "state" from optional to mandatory. A package is configured in CSDB as an optional package, is it possible to make it still mandatory when you assign the policy to a group? This without changing it in CSDB and thus not flag it for update for the rest of the users.
As Alexander has stated. You can use zedmams in which you would specify the keepdate=yes option. This change the required attribute, without changing the timestamp of the package. Existing users who have this already installed will not get an update.
For your question on making one single ZService both mandatory and optional: No, you cannot. This is a ZService level setting. The zedmams update will suppress the update for existing installs, but you will need to decide if you want that ZService M or O.
If you want both configurations to be available then you will need to have two separate ZServices.
This would change the URL value of TST_PACKAGE_A to http://www.google.be. I can see the changes with the CSDB editor but I can't seem get the client to reflect the changed value... aside from deleting the ASERVICE.EDM. I don't want to delete that EDM as it holds the records of already installed packages.
Is there a trick to make the clients reflect the updated value(s) without actually notifying the user there is an update of said pacakge?
I'll try to create a picture of what we're doing (and what we/the customer wants). We handle around 13K clients in our environment. We install a client computer with a Windows version and bundled with common and requested software (like the Belgium eID software for our eID cards).
Say we have version 1.0 in our main installation procedures. When version 2.0 comes out, we package it and after testing we make this available for the entire group. People who want or need to upgrade, can do it from that point in time. So far so good...
At some point the customer decides that the default installation should include version 2.0 and that all existing platform should have 2.0 mandatory. When we make the adjustments in the CSDB editor, all clients who already installed this version receive an update. In this thread it was made clear we need to make use of ZEDMAMS to make changes without sending it as an update.
Now, with some more testing, I found out the following behavior:
Package is O and already installed.
I change with ZEDMAMS to M.
I don't get an update on the client but the client sees and acts as if it's an optional package (instead of mandatory).
Also we split up the optional and mandatory packages into different catalog names. The catalog name isn't changed after the update with ZEDMAMS. It is of course visible in the CSDB editor. When I delete the ASERVICE.EDM, the catalog will be refreshed and the new information is visible. Of course the client now thinks the package isn't installed.
On the other hand, machines who haven't installed the package yet, also don't see the changes. Again the changes are visible when we delete the ASERVICE.EDM. This also means the package isn't coming down with the next software connect. (client doesn't see it as mandatory).
So, if not with ZEDMAMS, is there a way to acomplish my goal? Change a package from O to M without giving it an update on clients that already have it?
What is the behavior if you run a connect and specify SNAME for this application? I would expect that it would update the ASERVICE & APPINFO objects (exact behavior may vary depending on your ZVERIFY commands...)
I'm not recommending a modification of EDM objects, but rather than deleting have you tried updating the ZSVCMO attribute?
Well with the SNAME parameter we can install packages, that isn't a problem. In our environment we don't work with the timer, we initiate the radskman (with params for either software, audit, patch connect) from a local script/service. This gave us a better result with some load balancing and spreading the update cycle through the entire week.
If we need to adjust EMD objects (no problem with that, we're doing some stuff now for a more advanced detection we use in the ZSTOP parameters), we have to script that and deploy. We could force something through the logonscript with the SNAME but that just doesn't seem like an universal solution.
If the behavior, described above, is considered normal then I think we'll just make the changes through CSDB editor and mark the package with and update. Too bad for those that already have it, that's just a waste of bandwidth.
I hope in a new(er) version of the product, such things would be possible. The package is the same, only the installation procedure (from O to M) is different, so users don't really have to re-install it.