Monday, October 14, 2019

Pinned channels soon coming to Microsoft Teams

Here is a feature I'm looking forward to.
It will soon be possible to organize your channels by pinning the most important (to you) ones. Roadmap item 55369 is "just around the corner", and admins have been notified in the O365 message center.

According to the message in the admin portal, we should all see this by the end of October.

Friday, October 11, 2019

Testing the Sennheiser 660 MS - Can I finally travel with just one headset?


For years now, I have traveled with two headsets . I always have my trusted Bose headset in order to shut out unwanted noise, and comfortably listen to music or watch something on my mobile device. Bose is in my opinion the best headset on the market for this very reason. However, the Bose headset is really bad when it comes to speech in modern collaboration tools like Teams. And since I do a lot of meetings on the road, I always bring a second headset for that purpose.

I was hoping the Plantronics 8200 UC would solve my problem, and for two years it has been my preferred office and UC headset. The Call quality, the ANC and the music quality was really impressing. The music part can never compare to a headset like Bose, but it was close enough. However, the 8200 is quite big and bulky. This makes it slightly uncomfortable to use when traveling.

Enter the Sennheiser MB 660 MS. PeBeCom have generously given me a device to test, and I can honestly say I am impressed. The quality of voice is at par with the 8200, and the music quality is even better due to the different modes you can easily switch between. I have to say I think the noise cancellation is a bit better in the 8200, but where the 8200 is big and bulky the 660 is smaller, lighter and it fits my head a lot better.

With the 660 I have finally found one headset I can use for travelling and voice/video calls. My backpack just got a bit lighter, and I have one less device to pull out of the bag at security. I will probably still use my Bose on long haul flights and personal trips, but this is when I only care about the music and I don't want to work :)

Monday, August 19, 2019

Troubleshooting Powershell and GraphAPI with a little help of Fiddler

For the past two weeks, I have been trying to help a customer create a couple of scripts to create and edit Teams through the use of Powershell and GraphAPI. Although I'm familiar with Powershell's error messages, I faced a new challenge when trying to understand the messages I got when trying to create my scripts.

The biggest issue with how powershell presents the error, is that it seems to present only part of the https respons sent from graph. That wouldn't be an issue if all error messages were presented in the beginning of the response, like the following example:


This is a clear message, telling the user the "secret" used to create the access-token is wrong.

The next example, is not as clear (at least not to me). I have made a deliberate typo, but the error message is only giving me a "400 Invalid request" as a response.



Since using Powershell to invoke GraphAPI commands is basically https/rest traffic, I thought I'd try to capture it with fiddler and see if there was more to the error message than Powershell gave away.

Before you begin, configure Fiddler to capture HTTPS traffic in "options":



When everything is ready, start the capture and run your code. Here are a few examples of errors I ran into.

The following screenshot contain to windows. The upper window is a "raw" representation of what was sent from the client, and the second is capturing the response from Graph. This is quite useful to verify you are sending what you intended, and to capture the entire response:


With the plain error message, it was rather easy to find the right resource value "groups" instead of "group".

After i sorted out the correct URL, I was still hitting the same error message "400 Invalid request" as a response. Really frustrating, as I am now 100% certain my URL is correct. Well, Fiddler to the rescue once again. The response from the server was easy to read and understand. It was clear I had to go through and verify the JSON code.


I hope I have demonstrated how Fiddler (or any other web-traffic capture tool) can make troubleshooting a little bit easier.