 Exchange Server Pro (@ExchServPro)3/17/11 5:03 AM How to Import PST Files into Mailboxes with Exchange 2010 SP1 bit.ly/gjrP5t |
Thursday, March 17, 2011
@ExchServPro, 3/17/11 5:03 AM
Tuesday, March 15, 2011
Monday, March 14, 2011
New Home for the Exchange Team Blog
The Exchange team blog was redesigned and moved under the Technet banner.
http://blogs.technet.com/b/exchange/
http://blogs.technet.com/b/exchange/
Sunday, February 6, 2011
How To Move A Storage Group and Database on a CCR Cluster
When I started doing research for this task, I found a lot of conflicting information. It took some time to get all the relevant information together, but the task was completed successfully, so I wanted to take the time to document exactly what I did, in the hopes that it may benefit someone else.
The steps detailed in this article were performed on an Exchange 2007 SP2 (w/ hotfix rollup 4) CCR cluster. My cluster node disks are configured as follows:
C: - System, local drive (RAID1)
D: - Logs, local drive (RAID1)
E: - Applications (Exchange), local drive (RAID1)
H: - Databases 1, SAN drive
I: - Databases 2, SAN drive
J: - Transaction Logs 1, SAN drive
K: - Transaction Logs 2, SAN drive
Our CCR cluster contains 25 databases, spread over the two database drives (H: and I:). In general, for each database on drive H:, its related system and transaction logs are stored on drive J:. For each database on drive I:, its related system and transaction logs are stored on drive K:.
The problem: Over time, the databases on drive H: have grown in size at a faster rate than the databases on drive I:. Although free disk space was not yet an issue, I wanted to take action now, to balance out the disk usage before it became a problem at a more inopportune time. The difference in free space between drives H: and I: was approximately 50 GB. In reviewing the sizes of our databases, I found that the Accounting database, at 22 GB, was the best candidate for the move. This database is in a storage group named "SG Accounting". I should also note that each storage group and database lives in its own subfolder. Therefore, the Accounting storage group lives in the "J:\SG Accounting" subfolder, while the Accounting database lives in "H:\SG Accounting" subfolder.
The first thing I did was suspend the transaction log shipping between the CCR nodes for the SG Accounting storage group:
Suspend-StorageGroupCopy "MailboxServer\SG Accounting"
At this point, the database is still online and active. All we did was suspend log shipping for that storage group. All other storage groups are still replicating normally.
Next, I have to dismount the database, so the files can be moved. This will take the database offline, so be sure to schedule this task in the wee hours of the morning, when no one from Accounting is likely to be using their mailbox.
Dismount-Database "MailboxServer\SG Accounting\Accounting"
Although only the database drives have significant differences in free disk space, since we're moving the database from drive H: to drive I:, we'll also want to move the storage group system and transaction logs from drive J: to drive K:, in order to maintain the logical layout we described earlier.
To move the storage group system and log file paths, we'll use the following command:
Move-StorageGroupPath "MailboxServer\SG Accounting" -LogFolder "K:\SG Accounting" -SystemFolderPath "K:\SG Accounting" -ConfigurationOnly
Red Flag! - The above command only modifies the location of the SystemFolderPath and LogFolder in Active Directory. No files are actually moved on disk. You must manually move the files yourself - on both nodes of the CCR cluster. Personally, I just copy the files to the new location, in case I have to roll back to the old location.
With the storage group files moved, it's time to move the database files. Again, the following command will only modify the location in Active Directory. You will have to move the files yourself.
Move-DatabasePath "MailboxServer\SG Accounting\Accounting" -EdbFilePath "I:\SG Accounting" -ConfigurationOnly
Don't forget to move the database files on both nodes of the cluster.
With the storage group files and the databases in their new locations, all that's left is to mount the database and turn log shipping back on.
Mount-Database "MailboxServer\SG Accounting"
Resume-StorageGroupCopy "MailboxServer\SG Accounting\Accounting"
That's it. You can check on the status of the log shipping with the following command:
Get-StorageGroupCopyStatus
In the output, look for "Healthy" under SummaryCopyStatus, and "0" under CopyQueueLength. Depending on how long the database was offline, it could take a few minutes for log shipping to catch up. On my cluster, copying a 22 GB database, search index files, and another 1 GB of transaction logs, the Accounting database was only offline for about 14 minutes. Since there almost no activity on my system at the time I performed these steps, the databases were back in sync in less than a minute.
The last step was to go back and delete the old database and storage group files. In the end, the database drives on my cluster nodes were within 5 GB of each other, which is less than a 1% difference. I know it won't last long, but I know I won't have to worry about disk space for a little while longer.
Thanks for stopping by!
Mike
The steps detailed in this article were performed on an Exchange 2007 SP2 (w/ hotfix rollup 4) CCR cluster. My cluster node disks are configured as follows:
C: - System, local drive (RAID1)
D: - Logs, local drive (RAID1)
E: - Applications (Exchange), local drive (RAID1)
H: - Databases 1, SAN drive
I: - Databases 2, SAN drive
J: - Transaction Logs 1, SAN drive
K: - Transaction Logs 2, SAN drive
Our CCR cluster contains 25 databases, spread over the two database drives (H: and I:). In general, for each database on drive H:, its related system and transaction logs are stored on drive J:. For each database on drive I:, its related system and transaction logs are stored on drive K:.
The problem: Over time, the databases on drive H: have grown in size at a faster rate than the databases on drive I:. Although free disk space was not yet an issue, I wanted to take action now, to balance out the disk usage before it became a problem at a more inopportune time. The difference in free space between drives H: and I: was approximately 50 GB. In reviewing the sizes of our databases, I found that the Accounting database, at 22 GB, was the best candidate for the move. This database is in a storage group named "SG Accounting". I should also note that each storage group and database lives in its own subfolder. Therefore, the Accounting storage group lives in the "J:\SG Accounting" subfolder, while the Accounting database lives in "H:\SG Accounting" subfolder.
The first thing I did was suspend the transaction log shipping between the CCR nodes for the SG Accounting storage group:
Suspend-StorageGroupCopy "MailboxServer\SG Accounting"
At this point, the database is still online and active. All we did was suspend log shipping for that storage group. All other storage groups are still replicating normally.
Next, I have to dismount the database, so the files can be moved. This will take the database offline, so be sure to schedule this task in the wee hours of the morning, when no one from Accounting is likely to be using their mailbox.
Dismount-Database "MailboxServer\SG Accounting\Accounting"
Although only the database drives have significant differences in free disk space, since we're moving the database from drive H: to drive I:, we'll also want to move the storage group system and transaction logs from drive J: to drive K:, in order to maintain the logical layout we described earlier.
To move the storage group system and log file paths, we'll use the following command:
Move-StorageGroupPath "MailboxServer\SG Accounting" -LogFolder "K:\SG Accounting" -SystemFolderPath "K:\SG Accounting" -ConfigurationOnly
Red Flag! - The above command only modifies the location of the SystemFolderPath and LogFolder in Active Directory. No files are actually moved on disk. You must manually move the files yourself - on both nodes of the CCR cluster. Personally, I just copy the files to the new location, in case I have to roll back to the old location.
With the storage group files moved, it's time to move the database files. Again, the following command will only modify the location in Active Directory. You will have to move the files yourself.
Move-DatabasePath "MailboxServer\SG Accounting\Accounting" -EdbFilePath "I:\SG Accounting" -ConfigurationOnly
Don't forget to move the database files on both nodes of the cluster.
With the storage group files and the databases in their new locations, all that's left is to mount the database and turn log shipping back on.
Mount-Database "MailboxServer\SG Accounting"
Resume-StorageGroupCopy "MailboxServer\SG Accounting\Accounting"
That's it. You can check on the status of the log shipping with the following command:
Get-StorageGroupCopyStatus
In the output, look for "Healthy" under SummaryCopyStatus, and "0" under CopyQueueLength. Depending on how long the database was offline, it could take a few minutes for log shipping to catch up. On my cluster, copying a 22 GB database, search index files, and another 1 GB of transaction logs, the Accounting database was only offline for about 14 minutes. Since there almost no activity on my system at the time I performed these steps, the databases were back in sync in less than a minute.
The last step was to go back and delete the old database and storage group files. In the end, the database drives on my cluster nodes were within 5 GB of each other, which is less than a 1% difference. I know it won't last long, but I know I won't have to worry about disk space for a little while longer.
Thanks for stopping by!
Mike
Monday, July 19, 2010
iPhone Discovery Script
Nice vbscript to parse your OWA logs and find your iPhone users, including versions.
http://gsexdev.blogspot.com/2010/07/exchange-20072010-iphone-activesync.html
Thursday, December 3, 2009
Problem Removing Recovery Storage Group After a Restore
Probably just a minor bug in the Exchange Console GUI (SP1 w/ hotfix rollup 7), but I found myself unable to remove the recovery storage group after a restore. I dismounted the database (which reported a successful completion), but when I attempted to remove the storage group, the console complained that the database must first be dismounted. Switching to the shell, I ran the following command…
Remove-MailboxDatabase -Identity "mailbox-server\recovery storage group\restoreddatabase" -verbose
… which produced the following output:
VERBOSE: Remove-MailboxDatabase : Beginning processing.
VERBOSE: Remove-MailboxDatabase : Administrator Active Directory session settings are: View Entire Forest:
'False', Default Scope: 'mydomain.pvt', Configuration Domain Controller: ‘mydc.mydomain.pvt',
VERBOSE: Remove-MailboxDatabase : Searching objects "mailbox-server\recovery storage group\restoreddatabase" of type
"MailboxDatabase" under the root "$null".
VERBOSE: Remove-MailboxDatabase : Previous operation run on domain controller 'mydc.mydomain.pvt'.
VERBOSE: Remove-MailboxDatabase : Establishing the Admin RPC connection with Server
"mailbox-server.mydomain.pvt".
VERBOSE: Remove-MailboxDatabase : Checking the status of database "mailbox-server\Recovery Storage
Group\restoreddatabase".
Confirm
Are you sure you want to perform this action?
Removing Mailbox Database "mailbox-server\recovery storage group\restoreddatabase".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Pressing enter to accept the default [Y] response yields this:
VERBOSE: Remove-MailboxDatabase : Establishing the Admin RPC connection with Server
"mailbox-server.mydomain.pvt".
VERBOSE: Remove-MailboxDatabase : Checking the status of database "mailbox-server\Recovery Storage Group\restoreddatabase".
VERBOSE: Remove-MailboxDatabase : Taking cluster resource of database "mailbox-server\Recovery Storage Group\restoreddatabase" offline on server "mailbox-server".
VERBOSE: Remove-MailboxDatabase : Checking the status of database "mailbox-server\Recovery Storage Group\restoreddatabase".
VERBOSE: Remove-MailboxDatabase : Searching objects "mailbox-server\Recovery Storage Group" of type "StorageGroup" under the root "$null".
VERBOSE: Remove-MailboxDatabase : Previous operation run on domain controller 'mydc.mydomain.pvt'.
VERBOSE: Remove-MailboxDatabase : Dismounting the database, "mailbox-server\recovery storage group\restoreddatabase".
VERBOSE: Remove-MailboxDatabase : Searching objects "mydomain.pvt/Microsoft Exchange System
Objects/SystemMailbox{021114f7-3b45-464c-bffd-c5c9821aabbb}" of type "ADRecipient" under the root "$null".
VERBOSE: Remove-MailboxDatabase : Previous operation run on domain controller 'mydc.mydomain.pvt'.
VERBOSE: Remove-MailboxDatabase : Deleting "mailbox-server\Recovery Storage Group\restoreddatabase" of type
"MailboxDatabase".
VERBOSE: Remove-MailboxDatabase : Previous operation run on domain controller 'mydc.mydomain.pvt'.
WARNING: The specified database has been removed. You must remove the database file located in H:\MyStorageGroup\RSG20091202084953\restoreddatabase.edb from your computer manually if it exists. Specified database:
restoreddatabase
VERBOSE: Remove-MailboxDatabase : Searching objects of type "MailboxDatabase" with filter "(OriginalDatabase Equal
021114f7-3b45-464c-bffd-c5c9821aabbb)", scope "SubTree" under the root "$null".
VERBOSE: Remove-MailboxDatabase : Previous operation run on domain controller 'mydc.mydomain.pvt'.
VERBOSE: Remove-MailboxDatabase : Updating cluster database resource on server "mailbox-server".
VERBOSE: Remove-MailboxDatabase : Ending processing.
Now the restored database has been both dismounted and removed from Exchange. All that’s left is to go into the file system and delete the files themselves.
To finish cleaning up, we just need to remove the Recovery Storage Group. With the database dismounted and removed, we would be able to do this from the Exchange Console now, but since we already have a shell window open, we’ll just do it from there.
Remove-StorageGroup -Identity "mailbox-server\recovery storage group" -verbose
VERBOSE: Remove-StorageGroup : Beginning processing.
VERBOSE: Remove-StorageGroup : Administrator Active Directory session settings are: View Entire Forest: 'False',
Default Scope: 'mydomain.pvt', Configuration Domain Controller: 'mydc.mydomain.pvt',
VERBOSE: Remove-StorageGroup : Searching objects "mailbox-server\recovery storage group" of type "StorageGroup" under the root "$null".
VERBOSE: Remove-StorageGroup : Previous operation run on domain controller 'mydc.mydomain.pvt'.
Confirm
Are you sure you want to perform this action?
Removing Storage Group "mailbox-server\recovery storage group".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
VERBOSE: Remove-StorageGroup : Deleting "mailbox-server\Recovery Storage Group" of type "StorageGroup".
VERBOSE: Remove-StorageGroup : Previous operation run on domain controller 'mydc.mydomain.pvt'.
WARNING: The specified storage group has been removed. You must remove the log file located in J:\MyStorageGroup\RSG20091202084953 from your computer manually if it exists. Specified storage group: mailbox-server\recovery storage group.
VERBOSE: Remove-StorageGroup : Ending processing.
That’s all there is. Just have to delete the RSG20091202084953 folders under the MyStorageGroup folders on the H: and J: drives to remove the restored database and transaction logs. Then on to the next restore!
Tuesday, December 1, 2009
Exchange TechCenters
Exchange 2010 TechCenter - http://technet.microsoft.com/en-us/exchange/2010/default.aspx
Exchange 2007 TechCenter - http://technet.microsoft.com/en-us/exchange/bb330841.aspx
Exchange 2003 TechCenter - http://technet.microsoft.com/en-us/exchange/bb288525.aspx
Exchange 2007 TechCenter - http://technet.microsoft.com/en-us/exchange/bb330841.aspx
Exchange 2003 TechCenter - http://technet.microsoft.com/en-us/exchange/bb288525.aspx
Subscribe to:
Posts (Atom)