Using Group Policy to Manage Office 365 updates

Office 365 ProPlus deployments by default are configured to automatically update. This can be a good or bad thing depending on how you look at it. Good, because you are always current and up to date on the latest fixes and security updates from Microsoft. But bad for organizations that have an enterprise patching process that has testing and validation for patches and updates. These types of organizations need to have control to establish compatibility and support across many platforms.

There are several ways to manage updates in Office 365. During the deployment of Office 365 ProPlus you can configure the update settings the office deployment tool which modifies the XML file that is by the install process or you can simply skip that step and manage everything through Group Policy. In this post I will discuss how to use Group Policy to manage updates for your Office 365 deployments.

Getting Started…

Download the Office 2013 Administrative Template files (ADMX/ADML) and Office Customization Tool 

Once you have copied the Group Policy Administrative Template files into AD,  the policy settings will be located in the foloowing location in the Group Policy Managment Console:

Computer Configuration\Policies\Administrative Templates\Microsoft Office 2013 (Machine)\Updates

Some key settings to look at include:

Enable Automatic Updates – allows you to disable Office 365 from automatically updating. Be careful when using this option as you could miss out on security updates.

Update Path – This setting controls the source of where the Office 365ProPlus installs get their updates from. If this setting is not configured or left blank it will default to Microsoft’s CDN. If you have an internal source, such as network share, then you would include the path here.

Using Group Policy allows some flexible like applying patching sources for different groups of users, such as pilot users and production users. It also doesn’t require manual changes on each system and can make a change across multiple devices with 1 policy. Group Policy is useful when there are many deployment methods across your organizations but you want to manage the application without adding cumbersome deployment steps. If you decide to make a change later, update the Group Policy setting by using the Group Policy Management Console. The updated policy settings are automatically applied to Office 365 ProPlus, through the normal Group Policy update process.

SnapManager for Exchange fails to run scheduled snaps after running an upgrade to 6.0.4

Sometimes fixes & patches introduce another set of issues that will give way to another set of new patches and fixes.

In our case, it was our upgrade to SnapManager for Exchange( SME) 6.0.4 which had fixes to some bugs we were facing. Everything seemed to go real well, all the upgrades on the Exchange 2010 DAG member servers didn’t hiccup one bit. This was too good to be true, an upgrade of SME and no issues so far. I had my fingers crossed and was hoping for the best, maybe luck would be in our corner.

No Joy…

After completing the upgrade on all servers I needed to run a test of some exchange snaps. Got to make sure it works right? I first started out running manual snaps on all the databases on each node. Those worked great, No Problems.

So onward to the next test which was to kick off a scheduled snap of the DAG databases. After kicking off a scheduled snap through task scheduler the snaps failed to run. After some digging around and a few more tests, my co-worker discovered that there is bug when you upgrade to SME 6.0.4 which causes scheduled snaps to fail.

According to Netapp’s KB 649767 article it has to do the value “0” is not selectable in the “retain up-to-the-minute restorability” option in the GUI of this release like it was in previous releases.  When running the snaps through the GUI of SME 6.0.4 , you can manually enter the value “0” and the run the job immediately, backups will work. The issue occurs when SME creates a scheduled job; it creates the job with wrong parameter , it be should be NoUtmRestore if you don’t want to retain any transaction logs.


Getting Backups to work again…

To get scheduled backups to work again you will need to do one of 2 things:

  • Change the -RetainUTMDays and -RetainUTMBackups from something other than “0”. Changing the value to something other than “0” will retain your transaction logs for the specified value
  • If you don’t want to keep any transaction logs, manually modify the scheduled job and remove the -RetainUTMDays or -RetainUTMBackups parameters then replace with NoUtmRestore.
    • If you are running a DAG remember you will need to modify the scheduled job across all DAG members that have the scheduled job.


Using Custom Filters For Your Exchange Dynamic Distribution Groups

Dynamic Distribution groups are Distribution groups that dynamically add members into the group based on a certain set of filters and conditions, when an email is sent to the group. These are great for mass mailing a group of users that change can often and managing the group manually would be difficult to maintain.

Exchange offers 2 ways of creating these groups; you can use the EMC/ EAC or PowerShell. I have found that the majority of cases for Dynamic Distribution can be created using the EMC/EAC, which offers the following set of pre-canned filters and conditional.

  • IncludedRecipients
  • ConditionalCompany
  • ConditionalDepartment
  • ConditionalStateOrProvince
  • ConditionalCustomAttribute( 1–15)

There are times that this pre-canned list just doesn’t fit the bill. Let’s say you need a Dynamic Group that filters on users from a certain country or even a particular job title?  PowerShell to the rescue!

PowerShell offers the pre-canned filters as well as any of the account attributes that a user account would have, giving you a lot more freedom to create some customized Dynamic Distribution Group. Please note that you cannot combine pre-canned conditional filters and custom Recipient Filters in the same query.

For example, to create a Dynamic group for mailbox users only in a particular country and company, let’s say the US, use the following cmdlet:

New-DynamicDistributionGroup -Name "TestGroup" -Alias "TestGroup" -OrganizationalUnit "your/OU"-RecipientFilter {(RecipientType –eq  “UserMailbox”) -and (CountryOrRegion –eq “United States”) -and (Company –eq “mycompany”)}

If you have an existing group that you just need to modify to become custom use the Set-DynamicDistributionGroup cmdlet:

Set-DynamicDistributionGroup -Identity "TestGroup" -RecipientFilter {(RecipientType –eq  “UserMailbox”) -and (CountryOrRegion –eq “United States”) -and (Company –eq “mycompany”)}

Note that when creating your Dynamic Distribution Group using PowerShell you cannot combine pre-canned conditional filters and custom Recipient Filters. A list of all the available filterable properties  parameters can be found on TechNet’s site.

Exchange 2010 and Active Directory Operation Failed on DC errors

An annoying problem that I have seen since we upgraded to Exchange 2010 is when in the Exchange Management Console (EMC) , you are not able to perform certain tasks because a DC could not be contacted .The domain controller in the error is usually one that has been demoted from your environment but sometimes not.  The issues can also occur after recent changes to a DC, which causes the EMC to lose contact with the Domain Controller

When this particular scenario was first noticed , it puzzled us because the DC in question  was still  running and Exchange was able to discover it. We did all the typical AD and exchange troubleshooting steps, checked permissions, AD replication, etc., but none these steps fixed the issue, the tech was still not able to create accounts.  After some more digging around we later found out some FSMO roles were removed from that DC. Aha! A major change to the DC.

Common error messages may contain  “Active Directory operation failed on Dcxxxx” or “ LDAP server was unavailable”. When the problem occurs  you are not able to perform certain actions in the EMC, such as creating accounts, mailbox moves, basically any operation that requires contact with the DC.

 An example of an error is shown below:


So what’s the problem you ask?

The problem is a result of the Exchange Management Console caching the domain controller details in the MMC temp files. It caches the data but it’s not smart enough to update the data or locate another DC. To fix the issue you have to remove the MMC cache file from the users profile.

Use the following steps to clear the EMC MMC cache file:

1. Close the EMC if you have it open
2. Go to the User’s profile directory and delete the Exchange Management Console file.
3. File location can be found here:

      • C:\users\<specific user>\AppData\Roaming\Microsoft\MMC\Exchange Management Console


4. Reopen the EMC

See Microsoft KB article

Message restrictions on your Exchange groups preventing emails to be received?

A common problem I get support tickets on is distribution groups not receiving emails from non-Exchange systems. There can be various reason for this, but the first thing I do is check the mail flow settings for the group to determine if the group is restricted to only authenticated users.

When groups are created in Exchange 2010, the default settings are applied and off you go, ticket closed. What is often overlooked are the mail flow settings for the group. The mail flow settings control who can send to the group, which senders to reject messages from and require that all senders are authenticated. Typically this not an issue if you’re sending emails to the group in Outlook, but if you want to send emails to this group from outside of the Exchange system, you will want to make sure that this is not enabled. When the “require that all senders are authenticated”  is enabled it prevents any users that don’t have valid logon credentials in your organization from sending emails to this group. If you have servers in your environment that need to send emails to an Exchange group, you will want to disable this setting since that server is not authenticating. If the groups were created prior to Exchange 2010, this setting was not enabled by default therefore there were restrictions.

You can disable the setting by 2 ways, through Powershell or the Exchange Management Console (EMC).

To disable the setting in the EMC:

Go to the group properties in the EMC > Mail flow settings > clear the checkbox on “Require that all senders are authenticated”


To disable the setting in Powershell:

Set-DistributionGroup -Identity <DistributionGroupIdParameter> -RequireSenderAuthenticationEnabled $false


Check out some of my latest articles

As most of you know, I have started writing for IT knowledgebase. Check out some of  the articles and tell me what you think. 

Manage Calendar Sharing Permissions in Outlook Web App 2010

I often hear from users that they don’t like to use Outlook Web App  for email because they can’t see shared calendars.  I then inform the user that things have changed since the days of Exchange 2003. A nice added feature of Outlook Web App 2010( Outlook Web Access) is that you can use the Change Sharing Permissions within Outlook Web App to view the people you’ve shared your calendar with and the permissions they have. This also gives you the ability to stop sharing your calendar. Now you can’t use Outlook Web App  to give someone else permission to change your calendar, but you can use the Delegate Access feature in Outlook to give other people in your organization permission to make changes to your calendar and to respond to meeting requests on your behalf.

To Modify Calendar Sharing Permissions :

  1. In Outlook Web App, click Calendar in the Navigation Pane.
  2. Click Share on the Calendar toolbar.
  3. Click Change Sharing Permissions and then, in the Calendar dialog box, select the name of the calendar that you want to change sharing permissions for.
  4. Click the name of the person whose permissions you want to change.
  5. Click Edit and select the permissions you want.
  6. Click Save to save your change.

How to stop sharing a calendar:

If you want to stop sharing your calendar with someone:

  1. In Outlook Web App, click Calendar in the Navigation Pane.
  2. Click Share on the Calendar toolbar.
  3. Click Change Sharing Permissions and then, in the Calendar dialog box, select the name of the calendar that you want to stop sharing.
  4. Click the name of the person you want to stop sharing your calendar with to select it, and then click .
  5. Click Yes to confirm that you want to delete that person from the list, or click No to cancel.

So there you have it. Next time a user says they don’t like to use OWA because they can’t manage or see shared calendars you can let them know that’s not the case anymore.