…. we interrupt this hiatus….
I will thank Microsoft later for this curve ball. As many of you might know, Exchange 201x only supported up to .NET 4.5.2. Recently 4.6.1 had been released and has even been added to the Windows Updates. If you are pulling updates automatically to your Exchange Servers (something I would never recommend), then you may want to consider changing that process. A .NET update on an Exchange Server is not something you just want to happen because if you are running Exchange 2013 CU12 and before or Exchange 2016 RTM / CU1, a .NET upgrade could bring you some potential headaches.
.NET 4.6.1 Support Added
Those headaches will hopefully go away with the new CU releases for Exchange Server 2013 and 2016. Exchange 2013 CU13 and Exchange 2016 CU2 now support .NET 4.6.1. The caveat is that you need to upgrade the Exchange Server FIRST and then you can update .NET to .4.6.1. If you attempt the reverse, then you will need to uninstall .NET 4.6.1. A fellow Exchange MVP and Exchange Master, Jeff Guillet has written a great article on that process and covers any pitfalls you may run into – here.
Join myself and another speaker from Microsoft as we present information on Exchange Server 2016 and Office 365. You can sign up for the meeting on my Meetup page for the user group. Just click on the Meetup icon below. Hope to see you there!
Wednesday August 31, 2016 6:00 PM
Aon Center / Microsoft Office
200 East Randolph Drive
Over the past few weeks I have churned out a few posts and in actuality I have a large backload of posts I want to get out. However, I need to turn my attention now to my other new project which is a book I am writing with a fellow Exchange MVP Dave Stork. We are currently collaborating on the book and are hoping to get it out in the months near the end of summer. However, as we are both busy professionals, timelines like this could slip. Hopefully I will be able to take a small break now and again to post something here, but my priority is getting this project completed in a timely manner. Thanks for understanding.
This script is in its infancy and I am releasing it as a 1.0 script. It is heavily based of my Exchange 2010 and 2013/2016 version of my Distribution Group Cleanup script. The script performs the same actions as my other scripts. The main difference is that this one requires more reconfiguration on your part, which I will go through in a bit, as well as it will connect to Office 365 and Exchange remotely to query message logs. In Office 365, PowerShell will query the Message Trace logs for the past 30 days (which I believe is the maximum that can be queried). Once the Exchange Server Message Tracking logs have been queried, any active groups will be combined onto one list.
In order to be successful in using this script there are some caveats that need to be spelled out:
- Use the script in a Hybrid environment
- Run from a preconfigured workstation (see below)
- A group in Office 365 cannot be tracked directly at this point
- Only groups that are synched from AD can be correctly worked with in this version of this script
- Dynamic Distribution Groups cannot be tracked yet
In the next version or two, there will be some accountability for groups that are solely in Office 365. There will also be an inclusion made for dynamic distribution groups, which are not yet included in the search at this point.
In the past I wrote a script that would cleanup Distribution Lists in Exchange 2010. My original post can be found HERE. In the newest version I’ve changed the ‘Get-TransportServer’ and replaced it with ‘Get-TransportService’ as Microsoft has deprecated ‘Get-TransportServer’ in Exchange 2013/2016. I’ve also cleaned up the code, put more comments in and added a variable table to make modifying this script a bit easier. Other than that it operates like the Exchange Server 2010 version of the script.
There will be an Office 365 version coming soon that will scan Office 365 as well as your Hybrid server for mail traffic to distribution lists. This script will also run the same sort of process of marking the CustomAttribute10 to keep track of active/inactive groups. Look for it this week.
Second, and more importantly, I have not added support for Dynamic Distribution groups. Only groups that can be found via ‘Get-DistributionGroup’ are included at this time. The plan is to add that feature, but is on the backburner until I get the Office 365 version of the script completed.
I just released v 1.11 of the script (originally released in Sept of 2013). The current updates include:
(1) Removing references for C++ cleanup that are no longer necessary *
(2) Removing Office 2010 Filter Packs from the default installation **
(3) Fixing some bugs
(4) Created logic for failed downloads – will even apply to all downloads
As you can see from the below screenshot, if the Office Filter Packs are not installed, no error message appears any more:
Created a check to prove the packs are not installed:
The script can be downloaded from the Gallery link on the right or from HERE.
As it seems I am always in the middle when stuff breaks. For this post I thought I would recall a couple of scenarios, the pain that followed as well as the solution that was found to fix the issue. Recently I was migrating clients from Exchange 2007. One was going to Office 365 and the other to Exchange 2013.
Client was on Exchange 2007 and moving in this case to Office 365. The first problem that we encountered was with profile redirection. The user population was heavily populated with Citrix users with Outlook 2007. Of the population of users, 85% were on Citrix. With test accounts on Citrix we were never able to get an existing profile or a new Outlook profile to connect to the new server.
After a mailbox was moved, Outlook would popup with an error that an Action failed as well as a box that showed the user name and the old Exchange 2007 server. First it was noticed that they did not have a proper AutoDiscover record internally. With that record created, a new profile in Citrix would connect the new Exchange 2013. However an existing profile would not.