Converting SMTP Proxy Addresses to Lowercase

Update: Be aware, this script has not been tested with SIP, X400 or other address types. I am working on an update to validate these scenarios, but in the meantime, proceed at your own risk with these address types.

I recently encountered a question in an online forum where someone asked for a script to convert all of their user’s email addresses to lower case values.  While this doesn’t affect the message delivery, it can have an impact on aesthetics when the address is displayed in an external recipient’s email client.  An Exchange Email Address Policy can do this to some degree, but I wanted to see how it could be done with PowerShell.

The challenge with a script like this is twofold:

  1. Email addresses (proxy addresses) are a multi-valued attribute, which can be tricky to work with.
  2. PowerShell is generally not case-sensitive, and therefore when we try to rename Mr. Gallalee’s email address in the screenshot below, we can see that it does not work:

WARNING: The command completed successfully but no settings of 'demolab.local/Users/Rob Gallalee' have been modified.

After a little bit of inspiration from a script written by Michael B Smith, I came up with the below:


$MailboxList = Get-Mailbox  -ResultSize unlimited

$MailboxList | % {

$LoweredList = @()
$RenamedList = @()

foreach ($Address in $_.EmailAddresses){
if ($Address.prefixstring -eq "SMTP"){
$RenamedList += $Address.smtpaddress + "TempRename"
$LoweredList += $Address.smtpaddress.ToLower()
}
}
Set-mailbox $_ -emailaddresses $RenamedList -EmailAddressPolicyEnabled $false
Set-mailbox $_ -emailaddresses $LoweredList

#Without this line the "Reply To" Address could be lost on recipients with more than one proxy address:
Set-mailbox $_ -PrimarySmtpAddress $_.PrimarySmtpAddress
}

This script works as follows:

  1. Puts all mailboxes into the $MailboxList variable.  If you don’t want all mailboxes,  edit the Get-Mailbox cmdlet as you see fit.
  2. Filters out X400 and other non-SMTP addresses.
  3. Creates an array called $RenamedList which stores each proxy address with “TempRename” appended to it (e.g. Rgallalee@demolab.localTempRename).
  4. Creates another array ($LoweredList) and use the “ToLower” method on each proxy address.
  5. Sets the proxy address for the user to the value of $RenamedList and then to $LoweredList.
    1. This is how we get around the case case insensitivity – name it to something else and then name it back.
  6. Step 4 and 5 don’t preserve the “Primary” / “Reply-To” address, so we set it back manually with the last line.

Note: This script turns off the email address policy for each user.

As always, feedback is welcome.

EDIT Dec 2018:
This is a similar approach, but for mailboxes migrated to Office 365. In this case, only the Primary SMTP addresses are targeted.

It may also be faster than the above, due to the fact we’re only operating against mailboxes that have uppercase (vs all of them).

Set-ADServerSettings -ViewEntireForest:$true

$TargetObjects = Get-RemoteMailbox -ResultSize Unlimited | Where {$_.PrimarySmtpAddress.ToLower() -cne $_.PrimarySmtpAddress}

Write-Host $TargetObjects.count "Remote mailboxes have one or more uppercase characters." -ForegroundColor Cyan

#Backup First
Function Get-FileFriendlyDate {Get-Date -format ddMMMyyyy_HHmm.s}
$DesktopPath = ([Environment]::GetFolderPath("Desktop") + '\')
$LogPath = ($DesktopPath + (Get-FileFriendlyDate) + "-UppercaseBackup.xml")

$TargetObjects | select DistinguishedName, PrimarySMTPAddress, EmailAddresses | Export-Clixml $LogPath
Write-Host "A backup XML has been placed here:" $LogPath -ForegroundColor Cyan
Write-Host

$Counter = $TargetObjects.Count

foreach ($RemoteMailbox in $TargetObjects) {

    Write-Host "Setting: " -ForegroundColor DarkCyan -NoNewline
    Write-Host $RemoteMailbox.PrimarySmtpAddress -ForegroundColor Cyan
    Write-Host "Remaining: " -ForegroundColor DarkCyan -NoNewline
    Write-Host $Counter -ForegroundColor Cyan

    Set-RemoteMailbox $RemoteMailbox.Identity -PrimarySmtpAddress ("TMP-Rename-" + $RemoteMailbox.PrimarySmtpAddress) -EmailAddressPolicyEnabled $false
    Set-RemoteMailbox $RemoteMailbox.Identity -EmailAddresses @{remove = $RemoteMailbox.PrimarySmtpAddress}

    Set-RemoteMailbox $RemoteMailbox.Identity -PrimarySmtpAddress $RemoteMailbox.PrimarySmtpAddress.ToLower()
    Set-RemoteMailbox $RemoteMailbox.Identity -EmailAddresses @{remove = ("TMP-Rename-" + $RemoteMailbox.PrimarySmtpAddress)}

    $Counter --
}

Write-Host
Write-Host "Done." -ForegroundColor DarkCyan

#End

 

Combining PowerShell Cmdlet Results

In my last post I used used New-Object to create an desirable output when the “Get-Mailbox” cmdlet didn’t meet my needs.  If your eyes glazed over trying to read the script, let me make it a bit simpler by focusing on a straight forward example.

Say you need to create a list of user’s mailbox size with their email address.  This sounds like a simple request, but what you’d soon find is that mailbox sizes are returned with the Get-MailboxStatistics cmdlet and the email address is not.  For that, you need to use another cmdlet, such as Get-Mailbox.

With the New-Object cmdlet, we are able to make a custom output that contains data from essentially wherever we want.

See this example:

$MyObject = New-Object PSObject -Property @{
EmailAddress = $null
MailboxSize = $null
}

In this example, I have created a new object with 2 fields, and saved it as the $MyObject variable.

For now, we’ve set the data to null, as shown below:

$MyObject

The next step is to populate each of those fields.  We can write to them one at a time with lines like this:

$MyObject.EmailAddress = (Get-Mailbox mcrowley).PrimarySmtpAddress
$MyObject.MailboxSize = (Get-MailboxStatistics mcrowley).TotalItemSize

Note: The variable we want to populate is on the left, with what we want to put in it on the right.

To confirm our results, we can simply type the variable name at the prompt:

$MyObject with data

Pretty cool, huh?

Ok, so now about that list.  My example only shows the data for mcrowley, and you probably need more than just 1 item in your report, right?

For this, you need to use the foreach loop.  You can read more about foreach here, but the actual code for our list is as follows:

(I am actually going to skip the $null attribute step here)

$UserList = Get-mailbox -Resultsize unlimited
$MasterList = @()
foreach ($User in $UserList) {
$MyObject = New-Object PSObject -Property @{
EmailAddress = (Get-Mailbox $User).PrimarySmtpAddress
MailboxSize = (Get-MailboxStatistics $User).TotalItemSize
}
$MasterList += $MyObject
}
$MasterList

$MasterList with data

Finally, if you wanted to make this run faster, we really don’t need to run “get-mailbox” twice.  For better results, replace the line:

EmailAddress = (Get-Mailbox $User).PrimarySmtpAddress

With this one:

EmailAddress = $User.PrimarySmtpAddress

How to Set Windows 7’s Login Wallpaper with Group Policies

With Windows XP, you could set your own login background colors and/or wallpaper by modifying the values found in the following registry location: [HKEY_USERS\.DEFAULT\Control Panel\Desktop].
Windows 7 no longer reads this registry key.  Instead you’ve got to complete the multi-step process described in this article.
Login Background for Windows XP
While the steps to set a login wallpaper are not complicated, one challenging limitation is the fact your background wallpaper needs to reside on the workstation’s hard drive.  Interestingly, this is not true for the user’s wallpaper, as there are GPO settings to point to a network location.
So when I had a customer ask me to set their login wallpaper, I had to think of how I wanted to accomplish their request.  We could possibly write a script, and as much “fun” as that might be, I’d rather use something more controlled.  Something that would allow me to easily change the configuration later as well as be decipherable to the customer after I leave.
The answer?  Group Policy – Preferences, that is!
So before we jump in to the Group Policy Management Console (GPMC), let’s identify what we’re trying to do.  If you haven’t already, you may wish to read the above link, otherwise you’re about to be lost.
We want our policy to:
  1. Copy our wallpaper file to the user’s workstation.
  2. Instruct Windows to use our file instead of the default %WinDir%\System32\oobe\background.bmp file.
With the new (ok they aren’t that new anymore) Group Policy Preferences that Windows 7 has built-in, we can copy our wallpaper to the user’s computer, while reserving the right to pull it off if the computer leaves the scope of the GPO.  To copy files, open GPMC and follow these steps:
1. Navigate to: Computer Configuration\Preferences\Windows Settings\Files clip_image001
2. Right-click the “Files” node and select:

New > File
clip_image002
3. Select Replace

4. Type in the UNC path for your source file.
     •In my example I used:
\\Srv1\Share\CompanyLogo.jpg
     •Remember this file needs to be <256K
     •Also understand the permissions on this share need to allow the workstation’s computer account READ. If you leave the usual “Authenticated Users” you’ll be fine.
5. For the Destination File, type this exact text (without the quotes, and no line breaks):
“%windir%\system32\oobe\info\backgrounds\backgrounddefault.jpg
clip_image003
6. Click the “Common” tab

7. Select “Remove this item when it is no longer applied”. This will ensure your file is removed if:
     •The GPO is deleted or disabled
     •The workstation is moved to another OU where the policy is not linked
     •The policy is filtered out
     •You update your policy to send a new wallpaper file
clip_image004
8. Optionally: Select Item-level targeting to specify only Windows 7 computers. This will ensure your file isn’t sent to versions of Windows that wouldn’t make use of it anyway. clip_image005
Now we need to instruct Windows to render this image when the login screen is displayed.  If you read the above article, you’ll remember the OEMBackground registry key.  The good news is, we don’t need that key because there is actually a setting to enable it in GPMC already.
In the same Group Policy Object, navigate to:
Computer Configuration\Policies\Administrative Templates\System\Logon.
Once there, select “Always use custom logon background” and set it to “Enabled”.  This has the same effect of setting the registry manually.
image
Once you’ve completed these steps, close the Group Policy Management Editor and link your policy to an OU – you’re done!
This policy may take two refresh cycles (e.g. reboots) to take effect.  This is because the wallpaper file is not yet present when the “always use custom logon background” setting is first applied.  But once the file has completed copying you’ll see your image at logon.
If you would like to consider multiple screen resolutions, please consult this link.
Before we close, I should point out, this can work for Server 2008 R2 as well.  I have not tested with Vista or Server 2008.
Finally, here are some geeky, but not too over the top wallpapers:  Smile
Login Background for Windows 7

PowerShell Tip – Running a Service Pack Report – Faster

Imagine you wanted to run a quick report of all your server’s service pack level in your domain.  After all, SP1 just came out!  You could get this information quickly by using the Active Directory Module for Windows PowerShell.  If you don’t have at least one Windows 2008 R2 (RTM or SP1) Domain Controller, you could also do something similar with the free Quest PowerShell tools, but that’s for another day…

We can find this information using a few different methods.  Here I’ll show two:

Method 1

Get-ADComputer -Properties OperatingSystem, OperatingSystemServicePack -Filter * | Where-Object {$_.OperatingSystem -like '*server*'} |  Format-Table name, oper* -autosize

You can see with Method 1, we’re telling PowerShell to get all the computer accounts from Active Directory.  Then we pass those objects over to the “Where-object” cmdlet and ask it to select only those who have an OperatingSystem attribute containing “server”.  We then format the results in a table.  Give it a try.

Not too shabby; but let’s make it better!

Method2

Get-ADComputer -Properties OperatingSystem, OperatingSystemServicePack -Filter {OperatingSystem -like '*server*'} | Format-Table name, oper* -autosize

In Method 2, we’re making smarter use of the –Filter switch.  So instead of getting ALL the computer accounts, we do our filtering up-front.  This can lead to significant amount of time saved!

How much time, you ask?  Well, we can find out with the “Measure-Command” cmdlet.  Just put any command string in {} and it will tell you how long it took to run!

Here are the results from a small environment with fast servers. 677 milliseconds isn’t bad, but when you compare it to 73, you can begin to appreciate the potential.

clip_image001

One last thought:  You may wish to add this extra code to make your output prettier.  It will organize your results first by operating system and then by name:

Get-ADComputer -Properties OperatingSystem, OperatingSystemServicePack -Filter {OperatingSystem -like '*server*'} | Sort-Object operatingsystem, name | Format-Table name, oper* -autosize

Script for Missing UPNs

For various reasons I’ve found myself needing to fix customer sites where the User Principal Name (UPN) was not present for AD user accounts.

image

Most frequently this is because the environment was once NT4, which did not require this attribute.  Whatever the reason, I’ve fixed it using PowerShell.

If you don’t have 2008 R2 domain controllers you can use the free Quest PowerShell add-ins downloaded here.

If you DO have 2008 R2 domain controllers you can use the native Active Directory Module for Windows PowerShell.

Below is a script you can use for either scenario.  This will take all users with missing UPNs from the “My Users” OU in the “contoso.local” domain and set their UPN to username@contoso.local

Quest:

Get-QADUser –SearchRoot “contoso.local/My Users” -UserPrincipalName $null -SizeLimit 0 | % {$CompleteUPN = $_.samaccountname +"@contoso.local"; Set-QADUser -Id $_.DN -UserPrincipalName $CompleteUPN}

2008 R2 Native:

Get-ADUser  -Filter {-not (UserPrincipalName -like '*')} -SearchBase 'OU=My Users,DC=contoso,DC=local' | % {$CompleteUPN = $_.SamAccountName + "@contoso.local" ; Set-ADUser -Identity $_.DistinguishedName -UserPrincipalName $CompleteUPN}

Released: Active Directory Migration Tool (ADMT) version 3.2

The long awaited 2008 R2 version of ADMT has been released to the web.  You can download it here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=20C0DB45-DB16-4D10-99F2-539B7277CCDB&displaylang=en

A good read, if you’re looking at using this tool is:

Active Directory Migration Guide

&

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

However for complex migrations/transitions/whatever I prefer the Quest Migration Manager for Active directory.

Here is some info from the ADMT download page:

The Active Directory Migration Tool version 3.2 (ADMT v3.2) provides an integrated toolset to facilitate migration and restructuring tasks in an Active Directory Domain Services infrastructure.

Overview

The Active Directory Migration Tool version 3.2 (ADMT v3.2) simplifies the process of migrating objects and restructuring tasks in an Active Directory® Domain Service (AD DS) environment. You can use ADMT v3.2 to migrate users, groups, service accounts, and computers between AD DS domains in different forests (inter-forest migration) or between AD DS domains in the same forest (intra-forest migration). ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations.

System Requirements
  • Supported Operating Systems: Windows Server 2008 R2
  • ADMT can be installed on any computer capable of running the Windows Server 2008 R2 operating system, unless they are Read-Only domain controllers or in a Server Core configuration.
  • Target domain: The target domain must be running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2
  • Source domain: The source domain must be running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2
  • The ADMT agent, installed by ADMT on computers in the source domains, can operate on computers running Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.
Additional Information

  • PES v3.1 is a separate download also available on the Microsoft Download Center. See the Related Downloads section below.
  • ADMT v3.2 is the last version of the tool which will support migration operations involving Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 source domains, target domains, or domain controllers.
  • To obtain customer support if you are performing migration operations involving NT 4.0 (with SP4 or higher) or Windows 2000 Server source domains, or domain controllers, please contact your Microsoft Services representative or visit http://www.microsoft.com/microsoftservices.