DFS Issue - Creating App-V Package

[CraigD]

Hi,

To support AdminStudio / InstallShield use in multiple countries we have localised shares where our project files are stored, linked together using a DFS structure.

When we configure the ISM project to build an App-V package, if we are running from a first level DFS link thats been setup directly below the DFS root, then it works fine, however if the link is lower down second level or below then it fails to compile the App-V SFT file, giving a -10003 error for every file in the ISM project.

I've attached a screen shot to visualise the above, when run from the FirstLevel folder it will work fine, but the SecondLevel folder gives the -10003 errors.

Both DFS links are targetting exactly the same files on exactly the same "real" share.

Cheers,
Craig

[MichaelU]

I don't believe there is anything in particular we'd be doing that would make one of these scenarios work while the other does not -- we certainly don't target (or disallow) DFS directly. Perhaps something might show up in a comparison of two ProcessMonitor logs - one working and one failing - that might help diagnose the situation. (Of course teasing the relevant information out of what will be a huge log with different filenames may be really tedious.)

[CraigD]

I've already run a ProcessMonitor log in an attempt to diagnose this problem.

I can see during the build the MSI is extracted to C:\TMP\[AS]\[RandomNumber] along with all the source files. That part works from both DFS paths.

However at some point the extracted source files are copied back to the location the ISM is located on the DFS share under the App-VPackage sub folder ready for compressing into the SFT file.

That's the part thats failing when the ISM is located in a DFS path thats not linked at the root level, but the ProcessMonitor log doesn't show any useful data regarding the transfer back to the network.

I've tried it from different OS's (XP 32 and 64bit, and W7 64bit) and also different DFS root hosts (domain or standalone hosted) and its producing the same behaviour.

Cheers,
Craig

[CraigD]

I downloaded a trial of InstallShield Professional 2011 with the Virtualization Pack and that works from all DFS paths without any issues.

Unfortunately migrating to InstallShield Professional 2011 isn't a solution for us yet as we are using InstallShield Professional as part of AdminStudio (which is still 2010 based.)

So something in InstallShield 2011 resolves this issue that exists in 2010.

[CraigD]

Has anyone got any ideas as to why this would work in InstallShield 2011 but not in 2010?

• Are there any differences in the way each deals with DFS paths?
  
• Does it extract the files in the MSI and compile the SFT any differently?
  

Thanks,
Craig

[MichaelU]

I'll ask our App-V guy and see if he can clarify this. I don't believe we have any specific code changes (or just code itself) specific to DFS, but it wouldn't surprise me if we had a reason to change how we chose a temporary folder for extracting the MSI.

[CraigD]

Any hints as to when the next version of AdminStudio (with InstallShield 2011 included) is due as through whatever mechanism it fixed our issue.

Thanks,
Craig

[CraigD]

Hi Michael,

Did you get any information out of the App-V guy?

Thanks,
Craig

[MichaelU]

We talked about it a bit, and weren't able to figure out anything conclusive (not having a DFS environment set up to test things means it's pure conjecture). Perhaps the biggest (relevant) difference between these versions was a migration to VS2008. My understanding is several file primitives we used could be implemented completely differently in this version, which might explain the behavior change.

As for when you'll see that in AdminStudio? There's a chance the DLL could be dropped in, but we really can't support that. I don't have date information, but in general I was under the impression that there's up to about a six month lag between IS releases and AS releases that consume it. Does that sound like what you've seen previously?

[CraigD]

Hi Michael,

Thank you for that. 6 months sounds fairly typical to what's happened before. Your post inspired me to try a number of the DLL's from the IS 2011 System folder in the IS 2010 System folder.

The VirtConv.dll file alone seems to do the trick and fixes the problem and the resulting App-V package functions okay. Not sure what the long term impacts are and I realise its not officially supported but at least we have a workaround.

Thank you for your help.

Cheers,
Craig

[CraigD]

Although the updated VirtConv.dll seems to work okay now with DFS paths we've now hit the dreaded 255 character path limit issue.

It's fairly easy to hit on a defined DFS structure as the App-V extracted files make the path even deeper than it already is.

There are updated API's in Windows that can be used to prevent the 255 path limit becoming an issue but I imagine this would mean InstallShield would need to be recoded.