Wednesday, May 21, 2014

How To Convert a 16MB block size PVS VHD to a 2MB PVS VHD file using Hyper-V

If you've created a 16MB block size VHD file using Citrix PVS you've probably experienced that these disks are a touch more difficult to manage than the 2MB ones.  With 16MB block size VHD's you cannot mount them in Windows natively, compact them, and manipulate them with regular VHD tools.  The only tool that I've been able to manipulate them with is PVS, specifically CVHDMOUNT.EXE.  This allows you to mount the VHD file as a hard disk, but even so you cannot manipulate the disk with lots of tools; the disk isn't recognized at all.  This includes tools like Disk2VHD that you would think would make it easy to make it into a VHD.  Not so.

In order to convert from a 16MB block size PVS VHD you need to do the following steps:


1) Mount the VHD file using CVHDMount.exe (you may need to install the Provisioning Server role on it to get the CVHDMount.exe tools)


2) Go into Disk Management and set your disk to "Offline"


3) Open Hyper-V, right-click your server and go "New > Hard Disk..."


4) Choose the location and filename to save it.


5) Choose to copy from the PHYSICALDISK that corresponds to your VHD you mounted.


6) Click Finish.   And now you're done!  :)

Thursday, May 15, 2014

How to globally set Java settings

How to set Java settings on a machine/system/global level:

1) Create a new text file at "C:\Windows\Sun\Java\Deployment\deployment.config"
2) populate it with two values:

#deployment.config
#May 15 2014
# The First line below specifies if this config is mandatory which is simple enough
# The second line just tells Java where to the properties of your Java Configuration
# NOTE: These java settings will be applied to each user file and will overwrite existing ones
deployment.system.config.mandatory=True
deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties

Create or copy deployment.properties at
(You can copy the one created for your user profile @ %userprofile%\LocalLow\Sun\Java\Deployment\deployment.properties as a template).

Modify the values as needed (example):
#deployment.properties
deployment.security.level=MEDIUM

If the user has an existing deployment.properties under their user profile you may need to delete it.  On next java launch it will create a deployment.properties under their profile with the values you specified in the global file missing from their local file.

Tuesday, May 06, 2014

Microsoft Disable-AppvClient.ps1

Microsoft has noticed that AppV 5 sometimes has trouble cleaning up after itself and it looks like Microsoft has made a cleanup powershell script for AppV5.  It is located here:
 C:\Program Files\Microsoft Application Virtualization\Client

The command needs to be executed like so:

  .\Disable-AppVClient.ps1 -ModulePath "C:\Program Files\Microsoft Application Virtualization\Client\AppvClient\AppvClient.psd1" -RemoveAllPackages -PackageInstallationRoot "D:\AppVData\PackageInstallationRoot"

This powershell script will also inform you if you need to remove the packages manually because of permissions issues.  I would highly recommend putting it in the shutdown script of your servers/desktops.

Sunday, May 04, 2014

AppV 5.0 SP2 HotFix 4 (HF4)

I upgraded our test environment for AppV 5.0 SP2 to HF4  and came across an issue where our packages won't load.  The error specifically was: "Package {248b49bd-39f9-471c-b655-7483c11a6f69} version {868b72ed-ac56-4b8e-ae42-60a049401330} failed configuration in folder 'D:\AppVData\PackageInstallationRoot\' with error 0x4C40330C-0x12."

We got this error for all of our packages.  I procmon'ed it and it appeared to be OK, saying that it was creating folders and loading the .appv package, but when I went into the D:\AppVData\PackageInstallationRoot folder, nothing was in there.

It turns out that with Hotfix 4 Microsoft has changed the PackageInstallationRoot permissions to require Authenticated Users (Read/Write) to the folder, without this ACL we get the above error.  Microsoft appears to have made this change to allow Globally published application to be able to be launched on network shares without requiring the local machine account added to the share.  Unfortunately, without the ACL on the local folder we get the error above.  To create the folder with the correct ACL's, just delete the existing folder and restart the AppVClient service.  The service will auto-create the folder with the correct ACL's.

If the service does not recreate the folder, you may need to run the AppV publishing scheduled task to get it created.