none
Deny previously approved application request

    Question

  • Is there a way to revoke an application that was approved in SCCM 2012?

    Scenario: 

    User A requests app A and it is approved, then that user moves to a different department or role that no longer requires them to have access to this app.

    I know I can uninstall the application but the user could just go back in to the application catalog and reinstall the app. Is there any way to deny an application once it has already been approved?

    Sunday, May 20, 2012 3:03 AM

Answers

All replies

  • No, there is no way from the console to remove the approved status from an application.

    Kent Agerlund | My blogs: blog.coretech.dk/kea and SCUG.dk/ | Twitter: @Agerlund | Linkedin: Kent Agerlund

    Sunday, May 20, 2012 6:23 AM
  • Let me add that you can control access to the applications by creating deployments for the appropriate user collections. For example, if the application is deployed to a collection that only contains certain users or security groups, the user not in the collection or security group will not see the application in the Application Catalog.

    Sunday, May 20, 2012 7:24 AM
  • Hi - I asked pretty much the same question last night and got a good answer: http://social.technet.microsoft.com/Forums/en-US/configmanagerapps/thread/25372c4c-921b-4f57-a328-4568fc11b225

    I agree the most logical thing to do would have a mechanism for revoking that application, but for the meantime use either:

    a) Deployment type requirements to limit the scope of where the application can be deployed to. Assuming you set this up correctly in the first instance a person moving to a different role shouldn't cause a problem as they won't be eligible to install it.

    b) Deployment to collections that consist of security groups and not direct user links. That way when the user changes department they won't be in the collection any more and won't see the app.

    .

    I was trialling this in my test environment last night and basically did the following:

    1) Create collection for "Sales" that is limited to the AD security group "gSales"

    2) Create application with deployment type native MSI that has the requirements (User) of "Primary PC == True".

    3) Create user based deployment of the application to the Sales collection

    .

    So... when the user moves group they will they no-longer be able to see the application to install anymore as the deployment isn't advertised to them. Also in the meantime assuming they regularly use 3 PCs they will see it advertised on all PCs via the Application Catalog but can only issue the install on their primary PC thereby limiting Bob to using 1 licence and not a potential 3 licences.

    I suspect/hope a more practical "revoke" will come in SP1, but this will suffice until then.

    Cheers




    • Edited by JoeGough Sunday, May 20, 2012 11:52 AM
    • Proposed as answer by JoeGough Sunday, May 20, 2012 6:42 PM
    Sunday, May 20, 2012 11:39 AM
  • Yeah, adding on to what Anton was saying...

    I'm not a huge fan of Deploying an application that requires approval to "All Users".  I think you're much better off limiting who can see that instead based on SCCM Collections (which could be tied to AD groups if that's how you manage things).  Then of course bring UDA into the mix so that you don't have an end user running around giving everyone the app that they are approved to install.  Hold them to just their primary device.

    Of course if you use App-V then perhaps you could still let them have it everywhere they go...but only install the virtualized version on their non-primary rather than the full install (and have it remove itself when the logoff).


    Mike...

    Monday, May 21, 2012 4:57 PM
  • If you delete the user object from "\Assets and Compliance\Overview\Users" , the Approval Request will be removed.

    Its no easy feat...you'd need to

    1. capture all other information related to that user object (UDA, Approval Requests etc) - use the powershell cdmlets
    2. delete the user object
    3. run a full AD user discovery
    4. restore the captured information from step 1- I haven't looked into how to do this yet

    Sunday, April 14, 2013 1:30 PM
  • This is an interesting idea.. Going to look into this. If fully automated it might be just the solution we need until (hopefully) Microsoft realizes how the lack of this feature sure is crippling. :-/
    Wednesday, July 24, 2013 6:07 PM
  • So I haven't had much luck on this front as re-generating approval for any other app that you still want the user to be approved for has so far netted nothing for me.

    However... I was doing some testing and think I may have discovered a work around that could provide the same functionality, albeit with some definite additional administrative (or more appropriately automated) tasks to accomplish this.

    At the root of the "solution" is:

    If a user is targeted with one deployment (initially) that requires approval, you can target that same user with a second deployment that does NOT require approval.  The deployment that does NOT require approval supersesed the deployment that does.  Thus the application becomes available for immediate install once the new non approval deployment is created.

    Then, if you wish to "revoke" the approval you simply remove the deployment that does NOT require approval and the App Catalog reverts back to requiring approval.

    Still many angles to think through here but wanted to throw this out there for anyone who may be looking for alternative ways to accomplish this.  I will certainly be digging deeper into this.

    Wednesday, July 31, 2013 1:44 PM
  • I had the same problem and solved it by editing the Database Directly.

    Application requests are stored in a table called UserApplicationRequests, by changing the CurrentState for the specific request to the following values you can change the approval status:

    1 - Requested

    2 - Cancelled

    3 - Denied

    4 - Approved

    PS: Microsoft does not support directly editing the database so do this at your own risk :) I also don't think changing the state will force removal of the app, this will have to be done with another application deployed to the necessary collection.

    Wednesday, August 07, 2013 6:18 AM
  • Yeah, I contemplated that as a possible solution but couldn't bring myself to do it.  Just not 100% convinced it wouldn't come back to haunt me.  If only they had included the Cancel method in the WMI Class. :-/
    Wednesday, August 07, 2013 2:36 PM