I’ve had the pleasure of working on App-V projects for about eight years. I’ve created Sequencing standards, templates, setup VM Farms with the Sequencers and Clients for both sequencing and testing, as well as designed and implemented the App-V infrastructure. I believe I’ve setup App-V in almost every configuration known to man.
I’ve got to experience working on App-V projects for companies in ranging sizes, such as a bank with 60k end users, a retail company with 200k end users (80k on desktops), an Insurance company with 1,500 users and even some smaller user bases. I presented at a couple of conferences using specific case studies which you can view: HERE
I’ve setup App-V, deploying to just physical desktops, setup just to deploy to XenApp Servers. I’ve deployed to mixed cases or XenApp and Physical, RDSH etc. I’ve also deployed to ‘cloud’ hosted desktops. I think at this stage of my career, I am pretty confident that I’ve worked with and experienced App-V in many shapes and sizes. In this blog post, I’d like to share with you, my insight into Architecting an App-V implementation, particularly one which needs to scale for multiple geographic regions, servers, users and all of that jazz.
Lets looks at a few different implementation options. For actual official server sizing, I suggest you take a look at Microsofts own guidelines HERE, this will give you the figures to calculate how many servers you may need in your environment for publishing, managing, reporting etc.
App-V Full Infrastructure
I bastardized the App-V 4.6 Full Infrastructure diagram and put this together. You can see the Branch Office setup is still there on the right. This is a little bit of fallacy. Microsoft does still list this in the supported configurations (HERE)but of course, App-V 5.0 does NOT have a configuration with just a streaming server. App-V 4.x does. So the suggestion is that you could support co-existence and have App-V 4.x for a branch office streaming server scenario and have the rest of the setup using App-V 5.0. At the point of posting this, App-V 4.6 is coming to the end of mainstream support so this option is going to be redundant, very soon.
With that aside, you can see the main components at the top of the diagram. The management database, reporting database (which is somewhat optional, check this out HERE), you’ve got the App-V Web Services, of which there are now three. A Management Service, Publishing Service and Reporting Service. These can be deployed across separate servers. You may have several designated servers for Publishing.
Active Directory features yet again, as you can assign your applications using AD Groups. It should be noted, with App-V 5.0, you can now assign to computer objects, as well as users. We can see you can use the App-V native Management and Publishing server for streaming but can also use SCCM, which I’ll discuss further down this post.
You can see various different endpoints are still supported with the client. The desktop client and RDS client still exist in version 5.0. Of course with Windows 8.1 and Windows 10 in particular, looking at becoming more widely distributed on mobile devices and the Industry seemingly casting aside the ARM processors in Tablets in favor of the more traditional PC processors, this leaves the possibility of delivering App-V applications to a wide variety of devices. Right now, I’m streaming my apps to Laptops, Desktops, Virtual Machines and my Surface Pro 2 tablet. I’ve started to try App-V out on Windows 10 and it works great.
Some of my App-V peers have suggested that the App-V Full Infrastructure is a dud. I can see why they think that. Unfortunately, in it’s current form, the functionality for managing the applications, just isn’t there. You can easily publish applications, deploy upgrades and remove the applications BUT it’s missing pretty much everything in between. There’s even less functionality in this console than there was with App-V 4.5’s MMC snap-in console. You can view File Type Associations in the GUI but you can’t edit them. (You need to edit the config file and re-import that), You can disable shortcuts but again, you can’t edit them. There’s no longer a license control option.
You can see Reports are also not present in the console, you need to view these using SQL Reporting Services\Report Builder. App-V 5.0 does not fully remove the application package GUID folder from the machine, it leaves an empty folder behind, if you want to fully remove, you need to script that outside of the console. If you want to completely mount an application, you also need to get to scripting. If a published application is set to be removed from the client but is in use at the time the remove it attempted and thus never gets removed, you will not be able to force the remove from the console. It’s clearly lacking in functionality and I’ve only mentioned, but a few!
So, let’s say, even though it’s a bit lacking in that regard but you still want to proceed with the Full Infrastructure. I’d have to ask, what scale are you expected to deploy to? I set up the Full Infrastructure for XenApp Farms in the past and it actually works just fine. As it was just on Servers, it became much more manageable. If I needed to do something which the console could not take care of, at least I only needed to hit 15 servers rather than thousands of desktops. It fit the need, just fine. Not perfect but reasonably cheap, easy and effective. On the flip side, I’ve been asked to design an App-V Full Infrastructure for 45k end users, whom are located in various geographic regions. With about 38 different file servers across the regions, with a piss poor network in most of the sites.
The first challenge is, how do I replicate the applications to the file servers? App-V applications must be hosted on fileshares which are reachable by the end users. The name used for these shares with the App-V Full Infrastructure is the Content Share. This is a legacy name which was used in App-V 4.x and Softgrid. In fact, maybe I’m the only dummy still using that name 🙂 Nevertheless, The App-V Console cannot help you with replicating to the various different shares. You’ve got to get creative yourself. If you’ve got DFSR, it’s probably pretty simple. If not, get scripting, buddy! As per the sizing guide, the Management Server is capable of supporting a lot of users. The Publishing Servers take the brunt of the requests. It’s possible that you may need to spin up several Publishing Servers across those regions. All of a sudden. App-V Full Infrastructure is becoming an expensive endeavor, far too expensive for the lack of functionality!
If you configure the clients to point to the correct package root from the beginning it should work without issues. IF for any reason you need to move the clients to a different package root, it’s still possible but you may find yourself removing the applications from the clients and re-publishing them using the new package root. That’s a really crappy experience!
If you are running and supporting Virtual Desktops in a Data Center and those Virtual Desktops are non-persistent. The App-V Full Infrastructure is actually a little more fit for purpose. For the simple fact that making applications available and removing them are about the bulk of what you’ll need to do. Most other configurations you’ll need to do will be done centrally (clients configured for Shared Content Store) or will be something which will happen as the desktops are recycled. This is a little bit similar to the reason why it’s not such a dud for XenApp Servers or RDS Session Hosts.
Currently I’m testing out Non-persistent desktops using Hyper-V, RDS and Unidesk. With any applications which require significant work to sequence e.g. Drivers or COM+ delivered as Application Layers and my other applications streamed from using the App-V Full Infrastructure with the clients configured for Shared Content Store. The experience both as an end user and an Admin deploying the apps, is pretty great, so far. I’ll blog about my experience and setup, soon, so keep an eye out for that.
Let’s say you want to support a large scale project with physical desktops, laptops, tablets etc. Not just virtual. As you can see in the diagram near the top of this section. System Center Configuration Manager is a supported deployment option. Let’s talk about that!
System Center Configuration Manager
App-V Full Infrastructure scales like shit, I think we can all agree to that, right!?
You know what scales very well? SCCM 2012! In fact, Microsoft themselves, support 300k devices using SCCM. That’s what we call: eating your own dog food. For more about that, Read HERE
Odds are, if you work in Enterprise IT. The company for whom you are carrying out this App-V project currently deploys applications using some sort of a Software Distribution tool. Whether that be LANDesk, SCCM, Enteo, HPCA, Marimba etc. Those tools will host applications install sources on file shares. I believe Marimba calls them channels, SCCM calls them Distribution Points. Whatever the name, the logic behind them is the same. Applications on file shares in locations which provides adequate performance for your users. With App-V deployments in SCCM, your App-V applications will replicate to the DPs.
If you deployed App-V applications using SCCM 2007, don’t fret, Personally, I believe the experience with SCCM 2012 is better than it’s predecessor. You have the option to use Download and Execute mode, which will bring the application contents down to the machine and mount it, making it ready for use immediately as it’s delivered. Or you can choose to stream the applications from the Distribution points on demand, if streaming is your thing. You can even just deploy the MSIs which are generated when creating an App-V package, if you so please. I’ll discuss that further down this post.
When deploying App-V apps, you still require the App-V Client on the machine alongside the SCCM Client, as the App-V client is the secret sauce which allows the apps to work. The SCCM Client takes over control of delivery of all App-V applications from the moment you deploy your first App-V package using SCCM. SCCM is by far a much more attractive option than the App-V Management Console as SCCM contains features which allow you to deploy package\scripts and\or Use Task Sequences, if you require to script certain actions.
You also get the ability to leverage collections, as well as use the really cool requirements feature to only target machines which meet a certain criteria. Before the release of 5.0 SP3, SCCM was also best when it came to deploying Connection Groups. (I don’t believe that to still be the case as of the time I posted this) Connection Groups are applications which you’ve sequenced and then connect together in order to allow them to work and see each other. e.g. If an application is sequenced and requires say, Java 1.6 to work. You can sequence Java 1.6 and then put both apps in a Connection Group. With SCCM 2012’s Virtual Environments feature you can easily create them before deploying and you can even set the order of the applications and put some logic into it e.g. only group these apps together for this use case.
The Virtual Environments is also different than how the App-V Full Infrastructure delivers these Connection Groups. With the App-V Full Infrastructure the applications are delivered to the client and then the client creates the connection group after the apps are added to the machine. This adds a little overhead in order to process on each client. With SCCM, the connection group is created before the applications are delivered to the client, so there’s less overhead.
I had stated earlier that the App-V Full Infrastructure does work quite well in the data center for non-persistent VDI scenarios.. Unfortunately, this is SCCMs achilles heel, right now. SCCM processes on startup, but there’s a built in delay. If you deliver App-V applications using SCCM to a non-persistent desktop, the machine starts up and none of the App-V apps shortcuts appear until about 2 minutes later when SCCM kicks in and publishes the applications. This is not fit for purpose, obviously!
Another less significant issue that I have with SCCM as a deployment method for App-V, is the fact that App-V and SCCM obviously are two independent technologies. There for they have separate development paths. With the current state of the Industry, both should and likely are very important to one another BUT as the development teams and development cycles are different. There’s rarely feature parity between the two. That can be more of an annoyance than anything else.
App-V 5.0 Scheduler
My fellow MVP colleague, Bram Wolfs developed a really nifty tool called the App-V 5.0 scheduler. To find out more and to purchase the tool, read more HERE
I must be completely honest. The tool has been made available to me by Bram but I have yet to check out version 2.1. I’ve been a little too wrapped up in other work at the moment but I will check it out and blog about it here! I did check out version 2.0 and my impression at the time was WOW! This is what Microsoft should have delivered with the initial release of App-V 5.0. His tool fills in the gaps that the App-V Full Infrastructure and Client initially came with.
For example, his tool can see if an app is currently in use when you attempt to remove it and if it is, wait and try to remove again as the process becomes free. You can get some of the benefits of the App-V Streaming setup without the costly server setup. As you can see above, the setup and configuration for the Scheduler tool is very simple. The only real pre-requisite is a file share and your applications. In it’s current form, you may still have the problem of replicating apps to various different file servers but as is my understanding with 2.0, the tool is more aimed at uses with the RDS Client.
Perhaps the most impressive feature is the ability to deploy quickly and seamlessly using PVS\MCS by essentially mounting applications for use on the file share, greatly improving the end user experience and manageability in the process. As stated, I believe the 2.0 release of the tool was best suited for managing an RDS Client environment rather than Desktops. Perhaps 2.1, covers the entire spectrum. It looks like Bram has developed his own management console now so that is a great possibility. Check it out!!
RES and AppSense
When I think of RES and AppSense, my first thought is User Virtualization, replacing those crappy roaming profiles with a much easier to manage, centralized solution. Persisting what I want in a more transparent and controlled manner. I may make some enemies here when I say that I’ve used AppSense on about four projects now and I do not like it. It’s great for certain things but I believe it’s the inferior of the two! I’m much more of a RES Workspace Manager and Automation Manager fan. Even the fact that there’s less consoles with RES might seem like a small difference to some but to me, it’s huge. The AppSense database can also be a bit of a clusterfuck!
RES have an awesome solution for deploying App-V applications. You could deploy to traditional desktops, servers or virtual desktops in a uniformed fashion. And it scales pretty well too, for more on that, check this out HERE . You also get some of the other great RES features, such as the built in network configuration (firewall), obviously the profile management and the kick ass scripting capabilities. RES seems to scale much better than AppSense too, in my experience…like I said, the AppSense database can be a real clusterfuck, which I feel is what may let it down.
I’m a shithead blogger and un-prossfesional Techie, thus the high volume of curse words in this post. I usually post about technologies which I’m passionate about and enjoy the hell out of. I never look at the price tag. The App-V Full Infrastructure is attractive on paper to the guy holding the purse strings as it’s something which is available via Software Assurance. Tools like the RES suite and the AppSense suite cost money! That may revolt the cheap asses of the Enterprise World BUT Personally, even if AppSense is the choice. I think there’s many, many benefits to purchasing a tool such as these. Every time I tell somebody, hey you gotta check out Unidesk, Take a look at RES. They come back with, That’s really cool but we’re not interested in buying additional tools. They usually are also reluctant to invest time in developing their own tools so to them I say BOO!
App-V Standalone
If your company wants the benefits of isolation but you’ve got all kinds of restrictions in terms of file servers, network limitations, budget concerns etc. App-V Standalone is still an option and to paraphrase the great Steve Greenberg, who once said at ThinClient Computing community event that I attended: Virtualization is here, it’s a reality. Even if your company is not in the market for looking at virtual desktops, RemoteApp\XenApp, Azure\AWS, Cloud Backups etc. Some day they may be…the most work to get your applications and desktops into the cloud IS the applications. By starting to sequence or virtualize your applications now, you’re setting yourself up for a smoother transition in the future.
The App-V Sequencer produces an MSI as part of the output. You can simply take that MSI and deploy it to a machine with the App-V client and it just works, like any regular old application. It’s just that simple. You don’t get the dynamic upgrades, non-persistency or any of the cool benefits of streaming but at least you can deploy applications side by side which otherwise may have conflicts, you reduce the number of install related reboots, reduce the number of install related help desk tickets and you’re in good shape for the future.
Scripted Solution
App-V 5.0 is built on a Powershell backbone. Which is great because it means you can script pretty much everything. In fact, if you use the Client GUI there’s an option to view each task being carried out in it’s Powershell Cmdlet form. You can configure your clients settings using Powershell, you can deploy applications and remove applications using Powershell, you can create Connection Groups using Powershell, you can even sequence applications using Powershell! POWERSHELL,POWERSHELL, POWERSHELL!
If you use a Software Distribution Tool currently that has extensive Powershell Scripting capabilties you could leverage that. Simply store the applications on the ‘DP’ and script the Add, Publish and Mount, as well as removal or whatever the hell else you’d like to do.
Of course, your deployment team and packaging teams may be separate which can cause problems with knowledge transfer of such Powershell commands. You may need to deliver the ps1 files as the packager to your Deployment Admins. Or possibly you may even do what Bram did and create your own tool and just leverage Powershell in the code.
It works and it’s scalability really depends on your own capabilities!
Where this one falls down is the fact that many employers are very unwilling to allocate time to developing a tool. Many companies also get sweaty, fevered nightmares when it comes to creating in-house tools as they believe you will leave and they will be left dependent on a tool which cannot be developed without you there.
Conclusion
For the purposes of scalability. RES Workspace Manager and Automation Manager, as well as SCCM 2012 are the best solutions that I have used, so far. SCCM has some real problems with a VDI environment but is great for physical desktops. The App-V 5.0 Scheduler 2.0 tool takes a lot of the guess work out of an App-V implementation on the XenApp and RDS side of things and 2.1 is certainly worth a look. The App-V Full Infrastructure in it’s current form does not scale very well, at all.
As I sated earlier, many believe the App-V Full Infrastructure is a dud. Personally, I believe, rather than Microsoft scrapping it as a solution, I’d like to see them develop it further. Streaming performance wise kicks ass with the Full Infrastructure setup. It’s just missing the scalability and some of those extra functions that I’ve talked about. If those were implemented, I think it could have legs. If you agree please vote for this feature to be expanded on HERE and HERE
This has been my experience, I’d love to hear about yours!
