We are trying to use CSA for all of our desktops. However we use Microsoft SMS to deploy software. We were told we could configure CSA to permit certain users elevated priveleges within CSA to permit us to install software with that account, which by default is restricted.
How do I do this?
I have not found a way to permit access based on login credentials (I wish I could).
But I have created a file access control exception and associated it with all of our desktops. I allow the applications: **\apasetup.exe &
to read/write any files. Works like a charm, when anyone is logged in software installs without a problem.
Hope this helps.
Rob, do you use CSA to block all other applications so that your users can't install programs on them? I've been told you can do this but you would have to rewrite a lot of the policies.
This is real easy to do with the default rule sets. With the default rules, users are Queried by CSA if they are installing/uninstalling software when CSA detects a Setup program running, esp from Removable Media.
You have 2 easy choices (maybe more) to keep the users from setting up software.
1st - You can set the Group the Users belong to into "No User Interaction Mode" This would cause the rule that Queries the User if they are installing software to Automatically default to Deny.
2nd - You can change the rule that Queries the User directly from a Query rule to a Deny rule so users can never run setup programs.
Let us know if these 2 methods are not possible for you.
This was very easy to do. So now if I want allow certain applications to run, like MS patches, I would just use the wizard to allow them to execute while everything else is stopped, Correct?
Yes, you are correct. You can use the Wizard or Manually create an exception.
Sounds like you are on the right track.
Thanks for using CSA.
Another question for you, I've been able to block all applications from running, but now when I try to allow 1 MS patch to be installed I have to create at least 10 wizard rules to allow the patch to be installed. Is there any easier way to do this?
In the application class, have you chosen "This process and all its descendents"?
This may help to make the rule a bit easier to write.
Also, you may want to let any setup programs run from a network share \\SERVER\SHARE. You can then publish supported software & patches there and have 1 rule to let all apps including setup to run from there.
Let us know,
As Rob mentioned in his post, along with the person from Ascolta, permissions based on LogOn IDs is not available today.
This feature is slated for the next minor release of CSA later this year.
As Rob mentioned, you can allow the application like SMS to perform its tasks if this behavior is blocked by CSA with the default rule sets. I typically refer to applications like this as Trusted Applications used for Administration when working with my customers.
Typically, I will run CSA in test mode with my customer and look for events that would have been blocked in the Event Log. The Event Log will alert us to the potentially "Trusted Apps" that would have been blocked by the PCs with agent kits installed. It's up to the end user to determine the Trusted Apps and the associated exposure to allowing this application to behave as it does.
You can use the Wizard from the Event Log to create an exception once you deem you trust the application that caused the event to show up in the Event Log.
Let us know if this helps,