Archive

Posts Tagged ‘Lync Server 2013’

Script: Install-OfficeWebAppsLanguagePacks.ps1 – Easier Installation of Selected Language Packs

March 7th, 2015 No comments

PowerShell-logo-128x84Description

I was working with a global customer lately who has datacenters in various global regions (as most global orgs do). The customer had not decided, and basically, hadn’t even thought about what language packs to install on their Office Web Apps Servers (OWAS). I suggested that there are 49 language packs including the English pack that I install by default on every OWAS server. Those languages are:

Azeri (Latin)
Basque
Bosnian (Latin)
Bulgarian
Catalan
Chinese (Simplified)
Chinese (Traditional)
Croatian
Czech
Danish
Dari
Dutch
English
Estonian
Finnish
French
Galician
German
Greek
Hebrew
Hindi
Hungarian
Indonesian
Irish – Ireland
Italian
Japanese
Kazakh
Korean
Latvian
Lithuanian
Macedonian (FYROM)
Malay (Malaysia)
Norwegian (Bokmal)
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Romanian
Russian
Serbian (Cyrillic)
Serbian (Latin)
Slovak
Slovenian
Spanish
Swedish
Thai
Turkish
Ukranian
Vietnamese
Welsh

The customer decided on which language packs to install.

If you’ve ever tried to install these, you know you go to the language pack download page, and pick your desired language. When the next page comes up, you notice that it’s in the language of the desired language pack. You hope you’re clicking on the right link, download the file, then run the installer, which is mostly in the desired language, and go from there. It can be somewhat confusing, but extremely repetitive – especially if you’re installing a lot of language packs. It got me thinking that this was an area ripe for automation (what area isn’t?).

Well, as I’ve mentioned on this blog before, I’m lazy (as most coders are). So I wrote this script to make my life easier, and as a result, you gain from it. Here’s what the script does:

  1. Detects which (if any) language packs are installed on the local machines. This is accomplished by looking for the correct GUID in the Uninstall branch of the registry.
  2. Displays a grid list of the language packs that are available and not already installed on the machine (see image below). You can select one or more language packs to install and click “Ok”.
  3. The script will download the language pack(s)
  4. It will mount (if they are an .img file), or extract (if an .exe).
  5. It will silently install the language pack
  6. It will clean up after itself (unmount or clean up extracted files)

Here is the selection list presented. Notice that English is not in the list as that language pack is already installed.

OWAS language pack selection

Once installation is completed, you’re left with your language packs installed and a nice little log file.

OWAS post installation

Extract the files to any folder. The script and the .csv file MUST be in the same folder. Run it by calling Install-OWASLanguagePack.ps1 and it will default to using the following path structure (which it will create if it doesn’t already exist):

Path Purpose 
 c:\_Install  Root working folder. Can be changed using -TargetFolder when calling the script.
 c:\_Install\logs  Log files from the script are stored here
 c:\_Install\OWASLanguagePacks Downloaded language pack files are stored here. Folder name can be changed using -OWASLanguagePackFolder. Language packs are placed in sub folders of this folder. The sub folders match the language of the language pack.

A little bit of a rant. I *REALLY* wish the language packs were an MSI file that supported silent install instead of an .img file that must be mounted or an .exe that must be extracted, and then each called with complex syntax.

Syntax

Install-OWASLanguagePacks.ps1 [[-TargetFolder] <object width="300" height="150">][[-OWASLanguagePackFolder] <object>] [-WhatIf] [-Confirm] [-IncludeTotalCount] [-Skip <uint64>] [-First <uint64>][<commonparameters>]</commonparameters></uint64></uint64></object>

Installation

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

Assumptions

None

Download

v1.0 – 03-07-2015 – Install-OWASLanguagePacks.v1.0.zip

Changelog

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

One Liner – See Number Of Connected Users, Endpoints On A Lync Front End Server

January 22nd, 2015 2 comments

A question went around an internal DL at work today asking if anyone knew off the top of their head the name of performance counters that show connected users and endpoints. While digging up the answer, I started thinking – this would be a great little one liner.

My esteemed colleague Ron Cook (@roncook925) beat me to supplying the answer to the DL question. The two counters are:

LS:USrv – Endpoint Cache\USrv – Active Registered Endpoints
LS:USrv – Endpoint Cache\USrv – Active Registered Users

Endpoints is always higher than users, in my experience. There are always some users who are connected via mobile devices and rich client, or via OWA, or LPE. So I like to query both.

PowerShell has a great cmdlet called Get-Counter which, as you can guess, can query performance counters. There’s a pretty good tutorial on how to retrieve perfmon counter data for Lync related counters by the Lync PowerShell group at Microsoft in How Do We Love Performance Counters” Let Us Count the Ways. So let’s take a look at how we can get the data we need.

In this case, we’ll query the two counters mentioned above with one line. This is supported in Get-Counter by just separating the counters with a comma. We’ll select an expanded property called CounterSamples, which holds the data we need (among other info). And lastly, we’ll output the path (counter name), and something called the CookedValue, which is the actual counter value contained within CounterSamples. I know, CookedValue sounds like it could be just made up numbers, like those you get from a shifty accountant. But it is truly the value we want.

Plug this into your console as one long line:

Get-Counter "\LS:USrv - Endpoint Cache\USrv - Active Registered Endpoints","\LS:USrv - Endpoint Cache\USrv - Active Registered Users" | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto

That will give you a quick point-in-time snapshot of the number of users and endpoints connected to the front end, as shown below.

perfmon

The blurred text is just the front end name. If you’d like to query a remote front end, just tack on the ComputerName parameter, such as:

Get-Counter "\LS:USrv - Endpoint Cache\USrv - Active Registered Endpoints","\LS:USrv - Endpoint Cache\USrv - Active Registered Users" -ComputerName frontend.contoso.com | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto

For those wondering why I’m using Format-Table and the -Auto parameter, it’s because the counter path value is so long that it would otherwise get truncated short enough to where you wouldn’t know which counter was tied to which value.

Quality of Service (QoS) Calculator – Plan Your Network, GPO, and Lync Config More Easily

November 5th, 2014 4 comments

Description

When deploying Microsoft Lync Server, network health and configuration can be crucial.

The QoS Calculator allows you to pick and choose what components and clients will be used in your environment as well as which specific clients. You’re also able to pick a starting port number, port count, and DSCP value for each modality. The calculator will ensure that port ranges are consecutive, and that they don’t extend past 65535. The calculator will list all relevant Group Policy Object (GPO) settings, as well as the PowerShell commands needed to configure Lync Server. Clients available for configuration include Lync 2010 and Lync 2013 full client, Lync 2010 Attendant and Landis Computer’s Attendant Pro attendant clients, Windows Store App client, Lync Phone Edition, and more. Server side options include A/V conferencing, application sharing, Response Group Service applications, Conference Announcement service, Call Park, UCMA apps, PSTN audio, A/V Edge services, Exchange UM, and the VDI client.

To start with, go to the INPUT tab. Any of the green cells can be changed. Reset buttons allow you to set port and port count settings back to their original values. Future releases will also reset the DSCP values as well (just need to figure out how to do that in Office VBA). Red cells indicate an error (missing or incorrect data).

1

Enter your Front End and Edge pool FQDNs. If you have a separate mediation pool, enter that name as well. The values defined here are used to compose the PowerShell commands needed to configure Lync Server.

2

You can show/hide different policy types using the appropriate checkboxes.

qoscalculator3

If your Mediation role is collocated with your Front End servers, check the box. This will combine the appropriate GPO policies together.

qoscalculator4

Changes to green cells are immediately reflected elsewhere in the calculator.

Once you have the values entered/verified, go to the POLICIES tab to see a list of GPO settings needed. Check out Elan Shudnow’s awesome Enabling QoS for Lync Server 2013 and Various Clients and Jeff Schertz’s Lync Quality of Service Behavior for a deep dive into setting up QoS.

Next, go to the POWERSHELL-LYNC tab, and you’ll see the relevant Lync Management Shell commands to configure the server side based on the info you supplied. Copy and paste each into Lync Server Management Shell.

Lastly, go to the POWERSHELL-GPO tab, and you can copy and past PowerShell code into a PowerShell console on a domain controller to automatically create and configure the Group Policy Objects for server and client machines. Note that if your edge servers are not domain joined, the local security policy on the edge servers is used to configure QoS.

I have tons of ideas for more features and functionality. Feel free to comment below on things you’d like to see in future versions.

Syntax

None

Installation

None. Just open the file in Excel. As this is a macro based file, you’ll need to enable content when prompted.

Assumptions

None

Download

v1.2 – 02-27-2015 – Lync 2013 QoS Calculator v1.2.xksm

v1.1 – 01-26-2015 – Lync 2013 QoS Calculator v1.1.xslm

v1.0 – 11-5-2014 – Lync 2013 QoS Calculator v1.0.xlsm

Changelog

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

Script: Get-CsFederatedConversationDetails.ps1 – See Stats About Conversations With Specific Federated Domains

May 13th, 2014 4 comments

Lync 2013 logo 128x128Description

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

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

aol3

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

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

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

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

Syntax

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

Installation

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

Assumptions

None

Download

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

Changelog

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

 

Changelog: Get-CsFederatedConversationDetails.ps1

May 13th, 2014 No comments

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

v1.0 – 05-13-2014

  1. Initial version

Script: Get-CsUpdateVersion.ps1 – See the Cumulative Update Level Of All Lync Servers

May 2nd, 2014 13 comments

Description

My work at Modality Systems often has me doing health checks for customer Lync environments. These can be due to customer requests, or as part of our onboarding for new managed support customers. If you’ve ever had an Active Directory Risk Assessment Program (ADRAP) or Exchange Risk Assessment Program (ExRAP), it’s quite similar. Lots of tasks to run, lots of data to sift through. So it’s always beneficial to standardize and automate the steps to get the data. The same is the case when you’re responsible for your own environment and want to ensure good health.

Just like Get-CsDatabaseUpdateStatus.ps1, Dave Howe from the Lync product group and I teamed up to automate something. In this case, it’s looking at what Cumulative Updates are installed on each server throughout a Lync environment. This script queries each pool, then finds what servers are part of that pool, and queries each server to find the CU that’s installed. It then provides an easy to read output of the entire environment (with exceptions) for easy review. As shown below, we see three multi-server pools, the version number and “friendly” Cumulative Update info.

Get-CsUpdateVersion3

The script works fine with Standard Edition servers as well:

Get-CsUpdateVersion4

In the first example, you see that the first two servers show “PSRemoting failure”. This is because the script uses PowerShell Remoting to connect to each remote server to query information (see installation notes below). PSRemoting doesn’t really work the same when dealing with non-domain joined machines, such as the first two, which are edge servers. So the script isn’t able to communicate with them via PSRemoting, and flags them. If the script can’t ping a server, it will show as “offline”. The friendly name of the CU shown is coded in the script. So I’ll update it each time a new CU is released.

By default, the script checks all pools. But you can specify a single pool by using the -PoolFqdn parameter.

Syntax

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

Installation

This script uses PowerShell Remoting to query remote servers. PSRemoting is enabled by default on Windows Server 2012 and later, but disabled by default on 2008 R2. To enable PSRemoting on 2008 R2 servers, see Enable-PSRemoting.

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

None

Download

v1.9 – 02-19-2015 – Get-CsUpdateVersion.v1.9.zip

v1.8 – 02-09-2015 – Get-CsUpdateVersion.v1.8.zip

v1.7 – 01-01-2015 – Get-CsUpdateVersion.v1.7.zip

v1.6 – 12-12-2014 – Get-CsUpdateVersion.v1.6.zip

v1.5 – 11-21-2014 – Get-CsUpdateVersion.v1.5.zip

v1.4 – 09-24-2014 – Get-CsUpdateVersion.v1.4.zip

v1.3 – 09-02-2014 – Get-CsUpdateVersion.v1.3.zip

v1.2 – 08-07-2014 – Get-CsUpdateVersion.v1.2,zip

v1.1 – 06-02-2014 – Get-CsUpdateVersion.v1.1.zip

v1.0 – 05-02-2014 – Get-CsUpdateVersion.v1.0.zip

Changelog

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

Changelog: Get-CsUpdateVersion.ps1

May 2nd, 2014 No comments

This is the changelog page for Get-CsUpdateVersion.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.9 – 02-19-2015

  1. Added Lync Server 2013 CU 11 (5.0.8308.871)

v1.8 – 02-09-2015

  1. Added Lync Server 2010 CU 15 (4.0.7577.710)

v1.7 – 01-01-2015

  1. Added Lync Server 2010 CU 13 (4.0.7577.707)
  2. Added Lync Server 2010 CU 14 (4.0.7577.708)
  3. Added Lync Server 2013 CU 10 (5.0.8308.866)

v1.6 – 12-12-2014

  1. Added Lync Server 2013 CU 9 (5.0.8308.857)

v1.5 – 11-21-2014

  1. Added Lync Server 2013 post CU5 (5.0.8308.803)
  2. Added Lync Server 2013 CU 7 (5.0.8308.831)
  3. Added Lync Server 2013 CU 8 (5.0.8308.834)

v1.4 – 09-24-2014

  1. Added Lync Server 2013 CU6

v1.3 – 09-02-2014

  1. Added Lync Server 2010 CU12

v1.2 – 08-07-2014

  1. Added script check for updates. This is key because each time a new cumulative update comes out, the script will be updated with version info
  2. Added some preliminary code around getting version info for OWAS servers. Need to find a graceful way of getting the server names in a OWAS farm.
  3. Added Lync Server 2013 CU5

v1.1 – 06-02-2014

  1. Tweaked the PSRemoting code block for retrieving version numbers per Chris Irons. This should resolve unexpected results when querying Lync Server 2010 pools.
  2. Filtered out “Debugging Tools” “Resource Kit Tools” “Best Practices Analyzer” and “Meeting Room Portal” which could have a higher version number and cause incorrect results – thanks to Andy G for pointing that out.
  3. Shortened some of the output text to reduce the likelihood of word wrap.

v1.0 – 05-02-2014

  1. Initial version

Script: Get-CsDatabaseUpdateStatus.ps1 – See If Your Lync Databases Are Up To Date

April 30th, 2014 14 comments

Description

Anyone who has updated a Lync environment with a recent Cumulative Update knows that there are often manual steps to perform after the LyncServerUpdateInstaller.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 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
  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

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

Get-CsDatabaseUpdateStatus2

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.

Assumptions

None

Download

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.

 

Changelog: Get-CsDatabaseUpdateStatus.ps1

April 30th, 2014 No comments

This is the changelog page for Get-CsDatabaseUpdateStatus.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.1 – 04-30-2014

  1. Fixed an issue with mangled parameter blocks. Thanks to Dave for reporting it.

v1.0 – 04-30-2014

  1. Initial version

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

January 28th, 2014 2 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] ] [[-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.

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.