Client Policies and the Lync Client SDK
I had one of those moments the other day when I wondered what would happen if X was enabled and Y happened. In this case, I have a strict client policy for Lync where P2P File Transfers are disabled and I wanted to see if the Lync Client SDK respected these policies.
The code for doing the initial transfer is located here on MSDN.
Upon running this code I was promptly presented with the following popup;
Althoug
h this is good (the SDK is evaluating the server-side policies), I would have liked to have seen an exception thrown back to my code, instead of a UI error. If I was writing a plugin to Lync, I could have handled this much more gracefully with an inline warning and logged it out appropriately. But hey the important part is that it placated my curiosity and it worked.
Oh and in case you are wondering, because you don't have access to the LyncAutomation interface when running in UISuppressionMode you cannot do this at all.
SQL 2008 R2 Silent Reporting Services install for Lync
Before I get into Reporting Services, a quick addendum on the Powershell blog from a few weeks ago, where I mentioned that you needed to run the set-executionpolicy unrestricted in Powershell. On an x64 machine you will need to modify the powershell execution policy in both the x86 and x64 instances of powershell to avoid this error, one is just not good enough.
So, with that out of the way, let’s say you want to deploy the Lync Monitoring Role Reports, but your monitoring server is not hosting the databases and you are not able to install Reporting Services onto your database servers.
How do you accomplish this feat? Running the install you say? Tut, tut… if you only it were that simple.
For databases running SQL 2008 R2 one must run the install silently for these components to be installed. The following script (executed from a command prompt) will install the components for Reporting Services, when completed you can go into the GUI for the Reporting Services Configuration and setup the Report Server databases (point them to your selected SQL instance), Web Service and Reporting Service URLs.
setup /q /ACTION=install /FEATURES=RS /InstanceName= SERVER_INSTANCE /RSSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE" /RSINSTALLMODE="FilesOnlyMode" /IACCEPTSQLSERVERLICENSETERMS
Note: SERVER_INSTANCE is not the actual name of your SQL Instance, this is the name of the instance of Reporting Services that you are installing (i.e., your server name or whatever you want to call it that you are installing Reporting Services on).
Interesting note, Reporting Services no longer requires IIS to run, which can be good and bad, good because you don’t need IIS, bad because IIS did a lot for Reporting Services that it now needs to take care of.
Next, you need to deploy the monitoring reports, which when deployed in this manner, does not diverge greatly. The big gotcha to avoid is the first page where it asks you to enter in the SQL Server Reporting Services instance that you would like to install these reports to. When I did this the first couple of times I instinctively went to thinking that I should enter in the database (the ReportServer db) where the reports will be deployed to. Not so, you are putting in the name of the Reporting Services instance that you created in the previous command line installation. Once you do that it should be smooth sailing from there (assuming of course you have the appropriate permissions to install the reports into your remote database).
And once you’ve done those two steps you are golden. I’m currently working on writing some Lync reports that integrate Lync data with some system back-ends and there is a great blog by Dr. Rez on how to create custom Lync reports here if you’re interested in how to do this.
Lync Powershell and C#
I've been doing a lot of Powershell lately, beyond the typical - find a command, run a command, execute the command - business. I started off the with the following FREE pdf book - Master Powershell - if you are looking for a primer, this is a great place to spot. I learned a lot about the language and how it really differs from more strongly typed languages like C# - everything is so fluid and dynamic. If you don't believe how good Powershell can be, check out this post on using the Lync Client SDK INSIDE of Powershell... awesome.
My main goal was to figure out a better way to migrate a few couple thousand users over to Lync and set them up with some custom Client and Archiving policies. In the end I was able to do it merely through using some of the existing cmdlets available in Lync;
Get-CsAdUser -Filter (Enabled -ne $True) | Enable-CsUser -RegistrarPool "entpool.mydomain.com" -SipAddresstype EmailAddress -SipDomain mydomain.com
Get-CsAdUser -Filter {Enabled -eq $True} | ForEach-Object {Set-CsUser -Identity $_.SipAddress -AudioVideoDisabled $true}
Get-CsAdUser -Filter {Enabled -eq $True} | ForEach-Object {Grant-CSClientPolicy -Identity $_.SipAddress -PolicyName "IM Only Policy"}
Get-CsAdUser -Filter {Enabled -eq $True} | ForEach-Object {Grant-CsArchivingPolicy -Identity $_.SipAddress -PolicyName "Archive Policy"}
But even before starting this I had not used the ForEach-Objech command or even undersood the real value behind piping ("$_.SipAddress" is a property rendered from the initial query that only returns Enabled Lync users.
So then I was off to Phase 2 of my dastardly plans for World Domination which was to build an IM stress test tool for Lync that takes a couple of parameters, floods the system and doesn't require me to create a bunch of users in Active Directory and/or ask people for their passwords. To do this I'm using UCMA application endpoints that I will wire up at real-time and have them talk to each other.
So of course when I build anything I always want it to be self-contained. If I'm downloading free code, I want to install it and run with it. Not have to do 10 things somewhere else before I can use it - enter Powershell and C#. Having done this before with Exchange I was pretty confident that this wouldn't be too bad. If you are doing this straight from Powershell (not auto-provisioning your endpoints via UCMA) the execution order looks a little like this;
New-CsTrustedApplicationPool -identity entpool.mydomain.com -Registrar entpool.mydomain.com
Enable-CsTopology
New-CsTrustedApplication -ApplicationId "IMTester" -TrustedApplicationPoolFqdn entpool.mydomain.com -Port 5081
Enable-CsTopology
New-CsTrustedApplicationEndpoint -ApplicationId urn:application:imtester -TrustedApplicationPoolFqdn entpool.mydomain.com -SipAddress sip:IMUserA@mydomain.com -DisplayName IMTesterA
Not too bad - create a TrustedApplicationPool (if one does not already exist), reflect the change back to your topology, create the application, again enable topology and then start creating your endpoints. All-in-all pretty easy, until I got into the C# code.
I initially started with the following code to start Powershell and bring in the Lync module;
if (_runspace == null)
{
InitialSessionState state = InitialSessionState.CreateDefault();
_runspace = RunspaceFactory.CreateRunspace(state);
_runspace.Open();
}
_shell = PowerShell.Create();
_shell.AddScript(@"import-module Lync");
_shell.Commands.AddCommand("Out-String");
However when I did this I then started getting errors about the Powershell Code Policy and the module not actually being loaded (no notice given UNTIL I started doing something). I dug around and found an associated post where buddy basically boiled it down to two ways of accessing Lync Powershell from C#, the full article is here, but the one I went with is here;
if (_runspace == null)
{
InitialSessionState state = InitialSessionState.CreateDefault();
state.ImportPSModule(new[] { "Lync" });
_runspace = RunspaceFactory.CreateRunspace(state);
_runspace.Open();
}
_shell = PowerShell.Create();
I'm still trying to decipher the two methods, I know I have used the first snipped successfully when working with Exchange 2007 and never encountered an error at all. In addition to running the above "special" code snipped I had to modify the execution policy for Powershell on my server to "Unrestricted".
I'm not completely sold on these changes (one of those, keep making small changes until the experiment is so dirty you don't know if your problem mutated along the way) and right now I'm working on my dev server. Later this week I plan on bringing the code back into the office to give'r a whirl to see if I encounter the same issues.
Lync Conferencing Capabilities with UCMA 3.0
Take a look at this article I recently wrote that outlines the work my group has gone through in using UCMA 3.0's Conferencing capabilities to design and engineer a full-scale ACD Routing Application. This was not a trivial task and took a lot of work to get to the final product, but I also have the benefit of working with a great bunch of people who don't shy away from complex problems.
The full article is available here - http://www.prairiefyre.com/blog/agents-supervisors-and-conferences-oh-my/.
Office365: First Impressions
After months of trying to get into playing with Office365, I finally got access to the BETA this week to start playing around with it. (Really my access game through because it went Public Beta, but that's ok). My first impression is that Office365 is very slick, very well put together and real simple to use. When I received my email I immediately dove in and setup some users for email, created some documents and most importantly started playing around with Lync. I didn't really focus much on the Office part as I have already played around with this with SkyDrive and it seemed pretty similar.
By far - this has been the simplest Lync setup I have ever done in my life. On the first day I had some issues, which I don't know if they were a result of me missing a step, but this weekend I went in and tried again. After configuring the user for Lync, downloading the client install, I was pretty much done, I logged into my client and was ready to take IM/phone calls. In some cases I had to download the Microsoft Online Assistant to enable logins to Lync to work (which, on the main Lync Client SDK install, when it can't log you in the first time it prompts you for the install and then you're good to go). I have easily setup 4 users in a matter of minutes with little to no battles with certificates and DNS. The only thing I am trying to figure out now is if I can federate with other users and include them in my profile list and if that even can be done.
From a developer's standpoint, there is a ton of information out there on the topic of Sharepoint, Exchange and Lync. In Exchange, you get the Exchange Managed Service API (which wraps Exchange Web Services) and with Lync you get access to the Lync Client SDK (no UCMA or server-side code available yet), but I'm sure if you wrote a little UCMA app to sit on your server you might be able to have it talk to those SIP URIs. That's all conjecture at this point as really all I have been doing is play around with the interface to see what I can and can't do.
So for the above reasons, I did not get the blog updated this weekend. Lesson for me - don't announce a public change to your site when you get access to a brand-new Beta!