Getting Data Protection Manager agent to work on remote servers

I am now using Microsoft Data Protection Manager 2010 to handle backups of my personal Exchange mail server.  It took a while to figure out how to set this up since I had never used this product before and knew nothing about it until talking to my instructor at a recent Exchange 2010 training class I attended.  I learned a few tricks that may help someone else quickly avoid problems during a deployment of DPM 2010. 

First, DPM server must be a standalone server, it cannot be installed on an Exchange server or a domain controller.  In addition, you should install the AD management tools on the server as without them you will get a cryptic error message telling you that the server cannot communicate with AD and thinks you are in a workgroup or have a mis-configured DNS client. 

Now that you have the DPM Server installed, its time to deploy the agent.  You can deploy the agent to remove computers from a wizard driven interface, however I found that this did NOT work for me at all.  I had to manually install the agent by running the agent installer directly from the C:Program FilesMicrosoft Data Protection ManagerDPMProtectionAgents.  Think you are done…not quite!  Now open a command prompt and navigate to the DPMbin directory.  Execute this command “setdpmserver -dpmservername nameofyourserverhere” and press enter.  for the servername, use the FQDN (i.e. servername.domain.local).  The documentation says to use domainservername, but this DOES NOT WORK. 

One you do the above, you can go into the services control panel and set the DPM server service to automatic and start it.  Now you can go to your DPM server and configure protection groups and add member servers.  Enjoy!

Migrating to Exchange 2010

Last week, I took on the task of migrating my personal home mail system from Exchange 2007 to Exchange 2010.  As usual with Microsoft Exchange, there is no direct upgrade.  A migration is from one system to the other is the main method of accomplishing this task. 

This project was accelerated to the top of my todo list after taking a week long training course at Tech Sherpas on Exchange 2010.  The new high availability features and the added resiliancy of Exchange 2010 sold me on the new flavor of Exchange very early on.  I’m going to go through some of the things I experienced and learned during my migration.  I’ll be going through another migration soon and will append this post with any added information I disciver during a second g0-round. 

It all starts with Active Directory and DNS.  Planning your Active Directory and DNS namespace is critical to having a healthy and resiliant Exchange mail system.  I made a critical error a few years ago when setting up Active Directory in my home office.  I had chosen the AD domain name “home.us” to use internally, since I was not anticipating using any products that would create a conflict when using a public domain name internally.  The problem I had was with SSL certificates.  I wanted to get an SSL certificate that used SANs so that I could access OWA and ActiveSync internally and externally without getting a certificate prompt.  The issues started when I tried to generate a certificate using the home.us domain name, since its a public domain, anytime I tried to add a SAN using that domain, the request would fail.  Since home.us is a public domain, whowever owns it would have received the requests to create a certificate on that domain.  I called the SSL certificate provider I was using and confirmed with them that there is no way around this, I would have to change my internal domain name or not use it at all in my certificate.  So that is where my post about renaming an AD domain comes in.   Once I renamed my AD domain to something clearly internal only, I was able to generate my SSL certificate with all the SANs that I needed. 

Now regarding the actual migration of Exchange 2010, it was a bit tricky.  I ran into problems exporting my mailboxes from Exchange 2007.  I had to install the Exchange management tools on another server and install Outlook and all the prerequisites required to make the export work, which was a huge pain.  I’m seriously hoping that Microsoft one day makes mailbox exports a little easier and require less legwork to make it happen.  I finally got my mailboxes exported and jotted down most of my critical Exchange settings. 

Normally you would just install Exchange 2010 on a new server and migrate your mailboxes and other content over to the new server.  You can then shutdown the old server and you are done.  However, I had the domain rename issue to worry about which cannot be done if Exchange exists in your AD domain.  By removing Exchange completely, I was not doing a migration in a strict sense of the word, but instead a new installation and ended up importing mailboxes and manually restoring settings. 

I installed Exchange 2010 with no problems on my first server.  I then tried to import my mailboxes and ran into problems.  Turns out there is a known issue with Exchange 2010 and importing mailboxes on a single server.  So I setup a second Exchange 2010 temporarily and was then able to try again, this time I found that I could not export the mailboxes because the mailbox server absolutely has to have Outlook 2010 installed on it.  This is completely different from previous versions of Exchange where we are warned not to install Outlook on the Exchange server.  I finally got all the requirements in place and was able to import my mailboxes.  So far so good. 

I had some difficulty getting my Outbound SMTP connector re-configured, but I think that issue was only due to me fat fingering the password or authentication methods.  The next step was to try to take advantage of Enterprise features like DAGs for high availability.  The first issue I ran into here was that Exchange 2010 requires a host operating system of Server 2008 Enterprise edition in order for this to work (since clustering is used in the background).  My second server was only Server 2008 Standard edition, so I had to reload the server using Enterprise edition in order to proceed with my setup.  I finally had both server running the right operating system, same version of Exchange 2010 and ready to go.  Oh, one little caviat is that if you install any of the update rollups for Exchange 2010, you will run into issues when trying to uninstall Exchange 2010.  You get an error saying that a previous version of the product is already installed and it recommends removing the previous version before installing this one.  To get around this, just remove the update rollup and reboot.  Then re-appy the update rollup and then try the uninstall again.  That worekd for me and I was able to do my uninstalls with no further problems, although this took me a few hours to figure out. 

End result of hours of work for most of the day on Saturday was two fully functional Exchange 2010 servers with working mailboxes, incoming and outgoing mail and partially functional SSL certificate.  The Certificate issues were resolved a day or two later once I finally got my certificate straightened out with the provider, I had to re-key it a few times and wait for the e-mail confirmation. 

Now to work on high availability.  I created a Database Availability Group (DAG for short) and ran into some small issues with permissions.  I wanted to use my AD domain controller as my “witness” for the DAG, but I would get errors when trying to create the DAG which I discovered were actually permission errors.  If your witness server is not another Exchange server, you must add the “Exchange Trusted Subsystem” Security group to the local Administrators group of the server you are going to use.  Since in my case this is a domain controller on a private home office system, I just added the group to the Administrators group in AD, which accomplished what I needed to get this to work.  Once that was taken care of, I was able to create a DAG successfully.

Once the DAG is created, I then proceeded to add server members to the DAG, which took longer than I expected, but worked absolutely perfectly.  Once that step is done, you can proceed to add copies of mailbox databases to the DAG.  I added copies of my two databases to the DAG and made one server the first preferred server and made the second server the failover by assigning a preference value of “2”. 

I did some basic tests of the DAG failover and found that it worked perfectly.  I could switch back and forth between servers and it only took a few seconds at most.  During my testing, OWA clients would momentarily get a message saying an item was unavailable if they just happen to be opening a message during the first few seconds after switching servers.  Outlook clients would also only have a momentary issue if a user happened to be opening a message in online mode when the transition of servers is taking place.  For all intents and purposes the switchover of mailbox servers is transparent to the users, which is awesome! 

Another great feature of Exchange 2010 is that you can now move mailboxes between mailbox servers while the users are connected to their mailboxes.  The new “move request” feature allows the move to take place with the mailbox in use and any changes to the mailbox after the move is complete are written to the database to bring it current on the new mailbox server.  Users that are connected via Outlook will get a message saying that changes have been made that require Outlook to be restarted.  Once you restart Outlook, you are connected to your new mailbox server automatically (assuming the old server is still online to allow redirection to occur). 

How about backups?  This is one of my favorite things about the new Exchange 2010 DAGs.  Because you can now have super easy high availability in Exchange 2010, you get the added perk of making backups more efficient.  How?  Simple, backup your secondary DAG member databases.  Assuming you have at least one server in the DAG with a real time copy of the database in question.  By backing up the secondary copy, you reduce mailbox server load, by not running backups on a server users are connecting to.  Because its a real copy of the database, you can do brick level restores and anything else you would normally do in your backup strategy. 

To restore content in Exchange 2010, rely on your deleted items retention period for most of the common short range restore requests.  For anthing greater than that, you can restore a backup of a mailbox or an entire database to an Exchange recovery database.  Then use Exchange management shell cmdlets to recover specific information or the entire mailbox to the production database or mailbox. 

A few other perks that aren’t so loudly advertised about Exchange 2010:}
   1. OWA is now supported fully in other browsers, yes it works in firefox without having major rendering issues or having a requirement to use the “light” version.
   2 OWA now supports conversation views of message threads
   3. Exchange control panel lets administrators and regular users manage many aspects of their DL membership and account info right from their web brwoser.  This includes their mobile device management, contact info, ability to create new DLs, etc.
   4. There is better role based management of feature/security access in Exchange 2010.  You can define custom roles or use the default roles provided by Microsoft.  This is good for large companies who want to separate roles between admins. 
   5. Mailtips are cool!  You can create custom mailtips to be displayed at all times, in addition to the intelligent mailtips displayed by the OOO or calendar conflicts.  Mail Tips are informational messages displayed to the sender of new messages or calendar requests when using Outlook 2010 or OWA.  For example, if you send a user a meeting request, if the user isn’t available due to a calendar conflict, Mail Tips will let you know before you ever send your message and will suggest alternate dates for your meeting based on the user’s availability.  In addition, if a user has the OOO turned on, if you try to send a message to that user, you will get a Mail Tip telling you the user is out of the office and you will get a preview of the first fiew lines of the OOO message the user customized in his auto-reply. 
   6. If you will be using Exchange 2010 high availibility to handle your backups using DAGs and multiple database copies setup for a log reply lag, you can go ahead and set your loging to “circular”.  However, if you will be using another product to backup Exchange, such as Data Protection Manager or Backup Exec, then you will want to keep your logging setup as normal, so that your backups will clear committed logs.  Otherwise you will get warnings in Data Protection Manager specifically, that a synchronization isn’t possible because you are using circular logging and only full copies of the database can be used. 

There is so much more I could mention, but those are probably some of the best parts of Exchange 2010.  For more information I recommend giving the tiral version a try, or download a virtual Hard Drive and see for yourself all of the major improvements in Exchange 2010.  Some of the documentation isn’t very detailed yet, I had a hard time finding step by step instructions, so it seems this is one of those times when a good lab setup for testing is a great idea to get familiar with the caviats of how things work and what is required to get them configured.

My first AD domain rename

I recently had the pleasure of getting to perform my very first Active Directory domain rename.  This situation was the result of some bad planning on my part a few years ago when I first setup Active Directory in my home office, but I’ll talk about that in a separate thread that deals with Exchange 2010.

To do the rename, I was expecting to see the “Rename domain” option in ADUC, but as it turns out its all command line.  So after a few commands of the rendom tool, I was able to rename my AD domain.  I first had to remove Exchange completely, then I was able to perform the rename.   It wasn’t that bad and went rather well.  I did run into a few bumps, such as my DNS server needing a manual re-config, and the connected client machines (desktop and laptop) did not automatically update their DNS suffix.

I wouldn’t recommend doing this unless absolutely necessary, and I very nearly did just start over from scratch, but I wanted to press on and see if I could get everything to work on a renamed domain.  To my delight, it worked and I’ve even got Exchange 2010 running now.  The only thing I would recommend is to re-install Exchange on a server with a different node name than what it had previously.  This caused me all sorts of little issues that I’ll deal with later in a separate post.