The Skype for Business team recently sent out an email to preview customers with guidance around the Skype Meeting Broadcast feature. As I was away, Readify’s CIO, Tatham Oddie was the one who actioned it. The guidance in this email has a number of issues, leading him to post his thoughts up on Twitter, needless to say, he didn't like their advice!

The instructions were pretty simple, as you can see:

A full copy of the email can be found here.

I was shocked when I saw the guidance, from requiring elevation, to changing the execution policy without informing the user, and then a Lync reference to top it all off. I felt that some things needed a discussion.

Unneeded Elevation

The user is asked to run an elevated PowerShell session on two occasions. This is two too many.

For the first instance, the user is asked to run an elevated PowerShell simply to execute Get-Host. GET-HOST! There is no conceivable reason why you would ever need to be elevated to run this CMDLet. I think Get-Host is probably one of the simplest CMDLets in existence, yet the Skype for Business team felt like it needed to be elevated.

Now the second elevation attempt is almost legitimate. During the step titled “Connect to your Office 365 tenant through remote PowerShell”, we will be executing Set-ExecutionPolicy. Unfortunately, I will discuss later why this command shouldn’t be here, and hence there is no reason for elevation.

Any time you elevate, you need to be more aware of what you are doing. In most cases, elevation is only required if you are making changes to the local system. Instructions to configure a cloud based service requiring elevation should be ring big honking alarm bells, maybe even giant ones. Why on Earth would I be making changes locally, when configuring a cloud service?

I don’t run as local administrator; my every day account is not a member of the local administrators group. This has the unfortunate side-effect of breaking much of Windows 10 (thanks Gabe), however it dramatically improves your security posture. Even if UAC was bypassed, my account isn’t a member of the group, it doesn’t have the privileges you seek. When I need to elevate, it’s a conscious decision on my part, do I want this app to do this, do I want to make this change? I very much believe that all users, be they home users, developers, or system administrators, should run in this model. As a side note, its painfully obvious that most of the Microsoft development team runs with local admin.

Changing The Execution Policy

I always get a bit upset when someone or something changes the execution policy and in the guidance, that is exactly what the Skype for Business team want to do. Not only have they decided to make this change for me, but they have picked one of the least secure settings, unrestricted. They haven’t even made an attempt to switch it back and the end of the execution process.

The first thing I want to point out is that the Skype for Business CMDLets will work perfectly on execution policy of AllSigned and RemoteSigned. They are after all signed with a code signing certificate issued to Microsoft. After going through all of the effort to get their modules signed, the Skype team simple went YOLO, let’s set the policy to Unrestricted.

They could have of course gotten the user to run simply that PowerShell session as unrestricted, or they could have recorded what the policy was before they changed it, and switched it back. Like this:

There has also been no attempt at even checking what the execution policy was previously, perhaps all would have been OK? Why not have this as a prerequisite step?

Finally, they have made the assumption that the user receiving this guidance can change the policy. I have worked in a few environments where group policy would step in and prevent setting the execution policy to unrestricted.

What is an Admin with MFA to do?

It would have been great to see a mention of what an admin with MFA enabled, should do to run these commands. Thankfully the Skype for Business team allow the use of App Passwords, unlike their poorly informed and aggravatingly annoying peers in the SharePoint and Exchange online teams who reject app passwords.

Is that a Lync reference?

I know Tatham and I are being pedantic, but a Lync reference, seriously? Microsoft announced that Lync would be replaced by the Skype for Business branding a year ago!

What the email should have looked like

I don’t like tearing things apart without helping to fix them, so how could the Skype team have done things better?

Well here is one that I prepared:

As you can see, there are a number of changes.

• There are no elevation requests in the instructions. We check the prerequisites with no elevation, and the connection instructions no longer require elevation either.
• There are now appropriate checks to ensure the Skype for Business Online Connector is installed. This is a simple touch, but makes the process much easier for users.
• Checking what the Execution Policy is, and we link to Microsoft guidance on what the appropriate policy is, and how to change the policy.
• I removed the Lync reference.
• Changed the restart wording. Sometimes when you install the module, it doesn’t correctly prompt for a restart, but it does indeed need a restart.
• Added a note around what to do if MFA is enabled.

None of these changes were very difficult, nor where they very time consuming. I really don’t understand why no one at Microsoft picked up any of these issues prior to the email being sent off. I can’t see any excuses for missing this issues, they were painfully obvious.

Kieran Jacobsen