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.

• Documentation
• Announcement (2013) - Released
• Announcement (2014) - Added to many Office 365 plans
• MSExchange.org three part series on configuring and deploying

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.

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.  
4/20/2015 Update:  App Passwords worked for a very short window for this purpose.  Accounts with MFA enabled will need MFA disabled to use 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!
Chris

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: https://portal.microsoftonline.com.

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

Here's the URL:  http://technet.microsoft.com/en-us/library/jj151815.aspx#bkmk_installmodule

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:

• Microsoft Online Services Sign in Assistant
• Azure Active Directory Module for Powershell 

Hope this helps!  As of this posting, the current version is reporting 1.0.8073.4

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:
http://technet.microsoft.com/en-us/library/jj919235%28v=exchg.150%29.aspx

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:
http://msdn.microsoft.com/en-us/office/aa997187%28v=exchg.149%29

(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:

• Set up Microsoft Azure Rights Management for Office 365 Message Encryption 
• Define rules to encrypt or decrypt email messages

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 [email protected] and [email protected] but not [email protected].
$	The dollar sign ( $ ) character indicates that the preceding pattern string must exist at the end of the text string being matched. For example, contoso.com$ matches [email protected] and [email protected], but doesn't match [email protected]

Managing Office 365 Cloud changes

With some of the recent releases of new functionality in the cloud, many customers are finding themselves scrambling to document the new functionality for their end users, or find ways of disabling it until they can communicate, train, and document the new features.

In the past few months, Office 365 Groups was deployed for all Office 365 tenants, and the new Delve feature is available in preview as well.

First, I want to cover the Service Settings -> Updates section.  This allows you to enable or disable previewing new features.  This impacts all users in your tenant!  This allows you to control if your users will see new features first, or when they come out of preview mode.

One nice thing about First Release is that you do get to see and work with the newest features, but it also means your users will see new features "light up" immediately, meaning you won't have much time to document and instruct them on using it.

Of course, with First Release off, you won't prevent the new features from coming, but you will have more opportunity to read up on the feature and gain some intelligence on how other organizations are using them effectively.  The BEST place to read for this is the Office team blog at http://blogs.office.com

UPDATE (5/21/2015) As of May 2015, there is now an option that allows administrators to select first release not only for the entire organization, but for select users as well.

Another question I am constantly helping customers with is "what kind of data goes in an Office 365 group versus a distribution group versus a Lync persistent chat versus an Exchange Public Folder" - the answers here depend greatly on what licensing and resources you have and what kind of business process you already have developed, but I have found this link on Office 365 Collaboration to be very helpful for customers trying to find the right place for their data.


Recently released features and how to control them:

Delve

Microsoft Delve has a TechNet article on administering it - Delve is based on Office Graph, a new SharePoint function that collects data from Exchange, SharePoint and OneDrive to display data that is most relevant to your users in one place.  It uses machine learning to build and learn what content your users share and who they share it with to display documents, files, posts and content relevant to your users' workflows.

Instantly turn off Delve and the Office graph
You can instantly turn off access to the Office graph and remove Delve from the Office 365 global navigation.

1. Sign in to Office 365 with a global admin account.
   
2. Choose Admin > SharePoint. You’re now in the SharePoint admin center.
   
3. Choose Settings.
   
4. Under Office graph, select Don’t allow access to the Office graph.
   

Office 365 Groups  (updated 4/14/2015)

Currently there is not a way to completely remove Office 365 Groups, but you can prevent usage and creation of them until a time arrives that your organization is ready to deploy them and have had time to communicate and train business units on what content belongs in a group.

Tony Redmond has a great article covering Office 365 groups here, and so far it has the most detail of any article I have read.  Blocking Office 365 groups is done using OWA policy and the –GroupCreationEnabled attribute set to $false.   I would recommend setting your default OWA policy to $false, and then testing and training with groups with a pilot group of users with a separate OWA policy with this setting set to $true.   However, keep in mind, we are only blocking group CREATION.  So once a pilot user creates a group, all users with permissions in that group could participate in using the group.

In February 2015, Microsoft released the White Paper "An End-to-end Experience with Groups" - recommended read before deploying groups so you understand how the program expects people to utilize them!

Exchange Online Inbox Clutter  (updated 11/19/2014)

Microsoft unvailed Clutter this week to first release customers as an additional way for Outlook Web Access (OWA) users to help control their inboxes better.   There is not currently any way to control this administratively, it is a per user mailbox view setting.   Microsoft is also in the process of updating the "options" dialogs, but the below screenshot shows how a user may enable or disable this feature today.  By default, Clutter is disabled.  Tony Redmond has a great clutter FAQ.

Office 365 Video (Added on 11/20/2014)

Office 365 Video was introduced on 11/20/2014 on the Office Blog.  They had this administrative guide published on day one, and from it, we learn how to disable this feature as well.  For now, Office 365 video is only available if you have First Release enabled in your tenant.

To disable Office 365 Video

1. Sign in to Office 365 with your SharePoint Online admin account.
   
2. Go to the SharePoint admin center.
   
3. In the left navigation pane, select settings.
   
4. In the Streaming Video Service section, select Disable streaming video through Azure Media Services and disable the Video Portal.
   Note   While this change is propagated through the system, the Video link on the Office 365 top navigation bar or the Video icon in the Office 365app launcher might still be visible. Even while the link or icon is still visible, no one in your organization will be able to use Office 365 Video.

Outlook App for iOS and Android (Added on 2/4/2015)

Microsoft announced on 1/29/2015 that the Outlook application was coming to Apple iOS and Android devices as the rebranded Accompli application from their acquisition late last year.  The application is very slick and well done, but was immediately met with some resistance from infosec bloggers.

Thankfully, there are ways to prevent this client from being used - much thanks to Paul Cunningham for his post on this.

To block the Outlook for iOS and Android app in Office 365, Exchange Server 2010 or 2013:

[PS] C:\>New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

To quarantine instead:

[PS] C:\>New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Quarantine

Devices should now appear as blocked or quarantined with the reason of “DeviceRule”.

[PS] C:\>Get-MobileDevice -Mailbox alex.heyne | fl FriendlName,Device*,Client*,Is*


DeviceId                : 94B42B2A37D109AE
DeviceImei              :
DeviceMobileOperator    :
DeviceOS                : Outlook for iOS and Android 1.0
DeviceOSLanguage        :
DeviceTelephoneNumber   :
DeviceType              : Outlook
DeviceUserAgent         : Outlook-iOS-Android/1.0
DeviceModel             : Outlook for iOS and Android
DeviceAccessState       : Blocked
DeviceAccessStateReason : DeviceRule
DeviceAccessControlRule : Outlook for iOS and Android (DeviceModel)
ClientVersion           : 14.1
ClientType              : EAS
IsManaged               : False
IsCompliant             : False
IsDisabled              : False

And, if you already had users get their app installed and configured, the easy way to remove them all would be:

Get-MobileDevice | where { $_.deviceos -match "outlook for ios" } | remove-MobileDevice 

Skype for Business (Added on 4/21/2015) 
Lync 2013 renamed to Skype for Business and deployed it as a Windows Update.  Both Lync Server Administrators and Lync Online Administrators have a way to control this using Client Policy as documented by the team blog here.  
Since this is an Office 365 only article, I will focus on the Lync Online options.

Once you’re logged into the online service via PowerShell, you can use Grant-CsClientPolicy Cmdlet as shown below, to control the experience:
Disable Skype user interface (UI) for all users:

Grant-CsClientPolicy -PolicyName ClientPolicyDisableSkypeUI

Enable Skype UI for all users:

Grant-CsClientPolicy -PolicyName ClientPolicyEnableSkypeUI

These Cmdlets will control the UI presented to all users in your Office 365 or Lync Online tenant. There are more options for controlling the experience at an individual user or group level on TechNet.
  
Microsoft Garage Applications
#Send Application for iOS (Added on 7/23/2015)
Microsoft announced a new email integrated application for iOS (in case the native app, Outlook and OWA apps were not enough) This app is similar to SMS messaging, but is email based, but without subject lines.  It utilizes Exchange EWS for connectivity and it DOES NOT obey ActiveSync policies, so it may be of concern to security administrators to lock this down or prevent usage of this application.  Thanks to Paul Cunningham, here's how to block #Send from use in your Office 365 Organization (or On premises, I suppose)

At an organization level:

PS C:\> Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceBlockList

PS C:\> Set-OrganizationConfig -EwsBlockList @{add="MicrosoftSend/*"}

At a user level:

PS C:\> Set-CasMailbox Alan.Reid -EwsApplicationAccessPolicy EnforceBlockList

PS C:\> Set-CasMailbox Alan.Reid -EwsBlockList @{add="MicrosoftSend/*"} 

Groups Application for iOS (Added on 9/24/2015)
This application to connect to and participate with Office 365 groups was announced and can be blocked similarly to the Send application using EWSBlockLists.  The User Agent for Groups is:

Groupies/1.5 (iPhone; iOS 9.0; Scale/2.00)

So same as above, but "Groupies/*"   

Invite Application for iOS (added on 9/24/2015)
The Invite application was announced on 9/24 and allows users to schedule and manage meetings within the application.   I am hoping this is EWS based as well, but it doesn't work when I use a proxy.  

The user agent appears to be:
Invite/44 CFNetwork/758.0.2 Darwin/15.0.0 

So same as above but "Invite/*"

It also has an ominous security warning that it needs additional permissions (more than other Garage apps that you could argue access the same data)

Multi Organization O365 migrations - SMTP routing and Criteria Based Routing

When migrating three disparate email organizations into a single Office 365 tenant, one of the major hurdles in this was ensuring that once we have the first organization (CompanyA.com) migrated, the tenant is essentially in production, and while we are planning on turning up and licensing users for the next organization (CompanyB.com), we realized the problems this would cause.

The second organization is large.  Very large.  So we need to pre-stage data into mailboxes that could take days or even weeks.

The SMTP routing issue presented

If users from CompanyA.com were to attempt to email CompanyB.com, the messages would deliver to their mailbox in the tenant.   The same will be true when CompanyA.com and CompanyB.com are in production and CompanyC.com is pre-staging

We considered blanking out the mail attribute in AD to avoid this and just pre-stage to their tenant email address (companyABC.onmicrosoft.com) but too many other AD integrated applications relied on that field so that was not an option.

We began looking around in DirSync filtering for ways to blank the mail attribute by pairing it to an unused AD attribute in Active Directory.  This is NOT AT ALL recommended.

From Configuring Filtering for Directory Synchronization:

Microsoft does not support modification or operation of the Directory Sync tool outside of those actions formally documented.  The actions documented below in this article are supported. 

Unsupported actions include:

• Opening the underlying FIM Sync Engine to modify Connector configuration  
• Manually controlling the frequency and/or ordering of Synchronization Run Profiles or changing the attributes that are synchronized to the cloud. 

Any of these actions may result in an inconsistent or unsupported state of the Directory Sync tool and as a result, Microsoft cannot provide technical support for such deployments / usage of the tool.

Filtering configurations applied to your directory synchronization instance aren’t saved when you install or upgrade to a newer version. If you are upgrading to a newer version of directory synchronization, you must re-apply filtering configurations after you upgrade, but before you run the first synchronization cycle.

That seems like very clear and strong language.  It's not supported, and if you change anything it might also break if and when you patch DirSync.

So without putting the customer in an unsupported space, how can we address the presenting mail routing issue? 

Enter Criteria Based Routing!

Scenario: Conditional Mail Routing

Two basic steps here:

1. Create an Outbound Connector for the CompanyB.com domain
1. On the Delivery section, specify "Route mail through smart hosts" and manually enter the existing MX records for the CompanyB.com domain
2. On the "Scope" section, select "Use for Criteria Based Routing (CBR)"
2. Create a Transport Rule
1. Apply this rule if: The recipient is.. located inside the organization
2. And: A recipient's domain is.. companyb.com
3. Use the following outbound connector.. Select the connector created in Step 1

That's it.  Now you can license mailboxes with their correct SMTP addresses, pre-stage data, and they will NOT receive any SMTP traffic until you disable or remove the connector and the rule.  Which in addition is a much easier cutover day task than to be changing users or DirSync configurations en masse.

Hope this helps you, please post if it does!

Update 3/30/2015
This procedure only works if the domain name you are configuring the rule for is in the mailbox's PRIMARY SMTP address.   If it is a secondary SMTP address, the rule won't fire, as when someone checks names, it will default to their primary.

Exchange Online Shared Mailboxes - Licensing, quota and compliance

Like all things cloud, things change.  This was based on September 2014 data and findings.

Writing today about shared mailboxes as a customer recently had several requirements and in reviewing the service description, I have found some inconsistent information.

Exchange Online Service Description - Exchange Online Limits

And here's the current text of the footnote:

A user must have an Exchange Online license in order to access a shared mailbox. Shared mailboxes don’t require a separate license. However, if you want to enable In-Place Archive for a shared mailbox, you must assign an Exchange Online Plan 1 or Exchange Online Plan 2 license to the mailbox. If you want to enable In-Place Hold for a shared mailbox, you must assign an Exchange Online Plan 2 license to the mailbox. After a license is assigned to a shared mailbox, the mailbox size will increase to that of the licensed plan.

So for the purpose of this blog, I am going to focus on three issues:

1. How large can a shared mailbox (no license) be?
2. Can you put shared mailboxes into litigation hold or in-place hold?
3. If you needed >10GB mailboxes or in place hold, how would you assign a license? 

How large can a shared mailbox (no license) be?

I created a shared mailbox and did a get-mailbox and see the prohibit send and receive is at 50GB

So, either the service description is incorrect, or PowerShell's quota reporting of space is incorrect.

So, I started stuffing the shared mailbox.  I have a pretty nice home PC.  SSD, 32GB RAM, etc.  I'd say around 5GB, using Outlook 2013 with all current patches, a shared mailbox became pretty slow and difficult to work with, even in OWA and Outlook 2013.

Can you put shared mailboxes into litigation hold or in-place hold? 
Based on the service description, you need a license for both litigation hold or in-place hold.  
Here's the GUI versus powershell of my in place hold.  You can see that in shell it shows there are no sourcemailboxes but the GUI shows I have an in place hold.  Confusing and very misleading.

According to the shared mailbox screen, it is under in-place hold

And my test eDiscovery with in place hold seems to be capturing data:

 And the preview shows my data!

What about litigation hold?   Well, that allows me to set it:

But can we trust it?  Is it really holding data?  The answer is yes.  Here's a trimmed screenshot of a prior test (not the same as the in-place hold) that captured data.  Even better, this mailbox was deleted, so this also proves that it is in litigation hold since the mailbox is no longer enabled, we know we are not searching an active mailbox.

If you needed >10GB mailboxes or in place hold, how would you assign a license? 

According to the Service Description, if you need in place hold or larger than 10GB shared mailboxes, you need to assign an Exchange Online Plan 1 or Plan 2 license to the mailbox.

However, since the mailbox is shared, you cannot assign a license to it.

So I opened a quick case asking "how do I apply a license to a shared mailbox?"

Their answer was simple - you need to convert the mailbox to a user mailbox.

Once converted, you can assign a license.   However, one may argue or be concerned on the points this brings up:

• This is no longer a shared mailbox, but is a user mailbox that is shared, it now has a username and password (and the password assigned is not very complex if a cloud only account (@tenant.onmicrosoft.com) 
• This is now a cloud only account, if you run DirSync or had a security requirement that all accounts be sourced in AD, this would not be within that policy, or subject to any policies your authentication solution might enforce.  If you had a Hybrid environment, you could convert and move the shared user mailbox to on premise, or just create your shared mailboxes on premise
• Licensing does not appear to be required to have in-place or litigation hold enabled 

UPDATE 10/1/2014: Thanks to Nino Bilic for pointing out, you ABSOLUTELY can license a shared mailbox.  In O365 Users, search for it, and add a country and license.  He also advises that while quota and hold status may be working without a license, you should license them, in case Microsoft decides to enforce licensing, it could put you in a state of non compliance or over the size limit shared mailboxes!

UPDATE 10/8/2014: Another nod to Nino - In this article, Microsoft addresses Exchange Online licensing required and explicitly mentions Litigation Hold as WELL as in place hold require an Exchange plan 2 license!
Manage inactive mailboxes in Exchange Online

In closing..

1. Quota, litigation and in-place hold all function as expected on shared mailboxes without a license, however this could change and be enforced at any given time, so obviously recommend using licensing if the functionality is needed.
2. Litigation and in-place hold are completely enabled for shared mailboxes, regardless of the licensing section of the Service Description
3. Licensing a shared mailbox can be performed by converting them to a user mailbox or by assigning a license to the shared mailbox MSOLUser as documented above

Exchange Online and a Connection Filter limitation

Ran into a situation the other day where I was inputting Whitelisted IP's from a customer's current mail hygiene solution, and EOP would not let me input a /20 network into the dialog.  I double checked the IP/subnet was correct, the periods were really periods, and no whitespace characters in my input.  No go.   Turns out I hit a fun limitation of the connection filter.  Not sure why they would have this limitation, but here is the documented limit and a workaround (if you use Exchange Online - if you are an EOP only customer, I am not currently aware of a workaround)

From here: http://technet.microsoft.com/en-us/library/jj200718%28v=exchg.150%29.aspx
"You can specify a maximum of 1273 entries, where an entry is either a single IP address or a CIDR range of IP addresses from /24 to /32."

So that's the limitation.  Luckily, this customer is using Exchange Online, which allows you to also use Transport Rules that can then cover a larger subnet and bypass spam filtering for connections from that IP:

http://technet.microsoft.com/en-us/library/jj200718%28v=exchg.150%29.aspx#bkmk_addtionalconsiderationswhenconfiguringipallowlists

Lync Key Health Indicators (KHI) summarization

"Necessity is the mother of all invention."

Lync Call Quality Methodology is a great way to inspect your environment and find areas in need of improvement and troubleshoot end user reported problems better.  However the first portion of the methodology is collecting KHI's or Key Health Indicator reports from performance monitor.  I've found this article at Flinchbot to be pretty helpful in deploying the KHI's as well as triggering the stop and start of log collection.  But then the very manual process of collecting average and maximum values from multiple servers and days.

So I wrote this little thing in Excel.  If you find errors, let me know, I won't claim to be a programmer, so this is free and completely at your own risk.  I tried to make it simple.

1. Name your CSV's something like "Server - Date.csv"  Each file will be a new tab.
2. Edit the xlsm document with the folder where your CSV's are stored (E14)
3. Click "Summarize KHI CSVs"
4. Wait a bit.   Some of these files are large and the operation may make Excel hang or seem unresponsive for a bit.  I promise, I couldn't code a virus to save my life.
5. The output provides each counter with the Average and Max value, one sheet in the workbook per CSV provided.

Sample of interface:

Sample of Output





Download from Technet Here

Demonstration Video
Excuse the interface, I prettied it up before posting it!