Join Teams work meetings from Microsoft Teams (free) and vice versa

Microsoft Teams (Free) users can currently join Teams for work (or school) meetings only as guests, which requires them to use a browser and results in a sub-optimal experience. The new feature rolling out will allow these users to join Teams for work (or school) meetings in one click, without being redirected to the browser or asked to fill in their name/surname. They will also be able to continue collaborating with the meeting organizer and other participants via meeting chat after the meeting.  The feature will work in the opposite way as well, so Teams for work (or school) will just as easily be able to join meetings hosted by a Teams Free user with one click. This is associated with Roadmap ID: 167326

Enabling users for Lync, and making them aware

Here is a new script I've been working on for some time. It's a script I've been using both as part of a new deployment, but also as a scheduled task to enable new users in AD "automatically" as they are provisioned.

First of all, I would like to spend a few words on the power-shell command "send-mailmessage".
I've been wanting to automate as much as possible for a long time, and I have been doing so for some time with simple one liners, running as scheduled tasks. But I have always thought it would be nice to alert a user of his Lync capabilities as soon as they are available and some of the important properties associated with it.

Most of my one-liners have been based on "get-csuser", "get-csaduser" or similar, with a filter or two to identify users not enabled for Lync or Enterprise Voice. The problem with "send-mailmessage" is I've never been able to pass information from a get command to the send command. After giving up at first (due to lack of time), the solution came to as I was also looking at a different "issue" with my one liners.

A lot of my script and one-liners would read and write properties on to many user-objects, as I was never just editing a few users. If you study some of my older posts, the commands would usually grab all users in a OU, and then grant them a dialplan or a voice policy.

My solution (to my problem) was to first fetch ad users not enabled for Lync, grab the properties I needed, then export all of this to a temp file. The rest of the script rely on importing the same file and apply settings to users based on this file. This way, I would query AD only once for which users to edit. And I would not have to worry about the rest of the script trying to do things to additional users. This last part was important when I wanted to add the send mail functionality (Can you imagine how annoying it would be to get the same email over and over and over again?).

The solution to singe out objects to handle also had an interesting side effect. One of the properties I was editing to enable a user for Lync suddenly showed up in my test emails cript. As it turned out, the "send-mailmessage accepted parameters I had created by my self ($parameter) where it did not accept the "usual" $_.information from any get or import command I have tried before.

Second solution: create parameters based on imported values ($lineuri = $_.lineuri). It seemed a bit odd, but as it is working, I am happy, and ready to share it with you guys,

Now, Let's get to the important part, the script.

The first part of the script is dedicated to gathering information on what to do (This is the part you want to edit if you are going to run it as a scheduled task. I have tried to describe it as best as I can in the script itself. Basically, it queries the user for:
- OU-string to establish a searchbase
- Registrar to enable the user at
- Dialplan to use
- Voice policy to use
- External access policy to use
- Filepath to store the temporary information.

The query part looks like this:


If you want to edit this script to be run as a scheduled task, or to be run with out user intervention, you should re-write this to something like this:


After getting all the information I think was relevant at the time, the script will try to get the information you require, and dump it to a csv file. (line-breaks have been added in the screen shot, these are not present in the script)


I tried a couple of ways to create a readable csv file, but I found the "export-csv" to be the "best" command for my purpose. Don't forget the -notype parameter, as this removes a line you do not want in your csv file.

Having created the file containing all the information I need, it's time to start importing and doing the works.

The first task is to enable the user for Lync. In my example, I have chosen "userprincipalname" as type, this can of course, be edited.


My next step is enabling the user for EnterpriseVoice (presuming phone attribute is in a correct E.164 format in AD.


After enabling the user for EV, It's time to set dial plan and voice policy


Then I set the external access policy (You imagination is your limit here, to which policies you can possibly query for, and set).


At last, but not least, it is time to inform our users of their Lync capabilities and information. You can write all kind of information here, and add attachments if you like. The thing you need to pay attention to is how to create the output based on properties.

The command won't accept "Given name: $_.firstname", but it will accept "Given name: $fname", provided you have given the $fname a value the way I do in my example.

I hope you find this script and post useful as I have.
The Script can be found here: https://dl.dropbox.com/u/22417188/SendUserInfoInMail.txt, and will be added to my script page (where any updates will be posted)

As always, comments and feedback is appreciated.

Comments