During a routine update of an Exchange server, a client of mine had an issue with a Security Update for Exchange 2013 CU12. This patch, KB3184736, showed Status – Failed in the Windows Update History. After the install failed, Exchange Admin Console would not load, the Exchange Management Shell also could not connect to Exchange server, and then they noticed that all of the Exchange servers were not started.
In order to fix the same server, they then tried to update their server to CU16. When the CU16 installation complained about the .NET version, they upgraded .NET to 4.6.2. The CU16 upgrade was tried again and it failed.
Then I was called in to assist. We reviewed the situation and decided to move forward with the Exchange CU16 installation. According to Microsoft, the ideal upgrade plan would have been:
- Upgrade Exchange 2013 CU12 to CU15
- Update .NET to 4.6.1
- Upgrade Exchange 2013 CU16
I just recently posted two new script to the TechNet Gallery. These scripts perform the simple function of installing either .NET 4.6.1 or .NET 4.6.2. There are quite a few prerequisites for these installations so I decided to write a script that would do this for you. It does require two reboots. Also included in the script is a way to check the current .NET version.
.NET 4.6.1 Script Menu
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:
A client approached me with a need for some mailbox statistics. They wanted a script or some sort of PowerShell code to examine a few mailbox details for a migration from one environment to another that was being processed with third party tools. The source environment was running Exchange Server 2010. This means PowerShell 2.0. Now, I’ve written code for Exchange since Exchange 2007 came out. However, I learned a valuable lesson for these scripts. Test in the same version of Exchange. Yes. Obvious. Maybe even Captain Obvious level here…. However, I didn’t have an Exchange 2010 server with actual verifiable data I could use in my example.
So what did I do? I used Exchange 2013. I had data. I had calendar items, tasks, you name it. The cmdlets I was using are the same for both versions. Well “same” has a different meaning in Exchange PowerShell. So what happened? Lot’s of red. Basically Exchange 2010 wasn’t able to use the same parameters and switches like 2010 did. So I ended up rewriting the script to run on both 2010 and 2013, which would then make it more versatile. The script was also validated to run on Exchange 2016 in a lab. Continue reading
When I run into something in PowerShell that draws my curiosity, I usually go down a rabbit hole to further my knowledge of whatever that is. Sometimes this means digging into the text from the HELP for Exchange PowerShell cmdlets. For example, a while back I wrote a script to examine the text for the word ‘Deprecated’ because I Wanted to see what cmdlets were supposed to be deprecated over time. While checking out new cmdlets for Exchange Online, I ran into some cmdlets HELP that seemed to be half-way written. For the synopsis, these cmdlets showed this:
My curiosity was peaked, what other cmdlets are missing information in them. In order to find these cmdlets, I used a script I had created for the ‘Deprecated’ word check – https://justaucguy.wordpress.com/2014/12/05/exchange-2013-and-deprecated-powershell-get-commands/. I simply removed these phrases ‘cmdlet will be removed in a future version of’ / ‘cmdlet has been deprecated’ and inserted this line instead ‘Provide the topic introduction here.’
As if there aren’t enough ways to enjoy reading about PowerShell on Exchange 2016, our book is now available via Amazon Kindle and Kobo! We had some missteps with or provider, but they quickly figured out a solution and now our book is available in more formats. So in case you need something to choose from, here is how you can purchase our book now:
PDF – Direct From the Authors
PaperBack – Direct From the Authors / Amazon / Barnes & Noble
Kindle – Amazon
Nook – Barnes & Noble
ePub – Apple iBook Store
Kobo – Direct from Kobo
If you purchase the book, thank you for your support. It certainly was fun to write this one with Dave. If you get a chance, take a look at his blog – Dave Stork’s IMHO.
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: