Get-AssignedLineURI has been updated twice

Get-AssignedLineURI has seen two updated since my previous post. The first update came back in June, and the second one just yesterday.

I am trying my best to add information I find useful, and incorporate these as soon as I have time. My latest additions are most tied to license counting. So many of my customers have the headace of knowing how many licenses the have, what they have deployed and if the required functionality is being used.

My latest addition is a connection to the monitor database, to verify user last logon, and the use of conferencing for a particular user. I also copied the send_email function from the backup script. This script can now be run as a task, and send a report to a desired mail address.

Here’s a short list of my updates:

V 3.6 – June 2015:

  • New feature: If a Monitor database is detected, and connection is possible, the script will now add “last log on” and “last conference initiated” information to the output

V 3.7 – September 2015

  • New feature: LicinfoHTML -> A parameter to gather license info and add it to the html output
  • New feature: Send the report in an e-mail


License count in HTML output

One of the new features I would like to highlight is the license count in the HTML output.

By using -LicInfoHTML and -CreateHTMLOutput togehter, you should get a summary on top of the HTML report similar to the following image:

report summary

Listed above are the total number of users, how many of them have only peer-2-peer functionality, how many have the enterprise license (conferencing) and how many enterprise voice enabled users there are. Along with the previous information added by counting devices.

Using Monitor Data

I added the -usemonitordatabase back in June, but forgot to post about it. But it is a very useful addition for gathering information about your deployment. Using this switch requires access to the monitor database (both user rights and network access), and will increase the time taken to complete the script.

Connecting to the Monitor Database adds a wealth of information, but I have chosen to focus on three pieces of the puzzle. The last logon preformed by the user, the last time he/she initiated a conference and whether or not the user has an enterprise license. Adding these as columns to the end of the line for each user, you should get information similar to the following:


In the example above you can see there is a user who has not been logged in for the duration of the log files, there are users who initiates conferences, and there are users not assigned with conference rights.

This information can be useful when deciding who gets to keep their enterprise license or not (if saving cost is an issue), identify users who do not log on and ccould be disabled or maybe encouraged to log on and participate.

Two words of warning regarding the information above:

  • This report is based upon logged data. Check your retention time to figure out how “valid” the above statements are. Needles to say, the longer the period of data history, the more accurate the report is.
  • If a user has not logged in for a while, that is no reason to disable that user. But could be a reason to investigate if the user should be disabled or not. A long absence from logging in can be due to Holiday, maternity/paternity leave or other valid reasons. (Again, depending on your history of data, this information can be inaccurate)

I use the “last logged in” information mostly during a deployment of a new customer. It can easily identify late adopters of the solution.


The script is available for download at the Technet Gallery

I hope you find these changes useful. And as always, I appreciate feedback ;)

How I used get-assignedlineuri to identify users with a missing EXT

(and prevented a couple of helpdesk calls when login to conference failed)

Here is another example of how I use the get-assignedLineURI in my deployments

I run my script with the following switch: .\Get-AssignedLineURI.ps1 -ListAsGridView

Then I use simple filters in gridview to list all users with a LineURI where EXT is empty.



This simple task identified 12 users with a missing EXT (among 300 users) in just a couple of seconds.

Using this information it was easy to fix these users, without them ever knowing they had an issue :)

A few examples from the get-assignedlineuri

As with the search-lineuri script, I had to make parameters mandatory to make it as flexible as I wanted it to be for my usage. If the script is run without known parameters it will throw this custom error message, and I suggest running “get-help .\Get-AssignedLineURI.ps1 -Detailed” to get the complete list of options:


One of my favorites when I try to get an overview over a new system, or just keeping tabs on an existing one, is the the showsummary in shell. It gives a quick overview over how many objects within the Lync system there are with a assigned lineuri:


Then over to one my most used parameters. I use it in all my deployments, to get a detailed view over all the deployed lineURIs on all objects within Lync in one simple HTML document. Simply run Get-AssignedLineURI.ps1 -CreateHTMLOutput (with or without the -path parameter to control where the document is created):


I think this will be enough for one post, but I will be back with more examples in the following weeks.

A few examples from search-lineuri

It’s about time to give a few examples of our scripts, and I thought I’d start out with a few basics from the search-linerui script.

I have tried to create an accurate help description with in the script, so everything should be explained with the use of  “get-help .\search-lineuri.ps1 -Detailed” but here are a few pointers with screenshots as well.

One of the errors I see when other use the script is when the run it without any parameters. When the script was first created it did not require any parameters, but in order to do all the things I want to with it I had to make parameters mandatory. If you run the script without any valid parameters, you should receive the following custom error prompt:


Try run the script with at least one parameter like “-search” to get a result:


Please observe I have set a validation on the number parameter ($URIsearch) at least 2 digits and maximum 20 digits long ([ValidateLength(2,20)]). It will cause a system error if a search is tried with fewer or longer extensions:


That’s all for now. I will post more screen shots and usage examples in the following weeks