Friday, January 30, 2015

Lync - Setting Dial in conferencing PIN returns a Silverlight error

As George Bush famously didn't state, "Fool me once shame on you.  Fool me twice, shame on me"  I decided to not blog this one a while back, until I ran into it with a customer again.  Whenever I set a user's PIN in Lync, I get this error.  Below is the text of this very large error in case anyone is searching using this.  The only related thing I ever found was here (and I updated it today as well)

Message: Unhandled Error in Silverlight Application [Arg_COMException]
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See   at MS.Internal.XcpImports.CheckHResult(UInt32 hr)
   at MS.Internal.XcpImports.Application_Install(Application app, Boolean programmaticDetach)
   at System.Windows.Application.Install()
   at SkyPlayerOOB.InTheBrowser.Ui.InTheBrowserPageViewModel.OnInstallCommand()
   at PlayerCore.Commanding.RelayCommand.Execute(Object parameter)
   at System.Windows.Controls.Primitives.ButtonBase.ExecuteCommand()
   at System.Windows.Controls.Primitives.ButtonBase.OnClick()
   at System.Windows.Controls.Button.OnClick()
   at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
   at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl, EventArgs e)
   at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, Int32 actualArgsTypeIndex, String eventName, UInt32 flags)
Line: 1
Char: 1
Code: 0
 But really, this is not a Lync error.  It's a silverlight error.  And it doesn't result from setting the PIN.  You are a crafty quick admin, and as you move with the accuracy of a ninja cat through the night, you are not seeing the mistake.  Set a PIN.  NOW.  DO NOT MOVE YOUR MOUSE.  No error.

The problem is actually with the code in this screen:

The "Open my email application to send the new PIN to the user" will cause an error when you hover over it.  Try it.  Happens often.  Why?  You are on a server, and don't have a mail application installed.  If you use the Lync Admin control panel via your workstation, this actually is a nice feature.  Once I checked Do not show me again and allow, it automatically opens an email with a text blurb regarding their new PIN.  Neat.

Hope this helps!

Monday, January 26, 2015

Office Web Apps Server 2013 Updates and versions

As usual, if I spent too much time figuring something out, I post it here.  Partially to document for myself for next time, and partially to help the community.   Today, I was working on a customer with an OWAS server and wanted to determine the last OWAS patches deployed and patch it to the current version.  So I checked the add/remove programs and the version listed there was the RTM, and when showing updates, it showed me KB articles, but no version numbers.

There are several partial lists out there - here is a shoutout to a few sources of info:

Wictor's blog entry offered up the best tip - How to determine your OWAS version.  Quite simply, look at HTTP headers, and here's the simple one-liner:


This will output the version nice and clearly.  You can see here that I have 15.0.4693.1000 installed (and that is not on any of the previously linked lists)  This is the January 20th 2015 update posted here.  And please be sure to follow the Microsoft documentation on applying patches!

In the interest of trying to keep this information up to date, I will build on Wictor's list and update with any that people comment.   Please comment with the link to download as well as the version reported and I will update this list!

Name Version KB
RTM 15.0.4420.1007
March 2013 Public Update (1) 15.0.4481.1005 KB2760445
April 2013 Update 15.0.4481.1508 KB2810007
August 2013 Hotfix 15.0.4535.1000 KB2817521
October 2013 Cumulative Update (2) 15.0.4551.1003 KB2825686
November 2013 Update (3) 15.0.4551.1005 KB2837634
December 2013 Hotfix 15.0.4551.1508 KB2850013
January 2014 Security Update (MS14-001) 15.0.4551.1515 KB2863879
Service Pack 1 Preview 15.0.4569.1001 n/a
Service Pack 1 15.0.4569.1506 KB2817431
Service Pack 1 - Rerelease 15.0.4571.1502 KB2880558
April 2014 Public Update 15.0.4605.1001 KB2863899
May 2014 Public Update 15.0.4615.1001 KB2880453
June 2014 Cumulative Update 15.0.4623.1001 KB2881051
July 2014 Cumulative Update 15.0.4631.1000 KB2883003
August 2014 Cumulative Update 15.0.4675.1000 KB2883057
January 2015 Cumulative Update 15.0.4693.1000 Download (KB link is 404)
February 2015 Cumulative Update 15.0.4693.1001 KB2956101

Version notes

  1. Introduced new WOPI bindings, most significantly for WordPdf
  2. Removal of one WOPI binding; mobileView for WordPdf removed
  3. Includes fix for reported event log id's 1009 and 1150

Friday, December 19, 2014

Azure AD, Multifactor Authentication and app passwords

One of the pretty cool things that Azure AD added in late 2013 is Multi-factor authentication.    This rolled out in early February to more O365 licensees, and throughout the year, more and more organizations have been taking advantage of this functionality.

Microsoft's implementation of MFA is actually pretty nice and integrated.  We use it along with ADFS, so when I sign into web based services, I am asked for:

  1. My username
  2. My domain password
  3. The code that has been texted to my mobile device

Perfect, one thing known by a few people, one thing known to one, and one thing I need to have.

You can also see here that I can select to not use the MFA for 60 days.  This is actually a setting administrators can choose to allow or not.  However, not allowing it, the box still appears, so your users can click it all they want, they will be needing their mobile to sign in to any web services.  I really think if it isn't allowed by your administrator, the option should never be displayed, it just makes users think that something is broken.

When you first sign in after enabling MFA on an account, you will be prompted to enter or update your phone numbers used for account security.  This is actually pretty neat, and as you can see there are multiple methods of MFA available to your users.
 Additionally, you can see that there is a Mobile App for authentication, so if you have users who don't have text/SMS plans, you can advise that they use the mobile app.

Of course, there are some things that do not work with MFA at all.   Thick clients, OneDrive, Word/Excel/Outlook.   The answer for this are app passwords.   The implementation of MFA also prevents powershell access to your tenant, and app passwords do not work for PowerShell.

App passwords are also:
  1. all 16 characters
  2. all lower case alphabetical characters only
  3. can not be set to expire
  4. can not be individually managed by administrators

 They can be disabled entirely by administrators, but that rules out a lot of functionality for your MFA enabled users.

You can tell by the name, I was testing PowerShell access.  This is really the biggest downside of MFA in my opinion - the accounts you would want to protect the most, your elevated ones, you can enable MFA, but then they cannot do bulk edits in any of the online shells (MSOL, Azure AD, EXO, SPO, LYO)  and doubly worst, since Disabling MFA is something you cannot do to your own account, you either need to find another Global Admin to toggle this setting, or you need to have a "less secured" account for your bulk edits.  Maybe one that you enable/disable as needed would be the best security practice there?  I'd prefer they made app passwords work for PowerShell but require that you input allowed IP ranges for PowerShell connections.  A lofty request I am sure.

As shown above, the "Name" of your app password means nothing and is entirely for users to label/remember where they used it.  Also, Admin's can't "reset" an app password, the user needs to self manage these.

The "copy password to clipboard" dialog really surprised me.  In a world where tinyurl, imgur and other sites have this integrated, Microsoft has opted to deliver this via JavaScript pop up, forcing you to click once, Hit Ctrl-C then click to close the dialog.  It's less effort to highlight and Ctrl-C.

In all, the MFA implementation at this point works pretty well for users, but can introduce more security related helpdesk tickets with the way app passwords are implemented.  And for Admin accounts MFA is fairly useless.  Most things I need to do I do in PowerShell.  Also, if you work for a very tightly secured organization, the lack of app password manageability or oversight could prevent your InfoSec team from allowing you to use it.

Thursday, December 04, 2014

Lync Online PowerShell issues and solutions

So, I was asked to implement the fixes documented in Christian Burke's blog entry, SOLVED: Online Meeting Icon Missing from OWA in Exchange Online - which is a fairly complex and PowerShell heavy blog - he makes use of Lync Online PowerShell, Lync On premises PowerShell, and MSOL PowerShell(Microsoft Online Azure PowerShell)

I didn't think it would be, but the most complex part of completing the tasks on that blog was getting me connected to our Lync Online PowerShell!

Issue #1 - when running the New-CsOnlineSession, you are prompted for a TargetServer
You installed Lync on premise tools since you installed Lync Online.   Uninstall and reinstall the Lync Online Powershell.  See KB2955287.

Issue #2 - when running New-CsOnlineSession, you are getting "Unable to discover Powershell endpoing URI"  (Yes, the error has endpoint spelled incorrectly)
Your Lync autodiscover record is either pointed to on premise or non-existant.  If it is pointed to your on premise, you need to use -OverrideAdminDomain and specify your tenant domain.

Issue #3 - when running New-CsOnlineSession, you are getting errors like "Get-CsWebTicket : Arithmetic operation resulted in an overflow." or "Get-CsWebTicket : Failed to logon with given credentials" when you know your credentials are correct.

This one took a while.  I had MFA enabled and enforced on my account.  Apparently this will prevent me from using PowerShell.  Workaround is to utilize app passwords, or disable MFA to connect to PowerShell.

More on App Passwords in my next article "Azure AD, Multi Factor Authentication and App Passwords"

I'll post up any more as I find them, but these three hopefully will help some of you!

Tuesday, November 11, 2014

Updating Azure Active Directory Powershell

If you have been using Office 365 for any period of time, you may be familiar with seeing this error:

WARNING:  There is a newer version of the Microsoft Online Services Module.  Your current version will still work as expected, however the latest version can be downloaded at:

Thankfully, Microsoft updated their page to help show you what version you have and how to update this.

Here's the URL:

If you run the following command you can see the currently installed version:
(get-item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion

In order to update this, you need to uninstall the existing version.  If you have had this installed for a long time, you may also need to uninstall and reinstall the latest versions of these:
Hope this helps!  As of this posting, the current version is reporting 1.0.8073.4

Thursday, November 06, 2014

Using Regular Expressions in Exchange Transport rules

I was recently tasked with creating a Transport Rule that fired if an email's subject line "started with" a string.   Unfortunately, this is not an option in the GUI or powershell with Exchange 2013 or Exchange Online, but you can use regular expressions.

First, here's the link of the different Transport Rule Conditions:

If you scan the Description column for "that match the specified regular expression" you will see that many different Transport conditions can use these.

I did some searching, and found this older Exchange 2010 document that details the RegEx support here:

(And just in case, I will copy paste it at the bottom of this post as well)

So my customer's rule was very simple:
Choosing a subject matching ^## would select any subject that begun with ##

If you are interested in configuring Message Encryption, it requires Azure RMS licensing, and then following these two articles:

Another really good example of a usage for regex is to match on something like a SS# pattern and block transmitting external to the organization using something like:
If subject or body matches \d\d\d-\d\d-\d\d\d\d

Pattern matching in Exchange Transport Rules

Pattern string Description
\S The \S pattern string matches any single character that's not a space.
\s The \s pattern string matches any single white-space character.
\D The \D pattern string matches any non-numeric digit.
\d The \d pattern string matches any single numeric digit.
\w The \w pattern string matches any single Unicode character categorized as a letter or decimal digit.
\W The \W pattern string matches any single Unicode character not categorized as a letter or a decimal digit.
| The pipe ( | ) character performs an OR function.
* The asterisk ( * ) character matches zero or more instances of the previous character. For example, ab*c matches the following strings: ac, abc, abbbbc.
( ) Parentheses act as grouping delimiters. For example, a(bc)* matches the following strings: a, abc, abcbc, abcbcbc, and so on.
\ A backslash is used as an escaping character before a special character. Special characters are characters used in pattern strings:
  • Backslash ( \ )
  • Pipe ( | )
  • Asterisk ( * )
  • Opening parenthesis ( ( )
  • Closing parenthesis ( ) )
  • Caret ( ^ )
  • Dollar sign ( $ )
For example, if you want to match a string that contains (525), you would type \(525\).
^ The caret ( ^ ) character indicates that the pattern string that follows the caret must exist at the start of the text string being matched.
For example, ^fred@contoso matches and but not
$ The dollar sign ( $ ) character indicates that the preceding pattern string must exist at the end of the text string being matched.
For example,$ matches and, but doesn't match