One thing I see while doing Lync environmental health checks for some customers is some elevated accounts that are enabled for Lync. An example is members of the Domain Admins group. This can be somewhat problematic, especially for administration of those elevated accounts. For security reasons, it is not recommended to enable members of Domain Administrators group for Lync.

You cannot use Lync Server Control Panel to manage users who are members of the Domain Admins Active Directory group. For Domain Admins users, you can use Lync Server Control Panel only to perform read-only search operations. Attempting to perform write operations (such as enable or disable for Lync Server Control Panel, change pool or assigned policies, telephony settings, SIP address) on an elevated user will yield an “Access Denied” error. To perform write operations on a member of Domain Admins, you must use Lync Server Management Shell (PowerShell) cmdlets while logged on as a member of Domain Admins.

For more information please refer to this Microsoft page: User accounts enabled for Lync Server 2013

To query an elevated group, such as Domain Admins, for Lync enabled users, use the following:

(Get-ADGroupMember "Domain Admins").DistinguishedName | Get-CsUser -ErrorAction SilentlyContinue | Format-Table DisplayName,SipAddress

You can replace the “Domain Admins” with the name of any group, really. When you run it, you’ll end up with something like:

PS C:\> (Get-ADGroupMember "Domain Admins").DistinguishedName | Get-CsUser -ErrorAction SilentlyContinue | Format-Table DisplayName,SipAddress

DisplayName                                                 SipAddress
-----------                                                 ----------
Services                                                    sip:services@contoso.com
Dan Giles                                                   sip:dan.giles@contoso.com
Neil Armstrong                                              sip:neil.armstrong@contoso.com
Dawn Lopes                                                  sip:dawn.lopez@contoso.com
Bob Seger                                                   sip:bob.seger@contoso.com
Gail O'Grady                                                sip:gail.ogrady@contoso.com
Troy Dallas                                                 sip:Troy.Dallas@contoso.com
Steve Carrell                                               sip:steve.carrell@contoso.com

You can Lync disable these users for Lync, using the Disable-CsUser cmdlet. This can be done either individually using the -Identity parameter, or everyone at once by pipeline, with something like:

(Get-ADGroupMember "Domain Admins").DistinguishedName | Disable-CsUser -ErrorAction SilentlyContinue

If you have some accounts that were previously members of an elevated group like Domain Admins, but no longer are, then the AdminCount parameter on their account may still be set. This will cause the Access Denied issue to continue. You can manually change this on the user object using ADSIEDIT, or via a script such as Set-AdminUser.

Description

Anyone who has updated a Lync or Skype for Business environment with a recent Cumulative Update knows that there are often manual steps to perform after the LyncServerUpdateInstaller.exe/SkypeServerUpdateInstaller.exe program is finished. These are often database update functions. And often, multiple functions to update the various different databases, including the CMS, monitoring, archiving, Persistent Chat, etc. I’ve run across quite a few environments where the LyncServerUpdateInstaller.exe/SkypeServerUpdateInstaller.exe is run, and nothing else is done, and the client can’t figure out why things aren’t running as they expect. Fortunately, the Test-CsDatabase cmdlet will show you the current version of the database and the expected version. But then you have to manually compare each one to determine if an update is required. Of course, there are databases on the local Front End server(s), and the SQL backend server(s). Also, it’s important to review the status of SQL mirroring, and ensuring that databases are active on the principal node and not the mirror node. And that’s just part of the patching process.

Dave Howe, of the Lync product group, and I collaborated on a script that helps streamline part of this process. Dave did a lot of the initial grunt work, so he deserves a lot of the credit. I cleaned things up and optimized per some best practices.

Among the tasks that this script performs:

Determines whether database updates are required. It performs the following checks:

1. Detects whether the pool version is Lync Server 2013 or later, including Skype for Business
2. Detects whether database mirroring is enabled
3. Detects whether the primary and mirror SQL servers are online
4. Detects whether the mirror server is principal for any databases
5. Detects whether the local machine is a FE of the given pool
6. Detects whether the CMS is on Lync Server 2013 or later, including Skype for Business

And returns the following info:

1. Returns list of local databases, their versions, and whether a database update is required (if the local server is a member of the pool)
2. Returns list of backend databases, their versions, and whether a database update is required
3. Returns list of CMS databases, their versions, and whether a database update is required

An example output is shown below. Note that the local XDS database requires an update

Syntax

Get-CsDatabaseUpdateStatus.ps1 [[-PoolFqdn] ] [-WhatIf] [-Confirm] []

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.2 – 02-24-2018 – Get-CsDatabaseUpdateStatus.v1.2.zip

v1.1 – 04-30-2014 – Get-CsDatabaseUpdateStatus.v1.1.zip

v1.0 – 04-30-2014 – Get-CsDatabaseUpdateStatus.v1.0.zip

Changelog

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

Description

One of the really cool features of Lync Server 2013 is the Lync Room System. LRS is comprised of a single or dual screen system, video camera, and control unit. This system provides for a rich conferencing experience by providing HD video, touch screens with white-boarding, audio & video inputs, and more. For more information on Lync Room system, see the Product Group’s blog post. To see the systems optimized for Lync, see the catalog.

Deploying a Lync Room System involves several steps, and is outlined (albeit poorly) in the LRS Deployment Guide. I say poorly because from a PowerShell perspective, the 10 steps outlined can be combined down to about 6. Some are Exchange related, some are Active Directory related, and some are Lync related.

What I’ve done is to automate & streamline the process, add a ton of error checking, optimization, and validation. Instead of picking an Exchange server, the script will automatically find and connect to Exchange. It then performs the following tasks:

1. Create an Exchange mailbox configured as a room resource. Additionally, the description is defined, and the company name on the account is configured (see https://www.ucunleashed.com/2266 for why this is important). The room account is enabled. You’re prompted for a password for the account, and that password must conform to the organizations’ password policy for complexity. If the mailbox already exists, which would be common in most scenarios, the script will handle it gracefully, ensuring it’s configured properly.
2. The mailtip for the account is defined. It merely reminds users to make meeting requests a Lync meeting.
3. Set calendar processing to AutoAccept so that when the room account is added to meetings, it will automatically accept the request.
4. The AD account is enabled
5. The Lync Meeting room is created, and uses the email address for the SIP address. This is important to avoid Exchange Web Services (EWS) issues.
6. If a LineURI is defined, the meeting room is enterprise voice enabled. LineURI should be specified in E.164 format.

Any other configuration, such as conferencing policies, etc., can be set after the script runs. I’ve used this script to deploy a 70″ dual display SMART Room System.

See the assumptions section below for more info.

Syntax

New-CsLyncRoomSystem.ps1 [[-Alias] ] [[-Name] ] [[-UPN] ] [[-SamAccountName] ] [[-RegistrarPool] ] [[-LineURI] ] [[-CompanyName] ] [[-ResponseText] ] [[-ResourceCapacity] ] [-DeleteSubject ] [[-EnableResponseDetails] ] [-WhatIf ] [-Confirm ] []

example

New-CsLyncRoomSystem.ps1 -Alias nycconfroom -Name "New York City Conference Room" -Upn "nycconfroom@contoso.com" -RegistrarPool "frontendpool.contoso.com"

The SamAccountName only needs to specified if it needs to be different than the alias.

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

• The SIP address is set to match the SMTP address. This is to avoid issues where the two don’t match and Exchange Web Services (EWS) calls fail.
• Exchange 2010 or 2013 exists in the environment
• The user running the script has the appropriate rights in Exchange (Recipient Management or higher) and Lync (RTCUniversalUserAdmin or higher)
• The machine that the script runs on has both the Lync and Active Directory modules installed.

Download

v1.2 – 06-10-2014 – New-CsLyncRoomSystem.v1.2.zip

v1.1 – 02-08-2014 – New-CsLyncRoomSystem.v1.1.zip

v1.0 – 01-28-2014 – New-CsLyncRoomSystem.v1.0.zip

Changelog

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

Description

Some Lync 2013/Skype for Business 2015 policies have few parameters, like User Services Policies. Others, like Conferencing Policies, have a considerable number of parameters. Often, organizations need to have different policies for different groups of people. Many times, there is only one or two settings that are different. Creating a new policy based on an existing policy can be time-consuming. There are some cool utilities like Kevin Peters’ cool StareCompare, which shows where policy settings are different between two policies. But what if it was just easier to “clone” an existing policy to a new policy, and then just change the few settings that need changing? NextHop has a nice article on how to just that. You export the current policy to an XML file, edit the file, then import it into a new policy. Must faster, but still requires some manual editing of an XML file. Ya know why I don’t like that method? Not enough PowerShell! So what I did was write a script that automates that method, and allows you to clone an existing policy to a new policy in one step. The script exports the existing “source” policy, updates the XML, then imports into the “target” policy. One command to make life easier. Then you can use the appropriate “set” cmdlet to tweak the new policy. And it works with all Lync 2013/Skype for Business 2015 policy types, including Archiving, Client, ClientVersion, Conferencing, ExternalAccess, HostedVoicemail, Location, Mobility, NetworkInterSite, PersistentChat, Pin, Presence, UserServices, Voice, and VoiceRouting. The script only works with Lync Server 2013/Skype for Business 2015 policies, and only runs on PowerShell 3.0 or higher (Windows Server 2012 or later).

The script supports Get-Help, so run that if you need additional info.

Syntax

New-CsClonedPolicy.ps1 [[-ExportFolder] ] [[-ExportFile] ] [[-SourcePolicyName] ] [[-TargetPolicyName] ] [[-PolicyType] ]
[[-Description] ] []

An example would be

New-CsClonedPolicy.ps1 -SourcePolicyName global -TargetPolicyName "new policy" -PolicyType ConferencingPolicy

This would clone the global conferencing policy into a new policy called “new policy”. Acceptable values for PolicyType are “ArchivingPolicy”, “ClientPolicy”, “ClientVersionPolicy”, “ConferencingPolicy”, “ExternalAccessPolicy”, “HostedVoicemailPolicy”, “LocationPolicy”, “MobilityPolicy”, “NetworkInterSitePolicy”, “PersistentChatPolicy”, “PinPolicy”, “PresencePolicy”, “UserServicesPolicy”, “VoicePolicy”, and “VoiceRoutingPolicy”

When specifying a TargetName, keep one thing in mind. Using just a string value will create a user level policy. If you need to create a site level policy, specify “site:”, such as “site:Redmond” to create a policy for the Redmond site.

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.

Download

v1.3 – 02-03-2017 – New-CsClonedPolicy.v1.3.zip

v1.2 – 06-10-2014 – New-CsClonedPolicy.v1.2.zip

v1.1 – 02-08-2014 – New-CsClonedPolicy.v1.1.zip

v1.0 – 09-03-2013 – New-CsClonedPolicy.v1.0.zip

Changelog

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

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 ExternalAccess.

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.

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.

Download

v1.7 – 02-03-2017 – Grant-CsPolicyByADGroup.v1.7.zip

v1.6 – 09-23-2014 – Grant-CsPolicyByADGroup.v1.6.zip

v1.5 – 02-08-2014 – Grant-CsPolicyByADGroup.v1.5.zip

v1.4 – 01-27-2014 – Grant-CsPolicyByADGroup.v1.4.zip

v1.2 – 10-16-2012 – Grant-CsPolicyByADGroup.v1.2.zip

v1.1 – 09-19-2012 – Grant-CsPolicyByADGroup.v1.1.zip

v1.0 – 09-10-2012 – 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 that 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 folder, 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. With the newer Polycom VVX and Snom firmware files, they download in different formats. The Snom firmware just comes as the .cab file, while the Polycom VVX comes as a .zip file containing several .cab files. Nothing to do once you download the Snom file, but you do need to unzip the Polycom file.

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.

.\New-CsFirmware.ps1 -Download

Will download the firmware for LPE devices, and automatically import them. It does NOT download firmware for SNOM or Polycom VVX devices (yet).

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.

If you’d like to target just a specific pool for the updated firmware, using the -PoolFqdn parameter with the desired pool FQDN.

Once you’ve deployed the firmware, you can easily see the firmware versions connecting to Lync by using my Get-CsConnections script and specifying the -ClientVersion parameter with a value of “CPE”.

.\Get-CsConnections.ps1 -PoolFqdn mypool.fabrikam.local -ClientVersion CPE

And look at the first table:

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.

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.

Frequently Asked Questions

Question: Will this update Roundtable devices?

Answer: No, but fortunately, fellow Lync MVP Jeff Schertz has an excellent article on how to upgrade those devices at http://blog.schertz.name/2012/02/update-cx5000-rt-firmware/.

---

Question: My test phones aren’t downloading the right firmware?

Answer: Could be this quirky issue. http://uclobby.com/2013/11/06/lync-phone-edition-test-device-wont-update-to-unapproved-version/

Download

v2.1 – 02-08-2017 – New-CsFirmware.v2.1.zip

v1.9 – 03-31-2015 – New-CsFirmware.v1.9.zip

v1.8 – 02-08-2015 – New-CsFirmware.v1.8.zip

v1.7 – 05-20-2014 – New-CsFirmware.v1.7.zip

v1.6 – 02-08-2014 – New-CsFirmware.v1.6.zip

v1.5 – 09-09-2013 – New-CsFirmware.v1.5.zip

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