I hope to cover other App-V deployment methods later on but for now this is one I have documented so it seems the easiest to go with for this entry.
The App-V Management console is another nice tidy MMC snap-in just like the Client. However, this one is held on your management server. It will contain application information and be the central management point for your application streaming.
Usually, an App-V project using this method would support a Quality Assurance and PROD environment, as would always be advisable for testing purposes. Testing your application should obviously be done using some form of Quality Control. The first step to streaming your application should be to copy the application to your content share. The content share is your file share on which you should hold all your sequenced applications. Your end users will require read permissions to this share. It’s important to note that this should be reflective of the path set during sequencing e.g if you set your path to Microsoft/Project/2007 your files should go: \\<APP-VServer>\Content\Microsoft\Project\2007\ The codebase HREF in your OSDs should then have the correct path to find the SFT in.
When completed apps have been uploaded to the share, you could do a quick test before committing to putting the application into the Console (Management Server). To test you can take a copy of the OSD(s) and test on a VM with the client installed on it. You can do this by editing the OSDs and pointing the HREF CODEBASE to FILE and the location of the sft. This is pretty convoluted but may save you the bother of removing the application from the console if it doesn’t work.
To stream your application from the server you need to import into the Console (Management Server) , you can find the Console in Administrative Tools, you should see the options on the left:
Quick Explanation of the above options:
Applications are the applications imported
File Type Association are the FTAs that belong to the applications. These will take precedence for these FTA’s when delivered to the end users.
Packages are the sfts belonging to the applications
Application Licenses should be accompanying licenses for your applications (optional)
Server Groups would be whatever servers are setup on the infrastructure
Provider Policies can be configured to be more restrictive to lock down access to your App-V infrastructure.
Administrators are the administrators who are granted access to the Console.
Reports are SQL based reports on Application usage. There is also a Microsoft tool for publishing these directly to Sharepoint called the Dashboard
To add a new application you should go to Import applications this ensures everything for the app gets imported whereas New Application will only import one OSD at a time. You will have to browse to the .sprj file for your application on the content share.
The information in the above dialog which appears as the first screen after import should mostly be auto-populated. Ensure enabled is checked otherwise the app will not be active. OSD Path and Icon path are pointing to the Content share for these, these are taken from the OSD/SPRJ during the import so if the path different to where you actually put the apps this may result in the icon not appearing and app not streaming so double check. License Group and Server Group can also be used for restricted the application if required.
You can set where the shortcuts should be published via the above, this is also grabbed from the files during import but you have the option to override this here.
The above contains any FTAs related to the application. This should automatically be detected if captured during the sequence, if it isn’t you can add them yourself and this will override the OSDs.
Next we have access permissions. If you click add you will be able to browse to the AD Group or ACL Group which you would like to restrict the application to. Obviously, if the groups haven’t been set up you cannot complete this step.
Next is the relative path to the sft. This is very important. It sets where the app will be read from. It should be automatically populated also but ensure it is correct.
That should be all you need. As long as you are a member of the group entered for Access Permissions you should be able to test.
What I’ve done in the past is have QC AD group set up and during the QC phase only add this group with permissions. Then when it goes live this is removed and the actual Production access group (in my case usually a specific application group) is added. You may need to wait about 10 minutes or so depending on the network and then refresh the publishing server from your client machine. You should then see the shortcut on your machine. Happy Testing!
HANDLING UPGRADES
If it’s an active upgrade rather than a new application you can add this by just going to the Packages option on the left. Find your original package which you want to update. Then go to add version on the right.
You will then browse to your new sft and go through some similar dialogs to set the permissions and relative path. Then that should be it. The client will see it on refresh and take the newer sft file. If you have the increment SFT option enabled you can tell the sft is newer because each time it is saved it gets incremented by 1. For or example if you have 2 sft files with one of them _1 and the other _2 it will go for _2 by default.
Branched upgrades get imported the same way you import a new application because they are seen as such.
