Subtitles of the Movie

So, we'll go into ConsoleOne and we will take this local Notepad Application for example. We will associate this Application directly with the Admin User, since that's who we're always logging in as for our test. We'll put it on the Desktop as well as on the Start Menu, and also leave it in the Application Launcher. However, we will go into the Availability Distribution Rules and we'll set a Distribution Rule that our workstation has no hope of passing. Let's say Add, Memory, Memory Is Greater than or Equal To 2048 megs of RAM. You have to have 2 gigs of RAM in order to run Notepad. So, now that that's done we'll go back to our workstation here. We'll hit Refresh. The Application Launcher refreshes here for a second or two. The Application Launcher is finished refreshing. Where's our Notepad Application? We look in the Application Explorer and under All we see Audacity, but I know I associated that Notepad Application with the workstation, where is it? Well, lets look in our Advanced Application Information screen and see what we have. So we'll right-click this and choose Properties, we'll hold down F2 and click the More key here. And there's our Notepad Application. You'll notice that none of these options are set and if you scroll all the way over to the right you'll see that the Application is Filtered and is not displayed on the workstation. So even though the Advanced Application Launcher Information screen does not give you the exact reason why this particular Application is hidden, it does let you know that the Application is indeed associated with either a Group or directly to the User or to the Workstation. However, because of Application Distribution Rules set on the Application Object it cannot be actually displayed on this workstation. Now as you'll recall, the local Notepad Application is a prerequisite application for our Audacity Application, so what happens if we have a dependent application that can't actually be run on the workstation because of those Filter Rules? Let's find out, shall we? Let's double-click Audacity and it just comes right up and tells us: A dependent application failed to install. System memory 2048 megs and normally the name of the application is right here. Every so often, however, that application name does not display, as it did in this case. I can't really seem to nail down exactly when it does appear and when it doesn't appear. I think it's a bug in the code, but good luck trying to convince Novell of that. At the very least you know which rule was tripped on this workstation to prevent the application from deploying. So, that's another thing to keep in mind, that if you have dependent applications to an application object that is directly shown on the Desktop that your workstation has to meet all the requirements for those dependent applications in order for this Application to run, which really only makes logical sense. You wouldn't want some kind of back door to run applications on workstations that couldn't handle those applications. Say, for example, this was an application that really did require 2 gigs of RAM to run. You wouldn't want to try to run it on a machine with 128 megs of RAM, just by calling it as a dependent application. So, hopefully this little exercise here has shown you how to properly associate Applications to workstations and how to figure out which applications did not associate properly should the workstation not meet the minimum requirement. And this concludes our discussion of Application Associations.