.NET 2.0 hotfix

WRT the .NET 2.0 hotfix I mentioned a few posts ago, there's a new link in the article that will take you to a site where you can download the hotfix (you'll need to sign in with your Windows Live ID)! https://connect.microsoft.com/content/content.aspx?ContentID=3705&wa=wsignin1.0&siteid=210

Another good idea from Microsoft. I do appreciate that they're trying to make getting hotfixes simpler for all of us!

Memory Use High?

Microsoft just released a new .NET 2.0 hotfix that they're recommending be applied to all Exchange 2007 Servers, with an emphasis on applying it to CAS servers quickly. MS KB article 942027 describes the problem. My last post explains how to get hot fixes without calling Microsoft.

Hotfix Request Form

Kudos to Microsoft for releasing a new hotfix request form - it's simple to use, and you should get the hotfix you request within a day from what I've been told. Any time I can avoid picking up the phone to call PSS^H^H^H CSS, I'm a happy camper.

Cross-Forest Mailbox Moves in Powershell

I was recently working on a cross-forest migration from Exchange 2003 to Exchange 2007, and was looking for a way to move the mailboxes across the forests. There didn’t seem to be a single reference that was simple to follow and well explained, so I came up with something that worked for me, and thought it would be useful to share with others. Before you start moving mailboxes willy-nilly, be sure to understand what you’re doing. J Also, for this project, we are using ADMT v3 to migrate user accounts prior to migrating any mailboxes. The idea is that we’ll migrate all of the accounts first and then migrate the mailboxes in one fell swoop – this alleviates the need to worry about long term co-existence scenarios and details such as GAL synchronization.

Preparation information:

The users.csv file contains one sample line to show you what it should look like. Just add the names and OUs of the users that you want to move as shown in the file, save it (I suggest you save these in batches, and change the name of the csv file each time so you can track what has been done - you'll need to change the c:\users.csv reference in the script to reflect the name of the csv file you're referencing).

Users.csv should look like this (it can be more complex and contain more information - this is a simple one that worked for me – you can just use notepad to create the csv file, or Excel if you prefer, but do not that if you use Excel you can only have one worksheet in the file or the csv file won’t open properly for any other applications):

alias,OU
JDoe,domain\users

Put the users.csv file somewhere where it’s easily accessible – I tend to use the root of the c:\ drive, or sometimes c:\temp. You can get wild and create a separate directory to hold the csv file if that suits you.

Once you have your csv file in place (let’s say it’s at c:\users.csv for the purposes of this exercise), open the Exchange Management Shell and type the following:

$creds=get-credential

This command will bring up a dialog box asking for credentials - I used the administrator account because it’s a simple test environment. The account you use will require Exchange Recipient Administrator and Exchange Server Administrator rights in the source forest, and also requires local admin rights on the Exchange Servers in the source forest.

Next is the bulk of the command (major blogger problem alert - apparently the pipe character doesn't show up in posts, which is insanely aggravating. I've used the ^ character in place of the pipe - anyone who doesn't know what a pipe is should read the Unix section of this):

import-csv "c:\users.csv" ^ ForEach-Object -process {move-mailbox -identity $_.alias -TargetDatabase "Mailbox Database" -SourceForestGlobalCatalog ..com -SourceForestCredential $creds -NTAccountOU "CN=Users,DC=,DC=com"}

Note that I have put < > around the items that you will need to customize for your environment – take those out and type in the right things. Also note that the .com may not work in your environment – you may need a .net or a .local or a .somethingelse.

Let me break it down for you:

import-csv "c:\users.csv"

This is referencing the users.csv file I talked about above. It's feeding the information contained in that file into powershell (i.e. the Exchange Management Shell)

^

The above is a (pretend) pipe (darn blogger) - (remember to read the Unix section of this if you don't know what a pipe is or what it looks like) - it says "take the information I just gave you (i.e. the csv file) and do things to it.

Now it gets tricky:

ForEach-Object -process {move-mailbox -identity $_.alias -TargetDatabase "Mailbox Database" -SourceForestGlobalCatalog ..com -SourceForestCredential $creds -NTAccountOU "CN=Users,DC=,DC=com"}

So, for each object named in the csv file, move the mailbox. Breaking that down further:

-identity $_.alias

-identity is used to identify a unique object. The variable $_.alias is found in the csv file - it is the user's alias (JDoe is the alias in the sample csv file). So we're identifying the mailboxes to be moved based upon each alias.

-TargetDatabase "Mailbox Database"

The TargetDatabase is the database to which we're moving the mailboxes. Your target database may be named something other than “Mailbox Database”. Remember to use the quotes if there is a space in the database name.

-SourceForestGlobalCatalog ..com

This tells us that the GC to reference in the source forest is (it can be any GC in the domain - just pick one).

-SourceForestCredential $creds

This references the $creds variable that was created earlier - the administrator account that you typed into the dialog box that popped up early in this exercise.

-NTAccountOU "CN=Users,DC=,DC=com"

This simply tells the script where to look for the user object (or, if the user object doesn't exist, where to create it - because we're migrating the accounts with ADMT first, it is to link the accounts, not to create a new account).

So there you have it - test it first to make sure it will work in your environment - do it at your own risk! (I honestly don't think it's risky, but do pretend there's a disclaimer here similar to the "don't mess with the registry" disclaimer we all love and fear so much.)

Source Port 25?

Recently, I was asked if a new installation of Exchange 2007 could cause a spike in network traffic. I was sent some logs to review (I've hidden the full source IPs and changed the destination IP in a minor way):

The first thing I noticed was that the source port, not the destination port, was 25. SMTP uses port 25 to receive data, but does not use a static port for sending. The second thing I checked was to see what the name of the destination host was -- and it was not an Exchange server (or any other mail server).

I relayed this information back, and the workstation all of the traffic was destined to (192.169.1.1 for our purposes) was found and pulled from the network.

Lesson: Read the whole log.

Put Your Outlook Calendar on Your Desktop

Now this is cool! You can put your calendar on your desktop!

(If my desktop were ever within my view, I'd use it - but I generally have eight or ten programs running and rarely see my actual desktop.)

(Thanks to Jake for the link!)

ADMT, then Move Mailbox

Note:

When migrating to a new Exchange 2007 organization, use ADMT to migrate AD accounts first, then use move mailbox -- native in E2K7 (yay!) -- you do this through the Exchange Management Shell instead of the GUI -- to move the mailboxes from the existing org(s) to the new org.

I'm so happy things can happen this way. Another smooth move from the Exchange Product Group!

The Good News

The good news with Exchange 2007 is that the uninstall process is flawless. Being the dork that I am, I went through and removed all directories (well, moved the directories first, then whacked 'em later) and registry entries and such post-uninstall, but that's really not necessary. You do have to remove the edb and log files manually before reinstalling, but other than that, it's smooth like buttah.

Don't be a dork - CCR clusters

When you're installing a CCR cluster, you need to first cluster Windows, then do a custom install of Exchange, choosing either to install the Active Clustered Mailbox role (first) or the Passive Clustered Mailbox rold (second). Don't install Exchange assuming that you can go back and create a CCR cluster later.

LCR clusters, OTOH, can be created after Exchange has been installed.

Lesson of the day: Always review your docs before installing. Unless you like watching installs.

Outlook Anywhere and Self-Signed Certificates

Exchange Server 2007's Outlook Anywhere (the newly renamed RPC over HTTP(s)) doesn't support the use of self-signed certificates. While I get that this is because they're being security-conscious, it's a pain in the tuckus for my test lab.