« Posts under Lync

Lync UCS Contacts Reporting with Powershell

By default a Lync enabled account within a Lync/Exchange 2013 environment will be enabled for UCS (Unified Contact Store). This means that the Lync contacts get saved in the Lync user’s mailbox and not the Lync database. In order to get a list of the contacts associated with these accounts you have to export data to a zip file with some debug Lync commands and, even then, the information is buried in a hard to interpret XML file.

I had a need to validate the contacts which were getting stored in UCS for Lync users and so I came up with this script to accomplish the task. It creates a temporary directory and exports all the passed Lync users’ UCS contact information in a zip file within the directory. The function then parses and returns psobjects with the contact information by reading in the xml file directly from the zip file (no extraction to disk). After returning contact information back as nicely formatted powershell objects the temporary files are all cleaned up.

Here are a few small examples of what can be done:

You can download this script at the Microsoft Technet Gallery or at my new Github repo.

Lync and UM Correlation with Powershell

I’ve been working on an Exchange/Lync voice deployment lately and have found a new level of frustration for the lack of connectivity between the several voice components involved in turning up such a solution. That being said it is not very difficult to validate your deployment with a bit of Powershell.

There are a few necessary results to gather where I believe it can be easy to ‘miss’ configuration steps when turning up or disabling users:

  • You enable a user for enterprise voice but forget to set their pin
  • You enable a user for enterprise voice but forget to UM enable their mailbox
  • You disable a previously lync enabled user (enterprise voice enabled or not) and forget to disable them in Lync
  • You enable a user for lync enterprise voice and um enable their mailbox but use the wrong extension.

These are just a few areas which can go awry in your environment either during the initial deployment or simply occur over time.

Here is a pretty simple function which I’ve put together which gathers info about all lync enabled accounts and contacts in the environment. As I extrapolate the Exchange UM information from AD attributes this function needs only be run on a Lync server or remote session. Here are the important bits broken down for those who are interested. If you just want the function and do not care for my ramblings you can download it either at the technet gallery or at my new github repo.

First ensure that the lync modules are loaded and available (I use -Verbose:$false throughout the script as I only want my own verbose output to be shown, not verbose output from every lync cmdlet that runs). ‘Break’ is a nice way to simply exit the function. As it is very unlikely this function will be called in a non-standalone manner this kind of non-terminating non-error throwing exit is fine. I throw out a warning at least.

I also break out the properties I’m going to be snatching from users and contacts in AD. This is not at all necessary but it makes for easier script reading later on. Contacts and users are not the same so were I to try and use the user properties against a contact when querying AD I’d get errors.

I then go ahead and query AD for users which are lync enabled. I use an old school LDAP filter because I’m an old school type of guy (well that and opath filters do not always have the nuanced properties available for me to filter against).

If the user is Lync enabled then they also have a primary user address so I use that to gather even more information about the account. I have to do this in order to get the PIN information as that is not held in AD from what I could tell. In fact, if you remove the -Verbose:$false from the Get-CSClientPinInfo and run this whole function with the -Verbose parameter you will see the Lync cmdlet spit out primary frontend server names that are getting queried for PIN info.

At this point since I already have the Lync info I go ahead and use it to determine if the user is UM enabled or not. If it is UM enabled I look for any proxyAddress starting with eum: followed by some digits and that is very likely an extension for the voicemail for this user.

With the information we have collected I create another object and return it. I use a bit of regex trickery to extract the telephone number and extension from the full LYnc URI while I’m at it.

As it is very possible to have enterprise voice enabled contacts (that is all an autoattendant is in AD) we should probably get that information as well. I use Get-ADObject with another ldap filter to only look for contacts which are lync enabled.

I then return everything pretty much the same way as I did for user accounts except skip the voicemail and pin checking (though now that I’m writing this and thinking about it a pin check against enterprise voice enabled contacts may not be a bad idea….).

With this function you can now create and export reports with some interesting information that may help in your deployment. Here are a few examples.

As always, I welcome feedback and improvements. You can download the function in its entirety from the technet gallery or at my new github repo.

 

PS Quickie: New-PIN

Setting a bunch of PINs for Lync devices is not difficult at all. Here is a script to pre-generate them should you find the need to do so. The function simply generates random digits between 0 and 9 and convert to a string. An exception is made for the first digit (as zeros are often not displayed in csv files when opened in excel) and only digits 1-9 are used.

Lync 2013: The Many QoS Settings

There are more than a few QoS settings in Lync 2013. Here is a script which should gather most of them in a human readable format for your convenience.

»Read More

AD Audit Report with Powershell: Part 3

This is my third and final major update to my AD auditing script. This includes a handful of new useful sections such as domain published printers, NPS servers, DHCP servers, as well as SCCM sites and DPs. Other improvements include easier to use script parameters and bug fixes.

»Read More

Lync 2013: Monitoring Mirrored SQL Databases With PowerShell

In Lync 2013 you are given a powerful new backend redundancy option for your important databases in the form of SQL mirroring. In this article I’ll discuss which services are able to be mirrored, the databases they encompass, and provide a PowerShell script to generate a report on the database mirror status. I also threw in Lync CMS replication and service status sections because it is the civil thing to do…

»Read More

AD Audit Report With Powershell: Part 2

I’ve updated my AD auditing report. The forest level report now includes AD integrated zones, GPOs, and fixed code to conform to strict v2 Powershell. I’ve also included a new domain level report! This report provides some user/group stats, all privileged group membership, and more.

»Read More

Active Directory Audit Report With Powershell

Not too long ago I wrote a quick post on how easy it is to gather information from AD. As a case in point example I provided a script to gather all the disabled user accounts which are still assigned Lync IDs. In this script I take it one step further and provide a full blown Active Directory reporting script which can be produced with any non-privileged domain user account.

»Read More

Find Disabled Users With Lync Enabled Without Lync Cmdlts

Here is a quick tip which applies to more than just Lync. I use powershell with .NET ADSI to gather a list of all users which are disabled but still have Lync sip addresses assigned. There are numerous reasons to disable lync on such accounts. One reason would be to make certain that users whom are no longer with the organization get removed from the Lync address list. Another is so these same users can no longer access Lync! (Yes, a disabled AD account may still be authorized to access Lync).

»Read More

Exchange – The State Of External Client Access

Introduction

Most within the messaging and collaboration industry are hyped up about the next wave of Microsoft collaboration and messaging products which are soon to be released. Among these products is Exchange 2013 RTM. This type of release typically precedes yet another wave of architecture upgrades across the corporate landscape. Some of these (beta testers) will be will undoubtedly upgrade to Exchange 2013.

Other corporations will start to feel the burn to upgrade as well. These will be organizations which realize that their Exchange 2003/2007 infrastructure is nearing a decade old existence and cannot meet the demands of their ever growing mobile workforce. Realizing they are behind the curve, they may feel hastened to upgrade as well, possibly just to Exchange 2010. Regardless the reason in choosing to upgrade their messaging infrastructure, there are critical design decisions which need to be made in how clients access this infrastructure both internally and externally. This article focuses solely on the external access aspect of the infrastructure.

»Read More

Follow

Get every new post delivered to your Inbox

Join other followers