I recently worked with a client that we were working to move to Office 365. During the process we wanted to put in new Exchange 2016 servers which required upgrading the existing Exchange 2010 servers to a newer Update Rollup for Service Pack 3. Just trying to kick off an update resulted in an error:
Doing some research I was able to find out that PowerShell can reveal a series of Cmdlet Extensions, of which the Scripting Agent is one of. So running Get-CmdletExtensionAgent, we can reveal the current settings for these agents. On the client’s server, the Scripting Agent was enabled, as reported:
Dave Stork and I are currently producing a Monthly email Newsletter with practical PowerShell information in it. The April 2017 edition will provide useful links for learning PowerShell as well as provide a glimpse into the new PowerShell cmdlets that Microsoft has revealed in the past month. IF you like this sort of stuff and would like to receive a free Newsletter, please visit our website by clicking the link below:
Thanks for taking a look!
Sample section from the newsletter:
Microsoft recently announced and removed support for DirSync and Azure AD Sync. The upgrade path for these two is simply upgrading to Azure AD Connect. Depending on your version of software and even Windows OS, there are multiple paths that can be taken. Recently I was working with a client on upgrading their Azure AD Sync software which was installed on a Windows 2008 R2 server. Deciding that the Windows OS was also too old and support timeline was short. Also, because this was a smaller environment there was only a Windows 2012 R2 Domain Controller available.
While reviewing the event logs for the Azure AD Connect server, we noticed that there were a lot of DCOM errors. The EventID was 10016. With a bit of research I dug up an answer from a previous problem that I had had with a different issue.
In the past month, I’ve written a couple of articles on the changing cmdlets mix for the various Office 365 workloads. For the major workloads in Office 365, here is what I’ve noticed over the past two months:
** UPDATE 4/27/17 **
After writing this article, I started looking at other themes available on WordPress and decided that the ‘Zoren’ theme was more to my liking. , so you can ignore the original post and screenshot.
Over the next week or so I will be implementing a new look to the blog. After almost 5 years of working on the blog, I’ve decided to widen out the format a bit to give me more space to create content for my articles. It will also help me organize the sidebars of the blog, enabling the display of more links to helpful resources that are out there. The old theme is called Inove and the new one is called Andreas9. Here are the two themes side by side:
Obviously the one on the right will need some work to make it look better / be more useful, but that is the plan at the moment. As I said above, look for the change over the next week or so. Hopefully this won’t cause any issues while I test some formatting changes.
Thoughts On Exchange 2007, in 2007
I first cut my teeth on PowerShell way back when Exchange 2007 was introduced. Back then AutoDiscover had just been introduced and companies were using ISA Servers to secure connections to Exchange. I remember thinking about these two big changes that AutoDiscover was going to be a good thing, while PowerShell was going to drive some admins crazy. It’s really hard to remember that at one point of time, Microsoft was very focused on providing an awesome GUI (graphical) interface. Command line administration was playing second fiddle (or maybe third?). In 2007, Microsoft was pushing a new management interface, like UNIX and LINUX – command line. Black and white blinking screen. A language that required some bit of programming sense, but not requiring a full blown programmer to get good use of it. While the language was not as advanced as it is now, it was easier to use and learn than VBScript (IMHO).
Over the weekend, Microsoft quietly added a new set of PowerShell cmdlets to their Exchange Online PowerShell module. These cmdlets are designed to complement a feature that was included in Office 365’s Outlook on the Web client. The feature the PowerShell cmdlets affect is called ‘Sweep’ which provides web users of Exchange Online a way to help keep their Inbox clear and more manageable. Using the web client we can see the option is available in the toolbar above any emails present:
If you click on the sweep button, you have four options that appear as well as an option to check existing rules: