none
How do you force App-V 5 clients to stream apps from a specific publishing server?

    Question

  • I am having an issue where the App-V 5 clients in remote locations are not streaming the apps from their local App-V Publishing servers, but are instead going back across the WAN to the central App-V Management server.  


    Here is a breakdown of the work that I've done to troubleshoot this:

    I have a GPO setup for each site that configures the Publishing server to go to the local site server (Publishing Server Display Name and Publishing Server URL).  I also have streaming set to AutoLoad All Applications.

    The Publishing server for each site has been added to the central Management server.  When you launch the URL for each Publishing server you see the XML file that shows all of the applications are being published there.  

    I created a DFS Share \\domain\AppV which is replicated to all of the remote sites.  All applications are published in the Management server with the path \\domain\Appv\%AppName% so that the path is consistent to allow the apps to pull from the DFS share instead of any particular server.  However it appears that on random machines, that they will bypass the local server an connect back to the central server and attempt to stream over the WAN.

    In App-V 4.6 I was able to use a drive mapping to connect to the local Content share on the site server (using the Package Source Root GPO setting to enter a drive letter), but this doesn't appear to work with App-V 5.  

    I have run the App-V Powershell commands on the clients that are bypassing the local server and streaming from the central server to confirm their settings.  They are all getting the proper GPO settings and should be using their local server, so very I'm troubled as to why they would go back centrally or how they would even know to do this as the GPO should restrict them to only know about the one local publishing server

    Has anyone encountered this or come up with a solution to force clients to use their local server?

    Monday, August 12, 2013 6:17 PM

Answers

  • Hello,

    Well, this is most likely a DFS-issue - have you verified your DFS-setup?

    See these interesting articles;

    http://blogs.technet.com/b/askds/archive/2012/07/24/common-dfsn-configuration-mistakes-and-oversights.aspx

    http://blogs.technet.com/b/filecab/archive/2006/04/13/425169.aspx


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

    Tuesday, August 13, 2013 6:42 PM
  • So I have it finally working, tested and confirmed in two separate sites.  Here is what I did:

    1. Configured sites and services for each site.  I wasn't going to do this, as I don't have a DC at each site, but this turns out to be the key.  Created the Site, Subnet and SiteLink for each site.

    2. Created a DFS namespace (\\domain\appv) on the MGMT server that points to my Content folder and contains all of the packages that I published to my App-V MGMT server (using the path \\domain\appv\appname in the App-V MGMT Console).  This way all clients look to the same path for their packages.  I then installed the DFS role and added a DFS target folder (from the MGMT server) on each of the local DP servers in each site and setup replication to copy out all of the App-V packages.

    3. Set my GPOs for each site to tell the clients at that site to go to their local DP server as Publishing Server 1.  Each DP server has the Publishing Server installed and the XML file replicated from the MGMT server.

    DFS now sees that sites and services is configured (shows the proper site name for each location automatically when you create the DFS target folders) and therefore will stay local to its own subnet (based on the IP range set in Sites and Services) so it eliminates the problem of clients going back to the MGMT server or another DP server that have the same namespace share that the App-V apps are published to.  

    All clients tested (over 130 now) have all gone successfully to their local DP server instead of back to the MGMT server, which is the problem that I've been trying to solve.  Before this, there didn't seem to be any reliable way to force all clients in a particular site to go to the content share at that site to stream their packages.   This was a requirement due to a very slow WAN link between the MGMT server site and the distributed local sites.  Similar to the way the WSUS works (each update is pushed once to a local DP, which distributes the updates to the local clients instead of them going across the WAN).  App-V will now do the same with the software packages.   

    Thanks for all of your help guys.  Perhaps I wasn't clear enough on the issue I was having, but your suggestions helped to point me in the right direction to find the fix.  

    • Marked as answer by BradK77 Tuesday, August 27, 2013 1:27 PM
    Tuesday, August 27, 2013 1:27 PM

All replies

  • If your share has the correct rights, I can't see any reason why you could not map a drive to it. I have not encountered this issue with the publishing server settings not being applied correctly. Does the correct publishing server appear in the registry on the client machines?

    How did you deploy the client? Is it possible the client was deployed with the central server publishing information set either in the MSI\MST or passed on the command line as a parameter? It would be good if you could check under the reg hive in HKLM and confirm what publishing server settings appear.

    Also, did you perform a gpresult ? to ensure the GPO was applied?


    PLEASE MARK ANY ANSWERS TO HELP OTHERS Blog: rorymon.com Twitter: @Rorymon

    Monday, August 12, 2013 8:34 PM
  • Are you sure this is an App-V issue and not a DFS issue? Check where the DFS referrals are coming from and where the clients are connecting to from a DFS perspective.


    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.


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

    Twitter: @stealthpuppy | Blog: stealthpuppy.com | The Definitive Guide to Delivering Microsoft Office with App-V



    Monday, August 12, 2013 10:07 PM
  • The client was installed on the image with no server configured.  All server settings are pushed by a GPO for each site with the specific server for that site configured.  I have checked with the Powershell commands and in the registry to confirm that the clients are point to their correct local servers, but some still traverse back to the central server.   I have also run a gpresult /r to confirm that the correct GPOs are applied.


    Tuesday, August 13, 2013 1:38 PM
  • Originally I wasn't using DFS at all, I just published the apps on the MGMT server and added a publishing server, but found that the clients all bypassed the publishing server entirely, as all of the apps had the path \\MGMTserver\Content\%AppName%.  So it made sense that they would by-pass the local publishing server and go back to the MGMT server.  That is why I moved to a DFS structure so that I could use a \\domain path instead of a \\servername path.

    It was actually from one of your blogs Aaron that we got to idea to go with a DFS structure, as we couldn't figure out how to get around the \\servername path for all of the apps.

    The strange thing is that it does work for some of the clients, but not for all of them.  I imaged a batch of 30 machines and about 20 of them connected to the local site server right away to start streaming the apps, but the other 10 defaulted to the central server.  All were in the same OU in AD with the same GPO applied.  I did a side-by-side comparison of two machines, one going to the local server and another going to the central server and both had identical settings when I ran the Powershell commands to get the App-V server name and checked the settings in the registry.

    I imaged another batch of 30 machines and had the same results except this time it was closer to a 50/50 split, so it appears that the machines are randomly selecting their publishing server.

    Tuesday, August 13, 2013 1:43 PM
  • Hello,

    When you add the packages, what path do yo use?


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

    Tuesday, August 13, 2013 4:46 PM
  • I used the path \\domain\AppV\%appname% when I added the packages to the MGMT server.

    \\Domain\AppV is the DFS share, so the path is consistent on all Publishing servers.  

    Originally I had used the \\MGMTServer\Content\%appname% path, but all of the clients bypassed the local Publishing server completely, as the path was telling them to go back to the MGMT server specifically.  That's why I decided to use the DFS path instead.

    I've been playing with the Package Source Root field in the Computer Configuration\Policies\Administrative Templates\System\App-V\Streaming section of the GPO to try to force the clients to connect to the local server's content share or DFS share or to map a V: drive to the DFS share and force them to use that, but unfortunately it isn't working.  As soon as I populate that field with anything, App-V will not show any apps in the list at all anymore.   Do any of you know the correct usage for the Package Source Root field?

    Tuesday, August 13, 2013 5:17 PM
  • Hello,

    Well, this is most likely a DFS-issue - have you verified your DFS-setup?

    See these interesting articles;

    http://blogs.technet.com/b/askds/archive/2012/07/24/common-dfsn-configuration-mistakes-and-oversights.aspx

    http://blogs.technet.com/b/filecab/archive/2006/04/13/425169.aspx


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

    Tuesday, August 13, 2013 6:42 PM
  • Hi znack,

    I did find the second link interesting and have a question regarding this:


    Do you have to use Sites and Services in order to deploy App-V with DFS?  I currently have 2 central domain controllers, so I haven't had the need to do anything in Sites and Services, but from reading this blog post it sounds like if I had setup subnets for each site that it might help to keep the local machines local, just as if would if you wanted to keep them only talking to a local DC



    Thursday, August 15, 2013 2:59 PM
  • Perhaps I'm going about this the wrong way.  In App-V 4.x I used to install a Management Server and then use scripts to robobopy /MIR the Content share out to all remote sites.  I then would use a V: drive mapping in the login scripts for these sites to map them to their local server and used the Package Source Root setting in the GPO to tell the clients to go to the V: drive to get their packages.  I never had to use Streaming servers at all and didn't see the point in them.  This worked perfectly in App-V 4.x, but I can't seem to get it working the same way in App-V 5.


    So my question is this:

    What is the tried, proven, best practice from Microsoft for adding an application on a central App-V 5 Management server and having it stream to local clients in a remote site from a local server in that remote site?   I can't seem to find anything official from Microsoft on this.  

    Further to that, what does the publishing server actually do?   Aside from replicating the XML file list of published apps in the web-interface from the management server, I don't see it actually doing anything out of the box.  I don't see any packages actually replicating to the Publishing server or streaming from it by default.  I can't seem to find anything official from Microsoft on what the best practice is to get this server to actually do anything other than list an XML file in a webpage.


    Thursday, August 15, 2013 3:05 PM
  • Aaron, you posted a blog regarding App-V 4.x which is similar to what I'm looking for.  Do you have any updates on this for App-V 5?

    http://stealthpuppy.com/using-applicationsourceroot-to-stream-from-a-local-source/

    Friday, August 16, 2013 3:42 PM
  • Hello,

    Well - I think you are viewing this very oddly.

    DFS isn't App-V specific. Its functionality (such as allow clients to retrieve data from a target close to them) depends on your Active Directory design. The configuration you see in Sites and Services is part of Active Directory.

    If your infrastructure isn't working before, bringing App-V will certainly not resolve any issues you had before.

    So, publishing server;

    App-V publishing server can be contacted by App-V clients to retrieve XML-data of which applications they are assigned and howto publish them. Nothing else.

    It will not stream anything, it will however provide a path (such as a UNC-path - that could point to a DFS-target) that the client will connect to.

    From your description, the issue you are presenting is due to the concern that the UNC-path doesn't always point to a local repository of files. App-V doesn't care where these files reside - as it only knows about the UNC-path.

    If you want to, per a client installation basis, override the option and hardcode a client to point to a specific path - you could install it (or later use the powershell cmdlets) with the packagesourceroot. This is documented on TechNet;

    http://technet.microsoft.com/en-us/library/jj713460.aspx

    This will obviously only override what the Publishing Server provides. It will give you the option to provide a static hardcoded reference to a specific server. As one could guess, it doesn't resolve your DFS infrastructures issues.


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

    Sunday, August 18, 2013 9:13 PM
  • So I have it finally working, tested and confirmed in two separate sites.  Here is what I did:

    1. Configured sites and services for each site.  I wasn't going to do this, as I don't have a DC at each site, but this turns out to be the key.  Created the Site, Subnet and SiteLink for each site.

    2. Created a DFS namespace (\\domain\appv) on the MGMT server that points to my Content folder and contains all of the packages that I published to my App-V MGMT server (using the path \\domain\appv\appname in the App-V MGMT Console).  This way all clients look to the same path for their packages.  I then installed the DFS role and added a DFS target folder (from the MGMT server) on each of the local DP servers in each site and setup replication to copy out all of the App-V packages.

    3. Set my GPOs for each site to tell the clients at that site to go to their local DP server as Publishing Server 1.  Each DP server has the Publishing Server installed and the XML file replicated from the MGMT server.

    DFS now sees that sites and services is configured (shows the proper site name for each location automatically when you create the DFS target folders) and therefore will stay local to its own subnet (based on the IP range set in Sites and Services) so it eliminates the problem of clients going back to the MGMT server or another DP server that have the same namespace share that the App-V apps are published to.  

    All clients tested (over 130 now) have all gone successfully to their local DP server instead of back to the MGMT server, which is the problem that I've been trying to solve.  Before this, there didn't seem to be any reliable way to force all clients in a particular site to go to the content share at that site to stream their packages.   This was a requirement due to a very slow WAN link between the MGMT server site and the distributed local sites.  Similar to the way the WSUS works (each update is pushed once to a local DP, which distributes the updates to the local clients instead of them going across the WAN).  App-V will now do the same with the software packages.   

    Thanks for all of your help guys.  Perhaps I wasn't clear enough on the issue I was having, but your suggestions helped to point me in the right direction to find the fix.  

    • Marked as answer by BradK77 Tuesday, August 27, 2013 1:27 PM
    Tuesday, August 27, 2013 1:27 PM