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.
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.
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.
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.
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.
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:
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.
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:
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”
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 :
In Outlook Web App, click Calendar in the Navigation Pane.
Click Share on the Calendar toolbar.
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.
Click the name of the person whose permissions you want to change.
Click Edit and select the permissions you want.
Click Save to save your change.
How to stop sharing a calendar:
If you want to stop sharing your calendar with someone:
In Outlook Web App, click Calendar in the Navigation Pane.
Click Share on the Calendar toolbar.
Click Change Sharing Permissions and then, in the Calendar dialog box, select the name of the calendar that you want to stop sharing.
Click the name of the person you want to stop sharing your calendar with to select it, and then click .
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.
Have you ever gotten a ticket requesting if a particular email sent was delivered ? Or did our trusty Administrative assistant need to make sure that everyone received the latest company memo she just sent?
Well, with Exchange 2010, mailbox users can now do their own delivery reports. Since we’ve upgraded to Exchange 2010 I refer all my users with tracking requests to use the new Delivery reports available for them in OWA. The Delivery Reports can be used to search and get delivery information about messages sent by you or sent to you. If you sent a message to five people, for example, you can check the status of the delivery of that message to each person. Delivery reports is only available in OWA and is not accessible using any version of the outlook client. Once a result is viewed a users has the option to send the report to any email address of they choose.
Another added bonus with this feature, it even tracks the message once it’s in the mailbox. For example, User A indicated that she sent an email to User B and User C, but only User B said he received the email. User C insisted they never received the email and there must be an issue with our Exchange servers. I assured them there was nothing wrong with the mail servers and there had to be a valid explanation as to why he was not receiving the email. I walked User A through on how to run a Delivery report on her email messages she sent to User B and User C. The results of her search not only confirmed that BOTH User B and User C received her email but it also showed that User C had moved the email to the deleted items folder. OH Snap!
How to run a Delivery Report:
To access Delivery reports you or the User must login to your Exchange 2010 OWA site with your required credentials
See All Options > Organize E-Mail
You can search for reports on messages you’ve sent by using the Search for messages I’ve sent to box.
You can use the Search for messages I’ve received from box to search for delivery information about messages someone has sent to you.
Once required fields are filled in and the results are found, you can double-click on a result to see more details.
Delivery reports are a nice added feature made available to users with Exchange 2010. I personally think that this is way better than sending those awful read receipts for internal emails, which generate even more unneeded traffic.
This post is dedicated to a few of our techs that will stay nameless to protect the innocent (or guilty) because it seems that they forget how to export mailboxes when they get a request to do one. Don’t worry, I still love you guys and I totally understand on forgetting how to do something if you don’t do it everyday. Repetition is key and when you don’t export mailboxes everyday it’s easy to forget.
So the next time you guys come to me and ask “Can I export a mailbox and if so, how do I do that?” , I will simply refer you to this post. I’m only going to post 2 of most commonly requested cmdlets, but for more detailed information on Managing Mailbox Import and Export Requests on Exchange 2010 visit Microsoft’s Technet here.
Mailbox exports can only be performed using EMS ( Exchange Management Shell), they cannot be exported using the EMC
To be able to export a mailbox one must have the Mailbox Import Export management role assigned to them or be added to the built-in Discovery Management Role Group in Exchange 2010.
You need to create a network shared folder to place the exports
The account running the export should have appropriate permissions to access to the network share to view the files when completed.
The Exchange Trusted Subsystem group should be granted read/write permission on the network share. Please note: If you don’t grant this permission, you’ll receive an error message stating that Exchange is unable to establish a connection to the target mailbox.
Log onto a system that has EMS installed
Type the following cmdlets or you can copy and paste directly from this post.
And there you have it! Mailbox exports aren’t painful at all. Like with any powershell cmdlets you can copy these cmdlets and save to a text file. When you need it again just simply modify the names then do a copy and paste directly to EMS.
Something that I get asked quite often from our techs is “can I set Userxx’s Out of Office message?”. Luckily with Exchange 2010, any tech or admin with the correct permissions can easily do that. There are 2 ways ; via the Exchange Control Panel( ECP) or through Powershell. I personally think it’s easier to do it through the shell but the ECP has it advantages too. For instance the ECP can be accessed on any web browser and if you’re configured correctly you can even access it outside of your internal company network.
If you’re like me and you like quick & easy then using Powershell maybe the method for you. To set the OOF using Powershell run the following commands.