Changing the AppV content store location and how it affects sequences already published in RES Workspace Manager 2011

Let me start at the beginning….

Way back in June of 2012 I came to the project I am about to finish. During the start of the project the AppV content share was placed somewhere on the DFS. We were told (repeatedly) that that location was never going to change. Based on that we made about fifty sequences with the UNC location of the content share on the DFS as the location were the sequences reside. In conjunction with file based streaming this solution looked solid. The sequences were published in RES Workspace Manager 2011 so all the osd files were imported in to the RES Workspace Manager database.

In hindsight we should have implemented an environment variable from the start, but for reasons unknown we didn’t.

Just recently I was told that the location of the AppV content share needed to change. It was placed on a location that was prone to filling up with excessive data. I had a meeting with the system administrators to name some of the actions that needed to be executed.

Defined actions:

  • Create a new LUN dedicated to the AppV content share.
  • Copy all sequences from the current AppV content share to the new AppV content share.
  • Edit the Preload scripts.
  • Edit all osd files on the new AppV content share and replace the UNC path with an environment variable.
  • Edit all sequences that are published through RES Workspace Manager and replace the UNC path with an environment variable.

The first two actions (LUN and copy) were completed by the system administrators. Actions three and four were completed by another member of the migration team and me. I edited the Preload scripts (modified versions of the Wilco van Bragt preload scripts which can be found here). Another member of the migration team wrote a PowerShell script to change all the osd files on the new content store.

PowerShell Script:

$osds = Get-ChildItem -include *.osd -recurse -path \\[path to new AppV content share]
foreach ($osd in $osds)
{
$osdFile = $osd.fullname
$xml = New-Object XML
$xml.Load($osdFile)
$xml.SOFTPKG.IMPLEMENTATION.CODEBASE.HREF = $xml.SOFTPKG.IMPLEMENTATION.CODEBASE.HREF.ToUpper().Replace([path to new AppV content share], “%SequenceStore%”)
$xml.Save($osdFile)
}

And for the last action I had to consult RES Software. I opened I case with the question if there is a bulk method of changing the osd files in the RES Workspace Manager database. Within a few hours I received a response which proved good enough to implement.

The key combination CTRL + SHIFT + F9 opens up the screen below IF you press them in the Administration – Custom resources node. According to the mail of RES Software. In the dutch interface I found it at Configuratie – Datastore – Maatwerkbestanden.

RES_CTRL-SHIFT-F9

After selecting Microsoft App-V Integration and clicking OK I am presented with the following view.

RES_App-V_Integration

This view makes it easy to rapidly change all the osd files that are present in the database without having to open each individual published application to discover if it is in fact a published AppV sequence and to change the osd file by clicking in the “Click here to change the OSD file in the datastore” line in each published sequence. Which in the end saves time.

This option made the transition to a new AppV content store a lot easier to implement and it sped up the implementation a lot. Any improvements on the PowerShell script and RES Workspace Manager bulk edit action are more then welcome in the Comments field.

Leave a Reply