The D-Spot (The Deployment Spot)

We needed to have Access 2010 delivered through App-V on the same computers where Office 2010 Standard was published to. Office 2010 needs the Office 2010 Deployment Kit for App-V to activate, this was already up and running on our client computers.

If we streamed Access 2010 next to Office 2010 Standard, Access launched and asked for a Product Key:

I thought the Office Software Protection Platform must take action here, and contact our KMS Server to obtain a license, but it didn’t behave like that. The Office Software Protection Platform (osppsvc) service is responsible for the activation. This service is installed by the Office 2010 Deployment Kit for App-V.

After going through Technet and some forums, I finally got it all together and found the solution:

The KMS activation is done when installing the Deployment kit for App-V. To use Access 2010 and Office 2010 Standard together, the Deployment Kit for App-V needs to be installed with the STANDARD and ACCESS parameters combined. These Licensing Flags can be used on the command line separated by a space:

OffVirt.msi ACCESS=1 STANDARD=1 /qb REBOOT=REALLYSUPPRESS

To verify which actions the OffVirt.msi installer exactly did, use the logfile parameter and check the logs:

OffVirt.msi ACCESS=1 STANDARD=1 /qb REBOOT=REALLYSUPPRESS /l*v c:\temp\OffVirt.log

If the ACCESS=1 parameter wasn’t set, you’ll get this in the logfile;

MSI (s) (E0:E0) [17:11:35:989]: Skipping action: Access_KMS_Client (condition is false)

When you did set the ACCESS=1 licensing flag;

MSI (s) (40:58) [17:29:32:699]: Doing action: Access_KMS_Client

Going through the logs makes everything clear. Combining the OffVirt.msi parameters makes sense!

We had serious performance issues with our virtualized Office 2010. First launch could take up to 6 minutes, while Feature Block 1 was only about 100MB!

Because only Office 2010 was having this slow first start (and autoload), we blame our sequence, the App-V infrastructure or the application itself. But neither of these were the cause of the problem.

What got our attention was the Network utilization, it only reaches 2%. While this wasn’t an issue at all with other App-V applications. Streaming other applications goes fast and uses up to 95% of the available network bandwidth. But Office 2010 was sequenced with the 4.6 RTM version of the Application Virtualization Sequencer. Most other applications were sequenced with App-V sequencer 4.5.

Since version 4.6 the blocksize is fixed at 64KB, there is no way to change this with the GUI sequencer.

I managed to change the blocksize with the trail version of SFT Encoder. Once the blocksize was changed from 64 to 32K, Office 2010 launches ten times faster! However this isn’t a permanent solution for the slow launch. We don’t want to convert all newly sequenced packages with SFT Encoder!

So the reason why only Office 2010 suffered form this slow first start was because it was the only large package sequenced with version 4.6. Other packages made with sequencer 4.6 where to small to notice the slow launch.

A colleague of mine changed the network card speed from 1GBit/Full Duplex to 100Mbit/Full Duplex. With this setting changed, packages created with sequencer 4.6 are streaming fast like it should.

Maybe it’s a networking issue (switches?), maybe a network card setting misconfiguration (teaming?) .. to be investigated. But at least our 4.6 sequences are streaming fast again!

Thanks to Madelinde Walraven for the help with this issue!

To be continued!

After an App-V Server upgrade from Application Virtualization Server 4.5.1.15580 to 4.5.2.17140 we encountered the following error:

The Application Virtualization Client could not launch ApplicationName.

The package requested could not be found in the system data store or the files associated with this package could not be found on the server. Report the following error code to your System Administrator.

Error code: XXXXXX-XXXXXX0A-20000194

After some deep digging we found out that the App-V Management Server Installer set the CONTENT_DIR back to the default value! As we don’t use the default content dir C:\Program Files\Microsoft System Center App Virt Management Server\App Virt Management Server\content we found our problem.

Solve this by manually change the registry key  SOFTGRID_CONTENT_DIR (in HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Server) to your current Content location (for example \\servername\contentdir).

Microsoft’s application virtualization solution has reached version 4.6 some weeks ago. The most important thing about version 4.6 is support for 64 bit. The Server parts could run on x64 operating systems, but it was impossible to install the AppV client on x64 operating systems. Time to upgrade!

As the client needs to be updated first, I will cover the client upgrade process only. (Client first, server next, sequencer last). Good to know that only the client and the sequencer are updated to version 4.6. No need to update your Management server as version 4.5.2.17140 is still the latest and greatest.

AppV has some Prerequisites, I will install them first. Then I will install the AppV client itself, using some command line parameters and a registry file import for applying custom settings.

Prerequisites

Application error reporting

msiexec /I SOURCE_PATH\dw20shared.msi /QN APPGUID={4C1CE627-6B28-436E-BD12-3A881065FB20} REBOOT=REALLYSUPPRESS ALLUSERS=1

Visual C++ 2005 runtime

SOURCE_PATH\vcredist2005_x86.exe /Q:A /c:”VCREDI~3.exe /Q:A /C:”"MSIEXEC /I VCREDIST.MSI /QN “”"

Visual C++ 2008 runtime

msiexec /i SOURCE_PATH\vc2008\vc_red.msi /qn /l*v “LOGFILE_PATH\vc2008runtime.log”

AppV 4.6 Client with command line parameters

Because storage is expensive, we have a different cache policy for virtual machines. Cache size on virtual systems don’t have to be as enormous as on physical machines. Not only the cache size is reduced in virtual machines, also the AutoLoad features are disabled via the MSI command line parameters.

To identify virtual machines I query on the computer name. As we use specific names for our VM’s, this should be a piece of cake!

We do an architecture check in a batch file. So I have two code blocks, one for x64 and another for x86 operating systems. Only the paths are different, so I will post only one.

AppV Client Installation

Echo install AppV x64 Client

rem Virtual Machine check
Echo %computername% | findstr /i “ISOPC99 VPC” >NUL && (
    Echo Installing AppV x64 client for Virtual Machines
    msiexec /i “SOURCE_PATH\x64\setup.msi” SWICACHESIZE=”4096″ autoloadTriggers=0 AutoLoadTarget=0 AutoLoadonLaunch=0 AutoLoadonRefresh=0 AutoLoadonLogin=0 SWIDCSDISPLAY=”Company Streaming Server” SWIDCSTYPE=”RTSP” SWIDCSHOST=”appvserver.domain.local” SWIDCSPORT=”554″ SWIDCSREFRESH=”on” SWIGLOBALDATA=”C:\Program Files\Microsoft Application Virtualization Client\GLOBAL\” SWISOFTGRIDDRIVE=”Q” /q REBOOT=REALLYSUPPRESS /l*v “LOGFILE_PATH\appv46.log”
    ) || ( 
   Echo Installing AppV x64 client for Physical Machines
    msiexec /i “SOURCE_PATH\Source\x64\setup.msi” MinFreeSpaceMB=”6000″ SWIDCSDISPLAY=”Company Streaming Server” SWIDCSTYPE=”RTSP” SWIDCSHOST=”appvserver.domain.local” SWIDCSPORT=”554″ SWIDCSREFRESH=”on” SWIGLOBALDATA=”C:\Program Files\Microsoft Application Virtualization Client\GLOBAL\” SWISOFTGRIDDRIVE=”Q” /q REBOOT=REALLYSUPPRESS /l*v “LOGFILE_PATH\appv46.log”
    )

Echo Import Regkeys
regedit /s SOURCE_PATH\appv64_v2.reg

The registry file that is imported in the last line specify the sftlog.txt log file location, and some other tweaks, have a look:

Registry import (x86)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration]
“SystemEventLogLevel”=dword:00000004
“LogFileName”=”C:\\PATH_OF_YOUR_CHOICE\\sftlog.txt”
“UserDataDirectory”=”%APPDATA%”
“ApplicationSourceRoot”=”RTSP://server.domain.local:554″
“LaunchRecordMask”=dword:005a0000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\DC Servers\Company Streaming Server]
“Period”=dword:000002d0
“Refresh”=dword:00000001
“Reporting”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\AppFS]
“UnloadLeastRecentlyUsed”=dword:00000001
“MinPackageAge”=dword:00000001

Registry import (x64)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\Configuration]
“SystemEventLogLevel”=dword:00000004
“LogFileName”=”C:\\PATH_OF_YOUR_CHOICE\\sftlog.txt”
“UserDataDirectory”=”%APPDATA%”
“ApplicationSourceRoot”=”RTSP://server.domain.local:554″
“LaunchRecordMask”=dword:005a0000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\DC Servers\Company Streaming Server]
“Period”=dword:000002d0
“Refresh”=dword:00000001
“Reporting”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS]
“UnloadLeastRecentlyUsed”=dword:00000001
“MinPackageAge”=dword:00000001

That’s it.

When the SQL Server is on the same machine as the App-V Management Server (formerly known as the VAS Server), the App-V Management Server Service doesn’t start after a reboot.

Solve this by adding the MSSQLSERVER as dependency to App-V service in the registry. (Use MSSQL$SQLEXPRESS when using SQL Server Express edition). Name the new string DependOnService and value MSSQLSERVER or MSSQL$SQLEXPRESS  in the hive HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AppVirtServer:

To finalize, add a DWORD named DelayedAutostart with value 1 in the same hive:

Reboot the server, the Application Virtualization Management Server service should start (with a slight delay).

Microsoft announced that Desktop Optimization Pack (MDOP) 2009 R2 will be released in late October 2009 and will add Windows 7 support for all components, except for MED-V.  Server and management components will support Windows 2008 R2.

Microsoft is promising that the new MDOP tools will have management components that support Windows Server 2008 R2, which was released to manufacturing on Sept 14 and available through MSDN as we speak.  In addition, all of the components in MDOP 2009 R2, except for MED-V, will support Windows 7.  Microsoft expects to add Windows 7 support in MED-V when it releases MED-V 1.0 Service Pack 1 sometime in the “first quarter of calendar year 2010″, according to the blog.

MDOP employs six innovative technologies to increase desktop manageability, reduce TCO, and improve overall infrastructure satisfaction:

• Application Virtualisation. Deploy software applications that are never installed and never require regression testing, yet follow users anywhere, on demand.

• Advanced Group Policy Manager. Help IT take control of the desktop through effective change management, versioning and resets.

• Asset Inventory Service. Scan software inventory and transform title data into information that can help administrators make better asset-management decisions.

• Diagnostics and Recovery Toolset. Quickly repair unbootable or locked-out systems, restore lost data, remove malware from infected systems and diagnose problems.

• Microsoft Enterprise Desktop Virtualisation (MED-V). Enhance deployment and management of Virtual PC images on a desktop running the Windows operating system. Simultaneously provide a seamless user experience on a virtual PC environment independent of the local desktop configuration and operating system.

• Microsoft System Center Desktop Error Monitoring. Prevent or reduce the response time for system crashes and freezes with granular error filtering and automated alerts.

With its virtualization technologies and manageability components, MDOP 2009 R2 is an essential part of your Windows 7 planning and deployment strategy.
This is a great opportunity to highlight the key innovations of MDOP 2009 R2 and talk about how MDOP can help you rapidly migrate to Windows 7, deploy applications with greater ease, resolve application incompatibility, and reduce desktop management costs.

Full Article on The Official MDOP Blog.