How to Expand a Virtual Disk on the Dell MD3000i

I recently found myself in the position of having to expand a virtual disk on a Dell MD3000i. The Dell MD3000i is a great entry-point SAN, but the GUI lacks some of the functions that you think would be there (such as online volume growth).

The feat, however, can be accomplished. It just requires using the arcane command-line interface.

1. Log into the MDSM GUI and make sure no other operations are currently in progress (disk initialization, rebuild, etc). You can find this information on the Summary tab under Operations in Progress.
2. Note the virtual disk name that you want to expand (such as server_a_vol_1). To see a list of your virtual disks from the GUI, click on the Summary tab and then the Disk Groups & Virtual Disks link.
3. Note the name of the array. You can find this information on gray menu bar above the tabs.
4. Exit the MDSM GUI.
5. Open a command prompt and navigate to the directory where the MD storage software is installed (for the newer versions, the default location is C:\Program Files (x86)\Dell\MD Storage Manager\client on x64 platforms or C:\Program Files\Dell\MD Storage Manager\client on x86 platforms).
6. Run the command:

smcli -n arrayname -c "set virtualDisk [\"virtual disk name\"] addCapacity=n;"

Where:
arrayname is the name of the storage array
virtual disk name is the name of the virtual disk
n is the capacity in bytes to add (to convert GB to bytes, multiply the number in GB by 1073741824)

For example, if you want to add 50GB to the virtual disk server_a_vol_1 on the MD3000i array named production, you would type the following:

smcli -n production -c "set virtualDisk [\"server_a_vol_1\"] addCapacity=53687091200;"

From the Windows side, the LUN will not show up as its new size until the operation is complete. The volume growth process doesn't tack on space to the end of the volume, rather, it appears to move the volume to the end and then append the storage. For newly created volumes with no data, it is much faster to destroy the LUN and recreate it than to go through an online expansion. If the volume has data on it, though, you are left with little option.

Once the operation is complete, you can expand the volume using either the disk management snap-in (diskmgmt.msc) or diskpart.exe.

Outlook 2007 Continuously Prompting for POP3 Credentials

Recently, I had a customer running Outlook 2007 on Windows 7 that experienced a condition I like to refer to as "the dreaded attack of the authentication dialog box." She was connecting to a POP3 server and had the "Save password" box checked, but during every Send/Receive session, would get prompted twice for credentials.

The solution was simple, but elusive.

1. Close Outlook.
2. Open Windows Explorer.
3. Tools > Folder Options > View; click "Show hidden files, folders, and drives."
4. Deselect "Hid protected operating system files (Recommended)" and click OK.
5. Navigate to %USERPROFILE%\AppData\Roaming\Microsoft\Protect.
6. Rename the folder S-1-5-21- to S-1-5-21--old.
7. Rename the file CREDHIST to CREDHIST-old.
8. Restart.
9. Launch Outlook, enter credentials when prompted, and click Save Password.

General Authentication Failed when using IMAP over SSL on Exchange 2010

Ran into an interesting certificate issue with Exchange 2010 and wildcard certificates.

I had installed a wildcard certificate for our domain on an Exchange 2010 server (just like I had previously for Exchange 2007) and enabled the IMAP service (Microsoft Exchange IMAP4 is the Exchange 2010 name of the service). However, when running the Enable-ExchangeCertificate cmdlet, I received an error enabling the wildcard certificate for IMAP services.

I eventually stumbled across this KB Article, Certificates that contain wildcard characters may not work correctly on an Exchange 2007 Service Pack 1-based server. When I ran the Get-ImapSettings cmdlet, I received the following output:

UnencryptedorTLSBindings SSLBindings LoginType X509CertificateName
------------------------ ----------- --------- -------------------
{:::143, 0.0.0.0:143} {:::993, 0.0.0.0:993} SecureLogin myservername

According to the KB, this is due to a problem with the way the cmdlet generates the X.509 certificate name. It can't interpret the wildcard character correctly, so it says that the FQDN of your server is just the NetBIOS name of your server. Oops. Exchange 2007 SP1 Roll-Up 4 is supposed to fix this behavior, but I experienced it on an Exchange 2010 server that was updated to current before deploying the certificate.

After I updated the X.509 Certificate name (using the command Set-ImapSettings -X509CertificateName "myserver.mydomain.com"), I restarted the IMAP service.

To make sure everything was working, I configured an Outlook profile with the IMAP settings of my test mailbox. When I clicked the "Test Connection" button, I was greeted with yet another error:

Log on to incoming mail server (IMAP): General authentication failed. None of the authentication methods supported by your IMAP server (if any) are supported on this computer.

The answer, was, in fact, in the output of the Get-ImapSettings cmdlet that I previously ran. Apparently, it was looking for a secure login method. However, in most SSL-enabled configurations, data is submitted in clear text through the SSL tunnel. To test my theory, I ran the command Set-ImapSettings -LoginType PlainTextlogin and restarted the IMAP service again. In my Outlook client, I clicked the "Test Connection" button again and all was right with the world.