Migrating Content Share

Managing an App-V environment; Check-lists, Tips and Tricks, Best Practices, Videos, How to Guides

Moderators: kirk, jur, kkaminsk

Post Reply
dgoulson
Wanna Be AppVirtualizeR
Posts: 16
Joined: Wed Apr 28, 2010 11:08 am

Migrating Content Share

Post by dgoulson » Wed Feb 26, 2014 5:12 pm

Our existing AppV content share is creaking and groaning, often causing lots of faults. Same can be said for our aging AppV management servers (4.5). Unfortunately it doesnt look like I'm able to create a new AppV 4.6 infra just yet, so plan is to create a new content server and copy/move applications over to that.
Am I right in saying that if I configure the ASR on each server 1 at a time, it will use the content from that new location? It should override the CODEBASE HREF value shouldnt it? As I understand it, ASR is for more a situation where you need more local content (remote offices and AppV Desktops), but I could use the function like this yeah?
Once complete, I will change each OSD script (if any) and published application (Citrix env) to point to new Content Share.
Last stage, once all above is complete would be to change AppV Server Content directory.

Please can anyone tell me if this is likely to go wrong somewhere! Have I missed something? Its a large env, so I need to be as careful as possible. Circa 400GB Content (1/2 is preprod).

Thanks in advance
Dave

kirk
Guru
Posts: 810
Joined: Fri Aug 27, 2004 3:32 pm
Location: Germany
Contact:

Re: Migrating Content Share

Post by kirk » Thu Feb 27, 2014 12:58 pm

Hi,

that should work, but you should test it
- sometimes ASR struggles with the right folder structure (multi-level hierachy). For instance you OSDs may contain \\oldserver\content\packageA, you set ASR to \\newserevr\content and the result is an attempt to load the SFT from \\newserver\content\content\packageA (or the other way round... missing folders)
- Note that 'in between' some resources will be loaded from the old server, but streaming (SFT) will occur from the new server - don't confuse yourself, esp. when you deploy a new package or upgrade one
- use the Verbose log on the client for troubleshooting - it should show original and 'ASR'ed' URL (but it grows very fast then)
- on the client, unload, then load a package to see if ASR works
- You could consider using OSD SourceRoot and IconSourceRoot as well
- You could have a look onto viewtopic.php?f=2&t=4045&hilit=powershell to modify the OSDs/SPRJs afterwards
Falko

dgoulson
Wanna Be AppVirtualizeR
Posts: 16
Joined: Wed Apr 28, 2010 11:08 am

Re: Migrating Content Share

Post by dgoulson » Thu Feb 27, 2014 5:07 pm

Thanks kirk, I hadnt thought of OSDSourceRoot and IconSourceRoot, so added that into my plan. Testing seems to work fine, so looks like a goer.
We already have scripts to change OSD files on mass, so that shouldnt be a problem and by then we will have manually changed a large enough number to see any errors.
Dave

kirk
Guru
Posts: 810
Joined: Fri Aug 27, 2004 3:32 pm
Location: Germany
Contact:

Re: Migrating Content Share

Post by kirk » Fri Feb 28, 2014 2:41 pm

OK,

btw. I usually recommend to open&save a package on the Sequencer after every modification. This makes sure that all resources (OSD, SPRJ, Manifest, MSI) are on the same level and consistent.
Esp. the MSI is a little bit sensitive here, as it only contains copies of the original OSD/SPRJ - so as soon as you use the MSI you may get different results compared to the App-V Management Server + OSD combination (just imagine you 'install' a package on a test machine for troubleshoting) - but as you are not modyfing the package content itself, things should be OK.
Falko

Post Reply

Return to “Managing”

Who is online

Users browsing this forum: No registered users and 1 guest