Configuring Backup Exec 2012 to backup to a DataDomain 670 using the OST plugin

DataDomain Configuration

First things first, let’s verify that we have the DD Boost is correctly configured on the DataDomain

1. Log into your DataDomain Appliance and navigate to System Settings – Licenses and verify the correct licenses, it should look like this:
   
   
2. Navigate to Data Management – DD Boost – Settings and verify that DD Boost is enabled, like so:
   
3. Now click on the + sign to add your BackupExec host.  Enter the hostname and click OK
   
4. Next we need to create a DD Boost Storage Unit.  Navigate to Data Management – DD Boost – Storage Units and click Create.  Enter a descriptive name and configure any quotas, if desired.  Click OK
   
5. Now we need to enable an interface for DD Boost.  Navigate to Data Management – DD Boost – IP Network.  Highlight and edit an interface group and tick the “Enabled” check box in the resultant dialogue box and click OK.
   

That takes care of the configuration on the DataDomain side of things.  Let’s move over to Backup Exec

Backup Exec 2012 Configuration

1. Download and install the latest version of the EMC DataDomain Boost for Symantec OpenStorage (Version 2.5.0.3-314845) at the time of writing.  This file is available from the DataDomain support site (Powerlink Login required)
2. Open up the Backup Exec console, select the Storage tab and click Configure Storage
3. The type of storage is OpenStorage
   
4. Enter a name and description for the DataDomain
   
5. Select the DataDomain provider (the DataDomain only shows up once you completed the OST plugin installation as per Step 1)
   
6. Enter the connection details for the your DataDomain device
   
7. Enter the Storage Location configured on the DataDomain (BackupExec in our case)
   
8. Select the amount of concurrent operations allowed to the DataDomain
   
9. Click Finish on the Summary screen and confirm that you would like to restart the Backup Exec services
   

With that completed you’ll be able to select the DataDomain as a deduplication target (as opposed to B2D device).

Rebuilding the Exchange 2010 Offline Address Book (OAB) from scratch

IT peeps supporting Microsoft Exchange can be divided into two groups – those that have experienced problems with the OAB and those that will.  If you’re in the first camp – I feel your pain.  Those of you lucky enough to be in the second camp – file this away, it might come in handy…no I’m not being facetious.
The process below will blow away your OAB and create a new one, so be mindful.  FWIW I’ve never had any issues with this process.  This is especially effective if you’ve screwed up on the public folder replication during Exchange Migrations (don’t ask).
We rebuild the Exchange 2010 OAB like so:

Create a new Offline Address Book object

1. Open the Exchange Management Console (EMC) and navigate to Organisation Configuration – Mailbox
2. Click the Offline Address Book tab.  Right click in the blank area and click New Offline Address Book
3. Give your OAB a different name than the existing one
4. Select your Exchange 2010 MBX server as the OAB generation server
5. Check Include the default Global Address Lists option
6. Check Enable Web-based Distribution as well as the Enable public folder distribution option
7. Finish the wizard

Restart Exchange Services

1. Restart the Microsoft Exchange System Attendant service
2. Restart the Microsoft Exchange File Distribution service

Update and set the OAB as default Offline Address Book

1. Right-click your newly created OAB and click Update.  This can take a couple of minutes, confirm successful completion via your Application log
2. Right-click the OAB from step 1 and and click Set as default

Assign the OAB to the affected users databases

1. Open the Exchange Management Shell (EMS)
2. Execute the following:
   Get-MailboxDatabase |  set-MailboxDatabase  -OfflineAddressBook "%your new OAB%"
3. Wait for Outlook to complete it’s OAB download cycle (can be as much as 24 hours)

You can safely delete the old OAB once you’ve verified that your clients are successfully downloading the newly created one.

Performing a Non-Disruptive Disk and Shelf Firmware upgrade on a NetApp FAS2040

I received a mail from NetApp this morning, pointing my attention to KB ID 7010014.  In a nutshell, there is a drive firmware upgrade available which the lowers the drive failure rates.  AutoSupport has also been nagging me about out of date DS4243 shelf firmware, so I thought this would be a perfect opportunity to upgrade it all in in one go.  It goes without saying that the upgrades must to have zero impact on client access.  The process below was run on Data Ontap Release 8.1 7-Mode.

Update the Disk Qualification Package

1. Download the latest DQP from the NetApp support site
2. Extract the files and copy it to the /etc folder on your filer, overwriting the existing files

Update the Disk Shelf Software

1. Download the appropriate disk shelf software upgrade from the NetApp support site
2. Extract and copy it to the /etc/shelf_fw folder on your filer
3. Run the options shelf.fw.ndu.enable command and verify it is set to on
   • If not, enable it with the options shelf.fw.ndu.enable on command
4. Execute the storage download shelf command to update the shelf firmware and enter yes when prompted

Update the Disk Firmware

1. Download the latest disk firmware from the NetApp support site
2. Verify the following, otherwise you will not be able to do a non-disruptive upgrade
   • Aggregates need to be RAID-DP or mirrored RAID4
   • You need to have functioning spares
3. Run the options raid.background_disk_fw_update.enable command and verify it is set to on
   • If not, enable it with the options raid.background_disk_fw_update.enable on command
4. Extract and copy the disk firmware to the /etc/disk_fw folder on your filer
5. The upgrade should start automatically in a couple of minutes
6. Repeat for both controllers

Verifying the upgrade

Execute the sysconfig –v command to verify successful installation
And there we go, we have non-disruptively upgraded the firmware and disk drives in our filer!

Migrating CIFS Shares to a new NetApp Filer

What better way to kick off the festive season than a with a storage migration (only being slightly ironic!).  A customer uses their existing NetApp kit to provide block storage to vSphere hosts and CIFS shares to Windows clients and they wanted me to do a swap out upgrade.  Migrating the vSphere data is a cinch nowadays, what with Storage vMotion and all, so I’ll just document the CIFS stuff.

1. First you’ll need to setup a SnapMirror relationship of the CIFS volume between the source and destination filers (no faffing around with robocopy and the like)
2. Make a backup copy of the /etc/cifsconfig_shares.cfg file
3. Execute cifs terminate on the source filer (downtime starts here)
4. Update (quiesce if necessary) and break the SnapMirror relationship
5. Take the source filer offline
6. Assign the source filer’s IP to the new filer
7. Reset the source filer’s account in Active Directory (if applicable)
8. Execute cifs setup on the new filer
1. It goes without saying that you will assign the source filer’s hostname to the destination filer, as well as join it to the AD (assuming the source filer was joined)
9. Execute cifs terminate on the destination filer and replace the cifsconfig_shares.cfg with the backup copy you made in step 2
10. Execute cifs restart on the destination filer
11. Test client access