My top 5 new AppVirt (SoftGrid) 4.5 features

Hi everyone. Andrew Montgomery here; I’m a Program Manager on the AppVirt (SoftGrid) product team. We were all talking today that we want to start a regular posting process here on the blog. So, going forward, we’re going to do our best to have someone on the engineering team do a post every Wednesday. We’ll talk about all sorts of things, but will probably mostly focus on AppVirt 4.5 and some of the new capabilities we’ve built into the product. We’re pretty excited that the Public Beta is available to all of you and that you finally have the opportunity to put it into your labs and start working with it! BTW, “AppVirt” is the new short name we’re using for the product when we don’t want to type out Application Virtualization.

So, to kick things off, I thought I’d start with my personal list of the Top 5 new features that are being introduced in AppVirt 4.5 that didn’t exist in SoftGrid 4.2. This isn’t meant to be an exhaustive list and certainly isn’t meant to disparage other cool things we did in the product, but it will give you a sense as to how the product has changed since 4.2. I’m sure you’ve all seen the official web page describing the release (https://www.microsoft.com/systemcenter/softgrid/msappvirt45/default.mspx), so please reference that for more details and also stay tuned to this blog, too!

New Server Product!

For those of you who knew SoftGrid 4.2, you know that we had a single server component that we just called the server or the VAS (Virtual Application Server). Now, we have two different servers, so let’s clarify the differences between the two.

The SoftGrid server that you are familiar with from 4.2 still exists and works in mostly the same way. But, it’s new official name is “Microsoft System Center Application Virtualization Management Server”. I’m sure we’ll come up with an official “short name” for it soon, as we know that name takes a long time to say! For now, I’ll just call it the AppVirt Management Server. This is the server that requires Active Directory and SQL. We called it the “Management Server” because it can be used by itself to manage an AppVirt infrastructure. This means it performs two functions: publishing of application configuration information (shortcuts and file type associations – what we’ve traditionally called “DC Refresh”) and streaming of applications themselves. If you’re just deploying AppVirt to a small group of users in a single site, this is the only server you’d need.

Our new second server is called the “Microsoft System Center Application Virtualization Streaming Server”. Again, I’ll just call it the AppVirt Streaming Server for now. As you might guess from the name, it only performs one of the two functions above: streaming of applications. When you use the AppVirt Streaming Server in your infrastructure, that means that your clients are getting their application configuration information published to them via some other mechanism. The publishing could actually be performed in a variety of ways – from a separate AppVirt Management Server, an import triggered by a third-party Electronic Software Distribution (ESD) infrastructure or built-in integration that will be part of the System Center Configuration Manager 2007 R2 release that will be forthcoming next year. Look for more details on all these scenarios in future blog posts. The AppVirt Streaming Server will make it much easier for AppVirt to scale to large Enterprises than previous releases, since there isn’t a need to have the SQL database on the AppVirt Streaming Server and the intent is that it could be installed on a server that might already exist in a branch office. The goal is that the AppVirt Streaming Server can be better integrated into your existing ESD deployment and eliminate some of the dual management infrastructure that you have today with SoftGrid and your ESD managed separately. And, since the AppVirt Streaming Server works alongside your ESD, AppVirt can now scale as far as your ESD can scale, too.

Deploy AppVirt Without a Server At All!

In 4.2, you had no choice for how you were going to deploy virtual applications. You had to put them onto a server and then users would need to stream or pre-load the applications from the server. In AppVirt 4.5, we’ve added a new capability that lets you take advantage of the application isolation benefits of application virtualization without forcing you to use a server.

We call this feature Standalone mode. How it works is that the Sequencer can now output a MSI file in addition to the SFT file that you are already familiar with from 4.2. The MSI file contains the publishing information mentioned above and will create the shortcuts and file type associations for the virtual application. In addition, it does a full import of the SFT into the client cache (replacing the need to stream from an AppVirt server). The SFT is still a separate file and the MSI contains just the publishing information. The intent of this feature is that no AppVirt server is in use or will ever be in use in the future for the particular client that you are deploying to. You would use Standalone mode if you wanted to deploy virtual applications via a CD to remote users who have no local server and poor WAN connections. Or, you might use it if you wanted to deploy virtual applications via an existing ESD that is already familiar with deploying MSIs. And, for those of you out there who would actually be responsible for creating and testing packages, you’ll also love this feature, as it should speed up your testing of new packages, since you don’t need to load them onto a server anymore! Again, look for a future blog post with more details on this new feature.

Deploy Plug-ins and Middleware Dynamically With Applications That Need Them!

In 4.2, a struggle with virtual applications was if they used plug-ins/add-ins or leveraged middleware (such as the Java Runtime Environment (JRE)), it was necessary to “suite” the two applications together. For example, if you had 10 different applications that all depended on the same version of the JRE, you would need to create 10 different SoftGrid packages that all contained the application and the JRE. This meant you had 10 packages with the exact same JRE code. This would cause each package to be larger than they ideally should be (larger packages obviously take up more room on the server and take longer to stream) and also caused the need for 10 packages to be patched if there was ever an update to the JRE.

In AppVirt 4.5, we have a new feature called Dynamic Suite Composition (DSC). With DSC, you have the ability to allow one virtual application to interact with the virtual environment of another. This allows you, continuing the above example, to create just a single JRE package. Then, each of your 10 virtual applications can be packaged individually and made dependent on the JRE package. When each “primary” virtual application is launched, the JRE is launched as well and can access the virtual environment for the primary application. Now you have just a single instance of the JRE code being deployed to each server and only need to patch a single instance (instead of 10) as well. This feature is only targeted at plug-in/add-in and middleware scenarios and not all virtual application interactions, but we think it’s going to be a big bonus for many of you and will post more to the blog about it soon.

Package Non-U.S. English Applications and Use Them on Non-U.S. English Operating Systems!

In 4.2, there is no support for using SoftGrid on non-U.S. English Operating Systems. In addition, support for packaging applications localized in non-U.S. English languages is not supported (see https://support.microsoft.com/default.aspx/kb/935684 for more info).

In AppVirt 4.5, both of these scenarios will be supported! Except for complex script languages, we will support running AppVirt and packaging applications in all languages. This will allow you to deploy AppVirt globally and in the various locations that you have offices.

Deploy Virtual Applications Via the Internet!

In 4.2, it was not supported for you to allow clients to connect to the SoftGrid server over the Internet. It was always required for you to VPN into the corporate network first and then connect to the SoftGrid server. In AppVirt 4.5, this isn’t necessary. By using the RTSPS protocol, the clients in your Enterprise can be configured to use the AppVirt Management/Streaming server directly from the Internet. We hope that this will be a more seamless experience for you as you roam from your office to your home and continue to use virtual applications.

Again, this list is far from exhaustive and is just my personal list of the Top 5 new features in AppVirt 4.5 over SoftGrid 4.2. Stay tuned to this blog for continued posts from us on the product team on these features and more in AppVirt 4.5!

Thanks,

Andrew Montgomery, Senior Program Manager, Microsoft Application Virtualization Product Team