locked
Redirection or DSC issue? File appears in SFT_MNT but not in virtual location RRS feed

  • Question

  • My legacy application creates a user data file inside the application folder (I know, not good practice!), for example D:\MyOldApp\userdata.ini

    This file is then queried by a Microsoft Word macro (the user launches a Word template), which populates the new document with the contents of userdata.ini (customer address details, fwiw).

    My legacy app is a DSC reference inside virtualised Office 2003, otherwise Office wouldn't be able to see the user data file inside the legacy application environment.

    OK, so what's the issue? Word cannot 'see' the file to extract the data.

    I can see userdata.ini in %SFT_MNT%\MYOLDAPP.001\VFS\, but it isn't visible in D:\MyOldApp\.

    However, opening a CMD prompt inside the virtual environment I can see the file in D:\MyOldApp\.

    I've read Kalle's gridmetric post about VFS in AppV - I understand how a file or resource can be hidden, but this doesn't seem the same issue. I've also read Dan's packaqeology post - again, close to my issue but not quite.

    We are using AppV RDS Client 4.5.3 , Windows 2003. Any ideas would be greatly appreciated.

    PS We can't get the application to save the userdata.ini to %appdata% which would be the best solution.



    • Edited by TenBob Wednesday, June 13, 2012 2:55 PM
    Wednesday, June 13, 2012 2:46 PM

Answers

  • Turns out I didn't need official Microsoft help. I can confirm the issue lies in a terminal services environment:

    MyOldApp stores userdata.ini in the users locally cached PKG file. As this file is temporary and LOCAL, this can't be seen by Word if Word is launched from a different App-V server.

    Of course, userdata.ini can be seen by Word after the secondary package (MyOldApp) has been closed as the users PKG file is saved from it's temporary location to the network.

    The issue I now have is to make sure MyOldApp & Word always launch from the same server...

    Sounds so simple now I have the answer!

    Many thanks for your help

    • Marked as answer by TenBob Thursday, June 28, 2012 1:55 PM
    Thursday, June 28, 2012 1:55 PM

All replies

  • Which package is the primary package and how are you launching the command prompt (from the primary or secondary package)?


    Twitter: @stealthpuppy | Blog: stealthpuppy.com

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    Wednesday, June 13, 2012 5:05 PM
    Moderator
  • Primary package is Office 2003.

    Good point - I am launching CMD from secondary package, my old app.

    I've just launched from primary package (Office) and the result is the userdata.ini is indeed hidden. So:

    CMD prompt launched from secondary package (My Old App, which creates userdata.ini), userdata.ini visible in 'D:\MyOldApp\' and '%SFT_MNT%\MYOLDAPP.001\VFS\'

    CMD prompt launched from primary package (Office), userdata.ini NOT visible in 'D:\MyOldApp\' but IS visible in '%SFT_MNT%\MYOLDAPP.001\VFS\'

    (I should mention that ALL the application files are visible in either scenario, only the user file created isn't visible from the primary package)


    • Edited by TenBob Thursday, June 14, 2012 9:35 AM
    Thursday, June 14, 2012 8:14 AM
  • Hello,

    Does the folder exist in both packages?

    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, June 19, 2012 12:46 PM
  • Hello,

    Does the folder exist in both packages?

    Nicke Källén | The Knack| Twitter: @Znackattack

    'D:\MyOldApp\' only exists in secondary package. The primary package is Office 2003 (no additional or custom folder changes from a default installation).

    The folder is visible from both packages, only the 1 file 'userdata.ini' is hidden from Office.


    • Edited by TenBob Tuesday, June 19, 2012 1:13 PM
    Tuesday, June 19, 2012 1:12 PM
  • Hello,

    If you verify with process monitor how Office tries to find the userdata.ini - what does that show you? Which folders does it traverse? In what order does it do it?

    Nicke Källén | The Knack| Twitter: @Znackattack

    Wednesday, June 20, 2012 8:49 PM
  • OK, have found out a little more on this issue:

    After creating the Userdata.ini file, if I CLOSE MyOldApp, then the file can be seen by Word.

    If MyOldApp remains open, then Word can't see Userdata.ini.

    However, if in an earlier session of MyOldApp, I created Userdata.ini, and with MyOldApp still open, Word sees the earlier created file. Shut down MyOldApp, then Word sees the newly created file.

    If Word is opened before MyOldApp, the same test results are observed.

    Does this make sense?!

    I can't see any setting in the sequencer that would enable newly created data to be immediately visible (or hidden) to DSC'd applications. Is this a client issue/feature/bug?

    Tuesday, June 26, 2012 8:42 AM
  • Hello,

    Settings are saved within the PKG-file - when the applications are open they are actively working against a temporary local copy (within %LOCALAPPDATA%).
    Once the application is not in use - it is copied back to the user data settings folder - where the word package can access it.

    Suggestions on howto easily and smoothly resolve your problem;

    Create a single package

    Exclude the folder from the virtual environment so that both virtual applications are working against a native folder

    Manage files / registry keys using a third-party management solution

    Wether this fits your environment I can't say...


    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, June 26, 2012 9:03 AM
  • Thanks Nicke.

    Our environment is Terminal Services/Citrix.

    I can't exclude the folder from the VE as it's also the application folder in the secondary package. (I can't create the folder on the physical server either).

    This sounds like a limitation of DSC in our version of the client.

    Tuesday, June 26, 2012 9:59 AM
  • Hello,

    I wouldn't say its in "your" "version" of the client - its simply a limitation stated in the whitepapers released.

    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, June 26, 2012 11:18 AM
  • My understanding of DSC is that 2 (or more) applications are loaded into the same virtual environment.

    If that is true, and the secondary application creates a file, why does the secondary package have to be shut down before the primary package can see it?

    That's by design? It sounds more like a bug - I can't see how that is of benefit, hence my client version comment.

    Thanks for the help.

    Wednesday, June 27, 2012 10:46 AM
  • Hello,

    Well - your statement are valid in its simplicity, however Dynamic Suite Composition does still have its obstacles in a complex environment (anything that is more than one package) making that statement invalid.
    If you believe its a bug - I suggest you open a case with Microsoft.

    Settings may be saved in several places - some of these places may not be beneficial for a specific scenario when it comes to DSC. A file generated by one application (depending on which package it originates from) may be saved in a different PKG-file than the primary-package -causing this behavior.

    In case you want a full understanding - the not easy and not smooth route - to possibly find a working scenario, read these articles;

    http://www.tmurgent.com/WhitePapers/AppV_DSC_Transparency.pdf

    http://www.softgridblog.com/?p=17

    http://ajweh.com/blog/?p=95

    http://blog.stealthpuppy.com/virtualisation/dynamic-suite-composition-and-short-names/

    http://packageology.com/2011/12/strange-afoot-app-v-dsc-land/

    http://blog.gridmetric.com/tag/vfs/


    Nicke Källén | The Knack| Twitter: @Znackattack


    • Edited by znack Wednesday, June 27, 2012 10:56 AM
    Wednesday, June 27, 2012 10:56 AM
  • I've read most of those blogs and certainly the whitepaper before, but thanks for the URL dump ;)

    I disagree with your view that my statement is invalid. It depends on whether you think all resources in a VE should be visible to all apps in the VE (Microsoft say this is the case in their DSC notes). It's no secret that DSC isn't documented fully, hence the work by Tim in his whitepaper. The word 'bug' is also mentioned several times on those blogs.

    Many thanks for your help. My next stop is opening a case with Microsoft.

    Wednesday, June 27, 2012 1:03 PM
  • Many thanks for your help. My next stop is opening a case with Microsoft.

    If you get a resolution or update from PPS, please do update this thread.


    Twitter: @stealthpuppy | Blog: stealthpuppy.com

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    Wednesday, June 27, 2012 1:31 PM
    Moderator
  • Turns out I didn't need official Microsoft help. I can confirm the issue lies in a terminal services environment:

    MyOldApp stores userdata.ini in the users locally cached PKG file. As this file is temporary and LOCAL, this can't be seen by Word if Word is launched from a different App-V server.

    Of course, userdata.ini can be seen by Word after the secondary package (MyOldApp) has been closed as the users PKG file is saved from it's temporary location to the network.

    The issue I now have is to make sure MyOldApp & Word always launch from the same server...

    Sounds so simple now I have the answer!

    Many thanks for your help

    • Marked as answer by TenBob Thursday, June 28, 2012 1:55 PM
    Thursday, June 28, 2012 1:55 PM