In November of 2012, Microsoft announced that Public IM Connectivity (“PIC”) federation for AOL and Yahoo! would be ending. Microsoft gave a good advanced warning, eventually saying it would cease on June 30, 2014. They held true to that date, and connectivity via the traditional methods is no longer available. Some have even reported that Yahoo! federation stopped working as early as April 2014.

I’ve run some reporting using Get-CsFederatedConversationDetails.ps1 and verified that other than my occasional conversations with dear old Mom, no one was using these PIC providers. So no big loss, and certainly, no business impact. But, for those orgs that DO require connectivity to AOL, such as some of the hedge fund groups, AOL does have a service that will allow your users to communicate with AOL users. It does. however, require a monthly per user fee. More information can be found at https://aimenterprise.aol.com/microsoft/.

For now, any AOL or Yahoo! contacts that users have in their contacts list will show as Presence Unknown.

It now makes sense to remove the related configuration for your Lync config – if you had it configured previously. PIC federation is configured via Public Providers. We can see the public providers configured via the Get-CsPublicProvider cmdlet, as shown below.

Removing the configuration for AOL and Yahoo! can be performed with one line of code.

Get-CsPublicProvider | Where-Object {$_.ProxyFQDN -eq "sip.oscar.aol.com" -or $_.ProxyFQDN -eq "lcsap.msg.yahoo.com"} | Remove-CsPublicProvider

This will remove just the AOL and Yahoo! public providers, and leave any others, like Skype, as shown below when running Get-CsPublicProvider again.

If you’re a little apprehensive about using PowerShell (and you shouldn’t be – embrace the shell!), we can also remove the public providers in the Lync Server Control Panel. Navigate to Federation and External Access>SIP Federated Providers. You’ll see a list of both public and hosted providers as shown below.

Merely select the appropriate provider you’d like to remove, select Edit>Delete. Once you’ve removed both the AOL and Yahoo! providers, you’re left with any remaining public and hosted providers as shown below.

Once clients refresh their config, the options for AOL and Yahoo! will no longer be available when adding new contacts.

Users wills still need to manually remove AOL and Yahoo! federated contacts from their contacts list, though.

Description

Richard Schwendiman, PFE at Microsoft, came up with a great SQL query that you could plug into SQL Server Management Studio to see time & date info for conversations with federated or PIC domains. In Richard’s case, he used the aol.com PIC domain. Since PIC federation with AOL and Yahoo is ending next month, I thought this was great timing on Richard’s part. But sometimes, Lync admins can’t login to SQL servers to run queries due to security policy. Plus, the query is something you’d have to keep handy and edit accordingly each time you wanted to get data. So I figured – hey, why not whip up a quick script to allow an admin to query SQL for this data, allowing for any domain and time frame to be specified? Poof – out comes my script.

This script will query a specific SQL server for information about a specific federated SIP domain. The domain does NOT need to be in the allowed domains list if you’re open federating. Any SIP domain name works. You can specify a start date/time in the yyyy-MM-dd format, such as 2014-05-13 using the -TimeSpan parameter. Or, you can use some handy ranges I’ve included, including LastWeek (the last 7 days), Last30Days, Last year (last 365 days), FirstOfYear or ThisYear (since Jan. 1), FirstOfMonth or ThisMonth (since the 1st of the month), FirstOfWeek or ThisWeek (since Sunday). Optionally, you can specify an end date/time in the yyyy-MM-dd format. This script will default to FirstOfYear with no end date, and aol.com for the domain. As we see below, only the SQL server holding the LcsCDR database is queried.

Now, from this output, we see that there is not a lot of communications with people on AOL since the first of the year. The upcoming change should have very little impact.

If you’re using a named instance in SQL, you can specify it as well.

The script outputs a full object, just like other cmdlets, so you can pipe it to other commands to alter the display, including sorting, or my favorite, Out-GridView, as well as outputting to files such as .csv.

Hopefully, this tool will make life a little easier in digging out data.

Syntax

Get-CsFederatedConversationDetails.ps1 [[-SqlServer] ] [[-SqlInstance] ] [[-SipDomain] ] [[-TimeSpan] <object>] [[-EndDate] <object>] [-WhatIf ] [-Confirm ] [<commonparameters>]</commonparameters></object>

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Donations

I’ve never been one to really solicit donations for my work. My offerings are created because *I* need to solve a problem, and once I do, it makes sense to offer the results of my work to the public. I mean, let’s face it: I can’t be the only one with that particular issue, right? Quite often, to my surprise, I’m asked why I don’t have a “donate” button so people can donate a few bucks. I’ve never really put much thought into it. But those inquiries are coming more often now, so I’m yielding to them. If you’d like to donate, you can send a few bucks via PayPal at https://www.paypal.me/PatRichard. Money collected from that will go to the costs of my website (hosting and domain names), as well as to my home lab.

Assumptions

None

Download

v1.0 – 05-13-2014 – Get-CsFederatedConversationDetails.v1.0.zip

Changelog

See the changelog for information on what’s changed/included in each version.

This is the changelog page for Get-CsFederatedConversationDetails.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v1.0 – 05-13-2014

1. Initial version

I was curious the other day about where the company name comes from in the Lync/Skype for Business Contacts. For instance, we see Elan and Jeff below:

The quick answer is it can pull that info from an Outlook contact in your mailbox. But what if you don’t have the user in your Outlook contacts?

I knew that it was in Active Directory somewhere, and thought it would be an organization setting somewhere since my experience has shown that the company name is always exactly the same for all users in each company I see in my contacts – right down to punctuation. Some cmdlets let you specify an org name, like Set-CsConferencingConfiguration, but that wasn’t it.

With the help of fellow Skype for Business MVP Brian Ricks, we got it narrowed down to the Company field on a user’s account in Active Directory. For example, we look at Sara’s account in Active Directory Users and Computers, and see her company set:

And when a federated Lync/Skype for Business user looks at her in the Lync/Skype for Business client, we see her company defined:

But some people show as “External Network” as we see for fellow UC Architects member John Cook:

And there are two reasons why this can happen. The first is that the user is homed on a cloud hosted solution like Office 365. Not the case here for John. Like me, he’s got a full Lync install going on at home. The other reason this could happen is that the user’s company field is completely blank. Sure enough, John’s is blank. So he updates that field, and a short time later, his company name shows up to federated contacts.

This is really a minor thing, but I’ve noticed the company field is hit or miss in orgs where onboarding of users is done manually. But no worries, updating the users is fairly straight-forward in ADUC. You can highlight multiple users in one OU, right click to edit, go to the Organization tab, and enter a valid company name. In more complex orgs, you could use a query to list all of the users without a company name. This can be accomplished by right clicking on the Saved Query branch on the left, and selecting New>Query. Click Define Query, set Find to Custom Search, and add to conditions: Field to Company and Condition to Not Present. And second, Field to Office Communications Server Address, and Condition to Present.

Once you click OK, you’ll be presented with a list of the users who don’t have a company, but are Lync/Skype for Business enabled. Just like mentioned above, you can select multiple/all of the users, right click, go to Properties>Organization, and enter a company name.

Once updated and replicated, federated users should see the changes within a short time. We can also query and update user accounts via PowerShell on any machine with the ActiveDirectory module installed. We can query for users where the company name is not set using:

Get-AdUser -Filter {Company -notlike '*'} -Properties * -ResultSetSize $null | Select-Object -Property Name,Company

And we can update them all at once using:

Get-AdUser -Filter {Company -notlike '*'} -Properties * -ResultSetSize $null | Set-AdUser -Company 'Contoso'

Having it on the individual user’s account does make more sense as this allows for multiple names within the same org. But it does require ensuring that the company field is set for each user.

As for the title, the same applies – it’s set on the individual user account. However, unlike company name, title can also be set on Office 365 accounts.

Wanna see who you’re dynamically (openly) federating within Lync Server? It’s pretty straightforward with the Get-EventLog cmdlet. All we need to do is look for the most recent entry in the Lync Server event log with event ID 14601. One an Edge server, open PowerShell and run the following:

Get-EventLog "Lync Server" | Where-Object {$_.EventId -eq 14601} | Select-Object EventId, Message -First 1 | Format-List *

The description of the single returned event will list the domains you’re currently dynamically federating with. You’ll get something back like this:

EventID : 14601
Message : Report of discovered partners that the Access Edge Server is
          currently monitoring.
There are 21 discovered partners, identified by the common name of
their certificate.
Name: sip-na.contoso.com; Domains: contoso.com
Name: sip.fabrikam.com; Domains: fabrikam.com
Name: sip.fourthcoffee.com; Domains: fourthcofee.com
Name: sip.windtiptoys.com; Domains: windtiptoys.com
Name: edge.adatum.com; Domains: adatum.com
Name: sip.humongousinsurance.com; Domains: humongousinsurance.com
Name: LYNC-TOR-Edge.litware.com; Domains: litware.com
Name: sip.northwindtraders.com; Domains: northwindtraders.com
Name: sip.proseware.com; Domains: proseware.com
Name: sip.adventure-works.com; Domains: adventure-works.com
Name: sipeu.alpineskihouse.com; Domains: alpineskihouse.com
Name: Lyncedge.blueyonderairlines.com; Domains: blueyonderairlines.com
Name: ussea-w15access.cohovineyard.com; Domains: cohovineyard.com
Name: sip.cohowinery.com; Domains: cohowinery.com
Name: sip.lucernepublishing.com; Domains: lucernepublishing.com
Name: ap.malvertising.info; Domains: malvertising.info
Name: federation.fineartschool.net; Domains: fineartschool.net
Name: sip.strikestrike.com; Domains: strikestrike.com
Name: lync.treyresearch.net; Domains: treyresearch.net
Name: sip.wideworldimporters.com; Domains: wideworldimporters.com
Name: sip.woodgrovebank.com; Domains: woodgrovebank.com*

A note that as the Message field of the event log entry mentions, these are DISCOVERED PARTNERS – those found through SRV records. If you want to see who you’re federating with using enhanced or direct federation (those specifically defined in your Lync environment), from a non-Edge Lync server, run Get-CsAllowedDomain. For a breakdown on the various types of federation, see Kevin Peter’s excellent post A Few Words on Federation.

In this scenario, IM & Presence would work for some users to federated contacts, but wouldn’t work for others.

Federated User Access was enabled in the Global External Access Policy and in the Global Access Edge Configuration policy. The target domain was in the Federated Domains list as an allowed domain. There was no discernable pattern as to what users could communicate with federated contacts, and what users could not. They were spread across various Front End servers, OUs, etc. Various clients on the workstation made no difference.

When looking at logs in Snooper on the front end that the user connects to, “Federation is disabled” would appear when the user attempted to send a message out:Â

09/16/2011|13:09:13.108 FB8:109C INFO :: SIP/2.0 504 Server time-out
Proxy-Authentication-Info: Kerberos qop=”auth”, opaque=”59715D13″, srand=”DF93B1E9″, snum=”16″, rspauth=”040401ffffffffff0000000000000000450a1d9cc165348ae016ee91″, targetname=”sip/USSFA1L14POOL2.global.mydomain.net”, realm=”SIP Communications Service”, version=4
From: “user, test”<sip:test.user@mydomain.com>;tag=94a0d94c10;epid=67fd7944cb
To: <sip:prichard@federateddomain.com>;tag=6E14486DE28A93804279A401E6E7A4CF
Call-ID: db3c59b759ef4065adb458d54d03a687
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 10.1.1.98:58376;ms-received-port=58376;ms-received-cid=63500
ms-diagnostics: 1065;reason=”Federation is disabled“;domain=”federateddomain.com”;source=”sip.mydomain.com”
Server: RTC/4.0
Content-Length: 0

And traffic for this user would never get to the Access Edge servers. This was the case for ANY federated contacts the “broken” users would attempt to communicate with. Yet, other workers wouldn’t have ANY problem communicating to these same federated contacts. In fact, a “good” user could log onto a test workstation, launch Communicator, and it would work – but then close Communicator and launch Communicator as a “broken” user and not be able to communicate – even from the same Windows session. There was no pattern other than “broken” users would always be broken, and working users would always work.

Many things were inspected, and I tried doing things such as disabling the users in Lync and then re-enabling them. I drain stopped the Front End server that was the user’s preferred server to force them onto another server – no luck.

PSS spent several weeks on this one. Everything was configured correctly. What we decided to try was to set the Minimum session security for NTLM SSP based clients & servers. By default, a Windows 2008 R2 server has both settings set to 128-bit minimum. But Windows XP and earlier clients default to only 40-bit. It didn’t make much sense that this would work since we could duplicate both working and broken users on the same machine. But it was worth a shot. Here’s what we did.

Open the Local Security Policy and navigate to Local Policies>Security Options. Find the Network security: Minimum session security for NTLM SSP based (including secre RPC) clients & servers settings, as shown below:

Minimum session security for NTLM SSP based (including secure RPC) clients

Double click on each and clear the Require 128-bit encrytion checkbox as shown below:

Minimum session security for NTLM SSP based (including secure RPC) clients

The settings should now show “No minimum” in the Local Security Policy as shown below:

Minimum session security for NTLM SSP based (including secure RPC) clients

The settings don’t take effect until the server is rebooted. We performed this process on all of the Lync servers in the environment. Incidentally, the settings just change some registry keys. So we can instead change the values using the following PowerShell lines, which will make their way into my server build scripts:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "NtlmMinClientSec" -Value 0 Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "NtlmMinServerSec" -Value 0

After the servers were rebooted, and user connections reestablished (which took some time), the problem disappeared. All users were able to communicate with federated contacts.