Archive

Posts Tagged ‘Lync Server Management Shell’

Script: New-CsLyncRoomSystem.ps1 – Easily Deploy Lync Room Systems

January 28, 2014 3 comments

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 http://www.ehloworld.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] ] [-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.

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

Script: New-CsClonedPolicy.ps1 – Clones Existing Lync 2013 Policy To a New Policy

September 3, 2013 2 comments

Lync 2013 logo 128x128Description

Some Lync 2013 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 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 2013 policies, and only runs on PowerShell 3.0 (Windows Server 2012).

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”

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

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.

Finding a Domain Controller Within the Same AD Site via PowerShell

November 7, 2012 Leave a comment

Powershell_logo-137x137In 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

 

Script: Grant-CsPolicyByADGroup.ps1 – Assign Lync Policies to Users According to AD Group

September 10, 2012 7 comments

Lync 2013 logo 128x128This 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.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.

 

Lync Synthetic Tests: What They are and When They Don’t Work – Part II

August 18, 2012 2 comments

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:

New-CsHealthMonitoringConfiguration error

New-CsHealthMonitoringConfiguration 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.

Lync Synthetic Tests: What They are and When They Don’t Work – Part I

August 17, 2012 2 comments

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.

Test-CsClientAuth fails with June 2012 updates installed

Test-CsClientAuth fails with June 2012 updates installed

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]
Synthetic test using configured accounts

Synthetic test using configured accounts

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:

Test-CsCertificateConfiguration fails from management workstation

Test-CsCertificateConfiguration fails from management workstation

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

Log from Test-CsCertificateConfiguration

Log from Test-CsCertificateConfiguration

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:

Test-CsCertificateConfiguration successfull

Test-CsCertificateConfiguration successful

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.

Script: New-CsFirmware.ps1 – Upload Multiple Lync Phone Edition Firmware Updates to a Single or Multiple Pools

July 3, 2012 11 comments

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

Folder and file structure

Folder and file structure

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.

Files in each child folder

Files in each child folder

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.

Prompt for folder

Prompt for 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.

Firnware files being uploaded

Firmware files being uploaded

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

Get-CsVoiceCalls.ps1 – changelog

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

Script: Get-CsVoiceCalls.ps1 – See Realtime Call Info From Lync Management Shell

June 5, 2012 21 comments

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.

Call between Lync users

Call between Lync users

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

Call to PSTN number

Call to PSTN number

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.

Customizing the Lync Meeting Page – Part II

November 1, 2011 4 comments

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.

silverlight client

silverlight client

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:

Join using legacy client

Join using legacy client

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):

Allow legacy and attendee clients

Allow legacy and attendee clients

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