This post is about a recent migration of legacy public folders hosted on Exchange Server 2007 to modern public folders hosted on Exchange Server 2013.
A few weeks ago, Microsoft released Exchange 2016 to the public. By now, some of you will have had the chance to play with the latest member in the Exchange Server family and perhaps have formed an opinion on whether it’s something you are willing to consider upgrading to now, or after few more Cumulative Updates have been released.
Exchange Server 2016 has arrived and has been lauded as one of the most reliable releases of Exchange yet. In many ways, it’s an evolution of the core technologies built into Exchange Server 2010 – but the way it’s put together has been revolutionized, making deployment choices much more straightforward.
What’s new compared to Exchange 2010?
Exchange Server 2010 has been extremely popular and, for many, was the upgrade point from Exchange 2003. It revolutionized availability with Database Availability Groups and made it possible and practical to deploy site resilient Exchange with relative ease. Six years have passed since its original release, though, and in that time, Microsoft has learned a lot from running the world’s largest Exchange deployment inside Office 365.
Much is new under the hood, including a rearchitected Store engine and better automated availability checks, but some of the most interesting deployments include:
- A beautiful new Outlook Web App – renamed “Outlook on the web” providing near parity with the Outlook client, offline access and fantastic cross platform support, even on mobile devices.
Over the past two weeks, Microsoft has made a range of announcements around updates and new releases of Office, Office 365 and Exchange. The fact that Microsoft announces updates is hardly surprising. By now you should be used to the never-ending cascade of new features that are constantly dropped onto the market. A good way to keep track of what’s to come is the Office 365 Roadmap website.
Any seasoned Exchange administrator has at one time needed to deal with a massive storm of “reply all” emails circulating the organization. It’s a chaotic situation, and not much fun to deal with, although you may enjoy telling the story to friends for years afterward.
Email Group management is often a time consuming process. Exchange has two types of distribution groups, each with their pros and cons, and both out of the box may not be ideal for your organisation.
The normal Distribution List has been around for a long time. It's a group that has a list of members, however has adds, moves and changes that are normally manual. This can either be a time consuming process for people to manage each time when members of lists change, and leaves along with room for human error...
Dynamic Distribution Groups are the other type, that the automation covered by using rules, known as filters. The group will check these filters at the time of an email being sent to the group. This means that if someone's department changes, there is no need to make a change to the dynamic distribution group, and therefore causes much less of an administration burden.
For as long as Microsoft Exchange has existed, Outlook meeting corruption has been a consideration for those that rely on calendaring. Meeting corruption can appear in many forms. However, meeting corruption typically occurs when meetings disappear, when duplicate meetings appear or through other unusual anomalies that users may experience with an appointment. Microsoft continually makes strides toward eliminating calendaring issues through Outlook and Exchange updates, however, calendaring issues still persist. More importantly, it’s typically our organizational executives that see the most issues when their calendars are not functioning as expected.
So what can we do about this?
By: Adam Fowler - 8/13/2014 Exchange 2010 recently introduced a new feature called "cmdlet extension agents." These agents can be called when a cmdlet is running, and can also perform extra tasks as a part of the original cmdlet. Microsoft has a great article outlining what they do here. You can see which cmdlet extension agents are available by running this command in the Exchange Management Console (EMC):
Eventually all good things come to an end and that’s no exception to our 3rd party certificates that allow access to Outlook Web App and other web-based Exchange workloads such as Active Sync or Outlook. This article provides a step by step process on how to update your Exchange 2010 certificates from start to finish. This article also assumes we are using a DigiCert wildcard certificate. Most of this work can be pre-staged before the actual implementation and is highlighted below. With that, let’s begin!
Generate a CSR
Generating a CSR and making sure it has been well documented on multiple websites is the first step to obtaining an updated wildcard certificate for your Exchange 2010 environment. To ensure that your certificate has a private key refer to the “Using Shell to create a new Exchange Certificate” section in the TechNet article listed below for generating your CSR appropriately. http://technet.microsoft.com/en-us/library/dd351057(v=exchg.141).aspx#emc
Whether or not the private key should be exported depends on the application or the organization, and is a requirement for Exchange. The private key certificate is used so the 3rd party certificate can also be used across multiple Exchange servers. The certificate can also be used on the system or device that can authenticate external connections to ActiveSync, Outlook Web App or Outlook Anywhere. An example of this would be Threat Management Gateway (TMG), User Access Gateway (UAG) or a network based appliance. Be sure to investigate these requirements before the certificate updates on the Exchange server. This will need to be done in conjunction with the work below.
If you have ever been in a situation where you have lost a physical Exchange 2010 server from your DAG then this document is critical to your ability to recover this server. Examples of how this could occur are through OS corruption, accidental overwrite or a true datacenter disaster. Even if you haven’t been in this situation this article will provide the insight to what it takes to recover an Exchange server that had once been a beloved member of your Exchange 2010 DAG.
Just to set the stage, there are very specific steps to the recovery process beginning with a fresh server build. Before we can start building that new server there are some necessary steps to take and these are addressed next. Also, this document assumes that you are running Windows 2008 R2 and that you are recovering all Exchange server roles.