6 Replies Latest reply on Sep 17, 2010 6:45 AM by bcasler

    User application deployment

    Rookie

      We are about to roll out LDMS agents to our users as part of a PC Refresh project and are wanting to find out some further information on how best to deal with applications which fall outside of the SoE (limited license applications such as Acrobat Professional or MS Visio, etc) and deploy them to users who have been approved for there use.

       

      We have about 6 applications which have limited licensing and one application is licensed for about half of our staff, and would like to work out an ideal solution on how to best deal with these applications when they are given new PC's.

       

      Our business doesnt limit users to logging into the one PC, however most people do only login to the one PC and this is the PC they are assigned.

       

      Has anyone had any experience or have any ideas that could help me?

       

      How do you deal with the automatic (preferred) deployment of additional applications which the user has been assigned?

      How do you deal with users who do login to multiple PC's and therefore the requirements that these additional software be removed once the user logs in and the application has been deployed?

       

      We were thinking if we could define a PC as being assigned to a user, for example once the PC has been setup in there office an application or custom form is ran that specifies the user as the primary user in LDMS database; then the applications will be deployed to the PC, and if they were to login to PC's other then the one they are defined as the primary user then the software will not deploy automatically.

       

      However, we have a couple of users who's job is to provide relief assistance when other staff are away and therefore they may have some of these additional software assigned to them and they would need it deployed to them whenever they login to a PC, so in this case how do you deal with the removal of the software if the primary user doesnt have permission to use this software?

       

      And to throw a spanner into our Primary user solution, there are a handfull of staff who job share, so there will be PC's with two Primary users defined.

       

      If anyone can provide information on how they have dealt with this it would be greatly appreciated.

       

       

      Thanks,

       

       

      Matt

        • 1. Re: User application deployment
          phoffmann SupportEmployee

          Policies - that's the thing you want to read up on / look up / play in your lab with - especially you want to fire them off with user-login.

           

          You can assign policies to AD-queries (so your users who are OK'ed to use 'em), which will target/follow those uesrs, not the machines they're on.

           

          In addition, you can assign an UNINSTALL ASSOCIATION package -- the purpose of this is to clean up the package from the device it's on if the policy no longer applies.

           

          So for instance, we have User_Anton and User_Bob.

           

          ====

           

          User_Anton always stays on his machine - never leaves.

           

          Policies will download/install the package on to his machine, and - because he always logs in on the same place - keep it there.

           

          If some sneaky, unauthorised user logs on to User_Anton's PC, the policies will notice "hey, this isn't User_Anton, but rather Sneaky_User - time for me to kick off the uninstall association" ... removing the software package.

           

          ====

           

          Much the same applies to User_Bob. The machines he logs on to will get the policies installed (you can leave them optional), and they will get removed when an unauthorised user logs on.

           

          ====

           

          The "gotcha" factor here is time.

           

          Time to run policies (hence I mentioned, you want to do this at logon) and - more importantly - to actually install the apps. If this is just a few minutes, then no big deal. If we're talking about a 30-minute install,. I'm sure that our ficticious User_Anton will be much better off than User_Bob on account of using the same PC every day, rather than having to have the apps follow him around.

           

          Does this answer your question? It should give you something to start playing with in your lab, to see how this would work for your specific software packages / environment?

          • 2. Re: User application deployment
            Expert

            If users are assigned a machine and are also assigned an application, then I would NOT deploy applications to users, but rather to machines. The problem being is the "usually" factor. Usually users only use one machine, but what about meeting rooms, training centers, IT support, etc. Or, if a user discovers that app follows them, they may log in to another users machine in order to have it installed. Stick to the computer name. That way, if a user requests the app on another machine, the first question is why are you on the other machine? This actually forces users to report when they decide to pass off a machine to someone else and if you are implimenting an asset tracking system, this will force a low level of honesty from the end users.

             

            Just my opinion...

            • 3. Re: User application deployment
              phoffmann SupportEmployee

              Jeff,

               

              There's quite a fair number of work environments that now go the "virtual desk" approach, meaning people essentially book (by one form or another) their desk for certain days, and may sit this day over here, next week over there.

               

              It's not every workplace - thankfully - but such things exist. It ultimately boils down to what the nature of the original posters' work environment is like.

               

              It's certainly PREFERRABLE to have things locked down to machines, where possible, but the whole cloud-concept and so on are becoming much more user-oriented (something we've taken on board too), so it may not be as simple as that, sadly .

               

              Your observation would certainly be the more smooth approach, no question there. I suspect, however, that the given environment can't work that way - hence I gave the suggestions I did .

               

              - Paul Hoffmann

              LANDesk EMEA Technical Lead

              • 4. Re: User application deployment
                Expert

                Oh for sure, every environment has its quirks no doubt. Controlled or managed environments are always the goal, but doesn't always meet the needs of management idiologies. Weighing the pro's and con's or maybe the gain or expense and providing the solutions to management is what we are here for. I've worked in enironments such as the one I described (pc refresh with leased assets) and when management chose oprions that did not enforce users being strictly tied to thier assets, when I was asked "where is this machine" or "why does this person have this" or "why are we over our licenses" my answers clearly outlined the choices management had made. I still had to play chase the rabbit, but at least providing the understanding was easier.

                • 5. Re: User application deployment
                  Specialist

                  Trevor, if you are using an AD-Environment you can protect your Software with NTFS Security.

                  We install our Software with Batch Files, that includes NTFS Right settings (bound to the Domain Useraccount) to the starting

                  application like winword.exe. So the Users will maybe see the application(s) with filebrowsing, but can't use (start) the software.

                  Maybe this is an option also for you.

                   

                  Best Regards

                  Troga

                  • 6. Re: User application deployment
                    bcasler Apprentice

                    we do a policy for end user install that makes the install available to the user in software deployment portal based on membership in an ad group then they can install it on their PC and if the move re install it.

                     

                    Doesnt answer all your questions but..