dsccommunity
Share service applications between farms
In my environment, I have shared services farms that publish BDC, search, user profile, and managed metadata service applications for other farms. I've been looking at the currently published resources but not seeing DSC resources that would help me configure this. Wondering if there any plans to add support for this type of functionality.
Thanks, Naomi
@NaomiReeves Not on our radar at the moment, but no reason we can't include it. We are adding something to control the permissions that would help with this scenario, but we should look at adding and testing anything else needed to make it sharable.
This is an interesting one, but also a challenging one: It requires configurations on the two farms and output of each configuration as input for the remaining configuration on the other farm:
- Exchange trust certificates between the farms. https://technet.microsoft.com/en-us/library/ee704545.aspx (Exchange trust certificates between the two farms)
- On the publishing farm, publish the service application. https://technet.microsoft.com/en-us/library/ee704545.aspx (Export the Published URL)
- Set the permission to the appropriate service applications. https://technet.microsoft.com/en-us/library/ff700211.aspx (Set permissions for the farm ID of the consuming farm on the publishing farm)
- On the consuming farm, connect to the remote service application. https://technet.microsoft.com/en-us/library/ee704558.aspx (Connect the published service app to the consuming farm, using the Published URL)
Any suggestions on how to exchange these settings/this data??
Well I think in the context of publishing stuff (and I'm open to suggestion on this) we really should be focusing on a single farm at a time from a DSC perspective (the thought of a single config that crosses to another farm to make changes doesn't sit well with me at all - realistically the config going too far beyond a single server bothers me, back to that whole web.config discussion) so in my head it kinda goes like this:
- Publishing farm gets a config that ensure it has the certificates set up, the service app gets marked as published and the permissions are set
- Consumer farm gets a config that ensures the certs and then tells it to go and consume from the publishing farm
Now the scenario here where the consumer could go looking for the service app before it exists as its not tightly coupled is one that comes up, but realistically I would expect that the DSC resource we use there would just report a failure connecting to the primary farm to consume from. I mean if we try to use the file resource to connect to an admin share on a server to copy files, and the file server role hasn't been installed there yet we don't go reaching to the other server to install it so that the requesting server can get what it needs - it will simply try again at its next interval to get the files, and hopefully the target server is ready by that point. Do you get where I'm coming from on that one @ykuijs ?
I agree with @BrianFarnhill in that I'd like to keep the config focused on a single farm. I assumed that the farms would remain independent of each other and would not automatically configure the trust between themselves, but would rather use the configuration that I provide via DSC resource(s) to ensure that it remained in place.
As an aside, do you think that any cross-farm trust resources could also be able to be used to configure the trusts needed for farms consuming provider hosted add ins? At first glance these look vaguely similar.
Specifically to the service application publishing/consumption, I think these would be helpful:
- Resource to create a service application connection group
- Resource to publish service application and associate it to a service application connection group
- Add ability to specify a service application group for a web app
Thanks!
@BrianFarnhill, I get where you are coming from and totally agree, a resource should only focus on one server/farm.
The reason I brought this up was that I was thinking about a fully automated install of a farm, including this publishing/consuming of services. The steps you are describing cannot do this. Better yet: Before being able to create the config for the consuming farm, you need to have the publishing farm configured. This because you need the info from the publishing farm, for example the publishing URL, included in the consuming farm config.
So the question we will have to ask ourselves: Do we mind requiring fully creating the publishing farm before being able to create the config for the consuming farm?
For the Server-2-Server trust, we can use a file share (which is accessible to both servers) to exchange the certs. We don't need the File resource for that. Each server/farm exports his certs to that file share and checks if certs from the other farm exist there. If so, import them. If not, do nothing. If, like @NaomiReeves suggests, the trust is similar to provider hosted apps we can create a generic resource that does this for both scenarios.
@ykuijs I think it's OK that we work under that model of "build the publishing farm first then configure and build the consumer", it's something that from a deployment sense is not ideal if you want to hit one button and "deploy everything" but realistically I don't think it's that big of an cost to have to do it that way and then we get to keep our sorceresses focused within single servers/farms.
So in terms of resources to enable this scenario, I'm thinking we go with:
- xSPServiceApplicationProxyGroup - creates/manages the proxy groups. Could work with a list of strings to determine the members of the group?
- xSPTrustedRootAuthority - for establishing trust based on the exported certificate
- xSPTrustedServiceTokenIssuer - for the STS trust needed
- xSPCertificateTrustExport - for exporting the certs from one farm so they can be consumed by another
Then I think we update the previous service app resources that support being published to include a property that is "Published" as a boolean that defaults to false and thats how we can flag them as being published. We already have the xSPServiceAppSecurity resource which can manage permissions for sharing as well as administrators so that should cover the permissions piece, and then to finish it off we need to add some sharing proxy resources for those service apps that will be consumed. So something like:
- xSPSharedMetadataServiceApp
- xSPSharedSearchServiceApp
- xSPSharedUserProfileServiceApp
So these would have the properties of the farm topology URL from the other farm to pull them all out.
Does this sound like I've covered all bases on this on? Anything anyone thinks it missing from that scenario or anything need to change?
That is comprehensive.
Isn't there a need for the publisher farm to also have the consumer farm certificates? If so, we need to ensure certificates are created beforehand.
On 7 Apr 2016, at 8:32 AM, Brian Farnhill [email protected] wrote:
@ykuijs I think it's OK that we work under that model of "build the publishing farm first then configure and build the consumer", it's something that from a deployment sense is not ideal if you want to hit one button and "deploy everything" but realistically I don't think it's that big of an cost to have to do it that way and then we get to keep our sorceresses focused within single servers/farms.
So in terms of resources to enable this scenario, I'm thinking we go with:
xSPServiceApplicationProxyGroup - creates/manages the proxy groups. Could work with a list of strings to determine the members of the group? xSPTrustedRootAuthority - for establishing trust based on the exported certificate xSPTrustedServiceTokenIssuer - for the STS trust needed xSPCertificateTrustExport - for exporting the certs from one farm so they can be consumed by another Then I think we update the previous service app resources that support being published to include a property that is "Published" as a boolean that defaults to false and thats how we can flag them as being published. We already have the xSPServiceAppSecurity resource which can manage permissions for sharing as well as administrators so that should cover the permissions piece, and then to finish it off we need to add some sharing proxy resources for those service apps that will be consumed. So something like:
xSPSharedMetadataServiceApp xSPSharedSearchServiceApp xSPSharedUserProfileServiceApp So these would have the properties of the farm topology URL from the other farm to pull them all out.
Does this sound like I've covered all bases on this on? Anything anyone thinks it missing from that scenario or anything need to change?
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub
@camiloborges Yep - so lets add xSPCertificateTrustImport to that list as well - or maybe make it one resource with a property set to export/import?
To prevent adding another resource and potentially confusing users, I would vote for a xSPCertificateTrustManagement resource with a Type property to specify export or import.