Running the initial configuration wizard [ Edited ]

[#1]

Hi,

I'm running the initial install configuration wizard and there's a part where I need to migrate my LUNS. My question is, the Exchange 2003 DBs are already in their corresponding LUNs on the Filer. Will running that step dismount all my databases? If so, I can't run that during production. Any help is greatly appreciated.

Tom

[#2]

Jeff,

I just tested this in my lab, so results may vary slightly depending upon your environment configuration

In my particular tests with my database and logfiles on the appropriate LUN's, there was no action of dismounting that occurred after running the Configuration Wizard to point it to the same locations as it was originally stored.

You'll also find some references to your questions in the SME Admin guide on pages 145 and 146

You will probably want to make sure you have appropriate downtime/outage arranged if you need to move things other than your Log/DB data

(Examples being, MTA queue path, SMTP queue path, etc) (see page 147 of admin guide)

The best part is you can run the Wizard to get a feel for what changes likely will need to be made, and whether an appropriate outage can be arranged if needed.

Hopefully this addresses what you were looking for Jeff.

[#3]

Hi Jeff.

I wounder if you could help me on a particular behaviour of the Snapmanager for exchange wizard.

I can´t seem to move the MTA because it simply doesn't show up (the "from" pane is blank). We are talking about a two node Exch2003 cluster.

DB's and LOGs are moved without any problem.

One detail: The MTA is sitting on a mount point.

Any thoughts?

Regards,

J. Serra.

[#4]

HI there,

We have an Ask the Expert event happening this week and thought this question would be great to revive & possibly get more informaiton from the expert panel.

Thanks,

Terri

[#5]

SME won't be able to detect it to then move it if it is on a mount point. You could manually move it to a non mount point local disk (then have the SME config wizard move it) or simply move it to your desired shared NetApp LUN.  If you manually move it to your shared NetApp LUN, be sure to run the configuration wizard so that SnapManager for Exchange can update its information.

To manually move the MTA see the following Microsoft guidance:

http://technet.microsoft.com/en-us/library/aa997788(EXCHG.65).aspx

Relocating the MTA Database Directory

Exchange System Manager enables you to move the MTA database directory to another location in the file system (in the server's Protocols container, right-click the X.400 configuration object, click Properties, and then on the General tab, under Message queue directory, click Modify). When you modify the location of the queue directory in Exchange System Manager, you move the database files to the new location, and you change the msExchMTADatabasePath attribute of the MTA directory object to point to the new location. However, the msExchMTADatabasePath attribute is for informational purposes only. More important is the following registry key, which Exchange System Manager also updates.

Location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeMTA\Parameters
Value	MTA database path
Type	REG_SZ
Value Data	C:\Program Files\Exchsrvr\Mtadata
Description	Points to the location of the database files (queue files and message files) for the Exchange MTA. If the path is not valid or points to an empty directory, the MTA cannot start.

You should not place the MTA database directory on a file allocation table (FAT) partition. FAT16 partitions support a maximum of 65,535 files. This size limitation can be an issue on a busy bridgehead server. When a queue starts to fill, available entries with which to create new files can become depleted in only a single day. This problem is compounded because each message requires two .dat files. Moreover, FAT does not perform well on large volumes, provides only minimal fault tolerance, and has no recoverability after an unexpected system halt.

On a busy X.400 bridgehead server running Exchange Server 2003, you can optimize performance by placing the MTA database directory on a high-performance disk subsystem, such as a redundant array of independent disks (RAID). A RAID 0+1 with eight to ten disks is a good starting point for high-volume message transfer. A RAID controller with a cache larger than 64 megabytes (MB) also helps performance.

Note:
Under the MTA database path registry key, you can find a registry key called MTA Run Directory. This registry key points to the directory where the run files for the Exchange MTA are located. It is best to place the database and run directory on different disks.

[#6]

You can migrate _to_ a mount point, but not from one.

Thanks,

Robert

SME 5.0 Admin Guide:

Guidelines for migrating to mountpoints for LUN mapping
You can migrate an existing confguration that uses drive letters to map to Data ONTAP LUNs to a
new confguration that uses volume mountpoints instead. The migration process uses SnapDrive and
SnapManager.
This method briefy takes the affected Storage Groups offine as their paths are changed. You do not
need to copy the databases themselves from one LUN to another. You save time, and Storage Groups
go offine for less time.
Note: A drive letter is used for the mountpoint root volume and not all drive letters are eliminated.
The mountpoint root can be any of the following:
• The local C:\ drive
• The LUN that stores the transaction log fles
• A separate dedicated LUN
The best practice is to use the LUN that stores the transaction log fles. Using a separate LUN as
the mountpoint root adds an additional point of failure to the Exchange server.
Note:  In clustered confgurations, the mountpoint root must reside on a shared storage device
such as the transaction logs LUN.
For confgurations using more than one Storage Group, use one LUN with a drive letter for the transaction
logs of each Storage Group.
Because the System Attendant cluster resources require dependencies on the physical disk cluster
resources in clustered confgurations, the entire Exchange virtual server is brought offine during a
migration even if only a single Storage Group is migrated. Taking the physical disk resource for the
transaction logs offine for one Storage Group takes the System Attendant resource offine and with all
other Storage Groups.