locked
App-V Infrastructure + Office Add-ins question RRS feed

  • Question

  • Hi All,

    This is my first post, so apologies for any mistakes.  I have a total of 3 questions (queries not problems), but they're all interlinked which is why I've opted to put them all in the one post.  I also apologise in advance if this post is a little on the long side.

    I'm currently contracted to a company performing App-V sequencing for a XenApp 6.5 migration (from XP desktops).  They have used an external company to design the solution for them.  Only a few departments will be moving to the new solution with the rest of the population rolling out to Windows 7 (with MSI + ThinApp).  Not sure why they're using different solutions to be honest, but I'm only focussed on the XenApp desktop.  For their existing XP and new Windows 7 desktops they will continue to use their existing software distribution system (not SCCM).

    Query 1:

    My problem with the solution the external company has provided is they've put SCCM 2007 into the mix.  My understanding of integrating SCCM with App-V is you only do this if you already have SCCM implemented or you want to use it for a large desktop estate.  Surely the App-V Management server is the way to go when setting up a new Citrix farm where you want users to get their applications on a per-user basis?  To me it seems they're adding an extra layer of complexity for no reason.  I could understand it more if there was a plan to use SCCM to manage all of the desktops, but that definitely is not the case.

    Query 2:

    I've read the App-V and SCCM whitepaper, as well as some blogs and I'm slightly confused when it comes to the App-V icons on Terminal Services.  I understand that SCCM 2007 cannot be used with per-user targetting because the SCCM client will only respond on the console session, so a per-machine deployment must be used.  That's fine, I understand that.  I read either in that whitepaper or on a blog that it means all users get all icons (due to the machine deployment).  I've only worked with Citrix in the past and not Terminal Services (or RDS now) and from memory if a shortcut is installed to All Users Start Menu\Programs it doesn't appear on the user's start menu within their published Citrix desktop.  In order to see that icon you have to create a published application.  Is this just a difference between Terminal Services and XenApp?  Because we'll be using XenApp it's unlikely to be an issue, but I would just like to know if Terminal Services responds differently with icon publishing.  It terms of the users actually getting their published icons for XenApp they plan to publish the sfttray command with the /launch parameter, which obviously allows for per-user targetting.

    Query 3:

    Office plugins:

    So one of the great things about the App-V Management server is the per-application permissioning.  If you have, for example, a virtualised office you can sequence all of your Office addins seperately and then use DSC to tie the relevant Office app to each plugin.  By setting each of the dependencies to Mandatory="FALSE", it allows users to only get the plugins they're permissioned to.

    Under the SCCM environment I believe it's a case of either 1) each user gets every plugin or 2) each plugin needs it's own shortcut: e.g Word with Plugin A, Word with Plugin B.  As a user If I used 5 addins I would want to launch Word once and see each of the plugins, not launch 5 copies of Word.  Am I right in saying there isn't any mechnism to prevent the user from launching the plugin they're not permissioned to under the App-V / SCCM model?  I.E. the DSC link will just go and grab the package out of the App-V Cache via the GUID and there is nothing to validate whether that user can or can't run it

    These 3 things have been playing on my mind, so it will be great just to get a clear explanation on them.

    Thanks for your time.

    Friday, June 1, 2012 8:29 AM

Answers

  • If SCCM isn't already being used to manage the desktop environment, then it seems odd to just introduce SCCM to deploy App-V applications to the XenApp environment. But what about deployment and management of the base Windows image with XenApp and core applications? SCCM would be a natural fit for that role as well.

    Installing App-V packages via the MSI or SFTMIME ADD PACKAGE /GLOBAL will deploy the package applications and shortcuts to the machine globally, thus available for all users. This is no different to installing an application natively and using solutions such as AppLocker and controlling which shortcuts are displayed to control access to applications.

    The native Management Server is just one method of delivering applications to users; however you will want to ensure that application streaming does not affect performance (large write IO etc), so pre-caching the packages is recommended.



    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.


    Friday, June 1, 2012 3:06 PM
    Moderator

All replies

    • Query 1: the solution you choose to deliver App-V packages is really a business decision - do you want a single way to deliver App-V packages regardless of the desktop type to reduce administration? (physical, virtual, RDS)
    • Query 2: This is correct, SCCM 2007 can't be used for per-user deployments of App-V packages. There are no real differences between TS/RDS and XenApp as far as applications are concerned. XenApp extends TS/RDS. Publishing App-V packages would be the same command line if using XenApp or just native RDS
    • Query 3: If SCCM is used to deliver App-V packages to the machine (i.e. as global packages) then you'll need other solutions such as AppLocker to control which applications users can launch. Additionally App-V doesn't change application licensing - for example, Office is licensed per-device, but if you're delivering Office to users via App-V, you'll need to control which devices they are accessing Office from. The native App-V infrastructure cannot control access to App-V packages by device.


    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.

    Friday, June 1, 2012 11:03 AM
    Moderator
  • Hi Aaron,

    Just wanted to say the Stealthpuppy blog is awesome.

    Thanks very much for your reply.  Just need to follow up briefly and then I can "Mark As Answer".

    Query 1 - They're only looking to use SCCM to deploy the App-V package to the XenApp server and not as a total solution, which is why I think we should be using the management server.  It just seems that introducing SCCM only to deploy App-V packages to XenApp is overkill.  They plan to keep their existing SD system for their desktop machines and not switch over to SCCM.

    Query 2 - Thanks for this answer.  If I could just extend on this a little... The XenApp environment isn't built yet, so to do an initial smoke test of the App-V packages I've been using a Win2K8 R2 VM with the App-V client configured in stand alone mode.  I've been using the .MSI to install the packages.  The .MSI uses the manifest file to generate the application shortcuts.  If I install the .MSI as user a) the desktop shortcut for the application is generated.  If I logon as user b) the icon is also there.  So, what I was trying to get at with my question was when SCCM executes the machine advertisement it is obviously going to create the desktop shortcut, which were configured within the manifest file (which is used to import the package into SCCM).  What I'm trying to understand is these shortcuts that are created (not the ones that are published from the Citrix console with the sfttray command), do they bleed over into the user's published desktop?  Hence what I read before in article that said "all users get all icons".

    Query 3 - Edit-  Re-read your message on this one - Perfect, thanks.


    • Edited by plumblbw Friday, June 1, 2012 11:59 AM
    Friday, June 1, 2012 11:52 AM
  • If SCCM isn't already being used to manage the desktop environment, then it seems odd to just introduce SCCM to deploy App-V applications to the XenApp environment. But what about deployment and management of the base Windows image with XenApp and core applications? SCCM would be a natural fit for that role as well.

    Installing App-V packages via the MSI or SFTMIME ADD PACKAGE /GLOBAL will deploy the package applications and shortcuts to the machine globally, thus available for all users. This is no different to installing an application natively and using solutions such as AppLocker and controlling which shortcuts are displayed to control access to applications.

    The native Management Server is just one method of delivering applications to users; however you will want to ensure that application streaming does not affect performance (large write IO etc), so pre-caching the packages is recommended.



    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.


    Friday, June 1, 2012 3:06 PM
    Moderator