What a great way to start off the new year…. an article on Office 365 and new regulations coming before mid-year 2018.
For my past two blog articles I’ve covered quite a bit of details on what Secure Score can offer you and your Office 365 tenant. What I wanted to do for this article is tie this in with the new and upcoming regulation called GDPR. GDRP stands for General Data Protection Regulation. The regulation initiative was passed by the EU in April of 2016 and it goes into effect on May 18, 2018. The regulation is not solely for companies in the EU, but is intended to protect personal data for people in the EU. This means that if you have customers in the EU or have dealings with the EU, GDPR will affect you.
Recently I had a customer who fell behind on their upgrades for Exchange 2013. The servers were running Exchange 2013 CU, which was released in May of 2014. The newest update was CU18 and required some work due to changes in .NET requirements over the past three years. With this upgrade scenario CU15 could be used as a bridge update, allowing us to traverse the gap for .NET versions, while still being supported.
At first I thought that this was a problem unique to Exchange 2013. Then a fellow MVP pointed out a change to the .NET support listed on Microsoft’s Exchange compatibility matrix. This led to research to find a more complete view of .NET requirements for all versions of Exchange. I was about to find this chart – HERE The chart looks like this:
During a migration with a client we ran the Hybrid Configuration Wizard, as is a usual process for a migration, we ran into an issue. The HCW validating the domain, using the required TXT record, and while federating the domain, the wizard got stuck on ‘Adding Federated Domain’, like so:
If you are looking for a script to help you install all the prerequisites for Exchange 2016 CU8 and above, I’ve just released my newest version, v1.12, of the script. Currently it is listed on the TechNet Gallery for download. Here is the new and updated menu for the script:
You can download the script by clicking on the image below:
But What About .NET 4.6.2?
Look for an updated version of the .NET 4.6.2 script for Exchange 2016 hopefully over the weekend.
THAT message. Yes THAT message. I received this for a bunch of mailboxes I was moving From Exchange 2010 to Exchange 2016. The complete error is confounding and does not make much sense:
So what is the solution? The error’s solution is rather simple. There is an existing move request for the mailbox being moved. The solution is to remove any move requests. However, if the move request exists in Exchange 2010 and we try to remove this request from Exchange 2016’s PowerShell interface we get this error: Continue reading
Upon finishing my last project and stopping to take a look back at the past year or so I’ve realized that most (90%+) involved Office 365. Quite a dramatic change from my previous rate of around 50%. I have worked on a couple of migrations over the past year that revealed that Outlook 2016 is quite a different animal than all of its predecessors. Specifically when it comes to Public Folders on Legacy Exchange 2010 servers which is the last Exchange Server version to support Public Folders with actual Public Folder databases.
In my most recent migration I had a customer that was moving from Exchange 2010 to Exchange 2016. In doing to we needed to configure coexistence for Public Folders. The reason is that with Public Folders, if a mailbox is on Exchange 2016, it can access Public Folders on Exchange 2016 AND Exchange 2010. However, a user with a mailbox on Exchange 2010 can only access Public Folders on Exchange 2010. This is due to the way that Microsoft has always proxied requests from a higher version to a lower version, but never in the reverse (exception now would be 2013/2016).
For the past 3 months I have been hard at work with a client migrating from Lotus Notes to Office 365. Most migrations present some challenges, when coming from a system other than Exchange and migrating users to Office 36, there are additional challenges that present itself. In order to make the migration go smoother and to keep your own sanity, PowerShell scripts are necessary. With this migration I have an assortment of scripts that I have users and help with Forwarders, Retention Policies, Licensing and more.
Scripts and Background
One of the issues with this type of migration is Free Busy sharing between Office 365 and Lotus Notes users. This requires a bit of a special setup as well as a third-party tool to handle the query traffic between users of both email systems. In this scenario we used the Quest Coexistence product to provide this. This entails a multi-tiered approach to mailboxes and mail objects in Office 365. The underlying function of free busy has a dependency on the SMTP domain of the user to query. So we have this in Office 365:
Office 365 Users – User have a domain of @cloud.domain.com
Lotus Notes Users – A contact with @lotus.domain.com is used to direct email to Lotus Notes