No matter what type of UCMA application you want to write, one of the first things you’ll need to do is set up your environment to work with the Lync server. No matter what, this involves configuring a machine certificate, installing the prerequisites, and provisioning your application using the Lync Management shell. The official documentation on provisioning has come a long way for UCMA 4, so I’ll just point you to here (General Provisioning steps) for the basic steps. This post is just going to cover the changes for each method, and why you’d choose one over the other.
Automatic Provisioning (documented here) is the recommended activation procedure from Microsoft, and in theory it makes a lot of sense. Your application server has a replica of the Central Management store, and creating your collaboration platform is greatly simplified:
//Create the platform settings ProvisionedApplicationPlatformSettings platformSettings = new ProvisionedApplicationPlatformSettings(applicationUserAgent,_customProperties.ApplicationURN); //Create the CollaborationPlatform _collaborationPlatform = new CollaborationPlatform(platformSettings);
Manual provisioning (documented here) on the other hand, is similar to what we had in UCMA 2, and has the app server semi-absent from the Lync topology. It’s still a trusted application server, but it has no local replica. As such, we have to specify a few more settings when we create the platform:
ServerPlatformSettings platformSettings = new ServerPlatformSettings(applicationUserAgent, _customProperties.ApplicationServerFQDN, (int)_customProperties.ApplicationServerPort, _customProperties.ApplicationGRUU, certificate); //Create the CollaborationPlatform _collaborationPlatform = new CollaborationPlatform(platformSettings);
This constructor now has to include the gruu, certificate, port, Lync FQDN, and app server FQDN. Most of these are just outputs from the provisioning cmdlets that you ran to set up the application server, and the certificate is easily obtained by getting a reference to the local machine store like this:
X509Store store = new X509Store(StoreLocation.LocalMachine); store.Open(OpenFlags.ReadOnly); X509Certificate2Collection certificates = store.Certificates;
And then finding the appropriate cert based on the FQDN. It’ll also mean storing a lot more application configuration than you would in the auto provisioned case, but we’ll see in a minute why that might not be a bad trade off.
Now, as for reasons you’d want to use either of these methods, consider these advantages for manual provisioning:
- The application server does not need to be a member of the same domain as the Lync server, or even a member of ANY domain. Even a workgroup computer will work, which I’ve used when building reusable VMs containing UCMA apps. This can be really handy for cases where you’re deploying a managed application in an environment where someone wants you to support your app, but doesn’t want you having full domain access.
- Setup of the local replica can take a while: Usually, this goes pretty smoothly, but there’s more stuff to install, more reboots of the server, and more cmdlets to run to get replication working correctly. In general, it seems like more trouble than it’s worth just to avoid having to copy a gruu around.
- You’re tightly tied into one version of UCMA (more on this in another post…)
- You can easily run applications against multiple Lync domains: Switching between a dev, test, and production Lync server is just a matter of changing a setting in your app. No re-provisioning required.
On the other hand, auto provisioning means:
- less chance for errors when copying a gruu around
- certificates are assigned through powershell, rather than in the application config
So, when to use each? Ideally, support both in your app-it’s not difficult to add a flag, and you’ll need to store configuration information anyway, so give your users the option. When you’re in development, you’re definitely going to want to use manual provisioning. I know that I switch between Lync environments all the time, and my main Lync lab domain is separate from the domain my dev machines sit on. It’s much more flexible, and other than the initial setup of copying the settings from Lync to the app server, management has never been a problem. When deploying in production though, I’ll often flip things over to automatic provisioning if possible, just to keep the application servers in the topology, and allow Lync admins to manage app server certificates through the management shell. As always though, having the option gives you flexibility in whether you’re on the domain or not.