Microsoft Please, Smarter Not Harder

My grandfather always says to work “smarter and not harder” which is 1930’s speak for be more efficient.

Why couldn’t Microsoft have listened to him (and all the other grandpa’s of the world who say the same aphorism)?

I had a user come in the other day with a Windows Mobile HTC Touch Pro 2.  They wanted to hook up to EAS and have all the whiz bang features that my Palm Pre and all the whiz bang features that iPhones are able to have…synchronizing calendar, contacts, and email.  This user is by no means very technical.  They need a way to plug in their email address and server name and have it just work…much in the way that it does for the Palm Pre and iPhone.

The user dropped off the phone to me to handle this for them of course so I entered in all the information and went to connect it.  Promptly, I received the following message:

“your exchange server requires a personal certificate for authorization”

I anticipate this for some phones…on some phones you have to copy across a root certificate in order to have them connect to a SSL enabled CAS from the internet.  This would be my first phone that I’ve run across that didn’t automatically import the certificate.  Now, let me begin by saying this is probably one of the dumbest things I’ve ever heard of before (not automatically importing the certificate) because if you’re connecting to the exchange server and authenticating…you should trust whatever certificate is setup by your administrator automatically.  Locally here on our PC’s in the enterprise, we’ve automatically trusted the certificate from servers we can authenticate with passwords to.

As an example, if Microsoft treated their Domain Controllers in an AD Forest the same way…we’d be getting pop-ups anytime I regenerated a certificate on a DC.  We don’t get those because if a computer is authenticated and the server changes, we don’t want our users getting popups they can’t explain or understand.  We used group policy to silently negotiate the certificate exchange in the background.  We did the same for OWA when it is accessed internally.

But a smart phone running Windows Mobile?  Heck NO!  You have to manually copy the certificate over and import it manually…you’re not given the opportunity to authenticate and import automatically.  Nothing takes place in the background…even if you are ON THE DOMAIN.  The behavior gives you no other alternative.

I thought this would be fine…but it’s not.  There isn’t a way for me to get access to the filesystem of the phone.  I plug it in via USB.  It can’t install it because it can’t find drivers.  I use the software included with the phone and it wants to synchronize locally with Outlook…but the user that is using this phone DOESN’T HAVE OUTLOOK nor do they have their own PC, so why would they want to install software just to be able to get files onto their phone?  Why would I?

In this instance, this phone is locked down…which is fine in a corporate environment.  But this is a personal phone and there is no corporate Windows Mobile plan we have here.  I need it to be as easy as an iPhone.  I need it to be as easy as my Palm Pre.  I need to type in the information and have it connect and start working immediately.  It doesn’t.  Microsoft needs to work smarter and not harder on this.

I wasted 2 hours yesterday trying to get a certificate copied over to the device and I still can’t do it.  I pretty much gave up in frustration and figured I’d file an issue and see what someone can tell me…there comes a point though where security and usability collide in an awesome display of stupidity…and I think this is the case here.

I’m sure everyone is saying “You’re a dummy then!  It’s easy, you just perform action X and they Y and it works!”  and to that I ask that you leave a comment on how you get it working…remember, I can’t copy files to this device…it won’t let me.  So tell me how to get it done without copying files to the device or how to hack the device so I can copy files to it and I’ll agree with you by saying “yes, I am a dummy”.  Documentation on this problem and solution are non-existent…google and live were not my friends on this topic.  So please tell me how wrong I am…I want to be proved wrong and fix this.

In the meantime, please Microsoft, work smarter and NOT harder.  Making things this difficult to do simple things is dumb.  My boss doesn’t care about all the technical details.  She just knows that she took her iPhone in and I had it up and running in about 10 minutes.  And now she knows that one of her directors asked for the same functionality in a Windows Mobile phone and 2 hours later I told him I couldn’t get it to work.  Here it is 2 days later and I still can’t get it to work.  Making it so competitors systems work better on your own product is comparable to shooting yourself in the foot with a canon.

Migration Tip – XML Logs

When migrating from Exchange 2003 to Exchange 2007, I had problems with disk space on one of our network drives.  For the life of me, I couldn’t figure out what the problem was until we had about 100MB left.  Then I realized that every single mailbox move was being logged!  Try running a script that moves hundreds over at a time and then think of the log files!

I ran across a blog post that details just this and what to do about it.  Hopefully you won’t end up like me finding out after the fact!

http://www.telnetport25.com/component/content/article/11-exchmig/320-exchange-2007-tracking-and-analysing-large-mailbox-move-reports-using-the-exchangemovemailboxtaskviewer-tool.html

AllOutlookUsers Distribution List

One of the challenges at the hospital where I work is to duplicate the old mailing lists they’ve had around since Exchange came out.  Through each subsequent version the lists have been passed…and in some cases, they just won’t migrate or update and have to be recreated.

I found this specifically true for the “All Users” dynamic distribution list when migrating to Exchange 2007 from 2003.

Dynamic distribution lists just did not work when moved.  Period.  Luckily, there were only a handful of those in existence in our enterprise.  The most important of course is used daily to get announcements out to everyone.  When we migrated and things didn’t work, a major stick in the spokes of our hospital bike wheel was present.  Weeping and gnashing of teeth ensued.

There are two steps to get this resolved…one takes place on the Exchange front and the other takes place on the Client side of things.  It’s rather difficult on the client side of things because you’ll need to purge data from a cache file locally on each computer if it runs Outlook in cached mode.

First, we’ll go over how to recreate a dynamic distribution list to fit various needs and then we’ll go over what needs to happen client side to make sure the list works properly.

Server Side

On the server side of things, creation of dynamic distribution lists with variables for exclusion or inclusion are much easier using the Exchange Management Shell.  Using the console can be done in smaller environments where you might have mostly standard mailboxes, few contacts, and limited security groups, etc.  In my case however, we have over 50 contacts and around 100 system mailboxes that are not checked regularly for mail.  To limit these boxes from receiving mail, I used the Custom Attributes setting available to each mailbox when right clicking and selecting properties.  Rather than try and exclude by OU (which is possible…but since 2007 switches to OPATH from LDAP…it’s a bit more difficult to master the right query) I elected to exclude by this set attribute.  I’ve outlined the custom attribute button below on the right click properties of a mailbox in the Exchange Management Console.

After setting the customattribute1 to ‘exclude’ I can then create an exclusion rule for the Exchange Management Shell when creating a distribution list.  It could be anything recorded in the custom attribute…it doesn’t necessarily have to be ‘exclude’…it could be ‘hide’ or just an asterisk.  Determine what is best for you and use the shell command below to exclude those with the customattribute1 that you have set.

New-DynamicDistributionGroup -Name "AllOutlookUsers" -Recipientcontainer domain.org -RecipientFilter {((WindowsEmailAddress  -like '*@domain.org') -and -not(CustomAttribute1 -eq "exclude") -and -not(Name -like 'SystemMailbox{*') -and -not(Name -like 'CAS{*') -and (RecipientType -eq "UserMailbox"))}
  • -Recipientcontainer: tells us that the domain.org is the AD container where all users are found.  If yours differs, enclose it in quotes, i.e., “domain.org/users” .  Make sure you change it to your domain and don’t leave it as domain.org.
  • -RecipientFilter: is our criteria for filtering out information in AD.  In our instance above:
    • we match only @domain.org email addresses
    • we exclude system mailboxes
    • we exclude our customattribute1 = exclude
    • we exclude CAS system mailboxes
    • we match only UserMailboxes so that we don’t mail contacts on this list

You could change things up a bit and perhaps add -and -not(department -eq ‘specialString’)) somewhere in which special string might be a department you want to exclude.  For more information, open the exchange shell up and type get-help New-DynamicDistributionGroup | more (the more command appended to the end allows you to read one page at a time…spacebar moves forward a page) for more criteria you can add to the command.

Now that you’ve added in the distribution group, you’ll need to publish it and make it available to the masses.  You can wait until Exchange does this automatically the next maintenance window or you can push it out the the OAB (Offline Addressbook) manually.  In the Exchange Management Console, go to Organization Configuration >> Mailbox >> Offline Address Book tab.  Right click the OAB and choose “update”

Client Side

Here comes the difficult part. There are 2 parts to making this play nicely with clients.

Part 1: The first part is that if you want people to immediately be able to use the new distribution group you just updated, you’ll need them to click on the small arrow beside send/receive:

From there choose “Download Address Book” and select the address book you want to download and click “OK”.  This should be enabled for you but if it is grayed out, it may be prevented by group policy and thus you’ll need to see your group policy manager to re-enable.  When the progress window disappears (if it doesn’t, just click close) that client now has the most recent version of the address book you updated and this should include the new dynamic distribution list you just created.  However, there still can be problems as you’ll see in Part 2.

Part 2: Inside of Outlook, when you create a new email, there is an autocomplete history that is saved.  Inside this .n2k file is cached addresses that you’ve sent to before that will fill in when you begin to type a few letters.  While this saves time and effort…it wreaks havoc with the list you just created.  Why?

In Exchange 2003, I had a dynamic distribution list named “AllOutlookUsers(New)” that everyone used.  When updating to 2007 it was broke.  Now that we’ve created a new dynamic distribution list named “AllOutlookUsers” guess what everyone will choose to mail to?  That’s right, they’ll be getting “AllOutlookUsers(New)” from their Outlook client autocomplete history cache…which will completely bomb if they try to email to it.

How does one fix this?  You can do one of two things.  You can visit each client machine and delete the entry OR you can attempt to use group policy to delete the entire cache the next time they login.  The second option you’ll find many people don’t like because ALL of their autocomplete stuff will be erased.  The first option requires that you visit each individual outlook client…and of course, that’s going to give Administrators a horrible time.

To delete an entry, open up a new email and begin typing “all” in the address To: field.  When the autocomplete selection pops below, use the arrow keys to highlight the old address…in my case “AllOutlookUsers(New)”…and then press the delete key.  You’re done!  That entry has been removed from the autocomplete cache for that individual user.

For those wanting to manage this via group policy, the file is named Outlook.NK2 by default and is located in the %APPDATAA\Microsoft\Outlook folder.  Scripting it wouldn’t be too difficult.  If you’re like me though you have your AllUsers distribution list controlled by a security group so that only a few people can email to it…which means I didn’t have to visit too many desktops to make sure they weren’t using the old address.

Hopefully, this helps a few of you out there to stomp out problems that might pop up when you go to create new dynamic distribution lists after migrating from Exchange 2003 to Exchange 2007.

Moving Mailboxes from Exchange 2003 to Exchange 2007

During a migration from Exchange 2003 to Exchange 2007 many find that having 4 maximum thread transactions happening simultaneously is a bottleneck. Using powershell, one can increase the maximum number above 4 and save time and effort in the process.

During a migration from Exchange 2003 to Exchange 2007 many find that having 4 maximum thread transactions (default in using the Exchange Management Console) happening simultaneously is a bottleneck.  Using powershell, one can increase the maximum number above 4 and save time and effort in the process.

Some things to keep in mind during the migration:

  1. Tons of transaction logs will be generated and won’t be wiped until a backup happens…make sure you have space on your transaction log disks.
  2. Make sure your Mailbox Server has plenty of physical resources available to use during the move…RAM is a specific concern.  Always overshoot your estimates on how much RAM you need.
  3. Error reporting in the shell isn’t as intuitive as you’ll get using the EMC (Exchange Management Console)

My specific environment was moving from a single backend 2003 server to a single 2007 mailbox server.  The cmdlet that is posted can be used to move a mailbox database/storagegroup from one physical server to a another database/storagegroup on a different physical server.  I’ll go through what each section of the cmdlet means.

Get-Mailbox –Database “2003ServerName\StorageGroupName\DatabaseName” | Move-Mailbox –TargetDatabase “2007ServerName\StorageGroup\Database” –MaxThreads 10

The command above should be executed in powershell on your 2007 Mailbox Database Server.  The Get-Mailbox -Database command will tell Exchange where the mailboxes you are moving are coming from.   You then Move-Mailbox to a target database on the 2007 Mailbox Server.  The last portion of the command tells the command to increase the max threads of the command from 4 to 10.  Please make sure that you substitute in the server names, storage group names, and database names appropriately.

Remember that this will only move one database at a time…if you are like me, you like to take small steps in the process and verify that things look good after each small step.  Hopefully, this helps your migration take a little less time.