locked
SCCM and dynamic suites RRS feed

  • Question

  • Is it possible to compose dynamic suites when integrating APPV with SCCM. What should be mentioned in the codebase tag?
    Wednesday, November 18, 2009 4:46 PM

Answers

  • Hello,

    Yeah it should work.

    See this article;
    http://technet.microsoft.com/en-us/library/cc843662.aspx

    /Znack
    • Proposed as answer by znack Wednesday, November 18, 2009 8:55 PM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 2:38 PM
    Wednesday, November 18, 2009 5:24 PM
  • Hi,

    I would not classify this scenario as working "fine". You can make it work (technically), but you have to be very good aware of the arrival of the application on the client, like Tim mentioned.

    From what I see is that when application A has a dependency of application B (which is referenced in the dependencies tag of app A) and app A is imported through the wizard of ConfigMgr the actual CODEBASE of app A is altered to reference the changed SFT file. However the CODEBASE of the dependency (to app B) isn't altered.

    This means that application B will not be delivered dynamically when application A launches on the client. 
    If MANDATORY has been set to true, application A will not start (like Tim mentioned). 
    If MANDATORY has been set to false, application A will start, but depending of the dependency might not function (because it's simply not there).

    The only way (as far as I know) to workaround this issue is to have application B available (in cache!) on the client when application A launches. Because if the application B is already in cache, the client will ignore the URL mentioned in the CODEBASE and launch the dependency based on its GUID.

    To make application B available on the client you'd have several options:
    - push it (through machine or used based collections based on mandatory assignment)
    - chain A and B together with a Task Sequence (only with machine based assignments!) and advertise the TS (doesn't have to be mandatory)

    The reason why I'm not classifying this implementation as "fine" is that now you have to keep track of your dependencies in your applications (OSD) AND in your deployment sollution (ConfigMgr) making sure that every dependency is there before the primary application launches.
    I reckon that depending on the number of applications (and dependencies) this can be a challenge.

    Just to be clear: in a native App-V scenario (so with streaming servers) this behavior would not occur. In that case you'd only have to keep track of you dependencies in your applications. Dependent applications are streamed to the client just-in-time, so before application A would launch.

    Regards
    Ment van der Plas
    Thursday, December 24, 2009 10:02 AM
    Answerer

All replies

  • Hello,

    Yeah it should work.

    See this article;
    http://technet.microsoft.com/en-us/library/cc843662.aspx

    /Znack
    • Proposed as answer by znack Wednesday, November 18, 2009 8:55 PM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 2:38 PM
    Wednesday, November 18, 2009 5:24 PM
  • Yes, works fine.  You might need to be careful with MANDATORY=, since you probably have less control over order of arrival at the client, unless you send out as a task sequence.
    Wednesday, November 18, 2009 5:33 PM
    Moderator
  • Hi,

    I would not classify this scenario as working "fine". You can make it work (technically), but you have to be very good aware of the arrival of the application on the client, like Tim mentioned.

    From what I see is that when application A has a dependency of application B (which is referenced in the dependencies tag of app A) and app A is imported through the wizard of ConfigMgr the actual CODEBASE of app A is altered to reference the changed SFT file. However the CODEBASE of the dependency (to app B) isn't altered.

    This means that application B will not be delivered dynamically when application A launches on the client. 
    If MANDATORY has been set to true, application A will not start (like Tim mentioned). 
    If MANDATORY has been set to false, application A will start, but depending of the dependency might not function (because it's simply not there).

    The only way (as far as I know) to workaround this issue is to have application B available (in cache!) on the client when application A launches. Because if the application B is already in cache, the client will ignore the URL mentioned in the CODEBASE and launch the dependency based on its GUID.

    To make application B available on the client you'd have several options:
    - push it (through machine or used based collections based on mandatory assignment)
    - chain A and B together with a Task Sequence (only with machine based assignments!) and advertise the TS (doesn't have to be mandatory)

    The reason why I'm not classifying this implementation as "fine" is that now you have to keep track of your dependencies in your applications (OSD) AND in your deployment sollution (ConfigMgr) making sure that every dependency is there before the primary application launches.
    I reckon that depending on the number of applications (and dependencies) this can be a challenge.

    Just to be clear: in a native App-V scenario (so with streaming servers) this behavior would not occur. In that case you'd only have to keep track of you dependencies in your applications. Dependent applications are streamed to the client just-in-time, so before application A would launch.

    Regards
    Ment van der Plas
    Thursday, December 24, 2009 10:02 AM
    Answerer