In Exchange Management Shell and Lync Server Management Shell, you can target many cmdlets at specific domain controllers. This is crucial, especially in larger environments, if you need to make sure AD replication delays aren’t going to cause issues. An example is enabling a user for Lync using Enable-CsUser, then trying to use Set-CsUser or Grant-CsExternalAccessPolicy. The second will fail if it sends it to a different domain controller than the first, and replication hasn’t completed. So, the -DomainController switch can be used. Just send each command to the same DC, and even in rapid succession, you’ll succeed.

However, if you’re reusing your scripts or functions, especially in different environments, you have to find a valid DC in same AD site, put that into the script/function, and go. What a waste of time!

We can streamline the process with just a couple lines of code. First, we use Get-WMIObject to retrieve info on the local computer.

[object]$ComputerInfo = (Get-WMIobject -class "Win32_NTDomain" -namespace "root\CIMV2")

Next, we assign a variable, $ADSite, to the site name returned from the first line

[string]$ADSite = $ComputerInfo[1].ClientSiteName

Then we get a list of DCs in that same site

$DCsInSite = (Get-ADDomainController -Filter {Site -eq "$ADSite"})

And lastly, we randomly pick a DC from that list

[string]$QueryDC = ($DCsInSite | Get-Random).name

$QueryDC can now be used in your code, such as

Enable-CsUser [user] -RegistrarFQDN [fqdn] -SipAddressType [SIP address type] -DomainController $QueryDC

And that’s it. The only real requirement here is that the ActiveDirectory module be loaded, so that the Get-ADDomainController cmdlet works. This is easy:

Import-Module ActiveDirectory

In its entirety, here is the code:

Import-Module ActiveDirectory
[object]$ComputerInfo = (Get-WMIobject -class "Win32_NTDomain" -namespace "root\CIMV2") 
[string]$ADSite = $ComputerInfo[1].ClientSiteName 
$DCsInSite = (Get-ADDomainController -Filter {Site -eq "$ADSite"}) 
[string]$QueryDC = ($DCsInSite | Get-Random).name

 

This idea is from a LinkedIn post that I responded to. The original poster wanted to know if there was a way to manage Lync external access policies based on AD group membership. Absolutely!

This is a fairly simple script that uses a scheduled task that runs every 4 hours, looks at the members of a given AD security group, including nested groups, and applies a Lync policy to each member. The name of the AD security group and the type and name of the policy are all configurable. The ActiveDirectory and Lync PowerShell modules are used to complete this. The actual moving parts are pretty simple – really just two lines of code. But some extra error catching, installation code, and safeguards make it a tad bigger.

Caveat – users get policies when they launch the Lync client. So even though a policy might be assigned to a user, they won’t see any change until the client is restarted.

Caveat #2 – if you configure this script with several scheduled tasks to handle different policies and different AD groups, make sure users don’t end up in multiple groups, or you could have unintended results. Also removing a user from a group does NOT revert their policy back. The reason I didn’t add that is because moving a user from one group to another could cause problems if the script set them back to a default policy, yet another group needed to change it to a different policy.

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.

Download the script from the DOWNLOAD section below. Open it in your favorite text editor.

Find the line that reads

[string]$GroupDN = "",

and put the Distinguished Name of the group in between the quotes. For example

[string]$GroupDN = "CN=Lync Policy Group,DC=contoso,DC=com",

Next, define the policy that will be granted to members of the group. Find the line that reads

[string]$PolicyName = "",

and put the name of the Lync policy in between those quotes, such as

[string]$PolicyName = "Executives External Access Policy",

The last thing we need to do in the script file is define what KIND of policy we’re going to grant.

Find the line that reads

[string]$PolicyType = "ExternalAccess",

And adjust accordingly. The allowed values are Archiving,Client,ClientVersion,Conferencing,ExternalAccess,HostedVoicemail,Location,Mobility,Pin,Presence,Voice to represent the various types of policies you can apply to a user. The default is ExtnerAccess.

Next, ensure that the server where the script will run has both the ActiveDirectory and Lync PowerShell modules installed. Domain controllers typically have the ActiveDirectory module, and Lync servers have the Lync module. Install the appropriate ones using these steps.

To install the ActiveDirectory module, open PowerShell and type the following:

Import-Module ServerManager
Add-WindowsFeature -name AD-Domain-Services –IncludeManagementTools

To install the Lync Server Management Tools, which includes the PowerShell module, install the core components. See Install Lync Server Administrative Tools for details.

This will ensure that both modules are available. The ActiveDirectory module is used to get the members of the AD security group, and the Lync module is used to actually grant the policy.

The script must run as a member of the CsUserAdministrator or CsAdministrator groups, as those have the rights to assign policies.

Next, open PowerShell and run the script with the -install switch. The script will prompt for the password of the currently logged on user, and then create the scheduled task to run the script every 4 hours.

Grant-CsPolicyByADGroup.ps1 -install

The scheduled task will run every 4 hours, with a start time of when you ran the -install option. You can open the scheduled task in Task Manager and adjust as needed.

You can run the script manually as well. Just run

Grant-CsPolicyByADGroup.ps1

Note that it may take a while before the policy is visible on the user account due to AD replication.

Download

v1.2 – Grant-CsPolicyByADGroup.v1.2.zip

v1.1 – Grant-CsPolicyByADGroup.v1.1.zip

v1.0 – Grant-CsPolicyByADGroup.v1.0.zip

Changelog

See the changelog for this script for a description of changes with each release.

 

In Part I of this series, I talked about what synthetic tests are, and some of the issues you may see when using them. Today I want to bring up another issue with synthetic tests. Let me show you how I found it.

I tried to use New-CsHealthMonitoringConfiguration to assign two newly created accounts for synthetic testing. As I mentioned in part I, configuring the accounts makes running the test cmdlets easier. The syntax to use is

New-CsHealthMonitoringConfiguration -identity [pool FQDN] -FirstTestUserSipUri [string] -FirstTestSamAccountName [string] -SecondTestUserSipUri [string] -SecondTestSamAccountName [string]

When I ran it in my client’s environment, I got back a nasty error:

Notice that regex expression. Value must match pattern:[^\\/:\*\?\"<>\|\.][^\\/:\*\?\"<>\|]{0,14}\\[^\\/:\*\?\"<>\|\.][^\\/:\*\?\"<>\|]{0,14}”

At first I thought I didn’t have the SamAccountName in the correct format, but the New-CsHealthMonitoringConfiguration documentation clearly says I can use the domain\user format. Just as I was about to break out regex buddy to see what that regex was trying to match, I noticed the (0,14) at the end and wondered if it was only expecting up to 15 characters (starting at 0, 14 would be the 15th number). I looked at the test user SamAccountNames and they were more than 15 characters long. So I shortened them to 15 characters and ran the cmdlet again, and bingo – that worked. I tested some more and verified that as soon as the SamAccountName reaches 16 characters or more, I get the above error.

I looked at the documentation for SamAccountName and found that it supports, as I suspected, that it can be up to 19 characters in length. So the New-CsHealthMonitoringConfiguration limitation, which isn’t documented anywhere that I could find, can catch you up in environments where usernames can be longer, such as in my client’s.

I’ve reported this to the product group to get it documented.

As a side note, you can configure test accounts for every Front End and Director pool, and they should be different users for each pool.

Hopefully, this info will save you some troubleshooting time.

Synthetic test cmdlets are a great feature in Lync Server 2010. They allow you to test core functionality by simulating interaction between users, computers, etc. without having to fire up test workstations with the client installed. In Lync 2010 with the June 2012 updates installed, we see the following test cmdlets available:

cmdlet	purpose
Test-CsAddressBookService	Tests the ability of a user to access the server that hosts the Address Book Download Web service.
Test-CsAddressBookWebQuery	Tests the ability of a user to search for, and return, information from the Address Book by using the Address Book Web Query service.
Test-CsAVConference	Tests the ability of a pair of users to take part in an audio/video (A/V) conference.
Test-CsCertificateConfiguration	Returns information about the Microsoft Lync Server 2010 certificates being used on the local computer.
Test-CsClientAuth	Determines whether or not a user can log on to Microsoft Lync Server 2010 by using a certificate downloaded from the certificate provisioning service.
Test-CsComputer	verifies the status of the Microsoft Lync Server 2010 services running on the local computer. The cmdlet also verifies that the appropriate Lync Server 2010 Active Directory groups have been added to the corresponding local groups on the computer, and that the necessary computer firewall ports have been opened.
Test-CsDialInConferencing	Checks to see if a user can take part in a dial-in conferencing session.
Test-CsDialPlan	Tests a telephone number against a dial plan (formerly known as a location profile) and returns the normalization rule that will be applied to the number as well as the translated number after the normalization rule has been applied.
Test-CsFederatedPartner	Verifies the ability to connect to a federated domain.
Test-CsGroupExpansion	Tests the ability of a user to employ group expansion. Microsoft Lync Server 2010 enables users to configure an Active Directory distribution group as a contact. When you “expand” a group you will see the name and presence information for each member of the group.
Test-CsGroupIM	Tests the ability of two users to conduct an instant messaging (IM) conference. Test-CsGroupIM is a “synthetic transaction”: a simulation of common Microsoft Lync Server 2010 activities used for health and performance monitoring.
Test-CsIM	Tests the ability of two users to exchange instant messages.
Test-CsKerberosAccountAssignment	Verifies the configuration of the Kerberos account assigned to a site.
Test-CsLisCivicAddress	Tests one or more civic addresses against the Master Street Address Guide.
Test-CsLisConfiguration	Tests the Location Information Server (LIS) configuration.
Test-CsLocationPolicy	Runs a test to determine the location policy that will be used based on the criteria specified in the parameter values. The location policy contains the settings that will determine whether and how Enhanced 9-1-1 (E9-1-1) will be applied. E9-1-1 enables those who answer 911 emergency calls to determine the caller’s geographic location.
Test-CsMcxConference	Tests the ability of three users to participate in a Microsoft Lync Server 2010 Mobility Service conference. The Mobility Service enables users of mobile phones such as iPhones and Windows Phones to do such things as exchange instant messages and presence information; store and retrieve voice mail internally instead of with their wireless provider; and take advantage of Microsoft Lync Server 2010 capabilities such as Call via Work and dial-out conferencing.
Test-CsMcxP2PIM	Tests the ability of a pair of users to exchange instant messages by using the Microsoft Lync Server 2010 Mobility Service. The Mobility Service enables users of mobile phones such as iPhones and Windows Phones to do such things as exchange instant messages and presence information; store and retrieve voice mail internally instead of with their wireless provider; and take advantage of Microsoft Lync Server 2010 capabilities such as Call via Work and dial-out conferencing.
Test-CsMcxPushNotification	Verifies that the push notification service is working. The push notification service (Apple Push Notification Service and Microsoft Lync Server 2010 Push Notification Service) provides a way to send notifications about events such as new instant messages or new voice mail to mobile devices like iPhones and Windows Phones, even if the Microsoft Lync 2010 application on those devices is currently suspended or running in the background.
Test-CsOUPermission	Verifies that the required permissions needed to manage users, computers, and other objects have been set on the specified Active Directory container.
Test-CsP2PAV	Tests the ability of a pair of users to conduct a peer-to-peer audio/video (A/V) call.
Test-CsPhoneBootstrap	Verifies that a user can log on to Microsoft Lync Server 2010 using a Microsoft Lync 2010 Phone Edition-compatible device.
Test-CsPresence	Tests the ability of a user to log on to Microsoft Lync Server 2010, publish his or her presence information, and then subscribe to the presence information published by a second user.
Test-CsPstnOutboundCall	Tests the ability of a user to make a call to a phone number located on the public switched telephone network (PSTN).
Test-CsPstnPeerToPeerCall	Tests the ability a pair of users to conduct a peer-to-peer call over the public switched telephone network (PSTN) gateway.
Test-CsRegistration	Tests the ability of a user to log on to Microsoft Lync Server 2010. Test-CsRegistration is a “synthetic transaction”: a simulation of common Lync Server 2010 activities used for health and performance monitoring.
Test-CsSetupPermission	Verifies that the required permissions needed to install Microsoft Lync Server 2010 or one of its components have been configured on the specified Active Directory container.
Test-CsTopology	Verifies service activation and group permissions for your installation of Microsoft Lync Server 2010.
Test-CsTrunkConfiguration	Validates a trunk configuration against a phone number.
Test-CsVoiceNormalizationRule	Tests a telephone number against a voice normalization rule and returns the number after the normalization rule has been applied. Voice normalization rules are used to convert a telephone dialing requirement (for example, you must dial 9 to access an outside line) to the E.164 phone number format used by Microsoft Lync Server 2010.
Test-CsVoicePolicy	Tests a telephone number against a voice policy and determines which voice route would be used against that policy for that number.
Test-CsVoiceRoute	Tests a telephone number against a voice route number pattern and returns a Boolean (true/false) value stating whether the supplied number matches the number pattern for the route. Number pattern is just one of the properties used by voice routes to tell Microsoft Lync Server 2010 how to route calls from Enterprise Voice users to phone numbers on the public switched telephone network (PSTN) or a private branch exchange (PBX).
Test-CsVoiceTestConfiguration	Runs test voice configurations to ensure voice routing and policies work as expected.
Test-CsVoiceUser	Identifies the route that a phone call from a given user would take to be completed based on voice rules, routes, and policies.
Test-CsWebApp	Verifies that authenticated users can use the Microsoft Lync Web App to join a Microsoft Lync Server 2010 conference.
Test-CsWebAppAnonymous	Verifies that anonymous users can use the Microsoft Lync Web App to join a Microsoft Lync Server 2010 conference.

However, it should be noted that the last two shouldn’t be used in Lync 2010. And, with the June 2010 updates installed, Test-CsClientAuth appears to be broken.

The user related test cmdlets can be run one of two ways. You can manually specify users when calling the cmdlet, such as

Test-CsIm -targetFqdn [front end pool FQDN] -SenderSipAddress [string] -ReceiverSipAddress [string]

or, you can configure two accounts to always be used with user-related synthetic tests. This is done with New-CsHealthMonitoringConfiguration. Lync MVP and MCM Tim Harrington has a good article on setting this up: Configuring Accounts for Synthetic Transactions in Lync Server 2010. Once configured, you can then run tests with a much shorter command line.

Test-CsIm -targetFqdn [front end pool FQDN]

You can also use the synthetic test accounts when Using the Lync Topology Validator, although when doing this, you can’t disable the accounts as Tim’s article mentions. Additionally, you can configure synthetic tests in System Center Operations Manager (SCOM) for more detailed monitoring and reporting.

Synthetic tests work great and are a great tool when setting up and configuring Lync Server as they cut down on the time you need to log into Lync from test workstations and test functionality by IMing yourself. However, they should not be used as a complete replacement for enduser testing.

An important note about most of the synthetic tests is that they need to be run from a true Lync Server. That’s because they look for topology information in the (local)\rtclocal database, which only exists on Lync servers. It’s not on management workstations with the Lync Management Tools installed, SQL servers, etc. And the errors you may get can be ambiguous enough to have you thinking that your Lync SQL server is down. Here’s an example. We run the Test-CsCertificateConfiguration cmdlet from a management workstation. It fails:

We open the log file, and we notice that it’s trying to connect to (local)\rtclocal:

But notice the error text in red.

When we head over to an Enterprise FrontEnd server and run the same cmdlet, we get the results we expect:

As you can see, the synthetic test cmdlets can be a powerful tool when run from the right location. In the second part of this series, I cover an issue with the naming convention for synthetic test accounts.

Description

When cumulative updates are released from the Lync Product Group, they often contain firmware updates for Lync Phone Edition devices. The update process is somewhat arduous in that you have to download each update for each device model, extract it, then manually upload each firmware file, test it, then approve it for wide scale release. If you have multiple pools, the updates need to be uploaded to each one so tha a copy exists in each Lync file share. And there is no way to select multiple files and upload them, and each file is named ucpdates.cab, so they need to be in separate folders. So, I made this little script to help deal with the upload process.

Create a parent folder called whatever you want. In my example, it is called “CU6 – June 2012″. Inside that file, I have the Cumulative Update file, LyncServerUpdateInstall.exe, as well as child folders for the various devices. The child folders can be called anything.

Inside each of the child folders, I’ve downloaded the firmware update for that model, run the .exe, and extracted the file back to the same folder. So each folder has the original UCUpdates.exe file that was downloaded, and the ucupdates.cab file that was extracted. This is normal practice for me, even when manually uploading the files.

Next, run the script using

.\New-CsFirmware.ps1

If the script was launched from a plain PowerShell console, the Lync module will be loaded automatically.

Next, you’ll be prompted for the parent folder.

Select the parent folder and click ok. The script will look through the parent folder and all child folders for update files called ucupdates.cab, and will upload them to all pools that it can find.

That’s all there is to it. You will still need to follow the rest of the upgrading process such as configuring test devices, testing, and then approving. Fellow MVP Jeff Schertz has a fabulous blog post, Updating Lync Phone Edition Devices that details the entire process.

You can also include the path to the parent folder when you run the script, such as

.\New-CsFirmware.ps1 -FilesPath "c:\users\lyncent.administrator\desktop\cu6 -june 2012"

and the script will skip prompting for the folder.

A special shout-out to fellow MVP and Lync MCM Kevin Peters, who gave me the idea to script it out and include all of the child folders and all of the pools.

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.

No real installation required. The script can be run from any machine that has the Lync Core Components installed. As usual, you do need to set your Execution Policy to RemoteSigned or Unrestricted in order to run PowerShell scripts. The script will create a folder called .\Logs, and it will create the transcript file in there for future reference.

Download

v1.4 – 05-10-2013 – New-CsFirmware.v1.4.zip

v1.3 – 10-17-2012 – New-CsFirmware.v1.3.zip

v1.2 – 08-17-2012 – New-CsFirmware.v1.2.zip

v1.1 – 07-10-2012 – New-CsFirmware.v1.1.zip

v1.0 – 06-30-2012 – New-CsFirmware.v1.0.zip

Changelog

See the changelog for this script for a list of what’s changed in each version

This is the changelog page for Get-CsVoiceCalls.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.4 – 06-12-2012

1. Added some additional code to handle named SQL instances better. Still needs some testing in more environments.

v1.2 – 06-05-2012

1. Original version

Description

I had a need to see realtime call data. Lync MVP/MCM Tom Pacyk has a really cool script for logging concurrent calls to .csv over time by querying perfmon counters at regular intervals. That works great when you’re trying to determine concurrent for scale planning. But I wanted to see who was on the phone – not just the number of current calls.

This script will look at the LCSCDR database, which is installed when you install a Monitoring Server in your topology. The script gathers information about current calls in progress, and displays them in list style. It’s fairly basic.

As you can see, the list shows the two users in the call, their ID number, who initiated the call, when it was made, etc. In this screen shot, User 1 was connected from outside the environment (IsUser1Internal is false), while User2 was in a company office with WAN connectivity to the Lync infrastructure (IsUser2Internal is True).

If a user has initiated or received a call to/from a PSTN number, then User2Uri will read “PSTN call”.

As mentioned above, a Monitoring Server does need to be installed in your topology so that the LCSCDR database is created and updated. But the script can be run from anywhere.

You could also wrap this into a function and toss it in your PowerShell profile to make easily accessible.

This script was more of a proof of concept into querying SQL from PowerShell, and the required query. If you have suggestions, let me know!

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.

Download the script from below to a server with PowerShell. Run the script in PowerShell using

Get-CsVoiceCalls.ps1 -server [SQL server]

If the lcscdr database is in a named instance, specify the instance

Get-CsVoiceCalls.ps1 -server [SQL server] -instance [instance]

Where [SQL server] is the FQDN of the database server containing your LCSCDR database.

You can also hard code the SQL server FQDN and the instance in the script. Look for

[string]$server,

and change it to include the SQL server FQDN, such as

[string]$server = "sqlserver.domain.local",

and look for

[string]$instance,

and change it to include the instance name, such as

[string]$instance = "Lync",

And then you can just call the script by name using

Get-CsVoiceCalls.ps1

There is also full comment based help, using

Get-Help Get-CsVoiceCalls.ps1

Known Issues

1. The logic that looks for the database in named instances still needs more testing. If you run it in an environment where you have the lcscdr database in a named instance, please let me know your results.
2. I tried to adapt to correcting the time display. The data is aparrently stored in SQL in GMT. So I’ve coded the script to display it according to the local time zone (according to Windows). Let me know if your results aren’t as expected.
3. If a user receives a call from a PSTN number, the SessionStartedById field is blank. Working around that has been problematic, but I’m still trying.

Download

Get-CsVoiceCalls.v1.4.zip

Get-CsVoiceCalls.v1.2.zip

Changelog

See the changelog for this script to see what has changed between versions.

In part I, I showed you how to change the logo for the meeting landing page. In this part, we’ll go through adding options to the page for various types of clients.

By default, when entering a meeting, a machine with the Lync client will open up and automatically join. But what if the person attending the meeting doesn’t have the Lync client? A machine without the Lync client will open a popup browser window and use Silverlight, but that doesn’t support all Lync features.

We can allow users with the OCS 2007 R2 legacy Communicator client to use that to join the meeting. We simply open Lync Management Shell and use the Set-CsWebServiceConfiguration cmdlet on our Front-End servers:

Set-CsWebServiceConfiguration -ShowJoinUsingLegacyClientLink $true

And the web page looks like this when opened:

We can also provide a link for attendees to download the Lync 2010 Attendee client, which provides a better client experience. We can do this by using the same cmdlet in Lync Management Shell, but with a different switch:

Set-CsWebServiceConfiguration -ShowDownloadCommunicatorAttendeeLink $true

Combining the two together allows all possible options:

Set-CsWebServiceConfiguration -ShowDownloadCommunicatorAttendeeLink $true -ShowJoinUsingLegacyClientLink $true

At this point, attendees can join the meeting with the OCS Communicator, Lync, Lync Attendee, or web browser clients. The user would see this (assuming no Lync client installed):

Combine that with the custom logo configuration from part 1, and we now have a much more personal and flexible Meet page.

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:

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

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

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.

Posters

Microsoft Lync Server 2010 Protocol Workloads Poster

This poster shows each workload in Microsoft Lync Server 2010 communications software, describing relationships, dependencies, flow of information, and certificate requirements.

http://go.microsoft.com/fwlink/?LinkId=204599

Visio templates

Lync Server 2010

This stencil provides over 125 shapes to help you create a visual presentation of your Lync Server architecture.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=65b5a396-2c87-445d-be23-d324727d19cb

Office Communications Server 2007 and 2007 R2

The Office Communications Server 2007 and 2007 R2 Visio stencils contain icons for Office Communications Server 2007 and 2007 R2 server roles and components.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9194

Cheat Sheets

Lync Server 2010 PowerShell Cheat Sheet

A quick reference card for PowerShell use with Lync Server 2010.

http://www.powergui.org/entry.jspa?externalID=3091

Microsoft Lync 2010 Quick Reference Cards

This zipped file contains the quick reference cards for Microsoft Lync 2010. They are all in Microsoft Word, and can be edited as needed. The download contains the following Quick Reference Cards, which are also available separately:

• Microsoft Lync 2010 Attendant Quick Reference Card
• Microsoft Lync 2010 Attendee Quick Reference Card
• Microsoft Lync 2010 Instant Messaging and Presence Quick Reference Card
• Microsoft Lync 2010 Conferencing Quick Reference Card
• Microsoft Lync 2010 Sharing and Collaboration Quick Reference Card
• Microsoft Lync 2010 Voice and Video Quick Reference Card

http://www.microsoft.com/download/en/details.aspx?id=2324