Category Archives: PowerShell

Disable Exchange Online Remote PowerShell for users as a scheduled task

This PowerShell script can run unattended as a scheduled task and will enumerate the global administrators, then remove remote PowerShell access for any user who is not a global administrator.

#See Prerequisites section below to create these two certificate connection scripts below

Invoke-Expression -Command C:\scripts\connect-certificate.ps1

Invoke-Expression -Command C:\scripts\connect-azureadcertificate.ps1

$GlobalAdmins = Get-AzureADDirectoryRoleMember -ObjectId $(Get-AzureADDirectoryRole -filter “displayname eq ‘Global Administrator'”).ObjectID

$AllUsers = get-user -resultsize unlimited

$UserswithPowerShell = $AllUsers | where {$_.RemotePowerShellEnabled -eq $true}

$UsersWhoAreNotGlobalAdmins = $UserswithPowerShell | where {$_.userprincipalname -notin $GlobalAdmins.userprincipalname}

$counter = ($UsersWhoAreNotGlobalAdmins).count
$current = 1

if ($UsersWhoAreNotGlobalAdmins) {
write-host “Users who currently have remote powershell access” ($UserswithPowerShell).count
foreach ($user in $UsersWhoAreNotGlobalAdmins) {
write-host “Removing PowerShell access from user ” $current ” of ” $counter “(” $user.userprincipalname “)”
set-user -identity $user.userprincipalname -RemotePowerShellEnabled $false

#Optional, the next statement can also apply a authentication policy to block basic auth

#Set-User -identity $user.userprincipalname -AuthenticationPolicy “Block Basic Auth”
$current = $current + 1

}
}
else
{
write-host “there are no non-global admin users with PowerShell access”
}

Download the script (here).

Prerequisites: Create two Azure AD Applications (1) Exchange and (2) Azure AD

TIP: When creating the Scheduled Task,  the account must have the Logon as a service right assigned. Then the ‘action’ to start a program points to c:\windows\system32\windowspowershell\v1.0\powershell.exe
then the arguments are: -File “c:\scripts\scriptname.ps1”

PowerShell script to automatically heal non-deliverable emails (NDRs) as X500

One of the possible causes for a non-delivery report (NDR) is when a mail object in Exchange is moved or removed (Contact, Mailbox, MailUser, etc). When an object is moved, any internal user who had previously emailed that object will have a cached entry in their autocomplete cache that no longer matches up to what now exists. This happens because the autocomplete cache stores the value of the LegacyExchangeDN attribute of the original object before it is moved. When an object is moved, a new LegacyExchangeDN is created.

When sending a message, Outlook will check the Global Address List (GAL), and if it can’t find a match in the GAL, IMCEA encapsulation is used (Internet Mail Connector Encapsulated Addressing). An IMCEA encapsulated address looks like:

IMCEAEX-_O=CONTOSO_OU=First+20Administrative+20Group_cn=Recipients_cn=JDOE@contoso.com

So when an email is sent to the original cached object, an NDR will be sent back to the user containing a construct of the LegacyExchangeDN that it failed to reach, in a slightly different format:

A trailing “EX” at the end of IMCEAEX indicates that a non-SMTP address was encapsulated.

While a quick fix is to have the sender clear their autocomplete cache and re-send the message, a more automated solution is desirable when there are hundreds of potential senders who cached the old object.

I discovered a nifty PowerShell script (here) written by Michael England on 2/11/2013 that searches the Message Tracking Logs for NDRs, and then reconstructs the LegacyExchangeDN from the IMCEA format and adds that as an X500 proxy alias on the target recipient object (if it can be found). This works great in a scenario where the contact object was replaced by a Mailbox or MailUser object.

One of the things I appreciate about how he wrote this script is that when you run the script it reports what would be modified, then when you are ready to modify you just add the -Autoheal parameter to the end of the script. This way you can get an idea of what would be modified before it happens.

I had to modify Michael’s script because Microsoft changed the behavior of the LegacyExchangeDN value in Exchange 2010 SP1 Rollup 6 (released 10/27/2011) to add 3 random hex characters for uniqueness at the end of the LegacyExchangeDN. So when I attempted to use Michael’s script, it was not finding the destination object to add the X500 to it because the 3 random characters threw the search off. So I have posted a very minor change to an otherwise awesome script to strip the 3 characters when searching for the object to place the proxy alias on.

            Write-Host “looking for: ” $user.Substring(0,$user.Length-3)

            $user = $user.Substring(0,$user.Length-3)

 

I also made three separate copies, depending on the recipient object type (Mailbox, MailContact or MailUser).

You can download my slightly modified version of Michael’s script from the Microsoft Technet Gallery here.

https://gallery.technet.microsoft.com/Search-Message-Tracking-6be6d1b7

I left all original credit to Michael in the script, since I only slightly changed the code to strip the 3 random hex characters out, and made separate copies of the script to search for MailUser and MailContact since his script only searched for Mailboxes. I was stoked to discover this awesome script by Michael.

Also shout out to a different Michael, Michael de Rooij for an excellent blog article on this topic here: https://eightwone.com/2013/08/12/legacyexchangedn-attribute-myth/