This will be a rather short blog post.
With a lot of my clients connecting to cloud services I get to work with Hybrid configurations quite a bit. Typically setting up ADFS, Azure AD Connect and running the Exchange Hybrid wizard (if we are going to Exchange Online) are all relatively quick and generally the easiest part about the migration. It wasn’t always so.
So this particular blog article has to do with the Exchange Hybrid wizard and for the first time in a while I hit weird roadblock that stopped the Hybrid Wizard in its place. Now, the fix is very easy to put in place, but as you will read later, we will learn that the wizard looks for certain criteria from the certificate when it runs.
The error we received was that there was a valid certificate for the wizard to use. So, we checked the certificates installed on Exchange by running Get-ExchangeCertificate:
I simply cannot wait until Public Folders are gone. Increasingly over the years my customers have abandoned them for greener pastures. Yet, I still run into the occasional customer that has Public Folders and insists on moving them to Office 365. Moving folders to Office 365 is almost exactly the same as moving Public Folders to Exchange 2013 or 2016.
** Note ** This article refers to moving Legacy Public Folders which exist on Exchange Server 2010.
Recently I had a client that was existing in coexistence mode with Exchange 2010 and Exchange Online. The migration took a bit longer than planned with the migration of 1500 – 2000 mailboxes. At the end of the coexistence we needed to cutover Public Folder content to the cloud. We did this ONLY when ALL mailboxes were in Office 365. This is done to ensure no one loses access to the folders as an on premises mailbox cannot talk to Public Folders in Office 365.
The article to use when moving Public Folders to Office 365 is:
While performing a migration from Exchange 2007 to Office 365 using BitTitan Migration Wiz, a strange error was generated for each mailbox that was being migrated. The error message is cryptic at best – “The XML document ended unexpectedly”. That error looked like this in the wizard:
There are quite a few articles, blog posts, etc. out there on this issue:
BitTitan Support Doc
Microsoft Forum Post
However, none of these solve the problem. The solution in the end was to fix Exchange Performance counters. This solution was found due to errors located in the Application log, which led to a Microsoft Support Document
New-PerfCounters –definitionfilename “C:\Program Files\Microsoft\Exchange Server\V15\Setup\Perf\GlsPerformanceCounters.xml
After that, the migrations with BitTitan were able to get past this error.
Taking what we learned from the last blog post on the changing of Office 365 cmdlet we will now assemble a full fledge script that will reporting on these changes in a daily fashion. Where do we start? If we remember from the other post multiple connections to Office 365 will be required. Each of these connections connect to a different PowerShell URL. Would it be efficient to constantly have to enter credentials in order to connect to each individual service? Probably not. So, let’s start with that and work our way to building a script that will automate this process for us.
STEP ONE: Create Password file
In order to store the password for reference later, we’ll need to read in the password and store it securely using this methodology:
read-host -assecurestring | convertfrom-securestring | out-file C:\securestring.txt
Now we have our password stored in a secure file for later reference:
Microsoft’s cloud offering, Office 365, is in a constant state of flux. This state is driven by the amount of changed, additions and features that are made to the service. For customers, this state of change can be a bit bewildering, but Microsoft has provided some guidance on the changes with their Roadmap page for Office 365. This roadmap can be found here :
Notice the stages of feature releases. What you won’t see is PowerShell changes specifically declared. Just because the changes are not declared, does not mean the changes are not present. So how do we find those changes?
During what I thought would be a routine mailbox migration from Exchange 2010 to Office 365, some mailboxes refused to move to their new location in Exchange Online. Reviewing the Migration reports for the user, we noticed that there were error messages
Data migrated: 1.816 GB (1,950,176,027 bytes)
Migration rate: 0 B (0 bytes)
Error: MigrationMRSPermanentException: Error: An error occurred while updating a user object after the move operation. –> More than one ComponentShared mailboxes exist for this user. To prevent Primary mailbox from coexisting with ComponentShared mailbox, this MailUser cannot be converted into a Mailbox. Continue reading
Thinking of migrating to Office 365? Already migrated to the cloud? Think that because you’ve moved or are moving that there will be no maintenance required for your cloud infrastructure? Well, it’s mostly true. There are things that you can do to keep your environment running smooth now and in the future.
What needs upgrading? Active Directory Federation Server, Active Directory Federation Server Proxy, Directory Synchronization, Exchange and PowerShell.
- Active Directory Federation Server – version 2.0 was available for Windows 2008 R2. With Windows 2008 now entering its extended life phases, it is worth considering an upgrade from 2.0 to the 3.0 version included in Windows server 2013. This version is included in Windows 2012 R2 and should be done as a swing migration.