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:

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.

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:

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:

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

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

Office 365 DirSync (x64) Installation Walkthrough

As Microsoft has already stated, the new 64-bit version of DirSync.exe is not installed or configured differently than its 32-bit predecessor.  However, as a tinkerer, I wanted to verify this and have a look under the hood anyway!

Below are some screenshots of my experiences and insights along the way:

Before you start: Read and follow the instructions!  In this article, I assume you’re at the point where you’re actually ready to install this product.

1. First I installed the .Net Framework prerequisites as well as my favorite MMC snap-ins onto a new Windows 2008 R2 server. You can do this using the following two lines in PowerShell	Import-Module ServerManager Add-WindowsFeature NET-Framework,RSAT-ADDS -Restart
2. Then I ran dirsync.exe (downloaded from the portal.microsoftonline.com site). a. NOTE: Microsoft didn’t bother to change the installer’s executable name (dirsync.exe). This may be confusing if you plan to download and store both x86 and x64 versions.
3. A few clicks of the “Next” button…
a. NOTE: We install to the “Program Files” directory. If this were a x86 application we’d be using “\Program Files (x86)”
b. NOTE: This screen may take 5-10 minutes. It’s installing a few things in the background: i. SQL 2008 R2 Express ii. Forefront Identity Manager 2010 (FIM) iii. Configuration of the FIM Management Agents (MAs)
…
4. Once the background tasks have completed, you’re able to run the Configuration Wizard. This is where you will need to have your Office 365 tenant prepared and credentials identified, etc.
5. Next…
6. You should have created this account earlier. Whatever you put in here will be stored within FIM, and if you ever change the credentials, you’ll need to re-run this setup wizard.
a. Or for the expert user: Dive into FIM directly
7. Here you need to supply your forest’s Enterprise Admin credentials. This username is not saved anywhere, and is only needed once to set permissions for these new objects: a. Yourdomain\MSOL_AD_Sync b. Yourdomain\MSOL_AD_Sync_RichCoexistence
8. Selecting this box enables some extra features required for a “hybrid deployment” / “rich coexistence”, and by doing so you’ll allow FIM to update attributes IN YOUR Active Directory. If this box is not checked, FIM will read-only.
9. Next..
10. If you’re ready, you can run the initial full synchronization now. Otherwise, you can run it manually at any time. a. Once configured, DirSync runs every 3 hours.
11. If you promise to be careful, you can poke around in the FIM configuration. a. Note the “hidden” client UI b. If you get an error when opening the FIM console, log out and then back in. Your account was added to some groups that are not yet part of your login ticket. c. Clicking the Management Agents tab shows both sides of your configuration. “TargetWebService” is responsible for all of the Office 365 configurations and the “SourceAD” management agent contains your Active Directory connector information (double-click them to open). NOTE: Changing the DirSync configuration directly within FIM is unsupported by Microsoft. They would prefer you rerun the previously mentioned Configuration Wizard if you need to make any changes.	C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe
12. Finally, be sure to run Microsoft Update again. You’ll notice that SQL 2008 R2 does not have SP1.

A New Version Of Office 365′s Directory Synchronization Tool Has Arrived!

Most medium and large organizations using Microsoft’s Office 365 service will also be using “DirSync” to provision and manage user identities. Until now, DirSync has been based on ILM 2007 FP1, which is a functional, but older application, with no x64 support. This means when installing DirSync onto a server, you had to go out of your way to deploy the Windows Server 2008 operating system since the Server 2008 R2 OS is x64 only.

ILM was replaced by Forefront Identity Manager (FIM) 2010, which uses the x64 CPU architecture and as therefore Windows Server 2008 R2 as well. 

Today (finally), Microsoft announced DirSync can now be downloaded for use with the 64-bit architecture.  This is great news for new Office 365 customers – no more legacy software needed.  However, this does raise a question for existing DirSync users: How do we migrate?

You should check out the announcement for details, but essentially, you reformat and rebuild.  Wait!  Before you start muttering nasty things about Microsoft – the new installation of DirSync will find all of the identities currently in Office 365 and match them up with the appropriate Active Directory accounts in your environment.  There is no downtime for the users. 

RSAT for Windows 7 with Service Pack 1 (SP1)

Until now, there were no Remote Server Administration Tools (RSAT) available for Windows 7 SP1.

Microsoft released an updated version today which adds this support.  You can download it here:

Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1)

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.

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
2. Right-click the “Files” node and select: New > File
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”
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
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.

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.

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: 

http://www.jpl.nasa.gov/wallpaper

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.

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.