The power of PowerShell

To quote a colleague of mine:

“Be one with PowerShell”.

This statement holds near and dear to me.

Learning PowerShell has been a life changing skill, one which has paid many dividends. Having an understanding of PowerShell enables you to work with almost all of Microsoft’s services / products… and more importantly, understanding PowerShell lets you learn about a product quickly… it allows you to address problems at scale, on the spot, and get things done with relative ease.

There is practically a cmdlet for everything in the m365/o365 suite (except for intune, last time I checked). Therefore, understanding how to use get-help and Microsoft docs lets you administer things like Exchange Online, Skype for Business, SharePoint Online, and AzureAD with relative ease.

Product knowledge is without a doubt of great importance, understanding the fundamentals and principals behind the technology you’re administering is certainly helpful. Knowing where to look, though, is king. In the age of the cloud, where everything is fluid and changing — it’s not entirely about what you know at any given moment… rather… the value comes from what you can potentially know, how fast you find it, how quickly you can learn it and what skills you have to ACT on the findings.

PowerShell is the backbone of enablement, onboarding and administration.

Having been with one of most decorated Microsoft partners in the U.S. for nearly 3 years now, I’ve impacted some of the largest customers in the world. Having played a critical role on multiple projects has provided me insight into the things I’ve stated above. That is to say.. PowerShell is truly the great equalizer. Know it well. Know its inner workings and the world is yours.

Azure Learning Resources

This entry is mostly to provide myself and others a place to find links to content and training for Azure Architecture and Administration.

This list will grow and be updated. As of now, this is the list of online resources I have stumbled upon as I begin my journey towards obtaining the Azure Solutions Architect Expert certification.

As with all things, hands on experience and utilizing labs regularly is crucial to passing any Microsoft Exam.

Azure Code Samples:

Official Azure Documentation:

Microsoft Learn:

Azure Citadel – Labs and Workshops

Azure Hands on Labs

Official Microsoft Azure YouTube Channel

Official Microsoft Developer YouTube Channel

Download the Azure SDK’s for .NET, PowerShell, CLI and other languages

Official Github Repository for PowerShell Scripts

Azure REST API Browser

How To Get The Total Number of BadItems and Kind of BadItems for Failed Move Requests

A common bad practice when it comes to migrating mailboxes, is to set the badItem limit to 10, 20, 30, 40, 50 etc, and keep incrementing until Resume-MoveRequest finally works. When you do this, you’re blindly accepting large data loss, without knowing exactly what kind of items are corrupt or the total amount beforehand.

Here is a simple way of determining the total number of corrupt / bad items a mailbox move request has encountered, and exactly what type/kind the bad items are. In order to utilize this guide, you will need to connect to Exchange Online PowerShell if you’re moving the mailbox to o365, or use the on premises Exchange Management Console if you migrating on premises.

Before we start I will provide you with a basic summary of what we’re doing to accomplish this task. We are going going to take the MoveRequestStatistics of the mailbox and export that data to XML. Doing this supplies us with a number of details that are not prevalent within the standard -IncludReport switch. Once we have exported the data to XML, we will import it back into powershell and store it in a variable, which we will access using dot notation.

Step 1. Connect to Exchange Online Powershell OR open Exchange Management Console.

Step 2. Export the MoveRequestStatistics Report to XML:
Get-MoveRequestStatistics -Identity -IncludeReport | Export-CliXML C:\Location\of\YourChoice\FileNameGoesHere.xml

Step 3. Import the XML data and store it in a variable:
$BadItems = Import-CliXML C:\Location\of\YourChoice\FileNameGoesHere.xml

Step 4. Review the total number of items and the kind of items that are corrupt:
##(this is to get the total count)

$ (this is to view the kinds of bad items)

**Bonus** | Out-GridView
##(This will open a GUI explorer to review all of the bad items and their kinds.

Before we go on to step 5, I would like you to understand a few types of acceptable bad data… that would be Security Descriptors and Calendar Properties. Those tend to be the most common. Be careful not to accept actual corrupt items. Once you have determined the kinds of items are within scope of acceptable data loss.. move on to step 5.

Step 5. Increase the bad item limit to the total number you retrieved for the cmdlets above:
Set-MoveRequest -Identity -BadItemLimit 25

Step 6. Resume the move request (or set -CompleteAfter switch to $null, depending on your scenario)
Resume-MoveRequest -Identity


Set-MoveRequest -identity -CompleteAfter:$null