The PowerShell script is now available for download on the Immidio website (registration required).

App-V 5.0 now supports the client and sequencer in 24 languages and the server in 11 languages.

You are now able to sequence Microsoft Office 2010, you will need to use the Microsoft Office 2010 Sequencing Kit for Application Virtualization 5.0 and the Microsoft Office 2010 Deployment Kit for App-V to be able to do this.

The SP1 release notes can be found here:

http://technet.microsoft.com/library/dn144768.aspx

Checkout the presentation, including demos here: http://vimeo.com/60436547

As already mentioned on blogs from other community contributors, the APPVVE argument introduced App-V 5 is a very useful mechanism to launch locally installed programs inside a virtual environment of a App-V 5 package without having to make any modifications to that package.

I believe there are two common use cases for the APPVVE argument. The first would be troubleshooting a Virtual Application, simply snooping around inside the virtual environment and see how the application is seeing things.

The second is a bit more specific but you are able to launch specific programs inside a Virtual Application Package, where for instance the “launching” executable is installed locally, but a required part of the application (or a completely other application) is virtualized using App-V 5.

Example:

• You have sequenced a plugin for Internet Explorer that is required for a legacy internal web application.
  
• Any “normal” launch of Internet Explorer on the clients will not use this plugin, obviously.
  
• Now you need to retrieve the PackageID and VersionID from the virtual application package of this plugin. You can find this in the App-V Management Console or use the appropriate PowerShell commands.
  
• Now create a shortcut to Internet Explorer appending the /APPVVE argument, PackageID and VersionID as in the example below (don’t forget the underscore):
  

Download the App-V 5 client administrative templates from here:

http://www.microsoft.com/en-us/download/details.aspx?id=35516

The first edition of the European App-V User Group in 2011, was a great success also due the overwhelming number of attendants. Over 100 people from 14 different countries took part in the event. In the 2013 edition we create a similar experience.

The initiative is focused on bringing people from the App-V community together to learn about Microsoft App-V from the experts and share experiences and knowledge with each other. The events is sponsored by Login Consultants, but is free from commercial messaging and gives an independent insight in the Microsoft App-V market.

There is a large number of App-V MVP’s at the conference presenting on interesting topics. MVP’s Falko Gräfe, Nicke Källén, Ment van der Plas, Ruben Spruijt, Jurjen van Leeuwen, Kalle Saunamäki and Rodney Medina have confirmed their attendance. Additionally also people from the Microsoft support team will be present. Click here for speakers info.

The App-V User Group Conference is an excellent opportunity to learn about Microsoft App-V 5.0 from our presenters. Take a look at the agenda for all topics.

If you would like to participate, please register on the website. The number of available seats is limited, so register in time.

www.appvug.com

More info can be found here:

http://blogs.windows.com/windows/b/business/archive/2012/11/01/mdop-2012-now-available.aspx

App-V 4.6 SP2 is also a part of the MDOP 2012 download, which you will need to support the App-V 4.6 and App-V 5 “co-existence mode”. In addition App-V 4.6 SP2 also supports Windows 8 and Windows Server 2012, so you are not forced to update to App-V 5 just to support Windows 8 for instance.

In App-V 5 all command line scripting has been replaced with PowerShell (requires PoSh 3.0 as a minimum). As we’ve seen from other products of Microsoft the options that are available in the GUI are also available on command line.

There’s only one caveat: we have to learn it! (at least I did )

There are several modules available in App-V 5, depending if you’re on the server, sequencer or on the client they are named [AppVServer], [AppVSequencer] or [AppVClient]. A new feature of using PoSh 3.0 is that the App-V cmdlets no longer need to be imported before they can be used. Each of the modules has a variety of cmdlets available for you to use. They can be queried by using the help command. Here’s an example for the AppVClient

As there are many of them I’ve chosen to write about the “getting started” cmdlets that you might want to use before or during an evaluation or migration to App-V 5.

Note: I’m no PowerShell guru, so there are probably better, quicker and shorter ways to achieve similar functionality. These worked for me, but feel free to comment if you have any comments.

Note 2: Some of the cmdlets require admin privileges.

Converting Legacy App-V packages

If you are an App-V 4.x customer you would have to migrate you App-V 4.x applications to be compatible with the new format. Don’t worry you don’t have to re-sequence your entire application estate!

The conversion process can be initiated by the [Test-AppvLegacyPackage], which will test the App-V 4.x package for compatibility and output any error and warning but does not convert the package, and the [ConvertFrom-AppvLegacyPackage] which does the same but also actually converts it. Some of the conversion process caveats are further described here: http://www.softgridblog.com/?p=180

# ConvertPkg.PS1
# by Ment van der Plas, Login Consultants
# October 2012 - version 0.1
#
# This script enumerates through a given source dir and convert the App-V package to the given destination dir
# All actions will be logged in a log in the destination directory

# Remember to set execution policy (as administrator):
# Set-ExecutionPolicy Unrestricted
# Remember to import the AppVSequencer modules (as administrator):

#Define Source and Destination directories and create log file
$Now = Get-Date -Format yyyyMMdd_HHmmmss
$SourceDir = "C:\Convert\Source"
$TargetRoot = "C:\Convert\Destination"
$LogFile = $TargetRoot + "\Convert_" + $Now + ".log"
Write-Host "Creating $LogFile" -Foregroundcolor Green
#New-Item $TargetRoot -type Dir | Out-Null
New-Item $LogFile -type File | Out-Null

#Enumerate through folder structure and find App-V packages to convert
$DirArray = Get-ChildItem -path $SourceDir -recurse | where{$_.PsIsContainer -and $_-notmatch ‘Icons’}
ForEach ($Dir in $DirArray)
{
$TargetDir = $TargetRoot + "\" + $Dir
If (Test-Path $TargetDir) {
} else{
  Write-Host "Creating $TargetDir" -Foregroundcolor Green
  New-Item -path $TargetDir -type Directory | Out-Null
}

# Convert or Test any found App-V package. Remove remark if required
# $Dir | Test-AppvLegacyPackage >> $LogFile
$Dir | ConvertFrom-AppvLegacyPackage -Destinationpath $TargetDir >> $LogFile | Out-Null
}

Adding App-V 5 package to the local App-V client

So if you have App-V 5 packages created, either converted or created, you’d want to test them on the new App-V client. The quickest way to test if the packages actually works is to add them locally to the App-V 5 client. The following table shows the old and new command line options to achieve this:

App-V 4.x	App-V 5
SFTMIME ADD	Add-AppvClientPackage
SFTMIME ADD	Publish-AppvClientPackage
SFTMIME LOAD	Mount-AppvClientPackage

The following script allows you to import all packages from a certain source directory:

# AddPublishClient.PS1
# by Ment van der Plas, Login Consultants
# October 2012 - version 0.1
#
# This script enumerates through a given source dir and adds and/or publishes and/or mounts the package to the client
# All actions will be logged in a log in the %temp% directory

# Remember to set execution policy (as administrator):
# Set-ExecutionPolicy Unrestricted
# Remember to import the AppV Client module (as administrator):

#Define Source directory and create log file
$Now = Get-Date -Format yyyyMMdd_HHmmmss
$SourceDir = "C:\Temp"
$LogFile = $env:TEMP + "\Import_" + $Now + ".log"
Write-Host "Creating $LogFile" -Foregroundcolor Green
#New-Item $TargetRoot -type Dir | Out-Null
New-Item $LogFile -type File | Out-Null

#Loop through folder structure and find App-V packages
$Packages = Get-ChildItem -path $SourceDir -recurse | where{$_-match ‘.appv’}

ForEach ($Package in $Packages)
{
    #For package found add / publish / mount the package to the client
    #Remove quotes when required

    #Write-Host "Importing $Package" -Foregroundcolor Green
    #Add-AppvClientPackage $Package.FullName >> $LogFile | Out-Null

    Write-Host "Importing and publishing $Package" -Foregroundcolor Green
    Add-AppvClientPackage $Package.FullName | Publish-AppvClientPackage >> $LogFile | Out-Null

    #Write-Host "Importing, mounting and publishing $Package" -Foregroundcolor Green
    #Add-AppvClientPackage $Package.FullName | Publish-AppvClientPackage | Mount-AppvClientPackage >> $LogFile | Out-Null
}

Write-Host "Check out the log file $LogFile for any warnings or errors" -ForegroundColor Green

Adding Packages to the Management Server

Having a management server enhances the customization capabilities of deploying an App-V 5 application. Adding to and deploying applications through the management can be a manual process but can be automated as well. Remember that this was not possible in App-V 4.x (i.e. there are no API’s for importing packages into the server). Extremely useful to build a quick test environment or to automate a production environment!

The cmdlet [AppVServer] holds the possibility to add, grant and publish a package to the environment through scripting. The following script is an example of these actions:

# AddPublishServer.PS1
# by Ment van der Plas, Login Consultants
# October 2012 - version 0.1
#
# This script enumerates through a given source dir and adds and/or publishes and/or grants the package in the management console
# If required it can replace the UNC path (used for enumeration) with an HTTP path (used for streaming)

# Remember to set execution policy (as administrator) and import AppVServer module:
# Set-ExecutionPolicy Unrestricted

#Define Source and HTTP directory, create log file and set the group for publishing permissions
$Now = Get-Date -Format yyyyMMdd_HHmmmss
$SourceDir = "\\appvsrv3\content$"
$HttpDir = "http://appvpub.appv.demo.local/content"
$Group = $env:USERDOMAIN + "\Domain Users"
$LogFile = $env:Temp + "\Import_" + $Now + ".log"
Write-Host "Creating $LogFile" -Foregroundcolor Green
#New-Item $TargetRoot -type Dir | Out-Null
New-Item $LogFile -type File | Out-Null

#Loop through folder structure and find App-V packages

$Packages = Get-ChildItem -path $SourceDir -recurse | where{$_-match ‘.appv’}

ForEach ($Package in $Packages)
{
    #Import, Grant and Publish the package to the App-V Server   
    #Write-Host "Importing, Granting and Publishing package: [$Package]" -Foregroundcolor Green
    #Import-AppvServerPackage $Package.FullName.Replace($SourceDir, $HttpDir) | Grant-AppvServerPackage -Groups $Group | Publish-AppvServerPackage 2>&1 >> $LogFile | Out-Null

    #Import and Grant the package to the App-V Server. Not publishing! 
    Write-Host "Importing and granting: [$Package]" -Foregroundcolor Green
    Import-AppvServerPackage $Package.FullName.Replace($SourceDir, $HttpDir) | Grant-AppvServerPackage -Groups $Group 2>&1 >> $LogFile | Out-Null

    #Import the package to the App-V Server. The packages are not granted not published!
    #Write-Host "Importing: [$Package]" -Foregroundcolor Green
    #Import-AppvServerPackage $Package.FullName.Replace($SourceDir, $HttpDir) 2>&1 >> $LogFile | Out-Null
}

Write-Host "Check out the log file $LogFile for any warnings or errors" -ForegroundColor Green

As you can see having PowerShell as an automation framework foundation really extends the product and allows extreme customization!

I hope these scripts help you get started with App-V 5!

In the past I’ve had many discussions with Microsoft, MVP’s, peers, customers and students about the need for installing to the Q: (Asset Folder) and many people, like Falko Graefe and Tim Mangan have written about it on their blogs. Microsoft’s best practice is to install to Q: and there are several reasons to do so. However they are also debated. Like the infamous performance decrease if one would install to C; which was never measured nor proven. Or like the increased success ratio of virtualized applications.

While talking to some of the attendees after a presentation I did last week we had a nice discussion on the topic in relation to the upcoming release of App-V 5. Making Microsoft’s best practice questionable.

Anyone who has been looking at, hearing of or seeing some the goodness of the upcoming App-V 5 release may have noticed that many things are different. One of them being the package format. Where the App-V 4.6 format was proprietary and had application metadata located externally in the package directory, the App-V 5.0 format is open (extended ZIP) and has all the relevant information inside a single file. This primarily makes the App-V 4.6 and 5.0 format incompatible for their clients, meaning that an App-V 5.0 client is unable to read and apply an App-V 4.6 package and vice versa.

Because Microsoft realized that re-sequencing an entire application landscape isn’t a good marketing pitch they have delivered a legacy package converter with the sequencer, which is operated through PowerShell. The converter is available in two flavors:

• Test-AppvLegacyPackage (which test the legacy package for warning and errors)

ConvertFrom-AppvLegacyPackage (which actually convert the package, but also includes the warnings and errors)

Question that automatically raises is: “What will be the success rate of the conversion process?”

Because no application (nor package) is the same and the administrator may have customized it heavily, it is very hard to do an automatic conversion of one format to another. Therefor it won’t come as a surprise that there are some small caveats to the conversion process (which are also reported if applicable). Let me explain some of them.

OS Value

Microsoft App-V 5 is not supported on operating systems older then Windows 7 and Windows 2008 R2. This means that the converter actively checks if the <OS VALUE> is set and if unsupported operating systems are found, the following error is raised:

The package converter detected one or more applications in your package that is targeted for an unsupported operating system. This package cannot be converted unless the target operating system restriction is removed from the .osd file.

Having an OS limitation in the package doesn’t actually mean that the package won’t work on the target OS, but Microsoft wants to make sure that you manually configure this setting and most importantly test the application!

If you feel confident: OSD files can be batch-converted through scripting. An example of a powershell script can be found here: http://blogs.technet.com/b/appv/archive/2012/04/03/a-script-to-allow-easy-testing-of-your-app-v-package-on-any-os.aspx

Dynamic Suiting

If an OSD holds the <DEPENDENCIES> tag (used for Dynamic Suiting Composition) this will not be converted and will display the following warning:

This package has a dependency on the following package(s). To re-link these packages, apply an app connection group: Package: Camtasia.600.sft, Guid: 75AF56CD-62F3-4CB5-9097-8CC8CBB9E12D

Important: warning messages in the conversion process will still result in a converted, but slightly adjusted, package, whereas errors don’t convert the package at all.

To be fair, I can understand why Microsoft left this out. DSC has been replaced by Connection Groups and they are implemented quite differently. DSC was implemented in the package where connection groups are configured in the infrastructure environment or on the client. There’s basically no way to automate this process.

Scripts and Registry

The legacy package converter doesn’t migrate any <SCRIPT> or <REGISTRY> tags that are part of the package and gives the following warning:

The package converter detected the following script(s) in the legacy package. The script was not converted into the package. Please evaluate whether the script applies to the new package. Instructions for how to add scripts into an App-V 5.0 package can be found in documentation.

The package converter detected but did not convert the following registry variable(s) in the legacy package. If the package does not function correctly, consider manually implementing the registry variable override via policy.

As scripts or registry have deliberately been added to the package by the engineer, it’s probably well documented why this script needed to be applied (yeah right). At least hopefully someone can remember and identify if the script needs to be applied to the new package.

Important: these tags now end up in the manifest.xml file inside the package or can be overruled by the Deployment or User configuration xml files outside the package file. This does bring a small functional change to the table: 4.6 scripts and registry tags could differ per application (OSD file) but in App-V 5 they can only be implemented per package. This architectural change might have influence on the application and/or script behavior.

So what’s the link to the Q: drive discussion?

Well, basically Microsoft recommends that all applications are preferably sequenced to Q: and that only exceptions should be installed to C:. And you are probably also aware of the fact that App-V 5 no longer requires (or actually has) a Q: drive. From what I’ve seen from the conversion process I would like to argue that sequences that are NOT sequenced to Q: are more likely to work after conversion to App-V 5.0.

Allow me to explain: the 4.x sequencer would replace common locations with App-V variables (CSIDL_*) as much as possible. However this was limited to values in for example the registry and environment variables.

Environment Variables

If a package would for example extend the PATH variable with [C:\Program Files\Common Files\Application] because it has installed some dll’s at that location, the sequencer would pick that up and replace it with %CSIDL_PROGRAM_FILES_COMMON% variable.

<ENVLIST>

<ENVIRONMENT VARIABLE="PATH">%CSIDL_PROGRAM_FILES_ COMMON%\Application</ENVIRONMENT>

</ENVLIST>

The legacy package converter recognizes this variable and replaces it with {ProgramFilesCommonX86} in the Manifest.xml files.

<Include>

<Variable Name="PATH" Value="[{ProgramFilesCommonX86}]\Application" />

</Include>

And on the client this is resolved to the corresponding (virtual) directory in the VFS:

Note: this does not guarantee that the application will actually work, like in the example below:

Configuration files

Many applications save configuration in designated files and not in the registry. Unfortunately the
sequencer is unable to detect those text-based files and replace them with variables, like in the example below:

Just like the sequencer, these files are also not picked up by the converter and the file is identical after the conversion. Because it holds a location that is not available, the package will probably behave differently or
not function at all.

Now what if these applications were sequenced to the C: drive instead of the Q: drive?

Configuration files that were created during installation would hold a location that is not App-V specific (like on the Q: drive) but generic (like on the C: drive). The conversion process would literally migrate the value to the new App-V 5 format. In both cases the file would end up in the Virtual File System (VFS) of the application package and the configuration entry would point to that location as well. Which is good because that location is identical in both cases and the App-V engine would make sure that it’s redirected to the corresponding folder.

So my conclusion is that, if other aspects of the environment don’t change (like you simultaneously migrate from an x86 to x64 operating system) and it’s an “in-place” upgrade of the App-V environment, applications that are / were sequenced to C: have a much higher chance to be successfully converted then applications that were sequenced to Q:.

So if you are planning to migrate anywhere in the future, this might be a good time to rethink your sequence strategy. It might be beneficial in the future!

Besides many “under the hood” improvements, the following noticable functionality has been added to this release:

• Diagnostics and monitoring - Reporting information can be generated on the App-V clients. The reporting can be used to analyze, inventory and troubleshoot App-V client usage.
• End-to-End programmability - More Powershell functionality to automate App-V server, client and application sequencing operations.
• Updated App-V Client console - With more IT Pro level capabilities using the UI.
• Additional/improved Integration - Microsoft Office 2013 consumer preview is made available as an App-V package out-of-the-box. System Center Configuration Manager 2012 SP1 Beta will be able to manage App-V 5.0 Beta 2 clients/applications.

As I’ve mentioned before, get your hands on this and start testing. But don’t only sequence new applications, also invest time and effort on application package migration, since your App-V 4.x packages will not work untill you migrate them to the new App-V 5.0 format.

Normally I wouldn’t push people to really start testing as soon as possible, but in this case I really urge you to do so.  

Why should I test?

Well pretty much each component of App-V has been changed/rewritten from scratch.

Since the old SoftGrid days up untill App-V 4.6, everything was build on top of the old base this is why upgrading was quite easy as none of the components changes but where upgraded. I still have some Sequences that I have made with SoftGrid 2.0, which still work on App-V.

This is the first release where major changes have been made to the code, in such a way that a lot of the issues customers encounter should be solved by handling things completely different.

What’s different?

As mentioned, a lot. But here are the highlights in short which are most interesting for you:

• The management/streaming server is still there!
• RTSP is gone. SMB and HTTP(s) streaming only. Which is fine by me. I liked HTTP streaming more anyway.
• New management console for management server, no longer MMC snap-in. Now purely based on Silverlight.
• No more “Q:” drive, you will be able to just see the files on disk from the outside.
• Completely revamped client (Metro style), programmable using PowerShell.
• The Sequencer is pretty much the same as 4.6 SP1
• And last but not least the package format SFT is gone, and so are the OSD and ICO files. Everything will be stored in a new .APPV file format.

The .APPV file is actually a much more open format then the “old” .SFT file. If you rename it to .ZIP, you will see I’m not saying it’s a ZIP file BTW.

Update 23-04-2012: Changing the .APPV extension to .ZIP and editing the file through Windows Explorer is not supported by Microsoft. Also if the file is not readable by Windows Explorer after renaming it to .ZIP, this does not mean the App-V package is invalid.

The most important thing to realise is that you existing packages will not simply work on App-V 5.0, they will all have to be converted to a completely new format and they will run in a different/changed type of virtualization as you have seen so far with previous versions of App-V. App-V 5.0 already provides package converting tools, so my advise would actually be to focus most of your testing on your existing sequences!

Screenshot of new App-V 5.0 Client UI:

Have fun!

The main new features of version 7.5 are:

DirectFlex: Which can manage any application’s settings on the fly, regardless how the application is launched. For any DirectFlex-enabled application, settings are read at application launch and stored at exit, making logon and logoff times even shorter.

Predefined Settings: Easily pre-populate the user environment, like placing a desktop shortcut, creating an application configuration file or setting a registry value. For more advanced scenarios it is possible to use placeholders to insert dynamic information from user and computer variables.

Advanced process criteria: This feature allows more granular control over which Flex configuration files are processed and how they are processed, based on diverse user and computer attributes. Depending on the result of the check, you can control what Flex Profiles action is performed.

As always you can download a trial version from the Immidio website: http://www.immidio.com

Goto http://www.appvug.com for agenda details and registration.

Hope to meet you there,

Rodney & Ment

Benefit of configuring the client during installation is that the client is fully operational in the shortest amount of time and can be used directly after the installation. Configuration can be done through one of the many command line parameters. If command line configuration is not preferred, settings can also be captured in a Microsoft Transform file (MST) and applied to the original installation.

The downside however to applying your setting at installation time is that is does not cover changing any of the configuration items after initial deployment. Configuration changes like additional user permissions, a different client log level or advanced communication configuration are very likely to change during the life cycle of the App-V client.

Login Consultants has delivered additional configuration methods since the early days of SoftGrid and continued to do so through means of Group Policy ADM add-on when Microsoft officially released an ADM template for App-V 4.5 because that template didn’t cover all settings. App-V Group Policy ADM templates allow administrators to centrally manage settings of the App-V client through Group Policy Objects. If you want an overview on which settings can be managed by which template be sure to check out this great article by Login Consultants’ Falko Graefe.

Although ADM templates bring great benefits to administrating the client configuration, they have been replaced (or upgraded if you will) by ADMX and ADML templates since Windows Vista and Windows Server 2008. Since we see most of our customers are (at least) running these operating system versions, shouldn’t we be using the administrative tooling that come with those versions?

That’s what Ruben Koene thought, which is why he created the first App-V Client ADMX template which is available from the Login Consultants website today.

Ruben was very familiar with the settings that can be managed through the ADM template because he was the creator of the current add-on ADM template. Since ADMX files are structured in a very different way, he had to migrate the original template to the new structure setting by setting.

So I decided to sit down with Ruben and talk to him about the new release.

Why did you decide to create an ADMX template?

Koene: I work a lot at App-V customers. Usually they are running at least Windows Server 2008 in their domain, but still are using the ADM templates to manage their App-V clients, while ADMX and ADML templates have some great benefits over the older templates. Since Microsoft isn’t officially offering an ADMX template for the App-V client, I decided to create one of my own.

What’s the difference between the ADM and the ADMX templates?

Koene: ADM templates come in a proprietary format, while ADMX files are XML bases. It took me a little while to figure out the format but then I was able to migrate the App-V client settings one by one.

What are the benefits of using ADMX files?

Koene: When you use ADM templates, the ADM file itself (which can be several MB’s) is placed up inside the GPO. Because GPO’s are placed on each Domain Controller you end up using a lot of storage on the DC’s and consuming unnecessary bandwidth during replication. This does not only apply to the App-V template but also to ADM templates from other vendors, including the ones from Microsoft in the operating system. When the ADM file is not available the GPO can’t be edited. Organizations who have a lot of GPO’s run into a scenario which is known as a “SYSVOL bloat”. ADMX files don’t cause SYSVOL bloats because they are stored centrally and not in the GPO itself. The ADMX template remains centrally stored also when the GPO is edited.

Besides technical, are there any other benefits?

Koene: Yes. I work a lot with international customers and in some countries more than other administrators appreciate localized versions of their software, including their administrative tools. ADMX file have the benefit that specific languages are stored in a separate language (ADML) file. We are releasing with the default English (en-US) language file, but will be releasing German and French soon after because we have many customers in German and French speaking countries. We might rely on the community for additional languages.

Will this be an add-on as well?

Koene: No, it will not. Since Microsoft hasn’t released an ADMX template and we haven’t received any news that they will, we decided to merge the two templates back together. Settings from both templates can now be managed through a single file.

How should customers install the ADMX template?

Koene: The template installation process is very straightforward and comes with a Windows Installer installation method. There are two flavors in the installation process: complete and custom. Complete, which is the default installation, installs everything into C:\Windows\PolicyDefinitions making local Group Policy Editing possible through GPEDIT.msc. The custom installation allows you to install into a different path, like your central store. Make sure you enable the Group Policy Management Console (GPMC) on your machine if you want to be able to manage Domain policies through GPMC.msc). It also allows you to select either one of the available template files.

So there are again two template files?

Koene: Yes, but not for different settings. Because the location of the App-V client settings in the registry depends on the platform you are running on (32bit or 64bit) we made sure we created an ADMX template for both platforms. Don’t worry, you can still manage them from a single console and install them through a single installer.

Last and most important question: what’s the price?

Koene: Login Consultants has a reputation in the market for delivering the best and finest free tooling in this market space, therefore the ADMX client will also be freely available from our website www.loginconsultants.com/download (registration is required).

The binaries are actually available after you have installed System Center Virtual Machine Manager 2012 Beta evaluation.