Subtitles of the Movie

This is ZENworks Desktop Management 7. We are discussing application deployment options and in this video we're going to discuss Application Associations. Application Associations is where the rubber meets the road so to speak when it comes to distributing applications to workstations and users. Without these associations, you can set all of the other distribution options and have a perfectly-formed application and no one will get it. And by far, this is probably one of the simplest operations in the ZENworks Application Deployment Suite. Now, an application can be associated to a container object, a user object or a workstation object. The container object can be workstation groups, user groups or organizational units. Best practices dictate that you associate applications to organizational units or group objects rather than directly to user objects or workstation objects. The reason why is that if you have an application that is associated with 400 user objects, then every time a user logs in, you'll see a spike in server load as eDirectory has to resolve all of the links between the application objects and the user objects. And I'm not an expert on exactly how eDirectory database works and all of its internal gears and machinations. I do know from experience, however, that if you're not careful with your application associations, you can bring down a server at 8:15 every morning as every user's trying to log in. So with all that being said, let's associate this application with a couple of objects and we'll see what the different options are. First we will add and we will find the object we wish to associate the application with. In this case I will associate it directly with this admin user as well as the users OU so that I get all of the users. When you associate an application object to a container, you get the option to associate the application to the users, workstations or both within the organizational unit. Ninety-eight percent of the time you will want to choose users within this container. If you have users and workstations that are in this container and you want to make sure that everything under this container gets it, you can choose both users and workstations. However, since most ZENworks implementations are user-centric; i.e., this user gets this list of applications. It's best to associate the applications with the users rather than the workstations. So we'll choose to associate it with the users and now you see the two different associations that we've set up for our Audacity Installer. These small icons across the top row tell you where the application icon is placed on the user's workstation. By default, you'll notice that this is the only column checked. We check our legend down here, you see that it is associated with the application launcher. This means that by default the user would have to open the little folder on their Desktop, labeled Novell Delivered Applications and inside that choose the application that wish to run. If we wanted this Audacity Installer to be on the Desktop as well, we could choose this option here for the Desktop. What gets selected by default when you associate an application is controlled by this box at the bottom; Defaults for Subsequent Associations. If we want every application to appear on the Start Menu, the Desktop and the Application Launcher, then we simply click those options and the next time we associate an application object, we'll associate it with our workstation OU this time. You'll notice that those options are selected for this install. Here is where you also set the Force Run Option that we've discussed elsewhere in the tutorial. If you'll recall, we have an option for the Force Run Order so that if multiple applications are set to force run, you can determine which one will actually force run first. If you have the Force Run Option set here and also on the Run Options, you have the option set to run the application once, then that means that the application will distribute to the workstation, execute because it's set to Force Run and then immediately be removed and the user cannot run it again. Again, this is useful for distributing one-off registry changes or application file updates, et cetera that need to run once on the user's workstation. The user doesn't need to request it to be run and once it's run it doesn't need to be run again unless, of course, you bump the version number or whatever at which point it will distribute again just like any other ZENworks application. Now a word to the wise about application association; when you hit he Add Button here, you are restricted to what types of objects you can associate applications with. Obviously you can't associate applications with other applications. You'll notice this is blank. If you have alias objects in your tree, you can select them for association; however, I would recommend against doing it. It's been my experience that if you do that, you get really erratic results on the workstation. Sometimes the application will deploy, sometimes it will not deploy, sometimes you'll get the icon, you'll double click it and it'll say you're not associated with this application. It's generally best to associate the application directly with the actual user object or OU or group for the end user rather than trying to go through an alias. And that's pretty much it. As I said, the Associations Section of the application object is perhaps the easiest to grasp and understand and we'll see exactly how these options affect the end user's workstation when we go through our lab elsewhere in the tutorial. But for now, that concludes our discussion of Application Associations.