RDS 2012 R2 Separate Session Collection Behavior

Question

Hi everyone!  I should start by saying that I've found a number of threads which are semi-related to this topic, but they just don't seem to address my particular complaint.  I'm not sure if this is a bug, a configuration error on my part, or if
it is expected behavior (which would be unfortunate for my intended use cases).
The issue is that I need to provide two separate collections of RemoteApps, and I only want the collection appropriate to the logged-in user to be displayed in Web Access (or in the feed, for that matter).  One collection includes an expansive set of
RemoteApps, and the other collection includes a limited subset of those published in the first.
Now, I know that a SH can only belong to one session collection.  That makes sense, and in my case, I wouldn't want it any other way.  It offers better separation between the user environment intended for use by employees, and the user environment
intended for use by non-employees, which is a bit more restrictive.  (Those are the actual purposes of the two collections described earlier.)  So far, so good.  Now, it seems to me like every other role beside the SH role should be able to
do its job for all collections.  What other purpose could the concept of a "Collection" possibly serve, after all?  If I had to stand-up Connection Broker, Web Access, Gateway, and Session Host for every collection of RemoteApps, then there
wouldn't need to exist any concept in RDS 2012 R2 called "Collections".  So, I figured that Connection Broker, Web Access, and Gateway could serve all collections, and Session Host is of course limited to serving one single collection.  And,
I guess, that's largely the way it works, with one exception.
My issue is that in Web Access, all RemoteApps from all published RemoteApp collections are presented to every user who has access to one collection OR the other, despite my best intentions of having provisioned each collection with seprate user group assignments
using two separate AD groups.  I don't want to advertise all RemoteApps from all collections in the Web Access namespace!  To me, the presence of "User Group" configuration at both the Collection level and at the RemoteApp level implies
that there is some user group filtering going on, but so far that's looking like a false assumption.  Why would the RemoteApp list in one collection bleed into the RemoteApp list in the second collection?  Why would I want the users of one collection
to see the applications of the other, even when they're not going to be able to launch them anyway?
Does anyone have anything to add to the equation?  Is there something I'm missing?  Thanks ahead of time.

Answer 1

This is now resolved.  There is obviously some additional configuration necessary in some relatively odd places when you want your RemoteApp collections to work as advertised.  I hope this thread can help others in that regard.
The relevant (error) event generated for each "populate list of RemoteApps for Web Access" process (refreshing the web access portal was my test case), when my IIS application pool is provisioned by the new AD account is Event ID 10, Source: RDWebAccess. 
In the body, it says "[...] unable to access rdcb1.[local]" and suggests that the RD Web Access server needs to be added to the TS Web Access Computers security group on the connection broker.  However, that was obviously already the case.
Although not 100% correct in its suggested resolution, this error was helpful, because it shows that the break is occurring when Web Access tries to populate RemoteApps, and is shows that the break is occurring en-route to the CB server.  So, I added
the new service account (for the Web Access application pool identity) to the Administrators group on the server with the CB role, and all is now resolved.  I now have two separate collections, the list of each appearing for the appropriate user scopes,
but not for both user scopes like before. 
Obviously, adding an account as an administrator fixes a lot of access related things very easily, but it is probably not the least-privileged way of doing things.  To that end, I'd like to know the least privileged way, but can certainly live with
this much improved functionality as-is.
Thanks for all your help, Razwer.