Link to home
Start Free TrialLog in
Avatar of dannyboy266
dannyboy266Flag for Afghanistan

asked on

exchange server mailbox replacement

we currently have one cas/hub server and one mailbox server.  both are virtualized.  I need to swap out the existing mailbox server with a new one, but utilize the same database.  is there a way to connect two mailbox servers to the same database then decommision the old one?  our mailbox server is a vmware server and is provisioned with 1.7 TB which is obviously way to large.  we only use 60 gb and I want to provision it for 100gb to allow some growth.  need a fast solution with little risk.

thanks
Avatar of Shawn Constable
Shawn Constable
Flag of United States of America image

If all you really want to do is to "shrink" the disk - just create a new disk, present it to the exchange server, and "move" the database (you can do this from the GUI).  You will have a small amount of downtime while the database copies over, but you are only looking at 60GB so it will be minimal.  The other opeiont you are eluding to are much more involved and in my opinion have significant risk involved for what you are doing.
Avatar of dannyboy266

ASKER

If it were just the mailbox database that would work, but it is the server itself I am trying to replace and resize.  I was thinking I could add a server (essentially having two -non dag.) move the mailbox server role to the new smaller one and remove the old one.
You have a coupple of options since you are on a VM, if you have vmware tools installed you can use Vmware tools to Resize the disk (even to make it smaller).  You can also "Clone" the server (since Its exchange I would recomend shuting it down) and duing the "Clone" you will have the options to resize the disks.
Avatar of asher-is-me
asher-is-me

The URL file association registry entry is probably damaged.  I'd recommend restoring it to defaults by following this guide.  Scroll down to "URL" and run the registry script to fix.  Restart your computer to lock in the changes.
ASKER CERTIFIED SOLUTION
Avatar of Jim Millard
Jim Millard
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
thank you for your help!
what if you dont want to purchase the windows enterrpise license.... those are pretty expensive.
Same solution, but instead of a DAG and zero-downtime migration, you create a new DB on the new host and manually migrate mailboxes from the old server DB to the new server DB. There will be a brief disconnect a the client when the move is completed while OLK rediscovers the correct mailbox server and connects. Migrating public folders is done by creating a new PF DB and enabling replication. Once everything is on the new MBX host, delete DBs and decommission once that's successfully completed. DO NOT presume that public folder replication has copied all data--including system folders used for OLK2003 compatibility--until Exchange permits you to delete the PF DB.
perfect!
You should, however, be able to create a DAG even with Standard. The main limitation of Standard is the live DB count (5 for Standard, 100 for Enterprise)
when I was looking into the licensning, I think the exchange license is ok.  I was thinking the windows license would have to be enterprise.
Windows license doesn't have to be Enterprise unless you NEED an Enterprise feature like Clustering (no), higher core/CPU support (no) or RAM (no).

With a VM, you should be fine. Whatever is supporting your current MBX role should be your choice for the new MBX role. After all, you're decommissioning the old MBX host, so you should be thinking of this as a license transfer rather than a new purchase.
I thought I ready somewhere that the dags used the windows clustering service.  have you heard anything to that affect?
No. DAG is it's own "mailbox availability" system that is completely independent & distinct from clustering. You don't even need clustering to get resilient CAS or HT roles, either. Anyone who tells you that DAGs require clustering doesn't understand DAGs.
that is good to know.  glad it is easier than I thought.