Earlier this week I posted an article on how to run the various Best Practices Analyzers (BPAs for short) on a single server. For this post we are going to take what we learned from that and apply it to multiple servers. The hardest part about this script is that the BPA cmdlets need to be run locally. That’s right, we cannot reference another server name from the cmdlets. Running cmdlets remotely adds a layer of complexity not only from the perspective of connecting to a remote server that may or may not allow that connection, but also how to process the reports locally and copy them to a central source to be utilized for a health check.
Step One: PowerShell Connection To Server – To Run BPA Locally
One of the important steps in creating this script is creating a connection to the server in order to run the BPAs locally. The reason is that the BPAs cannot be connected to remotely. In order to do this, we need to first get a valid set of credentials to use for authenticating with a remote server:
write-host "Enter a user name and password for a Domain Admin. " $Credentials = Get-Credential
If you like to obtain a paperback copy of our Practical PowerShell Exchange Server 2016 book, go ahead and check it out at our site. The book comes in the 8.5″x11″ format and at 472 total pages, it is a good size book. I think the larger format makes easier to work with and read and provides a good value for the price ($49.99).
Here are some sample photos I took of a copy I have at home:
In my day job as an IT consultant I do work outside of Exchange and end on projects that touch Active Directory, Identity Management, Office 365 and more. A lot of these projects require some sort of health check or simply a quick review of an environment before proceeding with any changes. The thought process is that if we can eliminate any issues at the beginning of a project, less issues will occur to cause problems during the project. As a part of these health checks, we can sometimes utilize built-in Best Practices Analyzers for various components on a server.
Why Is This Important?
Exchange really needs a healthy base to stand on. I once worked for a company where there constant infrastructure issues – storage going offline, Active Directory on the fritz, DNS issues, networking issues…. you name it. Exchange reacted badly to these problems. My boss would hound me that Exchange was ‘down again’. Well, of course its down if users can’t get to it or if storage is not available and databases are not mounted or networking is down and emails will not route. So having healthy infrastructure servers (such as Domain Controllers) is very important. Use a BPA to check these servers out will help determine the healthiness of the systems Exchange relies on.
The book is making its way around to different distribution points. The first distribution point is Apple’s iBooks. So if you like to read your books on your Apple device, pick up your copy of our book today:
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. Read more…